Acquisition and Software Architectures

A major responsibility of DoD acquisition programs is to perform technical oversight and technical monitoring of the systems it acquires during the contract performance phase. Although these system acquisitions are highly software intensive, software considerations often take a back seat to system considerations due to:

• limited resources of the acquisition organization
• policies that emphasize a systems acquisition and system engineering focus
• software reviews that are often reactive or perfunctory in nature
• a lack of proven methods for evaluating software qualities early in the early software development cycle

Since the quality and longevity of a software intensive system is largely determined by its architecture, there is a growing recognition that the DoD acquisition community can realize significant benefits by adopting an architecture-centric software acquisition approach. Architecture-centric development involves iteratively

• understanding the mission drivers and creating the business case for the system
• understanding the stakeholder requirements
• creating or selecting the software architecture
• documenting and communicating the software architecture
• analyzing or evaluating the software architecture
• implementing the system based on the software architecture
• ensuring that the implementation conforms to the software architecture

The importance of focusing on the software architecture is that it embodies the earliest set of design decisions about a system. These design decisions:

• are the most profound
• are the hardest to get right
• are most difficult to change
• drive the entire software development effort
• are most costly to fix downstream
• are critical to achieving mission/business goals

Software architectures that are poorly designed result in greatly inflated development and integration and testing costs and an inability to sustain systems in a timely and affordable manner. As a result, the earlier the acquisition organization can evaluate the architecture as to its ability to achieve the desired system qualities (e.g., performance, security, availability, interoperability, modifiability, openness, and so forth) the better.

To support the DoD, the SEI has collaborated with DoD acquisition organizations and their contractors in transitioning and applying some of the architecture-centric techniques and methods developed under the Software Architecture Technology (SAT) Initiative in actual systems acquisitions. The overarching goal is to reduce software acquisition risk.

A number of the architecture-based collaborations have been documented in technical reports (TRs) and technical notes (TNs) that are relevant to or address some aspect of promoting an architecture-centric software development approach in an acquisition context. These technical reports and technical notes are divided into six categories as listed below.

Case studies

• Paul Clements, John Bergey, Dave Mason, Using the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study (CMU/SEI-2005-TN-027).
• Paul Clements, John Bergey, The U.S. Army's Common Avionics Architecture System (CAAS) Product Line: A Case Study (CMU/SEI-2005-TR-019).
• Mario Barbacci, Paul Clements, Anthony Lattanze, Linda Northrop, William Wood, Using the Architecture Tradeoff Analysis Method^SM (ATAM^SM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study (CMU/SEI-2003-TN-012).
• Brian Gallagher, Using the Architecture Tradeoff Analysis MethodSM to Evaluate a Reference Architecture: A Case Study (CMU/SEI-2000-TN-007).

Architecture focused standards

• William G. Wood, Sholom Cohen, DoD Experience with the C4ISR Architecture Framework (CMU/SEI-2003-TN-027).
• William G. Wood, Mario Barbacci, Paul Clements, Steve Palmquist, Huei-Wan Ang, Loring Bernhardt, Fatma Dandashi, David Emery, Sarah Sheard, Lyn Uzzle, John Weiler, Art Krummenoehl, DoD Architecture Framework and Software Architecture Workshop Report (CMU/SEI-2003-TN-006).
• M. Barbacci, W. Wood, Architecture Tradeoff Analyses of C4ISR Products (CMU/SEI-99-TR-014).

Architecture evaluation in an acquisition context

• Len Bass, Robert Nord, William Wood, David Zubrow, Risk Themes Discovered Through Architecture Evaluations (CMU/SEI-2006-TR-012).
• Paul Clements, John Bergey, Dave Mason, Using the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study (CMU/SEI-2005-TN-027).
• Mario Barbacci, Paul Clements, Anthony Lattanze, Linda Northrop, William Wood, Using the Architecture Tradeoff Analysis Method^SM (ATAM^SM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study (CMU/SEI-2003-TN-012).
• John K. Bergey, Matthew J. Fisher, Lawrence G. Jones, Use of the Architecture Tradeoff Analysis Method (ATAM) in Source Selection of Software-Intensive Systems (CMU/SEI-2002-TN-010).
• Lawrence G. Jones, Anthony J. Lattanze, Using the Architecture Tradeoff Analysis Method to Evaluate a Wargame Simulation System: A Case Study (CMU/SEI-2001-TN-022).
• John K. Bergey, Matthew J. Fisher, Use of the Architecture Tradeoff Analysis Method^SM (ATAM^SM) in the Acquisition of Software-Intensive Systems (CMU/SEI-2001-TN-009).
• Brian Gallagher, Using the Architecture Tradeoff Analysis MethodSM to Evaluate a Reference Architecture: A Case Study (CMU/SEI-2000-TN-007).
• John K. Bergey, Matthew J. Fisher, Lawrence G. Jones, Rick Kazman, Software Architecture Evaluation with ATAM in the DoD System Acquisition Context (CMU/SEI-99-TN-012).

Architecture training

• Stephen Blanchette Jr., John Bergey, Progress Toward an Organic Software Architecture Capability in the U.S. Army (CMU/SEI-2007-TR-010).

Architecture related documentation

• Len Bass, John Bergey, Paul Clements, Paulo Merson, Ipek Ozkaya, Raghvinder Sangwan, A Comparison of Requirements Specification Methods from a Software Architecture Perspective (CMU/SEI-2006-TR-013).
• John K. Bergey, Paul C. Clements, Software Architecture in DoD Acquisition: A Reference Standard for a Software Architecture Document (CMU/SEI-2005-TN-020).
• John K. Bergey, Paul C. Clements, Software Architecture in DoD Acquisition: An Approach and Language for a Software Development Plan (CMU/SEI-2005-TN-019)

Other architecture related applications

• Gary Chastek, Lisa Brownsword, A Case Study in Structural Modeling (CMU/SEI-96-TR-035).
• Gregory Abowd, Len Bass, Larry Howard, Linda Northrop, Structural Modeling: An Application Framework and Development Process for Flight Simulators (CMU/SEI-93-TR-014).

Additional Information

Contact Information: For more information about acquisition and software architectures, contact John Bergey.

Working with the SEI: Learn more about working with the SEI in software architecture.