Full Download PDF of Software Architecture in Practice (SEI Series in Software Engineering), 4th Edition Len Bass - Ebook PDF All Chapter

Software Architecture in Practice (SEI
Series in Software Engineering), 4th

Edition Len Bass - eBook PDF
Go to download the full and correct content document:
https://ebooksecure.com/download/software-architecture-in-practice-sei-series-in-soft
ware-engineering-4th-edition-ebook-pdf/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Architecting Cloud Saas Software - Solutions Or

Products: Engineering Multi-Tenanted Distributed
Architecture Software - eBook PDF
https://ebooksecure.com/download/architecting-cloud-saas-
software-solutions-or-products-engineering-multi-tenanted-
distributed-architecture-software-ebook-pdf/
(eBook PDF) Engineering Software Products: An

Introduction to Modern Software Engineering
http://ebooksecure.com/product/ebook-pdf-engineering-software-
products-an-introduction-to-modern-software-engineering/
Engineering Software Products: An Introduction to

Modern Software Engineering - eBook PDF
https://ebooksecure.com/download/engineering-software-products-
an-introduction-to-modern-software-engineering-ebook-pdf/
(eBook PDF) Microservices Flexible Software

Architecture
http://ebooksecure.com/product/ebook-pdf-microservices-flexible-
software-architecture/
(eBook PDF) Software Engineering 10th Edition
http://ebooksecure.com/product/ebook-pdf-software-
engineering-10th-edition/
(eBook PDF) Software Engineering: A Practitioner's

Approach 9th Edition
http://ebooksecure.com/product/ebook-pdf-software-engineering-a-
practitioners-approach-9th-edition/
Software Engineering: A Practitioner's Approach 9th

Edition (eBook PDF)
http://ebooksecure.com/product/software-engineering-a-
practitioners-approach-9th-edition-ebook-pdf/
Software Engineering 10th Edition by Ian Sommerville

(eBook PDF)
http://ebooksecure.com/product/software-engineering-10th-edition-
by-ian-sommerville-ebook-pdf/
Software Engineering: A Practitioner's Approach 9th

Edition Roger S. Pressman - eBook PDF
https://ebooksecure.com/download/software-engineering-a-
practitioners-approach-ebook-pdf/
Software Architecture in
Practice
Fourth Edition
The SEI Series in Software Engineering
Visit informit.com/sei for a complete list of available publications.
T he SEI Series in Software Engineering is a collaborative undertaking of

the Carnegie Mellon Software Engineering Institute (SEI) and Addison-
Wesley to develop and publish books on software engineering and related
topics. The common goal of the SEI and Addison-Wesley is to provide the
most current information on these topics in a form that is easily usable by
practitioners and students.
Titles in the series describe frameworks, tools, methods, and technologies

designed to help organizations, teams, and individuals improve their technical
or management capabilities. Some books describe processes and practices for
developing higher-quality software, acquiring programs for complex systems,
RUGHOLYHULQJVHUYLFHVPRUHH΍HFWLYHO\2WKHUERRNVIRFXVRQVRIWZDUHDQG
system architecture and product-line development. Still others, from the
SEI’s CERT Program, describe technologies and practices needed to manage
software and network security risk. These and all titles in the series address
critical problems in software engineering for which practical solutions are
available.
Make sure to connect with us!

informit.com/socialconnect
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
São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo
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 war-
ranty 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 elec-
tronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or
branding interests), please contact our corporate sales department at corpsales@pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact intlcs@pearson.com.
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
Figure 1.1: GraphicsRF.com/Shutterstock
Figure 15.2: Shutterstock Vector/Shutterstock
Figure 17.1: Oleksiy Mark/Shutterstock
Figure 17.2, cloud icon: luckyguy/123RF
Figures 17.2, 17.4, and 17.5 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
Contents
Preface xv
Acknowledgments 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
v
vi Contents
2.12 Restricting the Vocabulary of Design Alternatives 35

2.13 A Basis for Training 36
2.14 Summary 36
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
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
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
Contents vii
5.5 Tactics-Based Questionnaire for Deployability 80

5.6 Patterns for Deployability 81
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
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
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
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
viii Contents

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
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
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
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
Contents ix
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
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
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
CHAPTER 17 The Cloud and Distributed Computing 247

17.1 Cloud Basics 248
17.2 Failure in the Cloud 251
x Contents
17.3 Using Multiple Instances to Improve Performance and

Availability 253
17.4 Summary 261
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
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
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
Contents xi
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
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
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
xii Contents
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
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
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
Contents xiii
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
References 399
About the Authors 415
Index 417
This page intentionally left blank
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 infrastruc-
tures, 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 colleagues—working architects in the healthcare and automotive domains,
in social media and aviation, in defense and finance and e-commerce—none of whom can afford
to let dogmatic bias rule them. What we heard confirmed our belief—that architecture is just as
relevant today as it was more than 20 years ago, when we wrote the first edition.
Let’s 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 aren’t paying attention
to the modularity of their system (and, no, microservices are not a panacea here), that system
will quickly become an anchor—hard to understand, change, debug, and modify, and weigh-
ing down the business.
Second, while the level of abstraction in systems is increasing—we can and do regularly
use many sophisticated services, blissfully unaware of how they are implemented—the com-
plexity of the systems we are being asked to create is increasing at least as quickly. This is an
arms race, and the architects aren’t winning! Architecture has always been about taming com-
plexity, and that just isn’t 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 men-
tality 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 can’t help but notice that what is being modeled
is architecture. And who builds the models? Architects.
xv
xvi Preface
Third, the meteoric growth (and unprecedented levels of employee turnover) that char-
acterizes the world of information systems means that no one understands everything in any
real-world system. Just being smart and working hard aren’t good enough.
Fourth, despite having tools that automate much of what we used to do ourselves—think
about all of the orchestration, deployment, and management functions baked into Kubernetes,
for example—we still need to understand the quality attribute properties of these systems that
we depend upon, and we need to understand the emergent quality attribute properties when we
combine systems together. Most quality attributes—performance, security, availability, safety,
and so on—are susceptible to “weakest link” problems, and those weakest links may only
emerge and bite us when we compose systems. Without a guiding hand to ward off disaster,
the composition is very likely to fail. That guiding hand belongs to an architect, regardless of
their title.
Given these considerations, we felt safe and secure that there was indeed a need for this
book.
But was there a need for a fourth edition? Again (and this should be abundantly obvious),
we concluded an emphatic “yes”! Much has changed in the computing landscape since the
last edition was published. Some quality attributes that were not previously considered have
risen to importance in the daily lives of many architects. As software continues to pervade
all aspects of our society, safety considerations have become paramount for many systems;
think about all of the ways that software controls the cars that we now drive. Likewise, energy
efficiency is a quality that few architects considered a decade ago, but now must pay attention
to, from massive data centers with unquenchable needs for energy to the small (even tiny)
battery-operated mobile and IoT devices that surround us. Also, given that we are, more than
ever, building systems by leveraging preexisting components, the quality attribute of integra-
bility is consuming ever-increasing amounts of our attention.
Finally, we are building different kinds of systems, and building them in different ways
than a decade ago. Systems these days are often built on top of virtualized resources that
reside in a cloud, and they need to provide and depend on explicit interfaces. Also, they are
increasingly mobile, with all of the opportunities and challenges that mobility brings. So, in
this edition we have added chapters on virtualization, interfaces, mobility, and the cloud.
As you can see, we convinced ourselves. We hope that we have convinced you as well,
and that you will find this fourth edition a useful addition to your (physical or electronic)
bookshelf.
Register your copy of Software Architecture in Practice, Fourth Edition, on the InformIT
site for convenient access to updates and/or corrections as they become available. To start
the registration process, go to informit.com/register and log in or create an account. Enter the
product ISBN (9780136886099) and click Submit. Look on the Registered Products tab for
an Access Bonus Content link next to this product, and follow that link to access any avail-
able bonus materials. If you would like to be notified of exclusive offers on new editions and
updates, please check the box to receive email from us.
Acknowledgments
We are profoundly grateful to all the people with whom we collaborated to produce this book.
First and foremost, we extend our gratitude to the co-authors of individual chapters. Their
knowledge and insights in these areas were invaluable. Our thanks go to Cesare Pautasso of
the Faculty of Informatics, University of Lugano; Yazid Hamdi of Siemens Mobile Systems;
Greg Hartman of Google; Humberto Cervantes of Universidad Autonoma Metropolitana—
Iztapalapa; and Yuanfang Cai of Drexel University. Thanks to Eduardo Miranda of Carnegie
Mellon University’s Institute for Software Research, who wrote the sidebar on the Value of
Information technique.
Good reviewers are essential to good work, and we are fortunate to have had John Hudak,
Mario Benitez, Grace Lewis, Robert Nord, Dan Justice, and Krishna Guru lend their time and
talents toward improving the material in this book. Thanks to James Ivers and Ipek Ozkaya for
overseeing this book from the perspective of the SEI Series in Software Engineering.
Over the years, we have benefited from our discussions and writings with colleagues and
we would like to explicitly acknowledge them. In particular, in addition to those already men-
tioned, our thanks go to David Garlan, Reed Little, Paulo Merson, Judith Stafford, Mark Klein,
James Scott, Carlos Paradis, Phil Bianco, Jungwoo Ryoo, and Phil Laplante. Special thanks go
to John Klein, who contributed one way or another to many of the chapters in this book.
In addition, we are grateful to everyone at Pearson for all their work and attention to
detail in the countless steps involved in turning our words into the finished product that you
are now reading. Thanks especially to Haze Humbert, who oversaw the whole process.
Finally, thanks to the many, many researchers, teachers, writers, and practitioners who
have, over the years, worked to turn software architecture from a good idea into an engineer-
ing discipline. This book is for you.
xvii
PART I Introduction
1
What Is Software
Architecture?
We are called to be architects of the future, not its victims.
—R. Buckminster Fuller
Writing (on our part) and reading (on your part) a book about software architecture, which
distills the experience of many people, presupposes that
1. having a reasonable software architecture is important to the successful development of
a software system and
2. there is a sufficient body of knowledge about software architecture to fill up a book.
There was a time when both of these assumptions needed justification. Early editions of
this book tried to convince readers that both of these assumptions are true and, once you were
convinced, supply you with basic knowledge so that you could apply the practice of architec-
ture yourself. Today, there seems to be little controversy about either aim, and so this book is
more about the supplying than the convincing.
The basic principle of software architecture is every software system is constructed to satisfy
an organization’s business goals, and that the architecture of a system is a bridge between
those (often abstract) business goals and the final (concrete) resulting system. While the path
from abstract goals to concrete systems can be complex, the good news is that software archi-
tectures can be designed, analyzed, and documented using known techniques that will support
the achievement of these business goals. The complexity can be tamed, made tractable.
These, then, are the topics for this book: the design, analysis, and documentation of archi-
tectures. We will also examine the influences, principally in the form of business goals that
lead to quality attribute requirements, that inform these activities.
In this chapter, we will focus on architecture strictly from a software engineering point
of view. That is, we will explore the value that a software architecture brings to a development
project. Later chapters will take business and organizational perspectives.
1
2 Part I Introduction | Chapter 1 What Is Software Architecture?
1.1 What Software Architecture Is and What It Isn’t
There are many definitions of software architecture, easily discoverable with a web search, but
the one we like is this:
The software architecture of a system is the set of structures needed to reason about
the system. These structures comprise software elements, relations among them, and
properties of both.
This definition stands in contrast to other definitions that talk about the system’s “early”
or “major” or “important” decisions. While it is true that many architectural decisions are
made early, not all are—especially in Agile and spiral-development projects. It’s also true
that many decisions that are made early are not what we would consider architectural. Also,
it’s hard to look at a decision and tell whether it’s “major.” Sometimes only time will tell. And
since deciding on an architecture is one of the architect’s most important obligations, we need
to know which decisions an architecture comprises.
Structures, by contrast, are fairly easy to identify in software, and they form a powerful
tool for system design and analysis.
So, there we are: Architecture is about reasoning-enabling structures.
Let’s look at some of the implications of our definition.
Architecture Is a Set of Software Structures

