Paperback(4th ed.)
-
PICK UP IN STORECheck Availability at Nearby Stores
Available within 2 business hours
Related collections and offers
Overview
Updated with eleven new chapters, Software Architecture in Practice, Fourth Edition, thoroughly explains what software architecture is, why it's important, and how to design, instantiate, analyze, evolve, and manage it in disciplined and effective ways.
Three renowned software architects cover the entire lifecycle, presenting practical guidance, expert methods, and tested models for use in any project, no matter how complex. You'll learn how to use architecture to address accelerating growth in requirements, system size, and abstraction, and to manage emergent quality attributes as systems are dynamically combined in new ways.
With insights for utilizing architecture to optimize key quality attributes—including performance, modifiability, security, availability, interoperability, testability, usability, deployability, and more—this guide explains how to manage and refine existing architectures, transform them to solve new problems, and build reusable architectures that become strategic business assets.
- Discover how architecture influences (and is influenced by) technical environments, project lifecycles, business profiles, and your own practices
- Leverage proven patterns, interfaces, and practices for optimizing quality through architecture
- Architect for mobility, the cloud, machine learning, and quantum computing
- Design for increasingly crucial attributes such as energy efficiency and safety
- Scale systems by discovering architecturally significant influences, using DevOps and deployment pipelines, and managing architecture debt
- Understand architecture's role in the organization, so you can deliver more value
Product Details
| ISBN-13: | 9780136886099 |
|---|---|
| Publisher: | Pearson Education |
| Publication date: | 08/03/2021 |
| Series: | SEI Series in Software Engineering |
| Edition description: | 4th ed. |
| Pages: | 464 |
| Sales rank: | 396,760 |
| Product dimensions: | 7.40(w) x 9.40(h) x 1.15(d) |
About the Author
Dr. Paul Clements, VP of Customer Success with BigLever Software, helps organizations gain value from Product Line Engineering (PLE). As senior member of technical staff at SEI, he led advanced projects in PLE and software architecture.
Rick Kazman is Professor, University of Hawaii, and Visiting Researcher at SEI. His interests include software architecture, visualization, design, analysis, and economics. He co-created influential architecture analysis methods and tools, including SAAM, ATAM, CBAM, Dali, and Titan.
Read an Excerpt
PREFACE:
Software architecture is an important field of study that is becoming more important and more talked about with every passing day. But, to our knowledge, there exists little practical guidance on how to manage software architecture within a real software development organization from a technical or from a managerial perspective. This book has emerged from our belief that the coupling of the software architecture of a system and its business and organizational context has not been well explored.
Our experience with designing and reviewing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and also in its ultimate success or failure. Systems are built to satisfy an organizationis requirements (or assumed requirements in the case of shrink-wrapped products), and these requirements determine the extent to which a system must meet performance targets, be highly available, interoperate with other systems, or be designed for long lifetimes. These properties of a system are constrained by the systemis software architecture; or, to put it another way, the desire to achieve these properties influences the design choices made by a software architect.
In this book we demonstrate this coupling through the use of case studies drawn from real systems, including the following:
- In Chapter 7, we show how the desire to quickly and easily share documents within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web.
- In Chapter 11, we discuss how the extreme safety requirements of air traffic control ledone company to build a system around an architecture for achieving ultrahigh availability.
- In Chapter 14, we describe how the distribution of the subsystems of a flight simulator to different remotely located developers led to an architecture geared to enable the easy integration of these subsystems.
- In Chapter 16, we explain how the need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to economically build a set of complex, related software systems as a product line.
These and other case studies show how the architectures flow from requirements of organizations and their business models, from the experience of the organizationis architects, and from the prevailing design climate.
In addition, we discuss how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence how other products are built; certainly, the case study of the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness; less thought was given to accessibility of data; and security was the concern of only a few organizations, typically financial institutions and government agencies.
This book is aimed at the software professionalothe person designing and implementing large software-intensive systemsoand at the managers of software professionals. It does not contain, for example, detailed financial justification for using a software architecture, for doing early architectural analyses, or for investing in a product line approach to building software. We provide only anecdotal evidence to support the claims that these pay off, although we passionately believe they do.
A software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. This is because an architecture appears early in a productis lifetime. Getting it right sets the stage for everything to come in the systemis life: development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, analyzing architectures is inexpensive, compared with other development activities. Thus, architectures give a high return on investment partially because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.
We also believe that reusable components are best achieved within an architectural context. But components are not the only artifacts that can be reused. Reuse of an architecture leads to the creation of families of similar systems, which in turn leads to new organizational structures and new business opportunities.
A large percentage of this book is devoted to presenting real architectures that were designed to solve real problems in real organizations. We chose the case studies to illustrate the types of choices that architects must make to achieve their quality goals and to show how organizational goals affect the final systems.
In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture and for building architectures that meet these quality requirements. We look at architecture description languages as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architectureis fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multiyear development efforts.
We have also provided a visual language for describing software architectures that contains enough expressiveness to describe both procedural and object-oriented systems and enough generality to describe systems at any granularity: a division of functionality, a set of software structures, a set of hardware structures, or any combination of these. Although a visual notation is not, in itself, documentation of an architecture, it is an integral part of such a documentation. One of our complaints with the state-of-the-practice in architecture today is the vagueness of architectural descriptions. We hope that the visual language described here is a contribution to the field, aimed at increasing the effectiveness of architectural documentation.
The book targets software professionals, or students who have knowledge and experience in software engineering, and we anticipate the following three classes of readers:
- Practicing software engineers who wish to understand both the technical basis of software architecture and the business and organizational forces that are acting on them
- Technical managers who wish to understand how software architecture can help them to supervise the construction of systems more effectively and improve their organizations
- Students in computer science or software engineering who might use this book as supplemental reading in a first or second software engineering course
Although business issues are discussed throughout the book (for example, how an architecture affects an organizationis ability to compete in a market or how the architecture underlying a product family affects time to market), we present this material without going into the business issues in great depth and without using business jargon. We are, after all, software engineers. The technical sections are presented in more depth. These sections represent current work in the field of software architectureothe point where research meets practice; they are the philosophical foundations of the book. The case studies illustrate these technical foundations and show how they are realized in practice. However, we have written the case studies in such a way that expertise in the application domain from which each case study was drawn is not required. You will not need to be a pilot to understand either the air traffic control system or the flight simulation case studies. However, you will need to have a reasonable background in computer science, software engineering, or a related discipline to benefit from the lessons of the case studies.
One final note on the organization of the book. Software Architecture in Practice is not intended to be a prescriptive method for architectural design. In fact, we believe that it is impossible to satisfactorily create such a prescriptive design method. Any design involves trade-offs: Modifiability affects performance, security affects modifiability, scalability affects reliability, and everything affects cost. Any prescriptive method implicity or explicitly assumes that some of these qualities are more important than others and guides users toward the maximization of that goal. Our feeling is that although such an approach may be appropriate in a specific domain, it cannot possibly work in general. Quality requirements are different from organization to organization and from year to year.
By way of contrast, we offer a toolbox approach to design. We believe that different architectural tools and techniques are appropriate for different situations and different quality goals. No single technique will ever suffice. So, we present a number of different architectural tools (layering, multiple views, patterns, blackboards, and so forth) and techniques (analysis methods, integration strategies, engineering principles) and illustrate their usage in different business and technical contexts.
Not surprisingly, most of the case studies use a mix of tools and techniques because they were chosen to illustrate how software architecture was the foundation for a successful system. These systems were successful precisely because they chose the right tools and implemented them using the right techniques. Anything less would not have resulted in a successful system, as we hope to persuade you in the coming pages.
Table of Contents
Preface xvAcknowledgments xvii
Part I: Introduction 1
Chapter 1: What Is Software Architecture? 1
1.1 What Software Architecture Is and What It Isn't 2
1.2 Architectural Structures and Views 5
1.3 What Makes a "Good" Architecture? 19
1.4 Summary 21
1.5 For Further Reading 21
1.6 Discussion Questions 22
Chapter 2: Why Is Software Architecture Important? 25
2.1 Inhibiting or Enabling a System's Quality Attributes 26
2.2 Reasoning about and Managing Change 27
2.3 Predicting System Qualities 28
2.4 Communication among Stakeholders 28
2.5 Early Design Decisions 31
2.6 Constraints on Implementation 31
2.7 Influences on Organizational Structure 32
2.8 Enabling Incremental Development 33
2.9 Cost and Schedule Estimates 33
2.10 Transferable, Reusable Model 34
2.11 Architecture Allows Incorporation of Independently Developed Elements 34
2.12 Restricting the Vocabulary of Design Alternatives 35
2.13 A Basis for Training 36
2.14 Summary 36
2.15 For Further Reading 37
2.16 Discussion Questions 37
Part II: Quality Attributes 39
Chapter 3: Understanding Quality Attributes 39
3.1 Functionality 40
3.2 Quality Attribute Considerations 41
3.3 Specifying Quality Attribute Requirements: Quality Attribute Scenarios 42
3.4 Achieving Quality Attributes through Architectural Patterns and Tactics 45
3.5 Designing with Tactics 46
3.6 Analyzing Quality Attribute Design Decisions: Tactics-Based Questionnaires 48
3.7 Summary 49
3.8 For Further Reading 49
3.9 Discussion Questions 50
Chapter 4: Availability 51
4.1 Availability General Scenario 53
4.2 Tactics for Availability 55
4.3 Tactics-Based Questionnaire for Availability 62
4.4 Patterns for Availability 66
4.5 For Further Reading 68
4.6 Discussion Questions 69
Chapter 5: Deployability 71
5.1 Continuous Deployment 72
5.2 Deployability 75
5.3 Deployability General Scenario 76
5.4 Tactics for Deployability 78
5.5 Tactics-Based Questionnaire for Deployability 80
5.6 Patterns for Deployability 81
5.7 For Further Reading 87
5.8 Discussion Questions 87
Chapter 6: Energy Efficiency 89
6.1 Energy Efficiency General Scenario 90
6.2 Tactics for Energy Efficiency 92
6.3 Tactics-Based Questionnaire for Energy Efficiency 95
6.4 Patterns 97
6.5 For Further Reading 98
6.6 Discussion Questions 99
Chapter 7: Integrability 101
7.1 Evaluating the Integrability of an Architecture 102
7.2 General Scenario for Integrability 104
7.3 Integrability Tactics 105
7.4 Tactics-Based Questionnaire for Integrability 110
7.5 Patterns 112
7.6 For Further Reading 114
7.7 Discussion Questions 115
Chapter 8: Modifiability 117
8.1 Modifiability General Scenario 120
8.2 Tactics for Modifiability 121
8.3 Tactics-Based Questionnaire for Modifiability 125
8.4 Patterns 126
8.5 For Further Reading 130
8.6 Discussion Questions 131
Chapter 9: Performance 133
9.1 Performance General Scenario 134
9.2 Tactics for Performance 137
9.3 Tactics-Based Questionnaire for Performance 145
9.4 Patterns for Performance 146
9.5 For Further Reading 149
9.6 Discussion Questions 150
Chapter 10: Safety 151
10.1 Safety General Scenario 154
10.2 Tactics for Safety 156
10.3 Tactics-Based Questionnaire for Safety 160
10.4 Patterns for Safety 163
10.5 For Further Reading 165
10.6 Discussion Questions 166
Chapter 11: Security 169
11.1 Security General Scenario 170
11.2 Tactics for Security 172
11.3 Tactics-Based Questionnaire for Security 176
11.4 Patterns for Security 179
11.5 For Further Reading 180
11.6 Discussion Questions 180
Chapter 12: Testability 183
12.1 Testability General Scenario 186
12.2 Tactics for Testability 187
12.3 Tactics-Based Questionnaire for Testability 192
12.4 Patterns for Testability 192
12.5 For Further Reading 194
12.6 Discussion Questions 195
Chapter 13: Usability 197
13.1 Usability General Scenario 198
13.2 Tactics for Usability 200
13.3 Tactics-Based Questionnaire for Usability 202
13.4 Patterns for Usability 203
13.5 For Further Reading 205
13.6 Discussion Questions 205
Chapter 14: Working with Other Quality Attributes 207
14.1 Other Kinds of Quality Attributes 207
14.2 Using Standard Lists of Quality Attributes—Or Not 209
14.3 Dealing with "X-Ability": Bringing a New QA into the Fold 212
14.4 For Further Reading 215
14.5 Discussion Questions 215
Part III: Architectural Solutions 217
Chapter 15: Software Interfaces 217
15.1 Interface Concepts 218
15.2 Designing an Interface 222
15.3 Documenting the Interface 228
15.4 Summary 230
15.5 For Further Reading 230
15.6 Discussion Questions 231
Chapter 16: Virtualization 233
16.1 Shared Resources 234
16.2 Virtual Machines 235
16.3 VM Images 238
16.4 Containers 239
16.5 Containers and VMs 241
16.6 Container Portability 242
16.7 Pods 242
16.8 Serverless Architecture 243
16.9 Summary 244
16.10 For Further Reading 245
16.11 Discussion Questions 245
Chapter 17: The Cloud and Distributed Computing 247
17.1 Cloud Basics 248
17.2 Failure in the Cloud 251
17.3 Using Multiple Instances to Improve Performance and Availability 253
17.4 Summary 261
17.5 For Further Reading 262
17.6 Discussion Questions 262
Chapter 18: Mobile Systems 263
18.1 Energy 264
18.2 Network Connectivity 266
18.3 Sensors and Actuators 267
18.4 Resources 268
18.5 Life Cycle 270
18.6 Summary 273
18.7 For Further Reading 274
18.8 Discussion Questions 275
Part IV: Scalable Architecture Practices 277
Chapter 19: Architecturally Significant Requirements 277
19.1 Gathering ASRs from Requirements Documents 278
19.2 Gathering ASRs by Interviewing Stakeholders 279
19.3 Gathering ASRs by Understanding the Business Goals 282
19.4 Capturing ASRs in a Utility Tree 284
19.5 Change Happens 286
19.6 Summary 286
19.7 For Further Reading 287
19.8 Discussion Questions 287
Chapter 20: Designing an Architecture 289
20.1 Attribute-Driven Design 289
20.2 The Steps of ADD 292
20.3 More on ADD Step 4: Choose One or More Design Concepts 295
20.4 More on ADD Step 5: Producing Structures 298
20.5 More on ADD Step 6: Creating Preliminary Documentation during the Design 301
20.6 More on ADD Step 7: Perform Analysis of the Current Design and Review the Iteration Goal and Achievement of the Design Purpose 304
20.7 Summary 306
20.8 For Further Reading 306
20.9 Discussion Questions 307
Chapter 21: Evaluating an Architecture 309
21.1 Evaluation as a Risk Reduction Activity 309
21.2 What Are the Key Evaluation Activities? 310
21.3 Who Can Perform the Evaluation? 311
21.4 Contextual Factors 312
21.5 The Architecture Tradeoff Analysis Method 313
21.6 Lightweight Architecture Evaluation 324
21.7 Summary 326
21.8 For Further Reading 327
21.9 Discussion Questions 327
Chapter 22: Documenting an Architecture 329
22.1 Uses and Audiences for Architecture Documentation 330
22.2 Notations 331
22.3 Views 332
22.4 Combining Views 339
22.5 Documenting Behavior 340
22.6 Beyond Views 345
22.7 Documenting the Rationale 346
22.8 Architecture Stakeholders 347
22.9 Practical Considerations 350
22.10 Summary 353
22.11 For Further Reading 353
22.12 Discussion Questions 354
Chapter 23: Managing Architecture Debt 355
23.1 Determining Whether You Have an Architecture Debt Problem 356
23.2 Discovering Hotspots 358
23.3 Example 362
23.4 Automation 363
23.5 Summary 364
23.6 For Further Reading 364
23.7 Discussion Questions 365
Part V: Architecture and the Organization 367
Chapter 24: The Role of Architects in Projects 367
24.1 The Architect and the Project Manager 367
24.2 Incremental Architecture and Stakeholders 369
24.3 Architecture and Agile Development 370
24.4 Architecture and Distributed Development 373
24.5 Summary 376
24.6 For Further Reading 376
24.7 Discussion Questions 377
Chapter 25: Architecture Competence 379
25.1 Competence of Individuals: Duties, Skills, and Knowledge of Architects 379
25.2 Competence of a Software Architecture Organization 386
25.3 Become a Better Architect 387
25.4 Summary 388
25.5 For Further Reading 388
25.6 Discussion Questions 389
Part VI: Conclusions 391
Chapter 26: A Glimpse of the Future: Quantum Computing 391
26.1 Single Qubit 392
26.2 Quantum Teleportation 394
26.3 Quantum Computing and Encryption 394
26.4 Other Algorithms 395
26.5 Potential Applications 396
26.6 Final Thoughts 397
26.7 For Further Reading 398
References 399
About the Authors 415
Index 417
Preface
Software architecture is an important field of study that is becoming more important and more talked about with every passing day. But, to our knowledge, there exists little practical guidance on how to manage software architecture within a real software development organization from a technical or from a managerial perspective. This book has emerged from our belief that the coupling of the software architecture of a system and its business and organizational context has not been well explored.
Our experience with designing and reviewing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and also in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products), and these requirements determine the extent to which a system must meet performance targets, be highly available, interoperate with other systems, or be designed for long lifetimes. These properties of a system are constrained by the system's software architecture; or, to put it another way, the desire to achieve these properties influences the design choices made by a software architect.
In this book we demonstrate this coupling through the use of case studies drawn from real systems, including the following:
- In Chapter 7, we show how the desire to quickly and easily share documents within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web.
- In Chapter 11, we discuss how the extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultrahigh availability.
- In Chapter 14, we describe how the distribution of the subsystems of a flight simulator to different remotely located developers led to an architecture geared to enable the easy integration of these subsystems.
- In Chapter 16, we explain how the need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to economically build a set of complex, related software systems as a product line.
These and other case studies show how the architectures flow from requirements of organizations and their business models, from the experience of the organization's architects, and from the prevailing design climate.
In addition, we discuss how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence how other products are built; certainly, the case study of the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness; less thought was given to accessibility of data; and security was the concern of only a few organizations, typically financial institutions and government agencies.
This book is aimed at the software professional—the person designing and implementing large software-intensive systems—and at the managers of software professionals. It does not contain, for example, detailed financial justification for using a software architecture, for doing early architectural analyses, or for investing in a product line approach to building software. We provide only anecdotal evidence to support the claims that these pay off, although we passionately believe they do.
A software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. This is because an architecture appears early in a product's lifetime. Getting it right sets the stage for everything to come in the system's life: development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, analyzing architectures is inexpensive, compared with other development activities. Thus, architectures give a high return on investment partially because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.
We also believe that reusable components are best achieved within an architectural context. But components are not the only artifacts that can be reused. Reuse of an architecture leads to the creation of families of similar systems, which in turn leads to new organizational structures and new business opportunities.
A large percentage of this book is devoted to presenting real architectures that were designed to solve real problems in real organizations. We chose the case studies to illustrate the types of choices that architects must make to achieve their quality goals and to show how organizational goals affect the final systems.
In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture and for building architectures that meet these quality requirements. We look at architecture description languages as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architecture's fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multiyear development efforts.
We have also provided a visual language for describing software architectures that contains enough expressiveness to describe both procedural and object-oriented systems and enough generality to describe systems at any granularity: a division of functionality, a set of software structures, a set of hardware structures, or any combination of these. Although a visual notation is not, in itself, documentation of an architecture, it is an integral part of such a documentation. One of our complaints with the state-of-the-practice in architecture today is the vagueness of architectural descriptions. We hope that the visual language described here is a contribution to the field, aimed at increasing the effectiveness of architectural documentation.
The book targets software professionals, or students who have knowledge and experience in software engineering, and we anticipate the following three classes of readers:
- Practicing software engineers who wish to understand both the technical basis of software architecture and the business and organizational forces that are acting on them
- Technical managers who wish to understand how software architecture can help them to supervise the construction of systems more effectively and improve their organizations
- Students in computer science or software engineering who might use this book as supplemental reading in a first or second software engineering course
Although business issues are discussed throughout the book (for example, how an architecture affects an organization's ability to compete in a market or how the architecture underlying a product family affects time to market), we present this material without going into the business issues in great depth and without using business jargon. We are, after all, software engineers. The technical sections are presented in more depth. These sections represent current work in the field of software architecture—the point where research meets practice; they are the philosophical foundations of the book. The case studies illustrate these technical foundations and show how they are realized in practice. However, we have written the case studies in such a way that expertise in the application domain from which each case study was drawn is not required. You will not need to be a pilot to understand either the air traffic control system or the flight simulation case studies. However, you will need to have a reasonable background in computer science, software engineering, or a related discipline to benefit from the lessons of the case studies.
One final note on the organization of the book. Software Architecture in Practice is not intended to be a prescriptive method for architectural design. In fact, we believe that it is impossible to satisfactorily create such a prescriptive design method. Any design involves trade-offs: Modifiability affects performance, security affects modifiability, scalability affects reliability, and everything affects cost. Any prescriptive method implicity or explicitly assumes that some of these qualities are more important than others and guides users toward the maximization of that goal. Our feeling is that although such an approach may be appropriate in a specific domain, it cannot possibly work in general. Quality requirements are different from organization to organization and from year to year.
By way of contrast, we offer a toolbox approach to design. We believe that different architectural tools and techniques are appropriate for different situations and different quality goals. No single technique will ever suffice. So, we present a number of different architectural tools (layering, multiple views, patterns, blackboards, and so forth) and techniques (analysis methods, integration strategies, engineering principles) and illustrate their usage in different business and technical contexts.
Not surprisingly, most of the case studies use a mix of tools and techniques because they were chosen to illustrate how software architecture was the foundation for a successful system. These systems were successful precisely because they chose the right tools and implemented them using the right techniques. Anything less would not have resulted in a successful system, as we hope to persuade you in the coming pages.