Architecture Business Cycle Revisited: A Business Goals Taxonomy to Support Architecture Design and Analysis, The



Len Bass

Paul C. Clements

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: February 1, 2005

Business Goals as Forces

The elicitation of a software-intensive system's business goals is an integral part of standard architecture design and analysis methods. Business goals are the engines that drive the methods, through their realization as scenarios. That is, business goals are forces that shape the architecture. The architecture can be designed to make a system that is, for example, high performance, or easy to modify, or easy to integrate with other systems, or highly reliable, where each of these is presumably supporting a business goal (for example, a system supporting an e-commerce Web site should be high performance, highly reliable, secure and so forth). This architectural "shape" be achieved only when the business goals are translated into scenarios, which can be mapped onto architectural structures that realize the goals.

In the past, despite its crucial importance as the driver of architectural quality, the elicitation of business goals has typically been an unstructured activity. In an attempt to structure this activity, we have created a taxonomy of business goals. The idea of the taxonomy is to facilitate the thinking and to stimulate the creativity of stakeholders, and to ensure proper coverage of all business issues and all the forces that bear on an architecture.

An ideal design method or process must take into account many stakeholders and many forces. These forces transcend the traditional realms of requirements specification, and include business and political issues, legal or contractual issues, life-cycle concerns, the competitive environment of the system, the experience of the architect, and the goals of the developing organization. To our knowledge, no design method attempts to address all of these concerns. There is likely a good reason for this: such a method would probably be unwieldy. However, system stakeholders still face all of these concerns, and so, when choosing a design method, they should be able to choose one that focuses on the concerns that concern them the most. Currently we are attempting to enumerate these forces and to place them into a system-development context.

We have organized the set of forces into the following seven categories as follows:

  1. stakeholder needs
  2. business management issues
  3. legal/contractual issues
  4. commercial/competitive pressures
  5. technical environment
  6. political issues
  7. life-cycle issues

The ABC Revisited

To represent the ways in which a force may affect a design, we have adopted and adapted the Architecture Business Cycle (ABC) [Bass 03]. The ABC was originally envisioned as a means of depicting the influences on an architect and on how an architecture can eventually influence the forces that influenced the architecture, thus creating a cycle. The original influences were the stakeholders and the developing organization (who, together, fashioned the quality-attribute requirements), the technical environment, and the architect’s experience.

In our adaptation of the ABC, the “influences” have been replaced by a set of forces that collectively shape the requirements and, over time, the architect’s experience. The extended ABC is depicted in Figure 1.

 Figure 1: Extending the Architecture Business Cycle to Include All Design Forces

Figure 1: Extending the Architecture Business Cycle to Include All Design Forces

Notice that this extended ABC shows the requirements as being categorized into three overlapping sets: quality-attribute requirements (e.g., the system should initialize itself in 60 seconds), business requirements (e.g., version 1.0 must be available to our resellers by August 1), and functional requirements (e.g., the system must provide monthly sales summaries, broken down by region). These requirements, along with the architect’s experience, are the inputs to the architect and to the architecture-design process.

Capturing a Force

If we are to propose forces that designers and design methods can consider when designing a system, we should be able to describe these forces clearly. Our goal is to answer this question:

What do we need to communicate about a force so that everyone will understand it?

We propose the following scheme:

  1. stimulus source: who brings the force to bear?
  2. stimulus: what is the force?
  3. artifact stimulated: what does the force act on?
  4. environment: when is the force brought to bear (e.g., during development)?
  5. response: what does the stimulus source desire as an outcome?
  6. response measure: how will the stimulus source know when the outcome has been satisfactorily achieved?
  7. importance: how much does the stimulus source care about the outcome? What is its achievement worth, or what would failing to achieve it cost?

For example, we have said that efficient use of staff is a force. How would we capture that?

  1. stimulus source: project manager responsible for development and operations manager responsible for system operation, who want to optimize staffing levels
  2. stimulus: the force is desire to use staff efficiently and minimize new hiring. Staff include designers, developers, maintainers, deployers, operators.
  3. artifact stimulated: development organization
  4. environment: the force is manifested during inception, elaboration, construction, transition, production, retirement
  5. response: the desired outcome is no new hiring
  6. response measure: number of people, level of skill and understanding (Cockburn expert levels), total cost of employment
  7. importance: cost of hiring new people, possible cost of laying off current staff lacking needed skills

This taxonomy of business goals and the template for capturing them are a first step in enriching the architecture design methods being created at the SEI and elsewhere, to make them more capable of capturing all the forces on an architecture and not just the technical ones that have long been our focus.


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

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.

Len Bass is a Senior Member of the Technical Staff at the Software Engineering Institute (SEI) and participates in the High Dependability Computing Program. He has written two award-winning books in software architecture as well as several other books and numerous papers in a wide variety of areas of computer science and software engineering. He is currently working on techniques for the methodical design of software architectures and to understand how to support usability through software architecture. He has been involved in the development of numerous different production or research software systems ranging from operating systems to database management systems to automotive systems.

Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994.

Robert 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.