This is the first and most obvious implication of our definition. A structure is simply a set
of elements held together by a relation. Software systems are composed of many structures,
and no single structure can lay claim to being the architecture. Structures can be grouped
into categories, and the categories themselves provide useful ways to think about the architec-
ture. Architectural structures can be organized into three useful categories, which will play an
important role in the design, documentation, and analysis of architectures:
1. Component-and-connector structures
2. Module structures
3. Allocation structures
We’ll delve more into these types of structures in the next section.
Although software comprises an endless supply of structures, not all of them are archi-
tectural. For example, the set of lines of source code that contain the letter “z,” ordered by
increasing length from shortest to longest, is a software structure. But it’s not a very interesting
one, nor is it architectural. A structure is architectural if it supports reasoning about the system
and the system’s properties. The reasoning should be about an attribute of the system that is
important to some stakeholder(s). These include properties such as the functionality achieved
by the system, the system’s ability to keep operating usefully in the face of faults or attempts
to take it down, the ease or difficulty of making specific changes to the system, the system’s
1.1 What Software Architecture Is and What It Isn’t 3
responsiveness to user requests, and many others. We will spend a great deal of time in this
book exploring the relationship between architecture and quality attributes like these.
Thus the set of architectural structures is neither fixed nor limited. What is architectural
depends on what is useful to reason about in your context for your system.
Architecture Is an Abstraction
Since architecture consists of structures, and structures consist of elements1 and relations, it fol-
lows that an architecture comprises software elements and how those elements relate to each
other. This means that architecture specifically and intentionally omits certain information
about elements that is not useful for reasoning about the system. Thus an architecture is fore-
most an abstraction of a system that selects certain details and suppresses others. In all modern
systems, elements interact with each other by means of interfaces that partition details about an
element into public and private parts. Architecture is concerned with the public side of this divi-
sion; private details of elements—details having to do solely with internal implementation—are
not architectural. This abstraction is essential to taming the complexity of an architecture: We
simply cannot, and do not want to, deal with all of the complexity all of the time. We want—and
need—the understanding of a system’s architecture to be many orders of magnitude easier than
understanding every detail about that system. You can’t keep every detail of a system of even
modest size in your head; the point of architecture is to make it so you don’t have to.
Architecture versus Design

Architecture is design, but not all design is architecture. That is, many design decisions are left
unbound by the architecture—it is, after all, an abstraction—and depend on the discretion and
good judgment of downstream designers and even implementers.
Every Software System Has a Software Architecture

Every system has an architecture, because every system has elements and relations. However,
it does not follow that the architecture is known to anyone. Perhaps all of the people who
designed the system are long gone, the documentation has vanished (or was never produced),
the source code has been lost (or was never delivered), and all we have at hand is the exe-
cuting binary code. This reveals the difference between the architecture of a system and the
representation of that architecture. Given that an architecture can exist independently of its
description or specification, this raises the importance of architecture documentation, which
is described in Chapter 22.
1. In this book, we use the term “element” when we mean either a module or a component, and don’t want to distin-
guish between the two.
Not All Architectures Are Good Architectures

Our definition is indifferent as to whether the architecture for a system is a good one or a bad
one. An architecture may either support or hinder achieving the important requirements for
a system. Assuming that we do not accept trial and error as the best way to choose an archi-
tecture for a system—that is, picking an architecture at random, building the system from it,
and then hacking away and hoping for the best—this raises the importance of architecture
design, which is treated in Chapter 20 and architecture evaluation, which will be dealt with in
Chapter 21.
Architecture Includes Behavior

The behavior of each element is part of the architecture insofar as that behavior can help you
reason about the system. The behavior of elements embodies how they interact with each other
and with the environment. This is clearly part of our definition of architecture and will have an
effect on the properties exhibited by the system, such as its runtime performance.
Some aspects of behavior are below the architect’s level of concern. Nevertheless, to the
extent that an element’s behavior influences the acceptability of the system as a whole, this
behavior must be considered part of the system’s architectural design, and should be docu-
mented as such.
System and Enterprise Architectures

Two disciplines related to software architecture are system architecture and enterprise
architecture. Both of these disciplines have broader concerns than software and affect
software architecture through the establishment of constraints within which a software
system, and its architect, must live.
System Architecture
A system’s architecture is a representation of a system in which there is a mapping
of functionality onto hardware and software components, a mapping of the software
architecture onto the hardware architecture, and a concern for the human interaction
with these components. That is, system architecture is concerned with the totality of
hardware, software, and humans.
A system architecture will influence, for example, the functionality that is assigned
to different processors and the types of networks that connect those processors.
The software architecture will determine how this functionality is structured and how
the software programs residing on the various processors interact.
A description of the software architecture, as it is mapped to hardware and network-
ing components, allows reasoning about qualities such as performance and reliability.
A description of the system architecture will allow reasoning about additional qualities
such as power consumption, weight, and physical dimensions.
When designing a particular system, there is frequently negotiation between the
system architect and the software architect over the distribution of functionality and,
consequently, the constraints placed on the software architecture.
Enterprise Architecture
Enterprise architecture is a description of the structure and behavior of an organiza-
tion’s processes, information flow, personnel, and organizational subunits. An enterprise
architecture need not include computerized information systems—clearly, organizations
had architectures that fit the preceding definition prior to the advent of computers—but
these days enterprise architectures for all but the smallest businesses are unthinkable
without information system support. Thus a modern enterprise architecture is con-
cerned with how software systems support the enterprise’s business processes and
goals. Typically included in this set of concerns is a process for deciding which systems
with which functionality the enterprise should support.
An enterprise architecture will specify, for example, the data model that various sys-
tems use to interact. It will also specify rules for how the enterprise’s systems interact
with external systems.
Software is only one concern of enterprise architecture. How the software is used
by humans to perform business processes and the standards that determine the
computational environment are two other common concerns addressed by enterprise
architecture.
Sometimes the software infrastructure that supports communication among systems
and with the external world is considered a portion of the enterprise architecture; at
other times, this infrastructure is considered one of the systems within an enterprise.
(In either case, the architecture of that infrastructure is a software architecture!) These
two views will result in different management structures and spheres of influence for the
individuals concerned with the infrastructure.
Are These Disciplines in Scope for This Book? Yes! (Well, No.)
The system and the enterprise provide environments for, and constraints on, the
software architecture. The software architecture must live within the system and
the enterprise, and increasingly is the focus for achieving the organization’s business
goals. Enterprise and system architectures share a great deal with software architec-
tures. All can be designed, evaluated, and documented; all answer to requirements; all
are intended to satisfy stakeholders; all consist of structures, which in turn consist of
elements and relationships; all have a repertoire of patterns at their respective archi-
tects’ disposal; and the list goes on. So to the extent that these architectures share
commonalities with software architecture, they are in the scope of this book. But like all
technical disciplines, each has its own specialized vocabulary and techniques, and we
won’t cover those. Copious other sources exist that do.
1.2 Architectural Structures and Views
Because architectural structures are at the heart of our definition and treatment of software
architecture, this section will explore these concepts in more depth. These concepts are dealt
with in much greater depth in Chapter 22, where we discuss architecture documentation.
Architectural structures have counterparts in nature. For example, the neurologist, the
orthopedist, the hematologist, and the dermatologist all have different views of the various
structures of a human body, as illustrated in Figure 1.1. Ophthalmologists, cardiologists, and

podiatrists concentrate on specific subsystems. Kinesiologists and psychiatrists are concerned
with different aspects of the entire arrangement’s behavior. Although these views are pictured
differently and have very different properties, all are inherently related and interconnected:
Together they describe the architecture of the human body.
FIGURE 1.1 Physiological structures
Architectural structures also have counterparts in human endeavors. For example, elec-
tricians, plumbers, heating and air conditioning specialists, roofers, and framers are each con-
cerned with different structures in a building. You can readily see the qualities that are the
focus of each of these structures.
So it is with software.
Three Kinds of Structures

Architectural structures can be divided into three major categories, depending on the broad
nature of the elements they show and the kinds of reasoning they support:
1. Component-and-connector (C&C) structures focus on the way the elements interact
with each other at runtime to carry out the system’s functions. They describe how the
system is structured as a set of elements that have runtime behavior (components) and
interactions (connectors). Components are the principal units of computation and could
be services, peers, clients, servers, filters, or many other types of runtime element.
Connectors are the communication vehicles among components, such as call-return,
process synchronization operators, pipes, or others. C&C structures help answer ques-
tions such as the following:
■
What are the major executing components and how do they interact at runtime?
■
What are the major shared data stores?
■
Which parts of the system are replicated?
■
How does data progress through the system?
■
Which parts of the system can run in parallel?
■
Can the system’s structure change as it executes and, if so, how?
By extension, these structures are crucially important for asking questions about the
system’s runtime properties, such as performance, security, availability, and more.
C&C structures are the most common ones that we see, but two other categories of
structures are important and should not be overlooked.
Figure 1.2 shows a sketch of a C&C structure of a system using an informal notation
that is explained in the figure’s key. The system contains a shared repository that is
accessed by servers and an administrative component. A set of client tellers can interact
with the account servers and communicate among themselves using a publish-subscribe
connector.
2. Module structures partition systems into implementation units, which in this book we
call modules. Module structures show how a system is structured as a set of code or data
units that have to be constructed or procured. Modules are assigned specific computa-
tional responsibilities and are the basis of work assignments for programming teams. In
any module structure, the elements are modules of some kind (perhaps classes, packages,
layers, or merely divisions of functionality, all of which are units of implementation).
Modules represent a static way of considering the system. Modules are assigned areas of
functional responsibility; there is less emphasis in these structures on how the resulting
software manifests itself at runtime. Module implementations include packages, classes,
and layers. Relations among modules in a module structure include uses, generalization
(or “is-a”), and “is part of.” Figures 1.3 and 1.4 show examples of module elements and
relations, respectively, using the Unified Modeling Language (UML) notation.
Client Teller 1
Account Account
Server—Main Server—Backup
Account Administrative
Database
Key
Interface
Client
Publish-subscribe
Server
Client-server
request/reply
Database w/automatic
failover
Database Database
application access
FIGURE 1.2 A component-and-connector structure

