Integrating Architecture Methods: The Case of the ATAM and the CBAM



Rick Kazman

Robert Nord

This library item is related to the following area(s) of work:

Software Architecture

This article was originally published in News at SEI on: January 1, 2004

In a previous column (Rethinking the Software Life Cycle), we took a look at the traditional software development life cycle (SDLC) in the context of the architecture-centric methods that we have developed at the Software Engineering Institute over the past 10 years, including the Architecture Tradeoff Analysis Method, or ATAM, which helps a system’s stakeholders understand the consequences of architectural decisions with respect to the system’s quality-attribute requirements [1, 2].

The common wisdom is that the earlier in the SDLC that problems are found, the easier and cheaper it is to fix them. The problems that can be found by an architecture evaluation include unreasonable requirements, performance problems, problems associated with potential future modifications, and many others related to quality attributes. As we have gained experience from conducting ATAM-based architecture evaluation exercises, we have found the need to develop methods that extend even earlier into the SDLC. In this way, rather than simply reporting on problems following an architecture evaluation, we can anticipate these problems at requirements or design time. The Quality Attribute Workshop, or QAW, provides a method for eliciting quality attribute requirements [3]. The Attribute-Driven Design, or ADD, method provides a way of defining a software architecture by basing the design process on the quality-attribute requirements of the system [4].

Looking at later stages of the SDLC, the Cost Benefit Analysis Method, or CBAM, is a method for performing architecture-based economic analyses of software-intensive systems [1, 5]. The CBAM can be used to help the system’s stakeholders choose architectural alternatives during the design phase, but it can also be used to determine what architecture choices to make in enhancing the system, during the maintenance phase of the SDLC.

Although these methods share a common heritage and a common set of concepts and activities, they have not thus far been explicitly integrated with each other or integrated into common life-cycle models, such as the Rational Unified Process, or RUP [6]. Integration of this kind is essential if organizations are to reap the benefits of adopting an architecture-centric approach to software development. We call this integration “architecture-centric development,” as shown in the list below..

Architecture-centric development involves iteratively

  • creating the business case for the system
  • understanding the 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

We have already made some progress toward integrating architecture-based methods into the SDLC. For example, some organizations have applied more than one architecture-based method at different life-cycle stages—the ATAM followed by the CBAM, or the QAW followed by the ATAM, or the ADD followed by the ATAM. But the full benefits of this integration have not been realized.

For example, in our interactions with NASA’s EOSDIS project over several years, we integrated the ATAM and CBAM activities. (EODIS is the Earth Observing System Data and Information System, whose purpose is to acquire, archive, manage and distribute Earth observation data to a diverse group of users.) The results of applying the ATAM and the CBAM to the EOSDIS project have been documented, but each method is described separately [1, 7, 5]. The integration was piecemeal and opportunistic, rather than planned and organic.

Representations of the inputs, outputs, and participants of the ATAM and the CBAM are shown in Figure 1 and Figure 2.

Figure 2: ATAM Inputs, Outputs, and Participants

Figure 1: ATAM Inputs, Outputs, and Participants

Figure 2: CBAM Inputs, Outputs, and Participants

Figure 2: CBAM Inputs, Outputs, and Participants

A cursory observation shows that the two methods align well—many of the inputs, outputs, and stakeholders are aligned. But there are differences in the methods that prevent them from being simple to integrate.

In a forthcoming technical note [8] we address this by focusing on enhancements to the ATAM and the CBAM specifically designed for their integration within an SDLC process. The aim is to create a combined method that will help organizations design and manage the evolution of complex software-intensive systems by making a series of informed architecture-design decisions based on business factors.

The integrated ATAM/CBAM evaluates the software architecture and prepares for the next design iteration by considering new business goals and requirements. A CBAM exercise provides a natural follow-up to an ATAM exercise for those wanting an integrated process that provides more informed results. This combined approach provides an integrated method for both technical and economic analysis of a software architecture and offers the following benefits:

  • The integrated method optimizes the process. The results from the ATAM exercise can be used in the CBAM exercise and don’t have to be duplicated. Several CBAM steps can be shortened or eliminated, saving time and requiring fewer meetings for stakeholders.
  • The integrated method improves the quality of the results. The combined method is more capable and makes better use of the stakeholders’ time than either method applied independently.
  • The integrated method provides more guidance in eliciting artifacts. The integrated method more clearly differentiates the analysis of existing architecture versus development and analysis of new architectural approaches. It makes explicit the documentation needed to record new architectural decisions.

Clearly integration of architecture-centric methods with each other and with existing life-cycle models is the way of the future. Organizations cannot afford to develop an architecture that is less than technically capable, nor can they afford to make ill-advised or ill-timed economic decisions. Organizations need guidance in allocating their limited budgets for designing, implementing, maintaining, and augmenting a system over its lifetime. A combined ATAM/CBAM does just that, and does so better than either method could do on its own.


[1] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd ed., Boston, MA: Addison-Wesley, 2003.

[2] Kazman, R.; Klein, M.; & Clements, P. ATAM: Method for Architecture Evaluation(CMU/SEI-2000-TR-004, ADA382629). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000.

[3] Barbacci, M.; Ellison, R.; Lattanze, A.; Stafford, J.; Weinstock, C.; Wood, W. Quality Attribute Workshops (QAWs), 3rd ed. (CMU/SEI-2003-TR-016), 2003.

[4] Bachmann, F.; Bass, L.; Chastek, G.; Donohoe, P.; & Peruzzi, F. The Architecture Based Design Method (CMU/SEI-2000-TR-001, ADA375851). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000.

[5] Kazman, R. Asundi, J. & Klein, M. Making Architecture Design Decisions: An Economic Approach (CMU/SEI-2002-TR-035). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.

[6] Kruchten, P. The Rational Unified Process: An Introduction, 3rd ed., Boston, MA: Addison-Wesley, 2003.

[7] Clements, P.; Kazman, R.; & Klein, M. Evaluating Software Architectures: Methods and Case Studies, Boston, MA: Addison-Wesley, 2002.

[8] Nord, R.; Barbacci, M.; Clements, P.; Kazman, R.; Klein, M.; O’Brien, L.; & Tomayko, J. Integrating the Architecture Tradeoff Analysis Method with the Cost Benefit Analysis Method (CMU/SEI-2003-TN-038) Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2004.

About the Authors

Rick Kazman is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He is also an adjunct professor at the Universities of Waterloo and Toronto. His primary research interests within software engineering are software architecture, design tools, and software visualization. He is the author of more than 50 papers and co-author of several books, including a book recently published by Addison-Wesley titled Software Architecture in Practice. Kazman received a BA and MMath from the University of Waterloo, an MA from York University, and a PhD from Carnegie Mellon University.

Robert L. Nord is a senior member of the technical staff in the Product Line Systems Program at the Software Engineering Institute (SEI) where he works to develop and communicate effective methods and practices for software architecture. Prior to joining the SEI, he was a member of the software architecture program at Siemens, where he balanced research in software architecture with work in designing and evaluating large-scale systems. He earned a Ph.D. in Computer Science from Carnegie Mellon University. Dr. Nord lectures on architecture-centric approaches. He is co-author of Applied Software Architecture and Documenting Software Architectures: Views and Beyond.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.