Software Architecture in Practice
Fourth Edition
Len Bass
Paul Clements
Rick Kazman
Boston Columbus New York San Francisco Amsterdam Cape Town
Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City
So Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo
Software Engineering Institute | Carnegie Mellon
The SEI Series in Software Engineering
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.
CMM, CMMI, Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CERT, and CERT Coordination Center are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
ATAM; Architecture Tradeoff Analysis Method; CMM Integration; COTS Usage-Risk Evaluation; CURE; EPIC; Evolutionary Process for Integrating COTS Based Systems; Framework for Software Product Line Practice; IDEAL; Interim Profile; OAR; OCTAVE; Operationally Critical Threat, Asset, and Vulnerability Evaluation; Options Analysis for Reengineering; Personal Software Process; PLTP; Product Line Technical Probe; PSP; SCAMPI; SCAMPI Lead Appraiser; SCAMPI Lead Assessor; SCE; SEI; SEPG; Team Software Process; and TSP are service marks of Carnegie Mellon University.
Special permission to reproduce portions of works copyright by Carnegie Mellon University, as listed on page 437, is granted by the Software Engineering Institute.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.
The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at or (800) 382-3419.
For government sales inquiries, please contact .
For questions about sales outside the U.S., please contact .
Visit us on the Web: informit.com/aw
Library of Congress Control Number: 2021934450
Copyright 2022 Pearson Education, Inc.
Cover image: Zhernosek_FFMstudio.com/Shutterstock
Hand/input icon: In-Finity/Shutterstock
: Shutterstock Vector/Shutterstock
: Oleksiy Mark/Shutterstock
, cloud icon: luckyguy/123RF
computer icons: Dacian G/Shutterstock
All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, request forms and the appropriate contacts within the Pearson Education Global Rights & Permissions Department, please visit www.pearson.com/permissions/.
ISBN-13: 978-0-13-688609-9
ISBN-10: 0-13-688609-4
ScoutAutomatedPrintCode
Preface
When we set out to write the fourth edition of Software Architecture in Practice, our first question to ourselves was: Does architecture still matter? With the rise of cloud infrastructures, microservices, frameworks, and reference architectures for every conceivable domain and quality attribute, one might think that architectural knowledge is hardly needed anymore. All the architect of today needs to do is select from the rich array of tools and infrastructure alternatives out there, instantiate and configure them, and voila! An architecture.
We were (and are) pretty sure this is not true. Admittedly, we are somewhat biased. So we spoke to some of our colleaguesworking architects in the healthcare and automotive domains, in social media and aviation, in defense and finance and e-commercenone of whom can afford to let dogmatic bias rule them. What we heard confirmed our beliefthat architecture is just as relevant today as it was more than 20 years ago, when we wrote the first edition.
Lets examine a few of the reasons that we heard. First, the rate of new requirements has been accelerating for many years, and it continues to accelerate even now. Architects today are faced with a nonstop and ever-increasing stream of feature requests and bugs to fix, driven by customer and business needs and by competitive pressures. If architects arent paying attention to the modularity of their system (and, no, microservices are not a panacea here), that system will quickly become an anchorhard to understand, change, debug, and modify, and weighing down the business.
Second, while the level of abstraction in systems is increasingwe can and do regularly use many sophisticated services, blissfully unaware of how they are implementedthe complexity of the systems we are being asked to create is increasing at least as quickly. This is an arms race, and the architects arent winning! Architecture has always been about taming complexity, and that just isnt going to go away anytime soon.
Speaking of raising the level of abstraction, model-based systems engineering (MBSE) has emerged as a potent force in the engineering field over the last decade or so. MBSE is the formalized application of modeling to support (among other things) system design. The International Council on Systems Engineering (INCOSE) ranks MBSE as one of a select set of transformational enablers that underlie the entire discipline of systems engineering. A model is a graphical, mathematical, or physical representation of a concept or a construct that can be reasoned about. INCOSE is trying to move the engineering field from a document-based mentality to a model-based mentality, where structural models, behavioral models, performance models, and more are all used consistently to build systems better, faster, and cheaper. MBSE per se is beyond the scope of this book, but we cant help but notice that what is being modeled is architecture. And who builds the models? Architects.