CommonDialog Abstract class

System.IO.Log Package (italics)
Class with provided

interface
SaveFileDialog Class
UIElement
IAnimatable
SaveFileDialog
Class showing
FileName attribute and Interface not
«interface» shown as
Filter operation
IAnimatable lollipop
compartments
ShowDialog()
OnFileOk(…)
FIGURE 1.3 Module elements in UML
com.sun.ebank.web
Dispatcher
com.sun.ebank.web.taglib
Is-part-of Depends-on
«use»
relation relation
Context
Dispatcher BeanManager
Listener
«interface»
Account
Observer
Two forms of
is-a relation (class
inheritance and
interface realization)
Checking Savings Admin

Account Account AccountView
FIGURE 1.4 Module relations in UML

Module structures allow us to answer questions such as the following:

■
What is the primary functional responsibility assigned to each module?
■
What other software elements is a module allowed to use?
■
What other software does it actually use and depend on?
■
What modules are related to other modules by generalization or specialization (i.e.,
inheritance) relationships?
Module structures convey this information directly, but they can also be used to
answer questions about the impact on the system when the responsibilities assigned
to each module change. Thus module structures are the primary tools for reasoning
about a system’s modifiability.
3. Allocation structures establish the mapping from software structures to the system’s
nonsoftware structures, such as its organization, or its development, test, and execution
environments. Allocation structures answer questions such as the following:
■
Which processor(s) does each software element execute on?
■
In which directories or files is each element stored during development, testing, and
system building?
■
What is the assignment of each software element to development teams?
Some Useful Module Structures

Useful module structures include:
■
Decomposition structure. The units are modules that are related to each other by the
“is-a-submodule-of” relation, showing how modules are decomposed into smaller mod-
ules recursively until the modules are small enough to be easily understood. Modules in
this structure represent a common starting point for design, as the architect enumerates
what the units of software will have to do and assigns each item to a module for subse-
quent (more detailed) design and eventual implementation. Modules often have products
(such as interface specifications, code, and test plans) associated with them. The decom-
position structure determines, to a large degree, the system’s modifiability. That is, do
changes fall within the purview of a few (preferably small) modules? This structure is
often used as the basis for the development project’s organization, including the structure
of the documentation, and the project’s integration and test plans. Figure 1.5 shows an
example of a decomposition structure.
■
Uses structure. In this important but often overlooked structure, the units are also mod-
ules, and perhaps classes. The units are related by the uses relation, a specialized form
of dependency. One unit of software uses another if the correctness of the first requires
the presence of a correctly functioning version (as opposed to a stub) of the second. The
uses structure is used to engineer systems that can be extended to add functionality,
or from which useful functional subsets can be extracted. The ability to easily create a
subset of a system allows for incremental development. This structure is also the basis
ATIA-M
Windows apps
Common code
for thick clients
TDDT UTMC
Windows app Windows app
ATIA server- ATIA server-

side web side Java
modules modules
Notation: UML
FIGURE 1.5 A decomposition structure
for measuring social debt—the amount of communication that actually is, as opposed
to merely should be, taking place among teams—as it defines which teams should be
talking to each other. Figure 1.6 shows a uses structure and highlights the modules that
must be present in an increment if the module admin.client is present.
■
Layer structure. The modules in this structure are called layers. A layer is an abstract
“virtual machine” that provides a cohesive set of services through a managed interface.
Layers are allowed to use other layers in a managed fashion; in strictly layered systems,
a layer is only allowed to use a single other layer. This structure imbues a system with
portability—that is, the ability to change the underlying virtual machine. Figure 1.7
shows a layer structure of the UNIX System V operating system.
estore.webapp web::estore admin.client

«use»
Static
web
artifacts
«use»
«use»
«use»
«use»
web::shared
«use»
admin.core
web::accessControl
estore.core «use»
«use»
«use»
«use» «use»
«use»
dao
util
«use»
Notation: UML «use»
FIGURE 1.6 Uses structure
User programs
Libraries
System call interface
Process control subsystem

File subsystem
(IPC, scheduler, memory mgmt)
Buffering
mechanism
Character Block I/O

device drivers device drivers
Hardware control
Key
User-level Kernel-level Allowed
layer layer to use
FIGURE 1.7 Layer structure

■
Class (or generalization) structure. The modules in this structure are called classes, and
they are related through an “inherits-from” or “is-an-instance-of” relation. This view
supports reasoning about collections of similar behavior or capability and parameterized
differences. The class structure allows one to reason about reuse and the incremental
addition of functionality. If any documentation exists for a project that has followed
an object-oriented analysis and design process, it is typically this structure. Figure 1.8
shows a generalization structure taken from an architectural expert tool.
java.util.Observable Notation: UML
Fact
id : int
type : String
ScenarioVO
FunctionVO
ScenarioRespVO
FunctionRespVO RelationshipVO QuestionToUserVO
ResponsibilityVO ParameterVO
FIGURE 1.8 Generalization structure
■
Data model. The data model describes the static information structure in terms of data
entities and their relationships. For example, in a banking system, entities will typically
include Account, Customer, and Loan. Account has several attributes, such as account
number, type (savings or checking), status, and current balance. A relationship may
dictate that one customer can have one or more accounts, and one account is associated
with one or more customers. Figure 1.9 shows an example of a data model.
PurchaseOrder
OrderItem CatalogItem
PK poId INTEGER PK,FK1 poId INTEGER PK itemId INTEGER
PK,FK2 itemId INTEGER
FK3,I1 clientId INTEGER name VARCHAR(80)
FK1 shippingInfoId INTEGER qty NUMERIC(10,2) description TEXT(400)
FK2 billingInfoId INTEGER listPrice NUMERIC(10,2)
unit CHAR(10)
FK4 creditCardId INTEGER status INTEGER
price NUMERIC(10,2)
totalPrice NUMERIC(10,2)
Legend
For each A, there are 0 or more Bs;
Entity A B each B is related to exactly one A;
A’s PK is needed as part of B’s PK
PK = Primary key Column name Data type

FK# = Foreign key (bold means
I# = Index required column)
FIGURE 1.9 Data model
Some Useful C&C Structures

C&C structures show a runtime view of the system. In these structures, the modules just
described have all been compiled into executable forms. Thus all C&C structures are orthog-
onal to the module-based structures and deal with the dynamic aspects of a running system.
For example, one code unit (module) could be compiled into a single service that is repli-
cated thousands of times in an execution environment. Or 1,000 modules can be compiled and
linked together to produce a single runtime executable (component).
The relation in all C&C structures is attachment, showing how the components and the
connectors are hooked together. (The connectors themselves can be familiar constructs such
as “invokes.”) Useful C&C structures include:
■
Service structure. The units here are services that interoperate through a service coordi-
nation mechanism, such as messages. The service structure is an important structure to
help engineer a system composed of components that may have been developed inde-
pendently of each other.
■
Concurrency structure. This C&C structure allows the architect to determine opportuni-
ties for parallelism and the locations where resource contention may occur. The units are
components, and the connectors are their communication mechanisms. The components
are arranged into “logical threads.” A logical thread is a sequence of computations that
could be allocated to a separate physical thread later in the design process. The concur-
rency structure is used early in the design process to identify and manage issues associ-
ated with concurrent execution.
Some Useful Allocation Structures

Allocation structures define how the elements from C&C or module structures map onto things
that are not software—typically hardware (possibly virtualized), teams, and file systems.
Useful allocation structures include:
■
Deployment structure. The deployment structure shows how software is assigned to
hardware processing and communication elements. The elements are software elements
(usually a process from a C&C structure), hardware entities (processors), and commu-
nication pathways. Relations are “allocated-to,” showing on which physical units the
software elements reside, and “migrates-to,” if the allocation is dynamic. This structure
can be used to reason about performance, data integrity, security, and availability. It is of
particular interest in distributed systems and is the key structure involved in the achieve-
ment of the quality attribute of deployability (see Chapter 5). Figure 1.10 shows a simple
deployment structure in UML.
Internet *
user PC
1 «Win server»
«internet» Application server
«intranet»
«execution
environment»
1 «Linux server»
:WebSphere Database server
«Win desktop»
«intranet»
Admin user 1
PC
«deploy»
«deploy»
«artifact»
«artifact» Notation:
app-client.jar EnterpriseWebApp.ear UML
FIGURE 1.10 Deployment structure
■
Implementation structure. This structure shows how software elements (usually mod-
ules) are mapped to the file structures in the system’s development, integration, test, or
configuration control environments. This is critical for the management of development
activities and build processes.
■
Work assignment structure. This structure assigns responsibility for implementing and
integrating the modules to the teams that will carry out these tasks. Having a work
assignment structure be part of the architecture makes it clear that the decision about
who does the work has architectural as well as management implications. The architect
will know the expertise required on each team. Amazon’s decision to devote a single
team to each of its microservices, for example, is a statement about its work assignment
structure. On large development projects, it is useful to identify units of functional com-
monality and assign those to a single team, rather than having them be implemented by
everyone who needs them. This structure will also determine the major communication
pathways among the teams: regular web conferences, wikis, email lists, and so forth.
Table 1.1 summarizes these structures. It lists the meaning of the elements and relations
in each structure and tells what each might be used for.
Relating Structures to Each Other

Each of these structures provides a different perspective and design handle on a system, and
each is valid and useful in its own right. Although the structures give different system perspec-
tives, they are not independent. Elements of one structure will be related to elements of other
structures, and we need to reason about these relations. For example, a module in a decom-
position structure may be manifested as one, part of one, or several components in one of the
C&C structures, reflecting its runtime alter-ego. In general, mappings between structures are
many to many.
Figure 1.11 shows a simple example of how two structures might relate to each other. The
image on the left shows a module decomposition view of a tiny client-server system. In this
system, two modules must be implemented: the client software and the server software. The
image on the right shows a C&C view of the same system. At runtime, ten clients are running
and accessing the server. Thus this little system has two modules and eleven components (and
ten connectors).
C10
System C9 C1
Client C8 C2
S1
Server C7 C3
C6 C4
C5
Key: Module Key: Component
Request-Reply
Decomposition View Client-Server View
FIGURE 1.11 Two views of a client-server system

TABLE 1.1 Useful Architectural Structures
Software Element Types Relations Useful for Quality Concerns

