Major acquisition programs increasingly rely on software to provide substantial portions of system capabilities. Not surprisingly, therefore, software issues are driving system cost and schedule overruns. All too often, however, software is not even a consideration when the early, most constraining program decisions are made. Through analysis of troubled programs, SEI researchers have identified misalignments between software architecture and system acquisition strategies that lead to program restarts, cancellations, and failures to meet important missions or business goals. To address these misalignments, the SEI is conducting new research on enabling organizations to reduce program failures by harmonizing their acquisition strategy with their software architecture.

This blog posting, the first in a two-part series (Read part two here.) motivates the problem of misalignment and describes the SEI's current research for addressing this problem by analyzing program-specific quality attributes associated with business and mission goals.

A Real Problem with Competing Goals

Complex acquisition programs have diverse sets of stakeholders whose goals and priorities may be misaligned. Operational users, combatant commanders, funding authorities, and acquisition team members often think they have the same priorities, but when interviewed, their answers vary widely in terms of the goals and features they consider most important. In too many cases, solutions are created based on the goals of one set of stakeholders, whose goals often conflict with those of other stakeholders.

For example, an organization we encountered in our independent technical assessments of Department of Defense (DoD) acquisition programs showed how failures stemming from misalignment can occur. This organization was going to rebuild a significant system to replace a critical capability. The program manager gave the requirements to the software architect who returned with an architecture he thought was well-suited to the requirements he received. The architect was baffled when the program manager cited the lack of a database as a problem. The architect had intentionally eliminated the database because it resulted--in his opinion--in a more elegant solution. As it turned out, the program manager had an excellent database group who were dependent on work from this program. Though this was a business goal, it wasn't captured in any of the requirements given to the architect.

In another example, a program with a business goal to reduce the time to field a new system saw reusing an existing software component as a viable approach to provide a significant part of the system's capability. The structure of this component, however, was not consistent with the envisioned architecture for the new system. This program fortunately recognized this mismatch early enough to reconsider their approach, but not all programs are this lucky.

Pedigreed Attribute eLicitation Method (PALM): Our Starting Point

The genesis of our research project came about as the SEI was working with a government organization involved in a major system modernization project. Our prior experience taught us that business and mission goals are key sources of architecturally significant requirements.

We needed a way to identify the requirements that would have the most impact on the software and system architecture to ensure that these requirements were adequately captured, prioritized, and potential conflicts resolved. My former SEI colleagues Len Bass and Paul Clements had recently finished working on the Pedigreed Attribute eLicitation Method (PALM), which provided a good starting point.

PALM enables organizations to systematically identify the high-priority, mission- and business-goals from the stakeholders of a system. The architectural impact of those goals is then captured by determining any quality attribute requirements they imply. For example, if a high-priority goal of an organization was to ensure seamless continuity of operations in the face of regional disasters or cyber attacks, the architectural impact might be to mirror critical information systems in geographically distributed locations so failovers could be performed in real-time.

We used PALM to run an informal pilot with the organization responsible for the system modernization. PALM revealed a number of gaps between the identified program goals and what had been previously thought to be the architecturally-significant requirements. One gap concerned the program's business goal to stay within a yearly fixed budget. The program responded by periodically determining (with the user community) operational requirement priorities and possible deferrals to future releases. On the surface this goal appeared to have little impact on the architecture. On closer inspection, however, the goal had profound impacts on the required flexibility (and modularity) of the architecture to accommodate these changes.

PALM also illustrated conflicts among the goals. If these conflicts were not resolved they would have led to different architectural decisions with different solution implementations. For example, one stakeholder's mission goal was to establish a next generation operational superiority. In contrast, a second stakeholder's business goal was to reduce operational costs by replacing the legacy system (retaining current capability only) as rapidly as possible.

For the program to achieve the first stakeholder's mission goal, it would need a sophisticated, highly scalable architecture leveraging state-of-the-art technologies. For the program to achieve the second stakeholder's mission goal, it would require far less sophistication in the architecture and employ state-of-the-practice technologies with known capabilities and performance characteristics.

To our surprise, these competing goals also drove different acquisition strategies. The goal for operational superiority was supported by an acquisition strategy with an emphasis on architectural and technology prototypes, robust simulations, and continuous integration. The acquisition strategy for the goal to reduce operational costs, conversely, emphasized rapid deployment and tight control of requirements creep.

Beyond PALM

The application of PALM for our modernization project codified many of its requirements and clarified their impact on the architecture. Discovering examples where architecture decisions affected an acquisition strategy was exciting. Although this type of analysis was outside the original scope of PALM, we could see the possibilities of extending it to provide better acquisition support. This insight became the basis for our decision to develop a new systematic analysis method that leveraged PALM to better align acquisition strategy and software architecture approaches with stakeholder needs. The first phase of this research project involved identifying and articulating the relationships among four key aspects:

• business and mission goals
• architectures
• quality attributes
• acquisition strategies

In our research we used an interview-based approach to discover and document patterns of alignment among these aspects or misalignment that tend to pull them apart. Since most of our data comes from troubled programs, to date we have discovered evidence of misalignment or anti-patterns. We are studying these anti-patterns to develop a method that will help programs avoid these misalignments by explicitly identifying and deconflicting mission and business goals through analysis of their qualities attributes that will drive the definition of aligned acquisition strategy and software architecture.

What's Next

The next blog posting in this series will discuss a number of the anti-patterns we have identified, a number of the relationships that are beneficial for alignment, and how we are applying the results of our initial research to extend PALM to enable acquisition programs to better align their mission and business goals.

Additional Resources

Read the second post in this series, Reducing Project Failures by Aligning Acquisition Strategy and Software Architecture with Stakeholder Needs.