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.

FCW in Print

In the latest issue: Looking back on three decades of big stories in federal IT.


  • Anne Rung -- Commerce Department Photo

    Exit interview with Anne Rung

    The government's departing top acquisition official said she leaves behind a solid foundation on which to build more effective and efficient federal IT.

  • Charles Phalen

    Administration appoints first head of NBIB

    The National Background Investigations Bureau announced the appointment of its first director as the agency prepares to take over processing government background checks.

  • Sen. James Lankford (R-Okla.)

    Senator: Rigid hiring process pushes millennials from federal work

    Sen. James Lankford (R-Okla.) said agencies are missing out on younger workers because of the government's rigidity, particularly its protracted hiring process.

  • FCW @ 30 GPS

    FCW @ 30

    Since 1987, FCW has covered it all -- the major contracts, the disruptive technologies, the picayune scandals and the many, many people who make federal IT function. Here's a look back at six of the most significant stories.

  • Shutterstock image.

    A 'minibus' appropriations package could be in the cards

    A short-term funding bill is expected by Sept. 30 to keep the federal government operating through early December, but after that the options get more complicated.

  • Defense Secretary Ash Carter speaks at the TechCrunch Disrupt conference in San Francisco

    DOD launches new tech hub in Austin

    The DOD is opening a new Defense Innovation Unit Experimental office in Austin, Texas, while Congress debates legislation that could defund DIUx.

Reader comments

Fri, Jul 11, 2014

DODAF is fairy dust. Business Architecture does not exist in DoD environment. Operational Activities are not helpful for decision making. DoD enterprise architecture needs to practice more of the traditional EA apporach explain by Mr. Spires. GREAT article. I wish more organizations would adopt this apporach.

Thu, Jul 3, 2014 Buck Kulkarni New Jersey

Richard, Well-written article, thanks. Architecture is missed on all 4 quadrants - business enterprise, business program/project, technology enterprise and technology program/project with lack of time as the most standard justification. We see the consequences every day all around us. Thanks

Thu, Jul 3, 2014

DoD uses the Department of Defense Architecture Framework for this

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group