Structure Affected
Module Decomposition Module Is a submodule of Resource allocation and project Modifiability
structures structuring and planning;
encapsulation
Uses Module Uses (i.e., requires the Designing subsets and “Subsetability,”
correct presence of) extensions extensibility
Layers Layer Allowed to use the services Incremental development; Portability,
of; provides abstraction to implementing systems on top of modifiability
“virtual machines”
Class Class, object Is an instance of; is a In object-oriented systems, Modifiability,
generalization of factoring out commonality; extensibility
planning extensions of
functionality
Data model Data entity {one, many}-to-{one, many}; Engineering global data Modifiability,
generalizes; specializes structures for consistency and performance
performance
C&C Service Service, service Attachment (via Scheduling analysis; Interoperability,
structures registry message-passing) performance analysis; availability,
robustness analysis modifiability
Concurrency Processes, Attachment (via Identifying locations where Performance
threads communication and resource contention exists,
synchronization opportunities for parallelism
mechanisms)
Allocation Deployment Components, Allocated to; migrates to Mapping software elements to Performance,
structures hardware system elements security, energy,
elements availability,
deployability
Implementation Modules, file Stored in Configuration control, Development
structure integration, test activities efficiency
Work assignment Modules, Assigned to Project management, best Development
organizational use of expertise and available efficiency
units resources, management of
commonality
Whereas the correspondence between the elements in the decomposition structure and
the client-server structure is obvious, these two views are used for very different things. For
example, the view on the right could be used for performance analysis, bottleneck prediction,
and network traffic management, which would be extremely difficult or impossible to do with
the view on the left. (In Chapter 9, we’ll learn about the map-reduce pattern, in which copies
of simple, identical functionality are distributed across hundreds or thousands of processing
nodes—one module for the whole system, but one component per node.)
Individual projects sometimes consider one structure to be dominant and cast other struc-
tures, when possible, in terms of the dominant structure. Often, the dominant structure is the
module decomposition structure, and for good reason: It tends to spawn the project structure,
since it mirrors the team structure of development. In other projects, the dominant structure might
be a C&C structure that shows how the system’s functionality and/or critical quality attributes
are achieved at runtime.
Fewer Is Better
Not all systems warrant consideration of many architectural structures. The larger the system,
the more dramatic the difference between these structures tends to be; but for small systems,
we can often get by with fewer structures. For example, instead of working with each of sev-
eral C&C structures, usually a single one will do. If there is only one process, then the process
structure collapses to a single node and need not be explicitly represented in the design. If
no distribution will occur (that is, if the system is implemented on a single processor), then
the deployment structure is trivial and need not be considered further. In general, you should
design and document a structure only if doing so brings a positive return on the investment,
usually in terms of decreased development or maintenance costs.
Which Structures to Choose?

We have briefly described a number of useful architectural structures, and many more are
certainly possible. Which ones should an architect choose to work on? Which ones should the
architect choose to document? Surely not all of them. A good answer is that you should think
about how the various structures available to you provide insight and leverage into the system’s
most important quality attributes, and then choose the ones that will play the best role in deliv-
ering those attributes.
Architectural Patterns
In some cases, architectural elements are composed in ways that solve particular problems.
These compositions have been found to be useful over time and over many different domains,
so they have been documented and disseminated. These compositions of architectural ele-
ments, which provide packaged strategies for solving some of the problems facing a system,
are called patterns. Architectural patterns are discussed in detail in Part II of this book.
1.3 What Makes a “Good” Architecture? 19
1.3 What Makes a “Good” Architecture?
There is no such thing as an inherently good or bad architecture. Architectures are either
more or less fit for some purpose. A three-tier layered service-oriented architecture may be
just the ticket for a large enterprise’s web-based B2B system but completely wrong for an
avionics application. An architecture carefully crafted to achieve high modifiability does not
make sense for a throw-away prototype (and vice versa!). One of the messages of this book is
that architectures can, in fact, be evaluated—one of the great benefits of paying attention to
them—but such evaluation only makes sense in the context of specific stated goals.
Nevertheless, some rules of thumb should be followed when designing most architec-
tures. Failure to apply any of these guidelines does not automatically mean that the archi-
tecture will be fatally flawed, but it should at least serve as a warning sign that should be
investigated. These rules can be applied proactively for greenfield development, to help build
the system “right.” Or they can be applied as analysis heuristics, to understand the potential
problem areas in existing systems and to guide the direction of its evolution.
We divide our observations into two clusters: process recommendations and product (or
structural) recommendations. Our process recommendations are as follows:
1. A software (or system) architecture should be the product of a single architect or a small
group of architects with an identified technical leader. This approach is important to
give the architecture its conceptual integrity and technical consistency. This recom-
mendation holds for agile and open source projects as well as “traditional” ones. There
should be a strong connection between the architects and the development team, to avoid
“ivory tower,” impractical designs.
2. The architect (or architecture team) should, on an ongoing basis, base the architecture on
a prioritized list of well-specified quality attribute requirements. These will inform the
tradeoffs that always occur. Functionality matters less.
3. The architecture should be documented using views. (A view is simply a representa-
tion of one or more architectural structures.) The views should address the concerns of
the most important stakeholders in support of the project timeline. This might mean
minimal documentation at first, with the documentation then being elaborated later.
Concerns usually are related to construction, analysis, and maintenance of the system,
as well as education of new stakeholders.
4. The architecture should be evaluated for its ability to deliver the system’s important
quality attributes. This should occur early in the life cycle, when it returns the most
benefit, and repeated as appropriate, to ensure that changes to the architecture (or the
environment for which it is intended) have not rendered the design obsolete.
5. The architecture should lend itself to incremental implementation, to avoid having to
integrate everything at once (which almost never works) as well as to discover problems
early. One way to do this is via the creation of a “skeletal” system in which the commu-
nication paths are exercised but which at first has minimal functionality. This skeletal
system can be used to “grow” the system incrementally, refactoring as necessary.
Our structural rules of thumb are as follows:

1. The architecture should feature well-defined modules whose functional responsibili-
ties are assigned on the principles of information hiding and separation of concerns.
The information-hiding modules should encapsulate things likely to change, thereby
insulating the software from the effects of those changes. Each module should have a
well-defined interface that encapsulates or “hides” the changeable aspects from other
software that uses its facilities. These interfaces should allow their respective develop-
ment teams to work largely independently of each other.
2. Unless your requirements are unprecedented—possible, but unlikely—your quality
attributes should be achieved by using well-known architectural patterns and tactics
(described in Chapters 4 through 13) specific to each attribute.
3. The architecture should never depend on a particular version of a commercial product or
tool. If it must, it should be structured so that changing to a different version is straight-
forward and inexpensive.
4. Modules that produce data should be separate from modules that consume data. This
tends to increase modifiability because changes are frequently confined to either the
production or the consumption side of data. If new data is added, both sides will have to
change, but the separation allows for a staged (incremental) upgrade.
5. Don’t expect a one-to-one correspondence between modules and components. For exam-
ple, in systems with concurrency, multiple instances of a component may be running in
parallel, where each component is built from the same module. For systems with multiple
threads of concurrency, each thread may use services from several components, each of
which was built from a different module.
6. Every process should be written so that its assignment to a specific processor can be
easily changed, perhaps even at runtime. This is a driving force in the increasing trends
toward virtualization and cloud deployment, as we will discuss in Chapters 16 and 17.
7. The architecture should feature a small number of simple component interaction patterns.
That is, the system should do the same things in the same way throughout. This practice
will aid in understandability, reduce development time, increase reliability, and enhance
modifiability.
8. The architecture should contain a specific (and small) set of resource contention areas,
whose resolution is clearly specified and maintained. For example, if network utilization
is an area of concern, the architect should produce (and enforce) for each development
team guidelines that will result in acceptable levels of network traffic. If performance is
a concern, the architect should produce (and enforce) time budgets.
1.4 Summary
The software architecture of a system is the set of structures needed to reason about the sys-
tem. These structures comprise software elements, relations among them, and properties of
both.
There are three categories of structures:
■
Module structures show the system as a set of code or data units that have to be con-
structed or procured.
■
Component-and-connector structures show the system as a set of elements that have
runtime behavior (components) and interactions (connectors).
■
Allocation structures show how elements from module and C&C structures relate to
nonsoftware structures (such as CPUs, file systems, networks, and development teams).
Structures represent the primary engineering leverage points of an architecture. Each
structure brings with it the power to manipulate one or more quality attributes. Collectively,
structures represent a powerful approach for creating the architecture (and, later, for analyzing
it and explaining it to its stakeholders). And, as we will see in Chapter 22, the structures that
the architect has chosen as engineering leverage points are also the primary candidates to
choose as the basis for architecture documentation.
Every system has a software architecture, but this architecture may or may not be docu-
mented and disseminated.
There is no such thing as an inherently good or bad architecture. Architectures are either
more or less fit for some purpose.
1.5 For Further Reading
If you’re keenly interested in software architecture as a field of study, you might be interested
in reading some of the pioneering work. Most of it does not mention “software architecture”
at all, as this phrase evolved only in the mid-1990s, so you’ll have to read between the lines.
Edsger Dijkstra’s 1968 paper on the T.H.E. operating system introduced the concept
of layers [Dijkstra 68]. The early work of David Parnas laid many conceptual foundations,
including information hiding [Parnas 72], program families [Parnas 76], the structures inher-
ent in software systems [Parnas 74], and the uses structure to build subsets and supersets of
systems [Parnas 79]. All of Parnas’s papers can be found in the more easily accessible collec-
tion of his important papers [Hoffman 00]. Modern distributed systems owe their existence to
the concept of cooperating sequential processes that (among others) Sir C. A. R. (Tony) Hoare
was instrumental in conceptualizing and defining [Hoare 85].
In 1972, Dijkstra and Hoare, along with Ole-Johan Dahl, argued that programs should be
decomposed into independent components with small and simple interfaces. They called their
approach structured programming, but arguably this was the debut of software architecture
[Dijkstra 72].
Mary Shaw and David Garlan, together and separately, produced a major body of work
that helped create the field of study we call software architecture. They established some of
its fundamental principles and, among other things, catalogued a seminal family of architec-
tural styles (a concept similar to patterns), several of which appear in this chapter as architectural
structures. Start with [Garlan 95].
Software architectural patterns have been extensively catalogued in the series Pattern-
Oriented Software Architecture [Buschmann 96 and others]. We also deal with architectural
patterns throughout Part II of this book.
Early papers on architectural views as used in industrial development projects are [Soni 95]
and [Kruchten 95]. The former grew into a book [Hofmeister 00] that presents a comprehen-
sive picture of using views in development and analysis.
A number of books have focused on practical implementation issues associated with archi-
tectures, such as George Fairbanks’ Just Enough Software Architecture [Fairbanks 10], Woods
and Rozanski’s Software Systems Architecture [Woods 11], and Martin’s Clean Architecture:
A Craftsman’s Guide to Software Structure and Design [Martin 17].
1.6 Discussion Questions
1. Is there a different definition of software architecture that you are familiar with? If
so, compare and contrast it with the definition given in this chapter. Many definitions
include considerations like “rationale” (stating the reasons why the architecture is what
it is) or how the architecture will evolve over time. Do you agree or disagree that these
considerations should be part of the definition of software architecture?
2. Discuss how an architecture serves as a basis for analysis. What about decision making?
What kinds of decision making does an architecture empower?
3. What is architecture’s role in project risk reduction?
4. Find a commonly accepted definition of system architecture and discuss what it has in
common with software architecture. Do the same for enterprise architecture.
5. Find a published example of a software architecture. Which structures are shown? Given
its purpose, which structures should have been shown? What analysis does the architec-
ture support? Critique it: What questions do you have that the representation does not
answer?
6. Sailing ships have architectures, which means they have “structures” that lend them-
selves to reasoning about the ship’s performance and other quality attributes. Look
up the technical definitions for barque, brig, cutter, frigate, ketch, schooner, and
sloop. Propose a useful set of “structures” for distinguishing and reasoning about ship
architectures.
7. Aircraft have architectures that can be characterized by how they resolve some major
design questions, such as engine location, wing location, landing gear layout, and more.
For many decades, most jet aircraft designed for passenger transport have the following
characteristics:
■
Engines housed in nacelles slung underneath the wing (as opposed to engines built into
the wings, or engines mounted on the rear of the fuselage)
■
Wings that join the fuselage at the bottom (as opposed to the top or middle)
First, do an online search to find an example and a counter-example of this type
of design from each of the following manufacturers: Boeing, Embraer, Tupolev, and
Bombardier. Next, do some online research and answer the following question: What
qualities important to aircraft does this design provide?
2
Why Is Software Architecture
Important?
Ah, to build, to build!
That is the noblest art of all the arts.
—Henry Wadsworth Longfellow
If architecture is the answer, what was the question?

