Program management: The importance of architecture

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.