Digital Intelligence & Forensics
Measurement & Analysis
Performance & Dependability
Process & Performance Improvement
Security & Survivability
U.S. Department of Defense (DoD) program managers care about how well the software-intensive system they are developing will perform for the warfighter. They are not particularly interested in software architecture, at least not as architecture.
But through efforts made by the SEI, they are gaining an understanding that the architecture of the software-intensive systems they are developing significantly determines whether those systems will be reliable, secure, and safe—characteristics known as nonfunctional or quality attributes.
“Architecture is not a set of PowerPoint slides,” says Michael Gagliardi of the SEI. “It’s the bridge between the business goals and the way a system operates. When bottlenecks are seen at integration time or unanticipated system behavior occurs in operation, the root causes for those problems can be found in the architecture.”
“There is benefit to inserting an architecture-centric approach in acquisition,” Gagliardi continues. “The program manager can use leverage in acquisition to require a fully developed architecture that can be evaluated for risks and give early insight into necessary tradeoffs.”
The SEI’s proactive, architecture-centric approach has been tested and proved in several DoD software acquisitions over many years. Those engagements underscore several key lessons about the architecture-centric approach in acquisition and some SEI technologies.
An architecture-centric approach relates mission goals to the achievement of system quality attributes.
The architecture-centric approach begins before there is an architecture. Before a system is let out for bidding by contractors, the SEI can use an approach called a Quality Attribute Workshop (QAW) to capture key information. In a QAW, the SEI “brings together all of the system stakeholders across the life cycle in a facilitated session,” according to John Bergey of the SEI.
“We ask, ‘What are the mission or business drivers? What is your notional architecture?’” Gagliardi says. In the QAW, scenarios or vignettes are used to explicitly capture the system’s business and mission goals and quality attributes.
“We can also prioritize the drivers and attributes,” Gagliardi notes. “This gives an early indication of the kinds of tradeoffs that the system architect will have to deal with. For instance, if high availability is needed, then the system might not be able to provide as high a level of performance.”
An architecture-centric approach makes acquisition more effective.
The U.S. Army acquisition strategy calls for means to “minimize the time and cost it takes, consistent with common sense and sound business practices, to satisfy identified, validated needs, and to maximize affordability throughout a program’s useful life cycle” [Army 2008].
A program manager, Gagliardi says, “focuses on capabilities and functionality, while managing risk to cost and schedule. Architecture embodies the nonfunctional attributes that can affect cost and schedule.”
The SEI uses the term “architecture risks” to denote problems with architecture that hinder a system’s ability to deliver on the nonfunctional attribute requirements. “Letting architecture risks fester is costly,” Gagliardi warns.
As a first step toward finding and mitigating architecture risk, the SEI suggests that the request for proposal (RFP) include language such as the following: “As a software acquisition risk reduction measure, the contractor shall participate in and support a collaborative evaluation of the software architecture that is to be led by an evaluation team commissioned by the program office. The architecture evaluation shall be conducted prior to the preliminary design review (PDR) in accordance with the software architecture evaluation plan.”
A method the SEI employs to evaluate architecture risk is the SEI Architecture Tradeoff Analysis Method (ATAM). Using the ATAM , an impartial evaluation teams works collaboratively with stakeholders to evaluate a software architecture. When performed in the acquisition life cycle, an ATAM exercise reveals issues before they become problems to be addressed during the integration and test phase, when remediation is time consuming and costly.