This chapter focuses on why architecture matters from a technical perspective. We will
examine a baker’s dozen of the most important reasons. You can use these reasons to moti-
vate the creation of a new architecture, or the analysis and evolution of an existing system’s
architecture.
1. An architecture can either inhibit or enable a system’s driving quality attributes.
2. The decisions made in an architecture allow you to reason about and manage change as
the system evolves.
3. The analysis of an architecture enables early prediction of a system’s qualities.
4. A documented architecture enhances communication among stakeholders.
5. The architecture is a carrier of the earliest, and hence most-fundamental, hardest-to-
change design decisions.
6. An architecture defines a set of constraints on subsequent implementation.
7. The architecture dictates the structure of an organization, or vice versa.
8. An architecture can provide the basis for incremental development.
9. An architecture is the key artifact that allows the architect and the project manager to
reason about cost and schedule.
10. An architecture can be created as a transferable, reusable model that forms the heart of a
product line.
11. Architecture-based development focuses attention on the assembly of components, rather
than simply on their creation.
12. By restricting design alternatives, architecture channels the creativity of developers,
reducing design and system complexity.
13. An architecture can be the foundation for training of a new team member.
25
26 Part I Introduction | Chapter 2 Why Is Software Architecture Important?
Even if you already believe us that architecture is important and don’t need that point
hammered home 13 more times, think of these 13 points (which form the outline for this chap-
ter) as 13 useful ways to use architecture in a project, or to justify the resources devoted to
architecture.
2.1 Inhibiting or Enabling a System’s Quality Attributes
A system’s ability to meet its desired (or required) quality attributes is substantially deter-
mined by its architecture. If you remember nothing else from this book, remember that.
This relationship is so important that we’ve devoted all of Part II of this book to expound-
ing that message in detail. Until then, keep these examples in mind as a starting point:
■
If your system requires high performance, then you need to pay attention to managing
the time-based behavior of elements, their use of shared resources, and the frequency
and volume of their interelement communication.
■
If modifiability is important, then you need to pay attention to assigning responsibilities
to elements and limiting the interactions (coupling) of those elements so that the major-
ity of changes to the system will affect a small number of those elements. Ideally, each
change will affect just a single element.
■
If your system must be highly secure, then you need to manage and protect interelement
communication and control which elements are allowed to access which information.
You may also need to introduce specialized elements (such as an authorization mechanism)
into the architecture to set up a strong “perimeter” to guard against intrusion.
■
If you want your system to be safe and secure, you need to design in safeguards and
recovery mechanisms.
■
If you believe that scalability of performance will be important to the success of your
system, then you need to localize the use of resources to facilitate the introduction of
higher-capacity replacements, and you must avoid hard-coding in resource assumptions
or limits.
■
If your projects need the ability to deliver incremental subsets of the system, then you
must manage intercomponent usage.
■
If you want the elements from your system to be reusable in other systems, then you need
to restrict interelement coupling so that when you extract an element, it does not come
out with too many attachments to its current environment to be useful.
The strategies for these and other quality attributes are supremely architectural. But an
architecture alone cannot guarantee the functionality or quality required of a system. Poor
downstream design or implementation decisions can always undermine an adequate architec-
tural design. As we like to say (mostly in jest): What the architecture giveth, the implementa-
tion may taketh away. Decisions at all stages of the life cycle—from architectural design to
coding and implementation and testing—affect system quality. Therefore, quality is not com-
pletely a function of an architectural design. But that’s where it starts.
Another random document with
no related content on Scribd:
Bull and the Cockpit probably whistled the tune as they wended their
way homeward to crab-apple ale and spiced gingerbread.
Next to the Champions of Christendom, the King’s Knight Champion
of England is perhaps the most important personage—in the point of
view of chivalry. I think it is some French author who has said, that
revolutions resemble the game of chess, where the pawns or pieces
(les pions) may cause the ruin of the king, save him, or take his
place. Now the champ pion, as this French remark reminds me, is
nothing more than the field pion, pawn, or piece, put forward to fight
in the king’s quarrel.
The family of the Champion of England bears, it may be observed,
exactly the name which suits a calling so derived. The appellation
“Dymoke” is derived from De Umbrosâ Quercu; I should rather say it
is the translation of it; and Harry De Umbrosâ Quercu is only Harry of
the Shady or Dim Oak, a very apt dwelling-place and name for one
whose chief profession was that of field-pawn to the king.
This derivation or adaptation of names from original Latin surnames
is common enough, and some amusing pages might be written on
the matter, in addition to what has been so cleverly put together by
Mr. Mark Anthony Lower, in his volume devoted especially to an
elucidation of English surnames.
The royal champions came in with the Conquest. The Norman dukes
had theirs in the family of Marmion—ancestors of that Marmion of Sir
Walter Scott’s, who commits forgery, like a common knave of more
degenerate times. The Conqueror conferred sundry broad lands in
England on his champions; among others, the lands adjacent to, as
well as the castle of Tamworth. Near this place was the first nunnery
established in this country. The occupants were the nuns of St.
Edith, at Polesworth. Robert de Marmion used the ladies very
“cavalierly,” ejected them from their house, and deprived them of
their property. But such victims had a wonderfully clever way of
recovering their own.
My readers may possibly remember how a certain Eastern potentate
injured the church, disgusted the Christians generally, and irritated
especially that Simeon Stylites who sat on the summit of a pillar,
night and day, and never moved from his abiding-place. The offender
had a vision, in which he not only saw the indignant Simeon, but was
cudgelled almost into pulp by the simulacre of that saint. I very much
doubt if Simeon himself was in his airy dwelling-place at that
particular hour of the night. I was reminded of this by what happened
to the duke’s champion, Robert de Marmion. He was roused from a
deep sleep by the vision of a stout lady, who announced herself as
the wronged St. Edith, and who proceeded to show her opinion of De
Marmion’s conduct toward her nuns, by pommelling his ribs with her
crosier, until she had covered his side with bruises, and himself with
repentance. What strong-armed young monk played St. Edith that
night, it is impossible to say; but that he enacted the part
successfully, is seen from the fact that Robert brought back the
ladies to Polesworth, and made ample restitution of all of which they
had been deprived. The nuns, in return, engaged with alacrity to inter
all defunct Marmions within the chapter-house of their abbey, for
nothing.
With the manor of Tamworth in Warwickshire, Marmion held that of
Scrivelsby in Lincolnshire. The latter was held of the King by grand
sergeantry, “to perform the office of champion at the King’s
coronation.” At his death he was succeeded by a son of the same
Christian name, who served the monks of Chester precisely as his
sire had treated the nuns at Polesworth. This second Robert fortified
his ill-acquired prize—the priory; but happening to fall into one of the
newly-made ditches, when inspecting the fortifications, a soldier of
the Earl of Chester killed him, without difficulty, as he lay with broken
hip and thigh, at the bottom of the fosse. The next successor, a third
Robert, was something of a judge, with a dash of the warrior, too,
and he divided his estates between two sons, both Roberts, by
different mothers. The eldest son and chief possessor, after a
bustling and emphatically “battling” life, was succeeded by his son
Philip, who fell into some trouble in the reign of Henry III. for
presuming to act as a judge or justice of the peace, without being
duly commissioned. This Philip was, nevertheless, one of the most
faithful servants to a king who found so many faithless; and if honors
were heaped upon him in consequence, he fairly merited them all.
He was happy, too, in marriage, for he espoused a lady sole heiress
to a large estate, and who brought him four daughters, co-heiresses
to the paternal and maternal lands of the Marmions and the Kilpecs.
This, however, is wandering. Let us once more return to orderly
illustration. In St. George I have shown how pure romance deals with
a hero. In the next chapter I will endeavor to show in what spirit the
lives and actions of real English heroes have been treated by native
historians. In so doing, I will recount the story of Sir Guy of Warwick,
after their fashion, with original illustrations and “modern instances.”
SIR GUY OF WARWICK,
AND WHAT BEFELL HIM.
“His desires
Are higher than his state, and his deserts
Not much short of the most he can desire.”
Chapman’s Byron’s Conspiracy.
The Christian name of Guy was once an exceedingly popular name

in the county of York. I have never heard a reason assigned for this,
but I think it may have originated in admiration of the deeds and the
man whose appellation and reputation have survived to our times. I
do not allude to Guy Faux; that young gentleman was the Father of
Perverts, but by no means the first of the Guys.
The “Master Guy” of whom I am treating here, or, rather, about to
treat, was a youth whose family originally came from
Northumberland. That family was, in one sense, more noble than the
imperial family of Muscovy, for its members boasted not only of good
principles, but of sound teeth.
The teeth and principles of the Romanoffs are known to be in a
distressing state of dilapidation.
Well; these Northumbrian Guys having lived extremely fast, and
being compelled to compound with their creditors, by plundering the
latter, and paying them zero in the pound, migrated southward, and
finally settled in Warwickshire. Now, the head of the house had a
considerable share of common sense about him, and after much
suffering in a state of shabby gentility, he not only sent his daughters
out to earn their own livelihood, but, to the intense disgust of his
spouse, hired himself as steward to that noble gentleman the Earl of
Warwick. “My blood is as good as ever it was,” said he to the fine
lady his wife. “It is the blood of an upper servant,” cried she, “and my
father’s daughter is the spouse of a flunkey.”
The husband was not discouraged; and he not only opened his office
in his patron’s castle but he took his only son with him, and made
him his first clerk. This son’s name was Guy; and he was rather
given to bird-catching, hare-snaring, and “gentism” generally. He had
been a precocious youth from some months previous to his birth,
and had given his lady-mother such horrid annoyance, that she was
always dreaming of battles, fiery-cars, strong-smelling dragons, and
the wrathful Mars. “Well,” she used to remark to her female friends,
while the gentlemen were over their wine, “I expect that this boy”
(she had made up her mind to that) “will make a noise in the world,
draw bills upon his father, and be the terror of maid-servants. Why,
do you know——” and here she became confidential, and I do not
feel authorized to repeat what she then communicated.
But Master Guy, the “little stranger” alluded to, proved better than
was expected. He might have been considerably worse, and yet
would not have been so bad as maternal prophecy had depicted
him. At eight years ... but I hear you say, “When did all this occur?”
Well, it was in a November’s “Morning Post,” that announcement
was made of the birth; and as to the year, Master Guy has given it
himself in the old metrical romance,
“Two hundred and twenty years and odd,

