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.

The Fed 100

Read the profiles of all this year's winners.

Featured

  • Then-presidential candidate Donald Trump at a 2016 campaign event. Image: Shutterstock

    'Buy American' order puts procurement in the spotlight

    Some IT contractors are worried that the "buy American" executive order from President Trump could squeeze key innovators out of the market.

  • OMB chief Mick Mulvaney, shown here in as a member of Congress in 2013. (Photo credit Gage Skidmore/Flickr)

    White House taps old policies for new government makeover

    New guidance from OMB advises agencies to use shared services, GWACs and federal schedules for acquisition, and to leverage IT wherever possible in restructuring plans.

  • Shutterstock image (by Everett Historical): aerial of the Pentagon.

    What DOD's next CIO will have to deal with

    It could be months before the Defense Department has a new CIO, and he or she will face a host of organizational and operational challenges from Day One

  • USAF Gen. John Hyten

    General: Cyber Command needs new platform before NSA split

    U.S. Cyber Command should be elevated to a full combatant command as soon as possible, the head of Strategic Command told Congress, but it cannot be separated from the NSA until it has its own cyber platform.

  • Image from Shutterstock.

    DLA goes virtual

    The Defense Logistics Agency is in the midst of an ambitious campaign to eliminate its IT infrastructure and transition to using exclusively shared, hosted and virtual services.

  • Fed 100 logo

    The 2017 Federal 100

    The women and men who make up this year's Fed 100 are proof positive of what one person can make possibile in federal IT. Read on to learn more about each and every winner's accomplishments.

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