Online Sample Chapter
Evaluating a Software Architecture
Downloadable Sample Chapter
Click below for Sample Chapter related to this title:
clementsch02.pdf
Table of Contents
List of Figures.
List of Tables.
Preface.
Acknowledgments.
Reader's Guide.
1. What Is Software Architecture?
Architecture as a Vehicle for Communication among Stakeholders.
Architecture and Its Effects on Stakeholders.
Architectural Views.
Architecture Description Languages.
Architecture as the Manifestation of the Earliest Design Decisions.
Architectural Styles.
Architecture as a Reusable, Transferable Abstraction of a System.
Summary.
For Further Reading.
Discussion Questions.
2. Evaluating a Software Architecture. Why Evaluate an Architecture?
When Can an Architecture Be Evaluated?
Who's Involved?
What Result Does an Architecture Evaluation Produce?
For What Qualities Can We Evaluate an Architecture?
Why Are Quality Attributes Too Vague for Analysis?
What Are the Outputs of an Architecture Evaluation?
Outputs from the ATAM, the SAAM, and ARID.
Outputs Only from the ATAM.
What Are the Benefits and Costs of Performing an Architecture Evaluation?
For Further Reading.
Discussion Questions.
3. The ATAM—A Method for Architecture Evaluation. Summary of the ATAM Steps.
Detailed Description of the ATAM Steps.
Step 1: Present the ATAM.
Step 2: Present the Business Drivers.
Step 3: Present the Architecture.
Step 4: Identify the Architectural Approaches.
Step 5: Generate the Quality Attribute Utility Tree.
Step 6: Analyze the Architectural Approaches.
Step 7: Brainstorm and Prioritize Scenarios.
Step 8: Analyze the Architectural Approaches.
Step 9: Present the Results.
The Phases of the ATAM.
Phase 0 Activities.
Phase 1 Activities.
Phase 2 Activities.
Phase 3 Activities.
For Further Reading.
Discussion Questions.
4. The Battlefield Control System—The First Case Study in Applying the ATAM. Preparation.
Phase 1.
Step 1: Present the ATAM.
Step 2: Present the Business Drivers.
Step 3: Present the Architecture.
Step 4: Identify the Architectural Approaches.
Step 5: Generate the Quality Attribute Utility Tree.
Step 6: Analyze the Architectural Approaches.
Phase 2.
Step 7: Brainstorm and Prioritize Scenarios.
Step 8: Analyze the Architectural Approaches.
Step 9: Present the Results.
Results of the BCS Evaluation.
Documentation.
Requirements.
Sensitivities and Tradeoffs.
Architectural Risks.
Summary.
Discussion Questions.
5. Understanding Quality Attributes. Quality Attribute Characterizations.
Performance.
Availability.
Modifiability.
Characterizations Inspire Questions.
Using Quality Attribute Characterizations in the ATAM.
Attribute-Based Architectural Styles.
Summary.
For Further Reading.
Discussion Questions.
6. A Case Study in Applying the ATAM. Background.
Phase 0: Partnership and Preparation.
Phase 0, Step 1: Present the ATAM.
Phase 0, Step 2: Describe Candidate System.
Phase 0, Step 3: Make a Go/No-Go Decision.
Phase 0, Step 4: Negotiate the Statement of Work.
Phase 0, Step 5: Form the Core Evaluation Team.
Phase 0, Step 6: Hold Evaluation Team Kick-off Meeting.
Phase 0, Step 7: Prepare for Phase 1.
Phase 0, Step 8: Review the Architecture.
Phase 1: Initial Evaluation.
Phase 1, Step 1: Present the ATAM.
Phase 1, Step 2: Present Business Drivers.
Phase 1, Step 3: Present the Architecture.
Phase 1, Step 4: Identify Architectural Approaches.
Phase 1, Step 5: Generate Quality Attribute Utility Tree.
Phase 1, Step 6: Analyze the Architectural Approaches.
Hiatus between Phase 1 and Phase 2.
Phase 2: Complete Evaluation.
Phase 2, Step 0: Prepare for Phase 2.
Phase 2, Steps 1-6.
Phase 2, Step 7: Brainstorm and Prioritize Scenarios.
Phase 2, Step 8: Analyze Architectural Approaches.
Phase 2, Step 9: Present Results.
Phase 3: Follow-Up.
Phase 3, Step 1: Produce the Final Report.
Phase 3, Step 2: Hold the Postmortem Meeting.
Phase 3, Step 3: Build Portfolio and Update Artifact Repositories.
For Further Reading.
Discussion Questions.
7. Using the SAAM to Evaluate an Example Architecture. Overview of the SAAM.
Inputs to a SAAM Evaluation.
Outputs from a SAAM Evaluation.
Steps of a SAAM Evaluation.
Step 1: Develop Scenarios.
Step 2: Describe the Architecture(s).
Step 3: Classify and Prioritize the Scenarios.
Step 4: Individually Evaluate Indirect Scenarios.
Step 5: Assess Scenario Interactions.
Step 6: Create the Overall Evaluation.
A Sample SAAM Agenda.
A SAAM Case Study.
ATAT System Overview.
Step 1: Develop Scenarios, First Iteration.
Step 2: Describe the Architecture(s), First Iteration.
Step 1: Develop Scenarios, Second Iteration.
Step 2: Describe the Architecture(s), Second Iteration.
Step 3: Classify and Prioritize the Scenarios.
Step 4: Individually Evaluate Indirect Scenarios.
Step 5: Assess Scenario Interactions.
Step 6: Create the Overall Evaluation—Results and Recommendations.
Summary.
For Further Reading.
Discussion Questions.
8. ARID—An Evaluation Method for Partial Architectures. Active Design Reviews.
ARID: An ADR/ATAM Hybrid.
The Steps of ARID.
Phase 1: Rehearsal.
Phase 2: Review.
A Case Study in Applying ARID.
Carrying Out the Steps.
Results of the Exercise.
Summary.
For Further Reading.
Discussion Questions.
9. Comparing Software Architecture Evaluation Methods. Questioning Techniques.
Questionnaires and Checklists.
Scenarios and Scenario-Based Methods.
Measuring Techniques.
Metrics.
Simulations, Prototypes, and Experiments.
Rate-Monotonic Analysis.
Automated Tools and Architecture Description Languages.
Hybrid Techniques.
Software Performance Engineering.
The ATAM.
Summary.
For Further Reading.
Discussion Questions.
10. Growing an Architecture Evaluation Capability in Your Organization. Building Organizational Buy-in.
Growing a Pool of Evaluators.
Establishing a Corporate Memory.
Cost and Benefit Data.
Method Guidance.
Reusable Artifacts.
Summary.
Discussion Questions.
11. Conclusions. You Are Now Ready!
What Methods Have You Seen?
Why Evaluate Architectures?
Why Does the ATAM Work?
A Parting Message.
Appendix A: An Example Attribute-Based Architectural Style. Problem Description.
Stimulus/Response.
Architectural Style.
Analysis.
Reasoning.
Priority Assignment.
Priority Inversion.
Blocking Time.
For Further Reading.
References. Index. 020170482XT10082001
Preface
The foundation of any software system is its architecture, that is, the way the software is constructed from separately developed components and the ways in which those components interact and relate to each other. If the system is going to be built by more than one person—and these days, what system isn't?—it is the architecture that lets them communicate and negotiate work assignments. If the requirements include goals for performance, security, reliability, or maintainability, then architecture is the design artifact that first expresses how the system will be built to achieve those goals. The architecture determines the structure of the development project. It is the basis for organizing the documentation. It is the first document given to new project members, and the first place a maintenance organization begins its work. Schedules, budgets, and workplans all revolve around it. And the senior, most talented designers are paid to create it.
A system's longevity—how viable it remains in the face of evolutionary pressure—is determined primarily by its architecture. Some architectures go on to become generic and adopted by the development community at large: three-tier client-server, layered, and pipe-and-filter architectures are well known beyond the scope of any single system. Today, organizations are recognizing the importance and value of architectures in helping them to meet corporate enterprise goals. An architecture can give an enterprise a competitive advantage and can be banked like any other capitalized asset.
The right architecture is the first step to success. The wrong architecture will lead to calamity. This leads to an important question: If your organization is betting its future—or at least a portion of it—on an architecture for a system or family of related systems, how can you be sure that you're building from the right architecture and not the wrong one?
The practice of creating an architecture is maturing. We can identify causal connections between design decisions made in the architecture and the qualities and properties that result downstream in the system or systems that follow from it. This means that it is possible to evaluate an architecture, to analyze architectural decisions, in the context of the goals and requirements that are levied on systems that will be built from it.
And yet even though architecture is regarded as an essential part of modern system development, architecture evaluation is almost never included as a standard part of any development process. We believe it should be, and this book is an attempt to help people fill that gap.
The time has come for architecture evaluation to become an accepted engineering practice for two reasons. First, architecture represents an enormous risk in a development project. As we've said, the wrong one leads to disaster. It makes good sense to perform an evaluation on such a pivotal artifact, just as you would plan risk-mitigation strategies for other sources of uncertainty. Second, architecture evaluation can be remarkably inexpensive. The methods described in this book add no more than a week to the project schedule, and some abridged forms require no more than a day or two. Architecture evaluation represents a very cheap insurance policy. Compared to the cost of a poor architecture, the modest expense of a software architecture evaluation makes all the sense in the world. What has been lacking up to this point is a practical method for carrying it out, which is where this book comes in.
This is a guidebook for practitioners (or those who wish to become practitioners) of architecture evaluation. We supply conceptual background where necessary, but the intent of the work is to provide step-by-step guidance in the practice of architecture evaluation and analysis. To help put the methods into practice, we have included sample artifacts that are put into play during an architecture evaluation: viewgraph presentation outlines, scenarios, after-action surveys, final report templates, and so forth. The goal is that after reading this book, you will feel confident enough to try out the methods on an architecture in your own organization. We have tried to help answer the question, during an evaluation, "What should I do now?"
While the book is written from the point of view of the evaluator, there are others involved in an evaluation—project managers, architects, other stakeholders—who will gain valuable insights by reading this book. They will come to understand how their products will be evaluated and thus can position themselves to make those products fare better with respect to the evaluation criteria. This is rather like scoring well on a test because you've seen an early copy of the test, but in this case it isn't cheating but rather sound management and engineering practice. But know that when we use the word you in the text, we are speaking to the evaluator.
The techniques in this book are based on actual practice in government and industry. Most of the methods were developed by ourselves and others at the Software Engineering Institute and applied by ourselves and others to our customers' and collaborators' systems. Other material was gleaned by holding industrial workshops whose participants were experts in the analysis and evaluation of architecture. In short, we have learned by doing, and we have learned from others' doing.
This book will not teach you how to become a good architect, nor does it help you become fluent in the issues of architecture. We assume that you already have a good grasp of architectural concepts that comes from practical experience. This book will not help you assess the job performance of any individual architect nor a project's architecture (or development) process. What it will do is show you how to evaluate an architecture with respect to a broad spectrum of important quality attributes having to do with the architecture and the future system(s) that will be built from it.
Finally, we should say a word about software versus system architecture—that is, the architecture of software-intensive systems. This is a book about the evaluation of software architectures, but we often hear the question, "Well, what about the architecture of the system, not just the software? It's just as vital." We couldn't agree more. System architectures embody the same kinds of structuring and decomposition decisions that drive software architectures. Moreover, they include hardware/software tradeoffs as well as the selection of computing and communication equipment, all of which are completely beyond the realm of software architecture. System architectures hold the key to success or failure of a system every bit as much as the software architecture does for the software. Hence, they deserve to be evaluated every bit as much and for exactly the same reasons.
The methods presented in this book will, we believe, apply equally well to system architectures as to software architectures. If modifiability is a concern, the methods can be used to gauge the expense of making changes over the system's lifetime; if performance is a concern, the methods can be used to spot bottlenecks and problem areas in the system as well as the software; and so forth.
Why, then, do we call it a book about software architecture evaluation? Because that is the realm in which the methods were invented, developed, tested, and matured. In the remainder of this book when we speak of architecture, you can always safely prefix it with software. You can prefix it with system depending on how applicable you feel the methods are to system architectures and how confident you are about our intuition in the matter.
As a final word, we invite you to share your experiences with us. We would be keenly interested in knowing what you discover works well and what doesn't work so well. Writing a book is an opportunity to share lessons, but more importantly to us, it is an opportunity to gather new ones.
—PCC, Austin, Texas—RK, Pittsburgh, Pennsylvania—MHK, Pittsburgh, Pennsylvania
020170482XP10082001
Index
A
ABASs. See Attribute Based Architectural StylesAbowd, Gregory, xvii, 273Acknowledged communication, 95Acknowledging backups, 96, 98, 100Acme language, 266Active design reviews, 241, 245, 288nbsp conventional reviews versus, 242-243origins of, 243-244"Active Design Reviews: Principles and Practices" (Parnas and Weiss), 243Active Reviews for Intermediate Designs, xiv, 20, 32, 241-253, 287as ADR/ATAM hybrid, 245advantages with, 252case study, 248-252overview of, 288Phase 1 for, 246Phase 2 for, 246-248SAAM and ATAM compared with, 256sample agenda for review, 250steps of, 245-248. See also Architecture Tradeoff Analysis Method; Software Architecture Analysis MethodActuators, 8ADD. See Attribute Driven DesignADLs. See Architecture description languagesADRs. See Active design reviewsAlice in Wonderland (Carroll), 27Allocation policies, 111Analysis, within Attribute Based Architectural Style, 125Analysis support, with ATAT, 222Analytical point of view, 302APIs. See Application program interfacesApplication builder, and architecture evaluation, 66Application program interfaces, 88Aqua satellite, 128Architectsand architectural approach analysis, 197architectural approaches identified by, 162and architecture evaluation, 67architecture presented by, 157-158, 159and ARID, 251checklist of questions for, 145and evaluation process, 215-216expressing appreciation to, 152finding, 277missing, 292Phase 1 for EOSDIS Core System and attendance by, 143, 146and quality attribute characterizations, 125. See also StakeholdersArchitectural approaches, 13, 81, 186analysis of, for Battlefield Control System, 92-94, 102analyzing, 45, 68, 172-173, 196benefits in identifying, 181example of analysis of, 59example of description of, 123identifying, 44, 47-50, 90, 162-163template for analysis of, 58, 122Architectural decisions, 111, 112, 122availability-related, 116, 117modifiability-related, 119, 120performance-related, 114, 115Architectural documentation, improving quality of, 37Architectural risks, with Battlefield Control System, 106-107Architectural styles, 12-13, 43, 302attribute-based, 124-125importance of, 49Architectural views, 4, 47Architecture, 3, 20, 21-23audits, 259, 260, 276example template for presentation of, 48importance of, ixpresentation of, 47presentation of, for Battlefield Control System, 89quality attributes determined by, 109, 110reasons for evaluating, 288-290subdesign problems in, 241Architecture-based design, 16Architecture description languages, 10, 266Architecture documentation, 133, 143, 162discussing/reviewing, 148as reusable artifacts, 284reviewing, 164walk throughs of, 145, 147Architecture evaluations, x, 19-42benefits and costs of, 37-41comparison of methods for, 255-273countering skepticism during, 28customizing methods for, 296danger signals to look for with, 258-259follow-up survey: organizational impacts, 281follow-up survey: project impacts, 280full readiness for, 287, 291-294goals of, 109, 289growth of capability for, by organizations, 275-285importance of, xleading, 182-183maximizing evaluators efforts in, 97-98outputs of, 34-36people involved in, 26qualities in, 30-32and quality of stakeholders, 187reasons for, 23-24results produced by, 27, 29-30stakeholders for, 65-68techniques comparison, 271-272timing for, 24-25vague quality attributes and, 32-33and what's architectural?, 21-23Architecture presentations, distillation of, 164Architecture review, people issues involved in, 182Architecture Tradeoff Analysis Method, xiii, xvii, 20, 30, 32, 43-85, 241, 245, 272, 273, 287analysis put in, 80-82approximate cost of medium-size checklist-based evaluation with, 41approximate cost of medium-size evaluation with, 39approximate cost for small evaluation with, 40conceptual flow of, 295consensus-building qualities of, 133description of steps within, 45-51, 55-62, 68-70end-of-exercise participants' survey, 279enhanced ability of, in finding risks, 294EOSDIS Core System (NASA) application of, 127-210experiences with, 104-105hiatus between Phase 1/Phase 2, for EOSDIS Core System, 183-184as hybrid technique, 268maximizing evaluators efforts with, 97-98outline of standard, 151outputs only from, 35-36overview of, 288Phase 0 in, 71-76Phase 0 of, for EOSDIS Core System, 129-148Phase 1 information exchange in, 149Phase 1 of, for EOSDIS Core System, 148-167, 170-181Phase 2 of, for EOSDIS Core System, 184-202Phase 3 of, for EOSDIS Core System, 202-209phases of, 70-78, 79, 82-83postmortem meeting sample agenda, 206presentation of, for Battlefield Control Systems, 89quality attribute characterization used in, 121-124reasons behind success of, 290, 294-296results presented from, 68-70SAAM, ARID compared with, 256sample agenda for Phase 1, 147sample outline for final report, 204and sensitivities and risks, 69steps and outputs of, correlated, 71summary of steps within, 44-45supply checklist for exercise in, 144two faces of, 80-82. See also Active Reviews for Intermediate Designs; Software Architecture Analysis MethodArchitecture Tradeoff Analysis Toolassessment of scenario interactions, 235-236classifying/prioritizing scenarios, 228-231creation of overall evaluation: results/recommendations, 236-238describing architecture(s) of, 224-225, 227-228evaluation of indirect scenarios, 231functional view of architecture, 225SAAM applied to, 222-231, 235-238system overview, 222-223ARID. See Active Reviews for Intermediate DesignsArtifact repositories, maintaining/updating, 83, 202, 207, 285Asynchronous calls, and metrics, 264AT&T, 259, 276ATAM. See Architecture Tradeoff Analysis MethodATAT. See Architecture Tradeoff Analysis ToolATAT editorcode view of generic, 238code view of MVC-based candidate architecture of, 228code view of PAC-based candidate architecture of, 229ATAT-Entities, 228Attribute-Based Architectural Styles, xiii, 49-50, 124-125, 126, 181analysis, 299-302architectural style, 298example of, 297-302parts of, 297problem description, 297-298as reusable artifacts, 284stimulus/response, 298Attribute Driven Design, 16Audits, architecture, 259, 260, 276Authentication, 11Automated tools, 266Availability, 19, 31, 93, 94, 164and backup commander approach, 94, 95, 96and BCS system, 102characterization, 116and ECS architecture, 166and ECS utility tree, 169as quality attribute, 115-117sample questions about, 118and scenarios, 52Avritzer, A., 259, 260, 261BBack-of-the-envelope performance model, 98Backup commander approach, 94-96, 98Backups, and BCS architecture, 96Bandwidth limitations, mitigating against, 103Barbacci, Mario, 268Bass, Len, xvii, 8, 15, 239Battlefield Control System (BCS), 87-108, 289evaluation results for, 103, 105-107hardware view of, 90Phase 1, 89-90, 92-96, 98-100Phase 2, 100-103preparation, 88sample scenarios for evaluation of, 101Benefits surveys, 83Berra, Yogi, 109Blockingsources of, 301-302time, 299, 300, 301-302Boehm, Barry, 19, 84Bosch, J., 15Bottom-up strategy, for organizational buy-in, 276Brooks, Fred, 1Buildability, 27, 29Build-time, 31Buschmann, F., 15, 126, 239, 302Buses, 111Business case presentation, example template f