After our Savior Christ his birth,
When King Athelstan wore the crown,
I livéd here upon the earth.”
At eight years old, I was about to remark, young Guy was the most
insufferable puppy of his district. He won all the prizes for athletic
sports; and by the time he was sixteen there was not a man in all
England who dared accept his challenge to wrestle with both arms,
against him using only one.
It was at this time that he kept his father’s books and a leash of
hounds, with the latter of which he performed such extraordinary
feats, that the Earl of Warwick invited him from the steward’s room to
his own table; where Guy’s father changed his plate, and Master
Guy twitched him by the beard as he did it.
At the head of the earl’s table sat his daughter “Phillis the Fair,” a
lady who, like her namesake in the song, was “sometimes forward,
sometimes coy,” and altogether so sweetly smiling and so beguiling,
that when the earl asked Guy if he would not come and hunt (the
dinner was at 10 a. m.), Guy answered, as the Frenchman did who
could not bear the sport, with a Merci, j’ai été! and affecting an iliac
seizure, hinted at the necessity of staying at home.
The youth forthwith was carried to bed. Phillis sent him a posset, the
earl sent him his own physician; and this learned gentleman, after
much perplexity veiled beneath the most affable and confident
humbug, wrote a prescription which, if it could do the patient no good
would do him no harm. He was a most skilful man, and his patients
almost invariably recovered under this treatment. He occasionally
sacrificed one or two when a consultation was held, and he was
called upon to prescribe secundum artem; but he compensated for
this professional slaying by, in other cases, leaving matters to
Nature, who was the active partner in his firm, and of whose success
he was not in the least degree jealous. So, when he had written the
prescription, Master Guy fell a discoursing of the passion of love,
and that with a completeness and a variety of illustration as though
he were the author of the chapter on that subject in Burton’s
“Anatomy of Melancholy.” The doctor heard him to the end, gently
rubbing one side of his nose the while with the index-finger of his
right hand; and when his patient had concluded, the medical
gentleman smiled, hummed “Phillis is my only joy,” and left the room
with his head nodding like a Chinese Mandarin’s.
By this time the four o’clock sun was making green and gold pillars
of the trees in the neighboring wood, and Guy got up, looked at the
falling leaves, and thought of the autumn of his hopes. He whistled
“Down, derry, down,” with a marked emphasis on the down; but
suddenly his hopes again sprang up, as he beheld Phillis among her
flower-beds, engaged in the healthful occupation which a sublime
poet has given to the heroine whom he names, and whose action he
describes, when he tells us that
“Miss Dinah was a-walking in her garding one day.”

Guy trussed his points, pulled up his hose, set his bonnet smartly on
his head, clapped a bodkin on his thigh, and then walked into the
garden with the air of the once young D’Egville in a ballet, looking
after a nymph—which indeed was a pursuit he was much given to
when he was old D’Egville, and could no longer bound through his
ballets, because he was stiff in the joints.
Guy, of course, went down on one knee, and at once plunged into
the most fiery style of declaration, but Phillis had not read the Mrs.
Chapone of that day for nothing. She brought him back to prose and
propriety, and then the two started afresh, and they did talk! Guy felt
a little “streaked” at first, but he soon recovered his self-possession,
and it would have been edifying for the young mind to have heard
how these two pretty things spoke to, and answered each other in
moral maxims stolen from the top pages of their copy-books. They
poured them out by the score, and the proverbial philosophy they
enunciated was really the origin of the book so named by Martin
Tupper. He took it all from Phillis and Guy, whose descendants, of
the last name, were so famous for their school-books. This I expect
Mr. Tupper will (not) mention in his next edition.
After much profitable interchange of this sort of article, the lady
gently hinted that Master Guy was not indifferent to her, but that he
was of inferior birth, yet of qualities that made him equal with her;
adding, that hitherto he had done little but kill other people’s game,
whereas there were nobler deeds to be accomplished. And then she
bade him go in search of perilous adventures, winding up with the
toast and sentiment, “Master Guy, eagles do not care to catch flies.”
Reader, if you have ever seen the prince of pantomimists, Mr.
Payne, tear the hair of his theatrical wig in a fit of amorous despair,
you may have some idea as to the intensity with which Master Guy
illustrated his own desperation. He stamped the ground with such
energy that all the hitherto quiet aspens fell a-shaking, and their
descendants have ever since maintained the same fashion. Phillis
fell a-crying at this demonstration, and softened considerably. After a
lapse of five minutes, she had blushingly directed Master Guy to
“speak to papa.”
Now, of all horrible interviews, this perhaps is the most horrible.
Nelson used to say that there was only one thing on earth which he
dreaded, and that was dining with a mayor and corporation.
Doubtless it is dreadful, but what is it compared with looking a grave
man in the face, who has no sentiment into him, and whose first
remark is sure to be, “Well, sir, be good enough to tell me—what can
you settle on my daughter? What can you do to secure her
happiness?”
“Well,” said Guy, in reply to this stereotyped remark, “I can kill the
Dun cow on the heath. She has killed many herself who’ve tried the
trick on her; and last night she devoured crops of clover, and twice
as many fields of barley on your lordship’s estate.”
“First kill the cow, and then——,” said the earl with a smile; and
Shakespeare had the echo of this speech in his ear, when he began
the fifth act of his Othello. Now Guy was not easily daunted. If I
cared to make a pun, I might easily have said “cowed,” but in a grave
and edifying narrative this loose method of writing would be
extremely improper. Guy, then, was not a coward—nay, nothing is
hidden under the epithet. He tossed a little in bed that night as he
thought the matter over, and the next morning made sheets of paper
as crumpled as the cow’s horns, as he rejected the plans of assault
he had designed upon them, and sat uncertain as to what he should
do in behoof of his own fortune. He at length determined to go and
visit the terrible animal “incognito.” It is the very word used by one of
the biographers of Guy, an anonymous Northumbrian, who published
the life on a broad sheet, with a picture of Master Guy which might
have frightened the cow, and which is infinitely more ugly. Neither
the black-letter poem, the old play, nor the pamphlets or ballads, use
the term incognito, but all declare that Guy proceeded with much
caution, and a steel cuirass over his jerkin. I mention these things,
because without correctness my narrative would be worthless. I am
not imaginative, and would not embroider a plain suit of fact upon
any account.
Guy’s carefulness is to be proved. Here was a cow that had been
more destructive than ever Red Riding Hood’s Wolf was—that Count
Wolf, who used to snap up young maidens, and lived as careless of
respectability as was to be expected of a man once attached to a
“marching regiment,” and who turned monk. The cow was twelve
feet high, from the hoof to the shoulder, and eighteen feet long, from
the neck to the root of the tail. All the dragons ever heard of had
never been guilty of such devastation to life and property as this
terrible cow. Guy looked at her and did not like her. The cow
detected him and rushed at her prey. Guy was active, attacked her in
front and rear, as the allies did the forts of Bomarsund; very
considerably confused her by burying his battle-axe in her skull;
hung on by her tail as she attempted to fly; and finally gave her the
coup de grace by passing his rapier rapidly and repeatedly through
her especially vulnerable point behind the ear. In proof of the fact,
the scene of the conflict still bears the name of Dunsmore Heath,
and that is a wider basis of proof than many “facts” stand upon, to
which we are required by plodding teachers to give assent.
Besides, there is a rib of this very cow exhibited at Bristol. To be sure
it is not a rib now of a cow, but out of reverence to the antiquity of the
assertion which allegedly makes it so, I think we are bound to
believe what is thus advanced. Not that I do myself, but that is of no
consequence. I have a strong idea that the cow was not a cow, but a
countess (not a Countess Cowper), who made war in her own right,
lived a disreputable life, was as destructive to wealthy young lords as
a Lorette, and won whole estates by cheating at écarté. Guy took a
hand, and beat her.
Poor Master Guy, he was as hardly used as ever Jacob was, and
much he meditated thereupon in the fields at eventide. The stern earl
would by no means give his consent to the marriage of his daughter
with the young champion, until the latter had performed some
doughtier deeds than this. The boy (he was still in his teens) took
heart of grace, divided a crooked sixpence with Phillis, and
straightway sailed for Normandy, where he arrived, after meeting as
many thieves by the way as if he had walked about for a month in
the streets of Dover. But Master Guy killed all he met; there is a
foolish judicial, not to say social, prejudice against our doing the
same with the bandits of Dover. I can not conjecture why; perhaps
they have a privilege under some of the city companies, whereby
they are constituted the legal skinners of all sojourners among them,
carrying filthy lucre.
Guy met in Normandy with the last person he could have expected
to fall in with—no other than the Emperor of Almayne, a marvellously
ubiquitous person to be met with in legends, and frequently
encountered in the seaports of inland towns. The historians are here
a little at issue. One says that Master Guy having found a certain
Dorinda tied to the stake, and awaiting a champion who would stake
his own life for her rescue, inquired the “antecedents” of the position.
Dorinda, it appears, had been as rudely used as young lady possibly
could be, “by the Duke of Blois, his son,” and the duke was so
enraged at Dorinda’s charge against his favorite Otto, that he
condemned her to be burned alive, unless a champion appeared in
time to rescue her by defeating the aforesaid Otto in single combat.
Guy, of course, transacted the little business successfully; spoiled
Otto’s beauty by slashing his nose; and so enchanted Dorinda, that
she never accused her champion of doing aught displeasing to her.
Anxious as I am touching the veracity of this narrative, I have
recorded what biographers state, though not in their own words. But
I must add, that in some of the histories this episode about Dorinda
is altogether omitted, and we only hear of Master Guy appearing in
panoply at a tournament given by the Emperor of Allemagne, in
Normandy—which is much the same, gentle reader, as if I were, at
your cost, to give a concert and ball, with a supper from Farrance’s,
and all, not in my house, but in yours. Nevertheless, in Normandy
the tournament was held, and the paternal Emperor of Allemagne,
having then a daughter, Blanche, of whom he wished to get rid, he
set her up as the prize of the conquering knight in the tournament.
I think I hear you remark something as to the heathenness of the
custom. But it is a custom sacred to these times; and our neighbors
(for of course neither you nor I could condescend to such manners)
get up evening tournaments of whist, quadrilles, and a variety of
singing—of every variety but the good and intelligible, and at these
modern tournaments given for the express purpose which that
respectable old gentleman, the Emperor of Allemagne, had in view
when he opened his lists; the “girls” are the prizes of the carpet-
knights. So gentlemen, faites votre jeu, as the philosopher who
presided at Frescati’s used to say—faites votre jeu, Messieurs; and
go in and win. Perhaps if you read Cowper, you may be the better
armed against loss in such a conflict.
I need not say that Master Guy’s good sword, which gleamed like
lightning in the arena, and rained blows faster than ever Mr.
Blanchard rained them, in terrific Coburg combats, upon the
vulnerable crest of Mr. Bradley—won for him the peerless prize—to
say nothing of a dog and a falcon thrown in. Master Guy rather
ungallantly declined having the lady, though her father would have
given him carte blanche; he looked at her, muttered her name, and
then murmured, “Blanche, as thou art, yet art thou black-a-moor,
compared with my Phillis;”—and with this unchivalric avowal, for it
was a part of chivalry to say a thing and think another, he returned to
England, carrying with him the “Spaniel King’s Charls,” as French
authors write it, and the falcon, with a ring and a perch, like a huge
parroquet.
Master Guy entered Warwick in a “brougham,” as we now might say,
and sorely was he put to it with the uneasy bird. At every lurch of the
vehicle, out flapped the wings, elongated was the neck, and Master
Guy had to play at “dodge” with the falcon, who was intent upon
darting his terrific beak into the cavalier’s nose. At length, however,
the castle was safely reached; the presents were deposited at the
feet of Phillis the Fair, and Guy hoped, like the Peri, and also like that
gentle spirit to be disappointed, that the gates of paradise were
about to open. But not so, Phillis warmly praised his little regard for
that pert minx, Blanche, or Blanc d’Espagne, as she wickedly added;
and she patted the spaniel, and offered sugar to the falcon; and,
after the dinner to which Guy was invited, she intimated in whispers,
that they were both “too young as yet” (not that she believed so), and
that more deeds must be done by Guy, ere the lawyers would be
summoned by her papa to achieve some of their own.
The youthful Guy went forth “reluctant but resolved,” and he would
have sung as he went along,
“Elle a quinze ans, moi j’en ai seize,”

