NEWS AT SEI
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
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:
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.
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.
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:
For example, we have said that efficient use of staff is a force. How would we capture that?
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, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd ed. Boston, MA: Addison-Wesley, 2003.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.