CIO Perspective

Program management: The importance of architecture

Shutterstock image.

In this series of columns, I am presenting the five key elements of major IT program success. One key is having a solid business architecture supported by a solid technical architecture.

This column is not meant to dive into the intricacies of enterprise architecture (others can debate the relative merits of the Zachman Framework and The Open Group Architecture Framework) or expand on the Federal Enterprise Architecture model with its six sub-architecture domains.

I plan to address general use of enterprise architecture in future columns, but I want to begin by stressing the importance of having practical, usable architecture processes and artifacts that can support a program's development.

The business architecture describes the overall process of what the proposed system must do to support the desired mission or business outcomes. I am shocked by how often a comprehensive, high-level business architecture is not in place early in a program's life because that absence typically leads to major requirements changes during system development, testing and deployment.

Rarely is a program an island unto itself, so it is also vital that a program-level business architecture be properly integrated into the larger enterprise architecture business view. Understanding the business process and information flows between systems is critical for optimizing outcomes in a complex system-of-systems architecture.

Further, any architecture should include defined performance measures and outcomes that, together with the business architecture, support the overall strategic objectives of the organization. Those performance measures should provide the input required for the metrics ultimately used to gauge program success.

One valuable aspect of a business architecture is the ability to assess priorities for implementing mission or business functionality. There should be an effort to simplify the business processes, to the degree possible, and determine the minimum required capabilities for an initial system launch. That approach can greatly reduce program risk. The program team should develop realistic incremental business functionality release plans for the development life of the program.

All of this detailed planning should be reviewed and approved as a baseline by your program governance board (see my previous column on the importance of program governance).

As the program executes, the plans should be updated to reflect changes in the business architecture and incorporate feedback on past releases to address complexity and development team velocity.

Having a solid technical architecture in place, meanwhile, is also critical -- especially for a complex system with a number of subsystems. I believe in proof-of-concepts and prototyping to assess various options in a technical architecture -- for instance, to support subcomponent designs and even product selection. The ability to conduct such pilot tests, however, should be built into the overall master schedule as a necessary ingredient to program success.

One important but too often overlooked aspect of prototyping is performance load testing. Checking how a system performs under anticipated loads early in the program's development can save a lot of rework later.

If subsystems can be bought or repurposed from other systems that meet requirements, the government ought to do so. Buying rather than building lowers risk substantially. Agencies should use off-the-shelf software components when appropriate, whether they are offered by traditional software vendors or based on open-source technology.

And from a design perspective, the program ought to look at the appropriate leverage and use of application programming interfaces to simplify integration. One of the burgeoning commercial trends is much greater use of APIs to rapidly develop and field functionality.

Finally, program leaders should strive for overall simplicity in the technical architecture. Integrating dozens of off-the-shelf components creates its own set of technical complexities. Simplicity is essential because problems with a technical architecture tend to show up late in the development life cycle, often during integration and end-to-end testing, and they typically result in performance and scalability problems.

Having to recast even small parts of a technical architecture late in the development cycle is very costly and time-consuming and can even doom a program.

About the Author

Richard A. Spires has been in the IT field for more than 30 years, with eight years in federal government service. He served as the lead for the Business Systems Modernization program at the IRS, then served as CIO and deputy commissioner for operations support, before moving to the Department of Homeland Security to serve as CIO of that agency. He is now CEO of Learning Tree.

Featured

  • Defense
    Ryan D. McCarthy being sworn in as Army Secretary Oct. 10, 2019. (Photo credit: Sgt. Dana Clarke/U.S. Army)

    Army wants to spend nearly $1B on cloud, data by 2025

    Army Secretary Ryan McCarthy said lack of funding or a potential delay in the JEDI cloud bid "strikes to the heart of our concern."

  • Congress
    Rep. Jim Langevin (D-R.I.) at the Hack the Capitol conference Sept. 20, 2018

    Jim Langevin's view from the Hill

    As chairman of of the Intelligence and Emerging Threats and Capabilities subcommittee of the House Armed Services Committe and a member of the House Homeland Security Committee, Rhode Island Democrat Jim Langevin is one of the most influential voices on cybersecurity in Congress.

Stay Connected

FCW INSIDER

Sign up for our newsletter.

I agree to this site's Privacy Policy.