of Sedaine and Grétry, only neither poet nor composer, nor the opera
of Richard Cœur de Lion, had yet appeared to gladden heart and
ear. But the sentiment was there, and perhaps Sedaine knew of it
when he penned the words. However this may be, Master Guy,
though soft of heart, was not so of arm, for on this present cause of
errantry he enacted such deeds that their very enumeration makes
one breathless. His single sword cleared whole forests of hordes of
brigands, through whose sides his trenchant blade passed as easily
as the sabre, when held by Corporal Sutton, through a dead sheep.
Our hero was by no means particular as to what he did, provided he
was doing something; nor what cause he fought for, provided there
were a cause and a fight. Thus we find him aiding the Duke of
Louvain against his old friend the Emperor of Allemagne. He led the
Duke’s forces, slew thousands upon thousands of the enemy, and,
as though he had the luck of a modern Muscovite army, did not lose
more than “one man,” with slight damage to the helmet of a second.
Master Guy, not yet twenty, surpassed the man whom Mr. Thiers
calls “ce pur Anglais,” Mr. Pitt, for he became a prime minister ere he
had attained his majority. In that capacity he negotiated a peace for
the Duke with the Emperor. The two potentates were so satisfied
with the negotiator, that out of compliment they offered him the
command of their united fleet against the Pagan Soldan of
Byzantium. They did not at all expect that he would accept it; but
then they were not aware that Master Guy had much of the spirit
which Sidney Smith, in after-years, discerned in Lord John Russell—
and the enterprising Guy accepted the command of the entire fleet,
with quite an entire confidence.
He did therewith, if chroniclers are to be credited, more than we
might reasonably expect from Lord John Russell, were that
statesman to be in command of a Channel squadron. Having swept
the sea, he rather prematurely, if dates are to be respected, nearly
annihilated Mohammedanism—and he was as invincible and
victorious against every kind of Pagan. It was in the East that he
overthrew in single combat, the giants Colbron and his brother
Mongadora. He was resting after this contest, and leaning like the
well-breathed Hotspur, upon his sword, at the entrance to his tent,
when the Turkish governor Esdalante, approaching him, politely
begged that he might take his head, as he had promised the same to
an Osmanlee lady, who was in a condition of health which might be
imperilled by refusal. Master Guy as politely bade him take it if he
could, and therewith, they went at it “like French falconers,” and Guy
took off the head of his opponent instead of losing his own. This little
matter being settled, Guy challenged the infidel Soldan himself,
putting Christianity against Islamism, on the issue, and thus
professing to decide questions of faith as Galerius did when he left
Olympus and Calvary to depend upon a vote of the Roman senate.
Master Guy, being thrice armed by the justness of his quarrel,
subdued the infidel Soldan, but the latter, to show, as we are told, his
insuperable hatred for Christianity, took handfuls of his own blood,
and cast it in the face of his conqueror—and no doubt here, the
victor had in his mind the true story of Julian insulting “the Galilæan.”
We thus see how history is made to contribute to legend.
And now the appetite of the errant lover grew by what it fed upon. He
mixed himself up in every quarrel, and could not see a lion and a
dragon quietly settling their disputes in a wood, by dint of claws,
without striking in for the lion, slaying his foe, and receiving with
complacency the acknowledgments of the nobler beast.
He achieved something more useful when he met Lord Terry in a
wood, looking for his wife who had been carried off by a score of
ravishers. While the noble lord sat down on a mossy bank, like a
gentleman in a melodrama, Guy rescued his wife in his presence,
and slew all the ravishers, “in funeral order,” the youngest first. He
subsequently stood godfather to his friend Terry’s child, and as I am
fond of historical parallels, I may notice that Sir Walter Scott
performed the same office for a Terry, who if he was not a lord, often
represented them, to say nothing of monarchs and other characters.
Master Guy’s return to England was a little retarded by another
characteristic adventure. As he was passing through Louvain, he
found Duke Otto besieging his father in his own castle—“governor”
of the castle and the Duke. Now nothing shocked Master Guy so
much as filial ingratitude, and despite all that Otto could urge about
niggardly allowance, losses at play, debts of honor, and the
parsimony of the “governor,” our champion made common cause
with the “indignant parent,” and not only mortally wounded Otto, but,
before the latter died, Guy brought him to a “sense of his situation,”
and Otto died in a happy frame of mind, leaving all his debts to his
father. The legacy was by way of a “souvenir,” and certainly the
governor never forgot it. As for Guy, he killed the famous boar of
Louvain, before he departed for England, and as he drew his sword
from the animal’s flank, he remarked, there lies a greater boar, and
not a less beast than Otto himself. However, he took the head and
hams with him, for Phillis was fond of both; and as she was wont to
say, if there was anything that could seduce her, it was brawn!
When Master Guy stepped ashore at Harwich, where that
amphibious town now lies soaking, deputations from all quarters
were awaiting him, to ask his succor against some terrible dragon in
the north that was laying waste all the land, and laying hold of all the
waists which the men there wished to enclose. King Athelstan was
then at York hoping to terrify the indomitable beast by power of an
army, which in combat with the noxious creature made as long a tail,
in retreat, as the dragon itself.
Now whatever this nuisance was which so terribly plagued the good
folks in the North, whether a dragon with a tongue thirty feet long, or
anything else equally hard to imagine, it is matter of fact that our
Master Guy assuredly got the better of it. On his return he met an
ovation in York; Athelstan entertained him at a banquet, covered him
with honor, endowed him with a good round sum, and thus all the
newborn male children in the county became Guys. At least two
thirds of them received the popular name, and for many centuries it
remained in favor, until disgrace was brought upon it by the York
proctor’s son, whose effigy still glides through our streets on each
recurring 5th of November.
I will not pause on this matter. I will only add that the Earl of Warwick,
finding Guy a man whom the King delighted to honor, accepted him
for a son-in-law; and then, ever wise, and civil, and proper, he
discreetly died. The King made Guy Earl of Warwick, in his place,
and our hero being now a married man, he of course ceased to be
Master Guy.
And here I might end my legend, but that it has a moral in it Guy did
a foolish but a common thing, he launched out into extravagant
expenses, and, suddenly, he found himself sick, sad, and insolvent.
Whether, therewith, his wife was soured, creditors troublesome, and
bailiffs presuming, it is hard to say. One thing, however, is certain,
that to save himself from all three, Earl Guy did what nobles often do
now, in the same predicament, “went abroad.” Guy, however,
travelled in primitive style. He went on foot, and made his inn
o’nights in church-yards, where he colloquized with the skulls after
the fashion of Hamlet with the skull of “poor Yorick.” He had given
out that he was going to Jerusalem, but hearing that the Danes were
besieging Athelstan at Winchester, he went thither, and, in modest
disguise, routed them with his own unaided hand. Among his
opponents, he met with the giant Colbron whom he had previously
slain in Orient lands, and the two fought their battles o’er again, and
with such exactly similar results as to remind one of the peculiar
philosophy of Mr. Boatswain Cheeks.
This appearance of Colbron in two places is a fine illustration of the
“myth,” and I mention it expressly for the benefit of the next edition of
the Right Reverend Doctor Whateley’s “Historical Fallacies.” But to
resume.
Guy, imparting a confidential statement of his identity and intentions
to the King, left him, to take up his abode in a cave, in a cliff, near his
residence; and at the gates of his own castle he received, in the
guise of a mendicant, alms of money and bread, from the hands of
his wife. I strongly suspect that the foundation of this section of our
legend rests upon the probable fact that Phillis was of that quality
which is said to belong to gray mares; and that she led Guy a life
which made him a miserable Guy indeed; and that the poor
henpecked man took to bad company abroad, and met with small
allowance of everything but reproach at home And so he “died.”
A dramatic author of Charles I.’s reign, has, however, resuscitated
him in “A Tragical History of Guy, Earl of Warwick,” enacted several
times in presence of that monarch, and professedly written by a
certain “B. J.,” whom I do not at all suspect of being Ben Jonson.
The low comedy portion of this tragic drama is of the filthiest sort,
dealing in phrases and figures which I can hardly conceive would
now be tolerated in the lowest den of St. Giles’s, certainly not out of
it. If Charles heard this given more than once, as the titlepage
intimates, “more shame for him.” If his Queen was present, she
haply may not have understood the verba ad summam caveam
spectantia, and if a daughter could have been at the royal
entertainment, why then the very idea revolts one, and pity is almost
lost in indignation. That the author himself thought well of the piece,
which he printed in 1661, is proved by the defiant epigraph which
says:—
“Carpere vel noli nostra vel ede tua.”
I must not devote much space to a retrospective review of this piece,

