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. 

An architecture-centric approach delivers critical input at the right time for decision making. 

U.S. Army Acquisition policy calls for several key decision points. Specifically, the policy states, “The review associated with each decision point will typically address program progress, risk, affordability, supportability, program tradeoffs. . . ” [Army 2003]. 

Bergey suggests that ATAM-based evaluations be added at the scheduled decision points in the acquisition life cycle to feed information about what needs to be addressed into those reviews.  

“During an ATAM-based evaluation, the system architect presents the architecture and the architectural approaches taken for each nonfunctional attribute in each scenario,” Gagliardi explains. “ATAM evaluators probe the architecture and pose questions to the architect.” Gagliardi continues. “We search for risks, tradeoffs, and areas that comply with the scenarios. Risks are noted where we see inconsistencies between the approach chosen and the nonfunctional attribute it is intended to support.” 

An architecture-centric approach fosters improved communication. 

An architecture-centric approach gives “maintainers, sustainers, testers, architects, verifiers—all stakeholders—a view they didn’t have,” according to Gagliardi. Through application of the QAW and the ATAM, they “understand how the system is being put together,” he says. 

Even more, they have input into the development of the system about their needs and the non-functional attributes that are important to achieving the business and mission goals, Bergey adds. 

An architecture-centric approach identifies risk themes. 

The ATAM evaluators take the risks identified during question-and-answer sessions on scenarios with the architects and group them into larger risk themes. “We percolate up the risk themes,” Gagliardi says, “because significant risks are likely to cut across scenarios.” 

Risk themes, Gagliardi explains, are not just generalizations, however. Rather they are statements of risk patterns that resonate more readily with key decision makers. “We might have a risk theme such as “the data architecture is not well thought out, or security has not been attended to. The individual, specific risks that inform the theme are also provided,” he says. 

The purpose of the themes, too, is to point to systemic causes of risk that relate to the ability to achieve the business and mission goals and meet the nonfunctional attribute requirements. The program managers can use the risk themes to form overarching mitigation strategies, according to Bergey. 

Continuum of architectural support 

When software-intensive systems fail to perform as expected or exhibit safety or other problems, the warfighters and others who rely on them want to know why.

“Architecture is the underpinning to the system and the place where the causes of those problems can be found,” Gagliardi explains. 

“The SEI advises an architecture-centric approach throughout the life cycle, from the pre-RFP stage through development,” he says. “It’s in this focus on architecture from end to end that problems can be identified before they prove costly and time consuming to fix. Our continuum of architecture support—specification, evaluation, improvement—provides acquirers with a proactive approach that produces the timely information they need.” 

 [Army 2008]
Department of the Army. Army Acquisition Procedures (Pamphlet 70–3). Department of the Army, 2008. http://www.army.mil/usapa/epubs/pdf/p70_3.pdf

[Army 2003]
Department of the Army. Army Acquisition Policy (Pamphlet 70-1). Department of the Army, 2003. http://www.army.mil/usapa/epubs/pdf/r70_1.pdf