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: April 1, 2005
The importance of the right software architecture to a development effort has become widely recognized. This trend is probably not surprising to most readers of this column. Consequently this might be an odd time and place to ask why. Why is software architecture a critical software artifact?
The simple answer is that software architecture is important by definition. That is to say, software architecture was invented to be an artifact
Based on this simple observation, we can state a core principle of software architecture.
Principle 1 alone, however, is not sufficient to reap the potential benefits of software architecture. Principle 1 helps to make the software architecture right. Without understanding, in addition, how to “make the right software architecture,” we fall short.
At the Software Engineering Institute (SEI), we have been working on software architecture-related methods and tools for more than a decade and have considerable experience in applying architecture-based design and analysis methods to real systems from a wide variety of domains. From this experience, we have come to believe that there are two other essential principles for realizing the potential benefits of software architecture:
A software architecture lies at the fulcrum between a system's business (and/or mission) goals and its implementation. Principle 2 states that business goals provide the raison d’être for the system. Business goals naturally lead to quality-attribute goals, which, as stated by Principle 3, provide analytic rationale for an architecture to exhibit one type of design versus another.
Together, these three principles allow us to understand why software architecture is important, what purpose it is intended to fulfill, and whether it fulfills that purpose. These principles have been realized in several of our architecture analysis and design methods: the SAAM [Kazman 94], the QAW [Barbacci 03], the ATAM [Kazman 99], the ADD method [Clements 02], and the CBAM [Kazman 01]. More recently, however, we have begun to explore the techniques that link these methods to the principles mentioned above. This allows us to combine these techniques in new ways and create new methods for particular contexts.
The SAAM, the ATAM, and the CBAM work by explicitly identifying the business goals or context, capturing evaluation criteria by scenarios, choosing among criteria based on active stakeholder participation, and relying on the architect for an explanation of how the architecture satisfies the criteria. These methods are effective at identifying which portion of the architecture to examine to determine whether the criteria are satisfied.
These methods use a number of important common techniques.
These techniques are efficient at helping designers and analysts find the correct location to examine in an architecture to determine whether a scenario can be achieved. But these techniques provide little support for determining what to examine at that location. Most architecture-based methods, ours included, have relied heavily on the expertise of the designers and evaluators when examining the relevant portions of the architecture. Expert opinion has typically been required to determine whether the architectures are satisfactory.
To address this shortcoming, we have recently added two new techniques to the list above:
We are now in the process of creating a follow-on method to the ATAM that combines these techniques in new ways. Stay tuned to subsequent columns for more information.
Bachmann, Felix; Bass, Len; Klein, Mark. Deriving Architectural Tactics: A Step Toward Methodical Architectural Design (CMU/SEI-2003-TR-004). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
Bass, L.; Clements, P.; Kazman, R.; Software Architecture in Practice, 2nd edition, Boston, MA: Addison-Wesley, 2003.
Barbacci, Mario R.; Ellison, Robert; Lattanze, Anthony J.; Stafford, Judith A.; Weinstock, Charles B.; Wood, William G. Quality Attribute Workshops, Third Edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
Clements, P.; Kazman, R.; Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA: Addison-Wesley, 2002.
Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R.; Nord, R.; Stafford, J. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2003.
Kazman, R.; Asundi, J.; Klein, M. “Quantifying the Costs and Benefits of Architectural Decisions,” Proceedings of the 23rd International Conference on Software Engineering (ICSE 23), (Toronto, Canada), May 2001, 297-306.
Kazman, R.; Barbacci, M.; Klein, M.; Carriere, S.; Woods, S. “Experience with Performing Architecture Tradeoff Analysis”, Proceedings of the 21st International Conference on Software Engineering (ICSE 21), (Los Angeles, CA), May 1999, 54-63.
Kazman, R.; Abowd, G.; Bass, L.; & Webb, M. “SAAM: A Method for Analyzing the Properties of Software Architectures,” 81-90. Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, 1994. Los Alamitos, CA: IEEE Computer Society, 1994.
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 production or research software systems ranging from operating systems to database management systems to automotive systems.
Mark Klein is a senior member of the technical staff of the Software Engineering Institute. He has more than 20 years of experience in research on various facets of software engineering, dependable real-time systems and numerical methods. Klein's most recent work focuses on the analysis of software architectures, architecture tradeoff analysis, attribute-driven architectural design and scheduling theory. Klein's work in real-time systems involved the development of rate monotonic analysis (RMA), the extension of the theoretical basis for RMA, and its application to realistic systems. Klein’s earliest work involved research in high-order finite element methods for solving fluid flow equations arising in oil reservoir simulation. He is the co-author of two books: A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems and Evaluating Software Architecture: Methods and Case Studies.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.