particularly as the action begins after Guy has ceased to be “Master,”
and when, on his announcement of going to Jerusalem (perhaps to
the Jews to do a little business in bills), Phillis makes some matronly
remarks in a prospective sense, and a liberty of illustration which
would horrify a monthly nurse.
However, Guy goes forth and meets with a giant so huge, that his
squire Sparrow says it required four-and-twenty men to throw
mustard in his mouth when he dined. From such giants, Heaven
protects the errant Guy, and with a troop of fairies, wafts him to
Jerusalem. Here he finds Shamurath of Babylon assaulting the city,
but Guy heaps miracle on miracle of valor, and produces such
astounding results that Shamurath, who is a spectator of the deeds
and the doer; inquires, with a suspicion of Connaught in the accent
of the inquiry, “What divil or man is this?”
The infidel is more astonished than ever when Guy, after defeating
him, takes him into controversy, and laying hold of him as Dr.
Gumming does of Romanism, so buffets his belief that, the soldier,
fairly out of breath and argument, gives in, and declares himself a
Christian, on conviction.
During one-and-twenty years, Guy has a restless life through the five
acts of this edifying tragedy, and when he is seen again in England,
overcoming the Danes, he intimates to Athelstan that he has six
years more to pass in disguise, ere a vow, of which we have before
heard nothing, will be fulfilled. Athelstan receives all that is said, in
confidence; and promises affably, “upon my word,” not to betray the
secret. Guy is glad to hear that Phillis is “pretty well;” and then he
takes up his residence as I have before told, according to the legend.
He and an Angel occasionally have a little abstruse disquisition; but
the most telling scene is doubtless where the bread is distributed to
the beggars, by Phillis. Guy is here disguised as a palmer, and Phillis
inquires if he knew the great Earl, to which Guy answers, with a wink
of the eye, that he and the Earl had often drank at the same crystal
spring. But Phillis is too dull, or too melancholy to trace her way
through so sorry a joke.
And now, just as the hour of completion of the vowed time of his
disguise, Guy takes to dying, and in that state he is found by
Rainhorn, the son who knows him not. He sends a token by the
young fellow to Phillis, who begins to suspect that the palmer who
used to be so particular in asking for “brown bread” at her gate, must
be the “Master Guy” of the days of sunny youth, short kirtles, and
long love-making. Mother and son haste to the spot, but the vital
spark has fled. Phillis exclaims, with much composed thought, not
unnatural in a woman whose husband has been seven-and-twenty
years away from home, and whose memory is good: “If it be he, he
has a mould-wart underneath his ear” to which the son as
composedly remarks, “View him, good mother, satisfy your mind.”
Thereupon the proper identification of the “party” is established; and
the widow is preparing to administer, without will annexed, when
Rainhorn bids her banish sorrow, as the King is coming. The son
evidently thinks the honor of a living king should drown sorrow for a
deceased parent; just as a Roman family that can boast of a Pope in
it, does not put on mourning even when that Pope dies; the having
had him, being considered a joy that no grief should diminish.
Athelstan is evidently a King of Cockayne, for he affably expresses
surprise at the old traveller’s death, seeing, says his Majesty, that “I
had appointed for to meet Sir Guy” to which the son, who has now
succeeded to the estate, replies, in the spirit of an heir who has been
waiting long for an inheritance:—“that the death has happened, and
can not now be helped.”
But the most remarkable matter in this tragedy is that uttered by
Time, who plays prologue, epilogue, and interlude between the acts.
Whatever Charles may have thought of the piece, he was doubtless
well-pleased with Time, who addresses the audience in verse, giving
a political turn to the lesson on the stage. I dare say the following
lines were loudly applauded, if not by the king, by the gallants,
courtiers, and cavaliers generally:—
“In Holy Land abroad Guy’s spirits roam,

And not in deans and chapters’ lands at home.
His sacred fury menaceth that nation,
Which held Judea under sequestration.
He doth not strike at surplices and tippets,
To bring an olio in of sects and sippets;
But deals his warlike and death-doing blows
Against his Saviour’s and his sov’reign’s foes.”
How the Royalist throats must have roared applause, and

warrantably too, at these genial lines; and how must the churchmen
in the pit have stamped with delight when Time subsequently
assured them that Guy took all his Babylonian prisoners to
Jerusalem, and had them probably christened by episcopally-
ordained ministers! If the house did not ring with the cheers of the
Church-and-King audience there, why they were unworthy of the
instruction filtered through legend and tragedy.
Such is the story of “Master Guy;” a story whose incidents have
doubtless meaning in them, but which were never turned to more
practical purpose than when they were employed to support a
tottering altar and a fallen throne. Reader, let us drink to the immortal
memory of Master Guy; and having seen what sort of man he was
whom the king delighted to honor, let us see what honors were
instituted by kings for other deserving men.
GARTERIANA.
“Honor! Your own worth before
Hath been sufficient preparation.”— The Maid’s Revenge.
A brief sketch of the history of the foundation of the Order of the

Garter will be found in another page. Confining myself here to
anecdotical detail, I will commence by observing, that in former
times, no Knight could be absent from two consecutive feasts of the
order, without being fined in a jewel, which he was to offer at St.
George’s altar. The fine was to be doubled every year, until he had
made atonement. Further, every knight was bound to wear the
Garter in public, wherever he might be, on pain of a mulct of half a
mark. Equally obligatory was it on the knight, in whatever part of the
world he was residing, or however he was engaged, to wear the
sanguine mantle of the order from the eve of St. George till vesper-
time on the morrow of the festival. Some of the chevaliers who were
in distant lands must have caused as much surprise by their
costume, as a Blue-coat boy does, wandering in his strangely-
colored garb, in the streets of Paris. I need not allude to the absurd
consequence which would attend the enforcing of this arrangement
in our own days. Hunting is generally over before the eve of St.
George’s day, and therefore a robed Knight of the Garter could never
be seen taking a double fence, ditch and rail, at the tail of the
“Melton Mowbray.” But even the sight of half a dozen of them riding
down Parliament street at the period in question, would hardly be a
stranger spectacle. A slight money offering of a penny exempted any
rather loose-principled knight from attending divine service at St.
George’s Chapel when he was in or near Windsor. When a knight
died, all his surviving comrades were put to the expense of causing a
certain number of masses to be said for his soul. The sovereign-lord
of the order had one thousand masses chanted in furtherance of his
rescue from purgatory. There was a graduated scale through the
various ranks till the knight-bachelor was come to. For him, only one
hundred masses were put up. This proves either that the knight’s
soul was not so difficult of deliverance from what Prince Gorschakoff
would call the “feu d’enfer,” or that the King’s was so heavily pressed
to the lowest depths of purgatory by its crimes, that it required a
decupled effort before it could be rescued.
“Companionship,” it may be observed, profited a knight in some
degree if, being knave as well as knight, he fell under the usual
sentence of being “drawn, hanged, and beheaded.” In such case, a
Knight of the Garter only suffered decapitation, as Sir Simon Burley
in 1388. The amount of favor shown to the offending knight did not
admit of his being conscious of much gratitude to him at whose
hands it was received. It may be mentioned, that it did not always
follow that a nobleman elected to be knight willingly accepted the
proffered Garter. The first who refused it, after due election, in 1424,
was the Duke of Burgundy. He declined it with as much scorn as
Uhland did the star of merit offered to the poet by the present King of
Bavaria.
In treating of stage knights, I shall be found to have placed at their
head Sir John Falstaff. The original of that character according to
some namely, Sir John Fastolf, claims some notice here, as a Knight
of the Garter who was no more the coward which he was said to be,
than Falstaff is the bloated buffoon which some commentators take
him for. Sir John Fastolf was elected Knight of the Garter in 1426.
Monstrelet says he was removed from the order for running away,
without striking a blow, at the battle of Patay. Shakespeare’s popular
Sir John has nothing in common with this other Sir John, but we
have Falstolf himself in Henry VI. act iv. sc. 1, with Talbot, alluding to
his vow, that
“When I did meet thee next,

To tear the Garter from thy craven’s leg,
The which I have done, because unworthily
Thou wast installed in that high degree.”
This sort of suspension or personal deprivation was never allowed

by the rules of the order, which enjoined the forms for degrading a
knight who was proved to have acted cowardly. The battle of Patay

Full Download PDF of Software Architecture in Practice (SEI Series in Software Engineering), 4th Edition Len Bass - Ebook PDF All Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Download PDF of Software Architecture in Practice (SEI Series in Software Engineering), 4th Edition Len Bass - Ebook PDF All Chapter

Uploaded by

Copyright:

Available Formats

Software Architecture in Practice (SEI

Series in Software Engineering), 4th

Architecting Cloud Saas Software - Solutions Or

(eBook PDF) Engineering Software Products: An

Engineering Software Products: An Introduction to

(eBook PDF) Microservices Flexible Software

(eBook PDF) Software Engineering: A Practitioner's

Software Engineering: A Practitioner's Approach 9th

Software Engineering 10th Edition by Ian Sommerville

Software Engineering: A Practitioner's Approach 9th

Visit informit.com/sei for a complete list of available publications.

T he SEI Series in Software Engineering is a collaborative undertaking of

Titles in the series describe frameworks, tools, methods, and technologies

Make sure to connect with us!

Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town

CHAPTER 2 Why Is Software Architecture Important? 25

2.12 Restricting the Vocabulary of Design Alternatives 35

PART II QUALITY ATTRIBUTES 39

5.5 Tactics-Based Questionnaire for Deployability 80

CHAPTER 6 Energy Efficiency 89

CHAPTER 7 Integrability 101

CHAPTER 8 Modifiability 117

CHAPTER 9 Performance 133

9.5 For Further Reading 149

CHAPTER 10 Safety 151

CHAPTER 11 Security 169

CHAPTER 12 Testability 183

CHAPTER 13 Usability 197

CHAPTER 14 Working with Other Quality Attributes 207

PART III ARCHITECTURAL SOLUTIONS 217

CHAPTER 16 Virtualization 233

CHAPTER 17 The Cloud and Distributed Computing 247

17.3 Using Multiple Instances to Improve Performance and

CHAPTER 18 Mobile Systems 263

PART IV SCALABLE ARCHITECTURE PRACTICES 277

CHAPTER 20 Designing an Architecture 289

20.5 More on ADD Step 6: Creating Preliminary Documentation

CHAPTER 21 Evaluating an Architecture 309

CHAPTER 22 Documenting an Architecture 329

CHAPTER 23 Managing Architecture Debt 355

PART V ARCHITECTURE AND THE ORGANIZATION 367

CHAPTER 25 Architecture Competence 379

PART VI CONCLUSIONS 391

1.1 What Software Architecture Is and What It Isn’t

Architecture Is a Set of Software Structures

Architecture versus Design

Every Software System Has a Software Architecture

Not All Architectures Are Good Architectures

Architecture Includes Behavior

System and Enterprise Architectures

1.2 Architectural Structures and Views

structures of a human body, as illustrated in Figure 1.1. Ophthalmologists, cardiologists, and

FIGURE 1.1 Physiological structures

Three Kinds of Structures

FIGURE 1.2 A component-and-connector structure

CommonDialog Abstract class

Class with provided

FIGURE 1.3 Module elements in UML

Checking Savings Admin

FIGURE 1.4 Module relations in UML

Module structures allow us to answer questions such as the following:

Some Useful Module Structures

ATIA server- ATIA server-