 BOOK

Software Architecture in Practice, 4th

Edition

By Len Bass, Paul Clements, Rick Kazman

TIME TO COMPLETE:
12h 53m
 Contents

Preface

1. What Is Software Architecture?

2. Why Is Software Architecture

Important?

3. Understanding Quality Attributes

4. Availability

5. Deployability

6. Energy Efficiency

7. Integrability

8. Modifiability

9. Performance
 Table of Contents

Preface

1. What Is Software Architecture?

1.1 What Software Architecture Is

and What It Isn’t

1.2 Architectural Structures and

Views

1.3 What Makes a “Good”

Architecture?

1.4 Summary


1.5 For Further Reading

1.6 Discussion Questions

Preface

When we set out to write the fourth

edition of Software Architecture in
Practice, our first question to
ourselves was: Does architecture
still matter? With the rise of cloud
infrastructures, microservices,
frameworks, and reference
architectures for every conceivable
domain and quality attribute, one
might think that architectural
knowledge is hardly needed
anymore. All the architect of today
needs to do is select from the rich


array of tools and infrastructure

alternatives out there, instantiate
and configure them, and voila! An
architecture.
 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
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 motivate the
creation of a new architecture, or
3. Understanding Quality
Attributes

Quality is never an accident; it is

always the result of high intention,
sincere effort, intelligent direction and
skillful execution.

—William A. Foster

Many factors determine the qualities

that must be provided for in a
system’s architecture. These qualities
go beyond functionality, which is the
basic statement of the system’s
capabilities, services, and behavior.
Although functionality and other
qualities are closely related, as you
will see, functionality often takes the
front seat in the development
4. Availability

Technology does not always rhyme

with perfection and reliability.

Far from it in reality!

—Jean-Michel Jarre

Availability refers to a property of

software—namely, that it is there and
ready to carry out its task when you
need it to be. This is a broad
perspective and encompasses what is
normally called reliability (although
it may encompass additional
considerations such as downtime
due to periodic maintenance).
Availability builds on the concept of
reliability by adding the notion of
5. Deployability

From the day we arrive on the planet

And blinking, step into the sun
There’s more to be seen than can ever
be seen
More to do than can ever be done

—The Lion King

There comes a day when software,

like the rest of us, must leave home
and venture out into the world and
experience real life. Unlike the rest
of us, software typically makes the
trip many times, as changes and
updates are made. This chapter is
about making that transition as
orderly and as effective and—most of
all—as rapid as possible. That is the
6. Energy Efficiency

Energy is a bit like money: If you

have a positive balance, you can
distribute it in various ways, but
according to the classical laws that
were believed at the beginning of the
century, you weren’t allowed to be
overdrawn.

—Stephen Hawking

Energy used by computers used to

be free and unlimited—or at least
that’s how we behaved. Architects
rarely gave much consideration to
the energy consumption of
software in the past. But those days
are now gone. With the dominance
of mobile devices as the primary
7. Integrability

Integration is a basic law of life;

when we resist it, disintegration is
the natural result, both inside and
outside of us. Thus we come to the
concept of harmony through
integration.

—Norman Cousins

According to the Merriam-Webster

dictionary, the adjective integrable
means “capable of being
integrated.” We’ll give you a
moment to catch your breath and
absorb that profound insight. But
for practical software systems,
software architects need to be
concerned about more than just
8. Modifiability

It is not the strongest of the species

that survive, nor the most intelligent,
but the one most responsive to
change.

—Charles Darwin

Change happens.

Study after study shows that most of

the cost of the typical software
system occurs after it has been
initially released. If change is the
only constant in the universe, then
software change is not only constant
but ubiquitous. Changes happen to
add new features, to alter or even
retire old ones. Changes happen to
fix defects, tighten security, or
9. Performance

An ounce of performance is worth

pounds of promises.

—Mae West

It’s about time.

Performance, that is: It’s about time

and the software system’s ability to
meet timing requirements. The
melancholy fact is that operations on
computers take time. Computations
take time on the order of thousands
of nanoseconds, disk access (whether
solid state or rotating) takes time on
the order of tens of milliseconds, and
network access takes time ranging
from hundreds of microseconds
within the same data center to
10. Safety

Giles: Well, for god’s sake, be careful…

If you should be hurt or killed, I shall
take it amiss.

Willow: Well, we try not to get killed.

That’s part of our whole mission
statement: Don’t get killed.

Giles: Good.

—Buffy the Vampire Slayer, Season 3,

episode “Anne”

“Don’t kill anyone” should be a part

of every software architect’s mission
statement.

The thought that software could kill

people or cause injury or damage
11. Security

If you reveal your secrets to the wind,

you should not blame the wind for
revealing them to the trees.

—Kahlil Gibran

Security is a measure of the system’s

ability to protect data and
information from unauthorized
access while still providing access to
people and systems that are
authorized. An attack—that is, an
action taken against a computer
system with the intention of doing
harm—can take a number of forms.
It may be an unauthorized attempt
to access data or services or to
12. Testability

Testing leads to failure, and failure

leads to understanding.

—Burt Rutan

A substantial portion of the cost of

developing well-engineered systems
is taken up by testing. If a carefully
thought-out software architecture
can reduce this cost, the payoff is
large.

Software testability refers to the ease

with which software can be made to
demonstrate its faults through
(typically execution-based) testing.
Specifically, testability refers to the
probability, assuming that the
software has at least one fault, that it
13. Usability

People ignore design that ignores

people.

—Frank Chimero

Usability is concerned with how easy

it is for the user to accomplish a
desired task and the kind of user
support that the system provides.
Over the years, a focus on usability
has shown itself to be one of the
cheapest and easiest ways to
improve a system’s quality (or more
precisely, the user’s perception of
quality) and hence end-user
satisfaction.

Usability comprises the following

areas:
14. Working with Other
Quality Attributes

Quality is not what happens when

what you do matches your intentions.
It is what happens when what you do
matches your customers’
expectations.

—Guaspari

Chapters 4–13 each dealt with a

particular quality attribute (QA) that
is important to software systems.
Each of those chapters discussed how
its particular QA is defined, gave a
general scenario for that QA, and
showed how to write specific
scenarios to express precise shades
of meaning concerning that QA. In
15. Software Interfaces

With Cesare Pautasso

NASA lost its $125-million Mars

Climate Orbiter because spacecraft
engineers failed to convert from
English to metric measurements when
exchanging vital data before the craft
was launched.…

A navigation team at [NASA] used the

metric system of millimeters and
meters in its calculations, while [the
company that] designed and built the
spacecraft provided crucial
acceleration data in the English
system of inches, feet and pounds.…

In a sense, the spacecraft was lost in

translation.
16. Virtualization

Virtual means never knowing where

your next byte is coming from.

—Unknown

In the 1960s, the computing

community was frustrated by the
problem of sharing resources such as
memory, disk, I/O channels, and user
input devices on one physical
machine among several independent
applications. The inability to share
resources meant that only one
application could be run at a time.
Computers at that time cost millions
of dollars—real money in those days
—and most applications used only a
fraction, typically around 10%, of the
17. The Cloud and
Distributed Computing

A distributed system is one in which

the failure of a computer you didn’t
even know existed can render your
own computer unusable.

—Leslie Lamport

Cloud computing is about the on-

demand availability of resources.
This term is used to refer to a wide
range of computing capabilities. For
example, you might say, “All my
photos are backed up to the cloud.”
But what does that mean? It means:

• My photos are stored on someone

else’s computers. They worry about
18. Mobile Systems

With Yazid Hamdi and Greg

Hartman

The telephone will be used to inform

people that a telegram has been
sent.

—Alexander Graham Bell

So, what did Alexander Graham Bell

know, anyway? Mobile systems,
including and especially phones,
are ubiquitous in our world today.
Besides phones, they include trains,
planes, and automobiles; they
include ships and satellites,
entertainment and personal
computing devices, and robotic
systems (autonomous or not); they
19. Architecturally
Significant
Requirements

The most important single aspect of

software development is to be clear
about what you are trying to build.

—Bjarne Stroustrup, creator of C++

Architectures exist to build systems

that satisfy requirements. By
“requirements,” we do not
necessarily mean a documented
catalog produced using the best
techniques that requirements
engineering has to offer. Instead,
we mean the set of properties that,
if not satisfied by your system, will
cause the system to be a failure.
20. Designing an
Architecture

With Humberto Cervantes

A designer knows he has achieved

perfection not when there is nothing
left to add, but when there is nothing
left to take away.

—Antoine de Saint-Exupéry.

Design—including architectural
design—is a complex activity to
perform. It involves making a
myriad of decisions that take into
account many aspects of a system. In
the past, this task was only entrusted
to senior software engineers—gurus
—with decades of hard-won
21. Evaluating an
Architecture

A doctor can bury his mistakes, but

an architect can only advise his
clients to plant vines.

—Frank Lloyd Wright

In Chapter 2, we said that one major

reason architecture is important is
that you can predict the quality
attributes of any system derived
from it, before you build the system,
by examining its architecture. That’s
a pretty good deal, if you think about
it. And this is the chapter where that
capability comes home.
22. Documenting an
Architecture

Documentation is a love letter that

you write to your future self.

—Damian Conway

Creating an architecture isn’t

enough. It has to be communicated
in a way to let its stakeholders use it
properly to do their jobs. If you go to
the trouble of creating a strong
architecture, one that you expect to
stand the test of time, then you must
go to the trouble of describing it in
enough detail, without ambiguity,
and organized so that others can
quickly find and update needed
information.
23. Managing
Architecture Debt

With Yuanfang Cai

Some debts are fun when you are

acquiring them, but none are fun
when you set about retiring them.

—Ogden Nash

Without careful attention and the

input of effort, designs become
harder to maintain and evolve over
time. We call this form of entropy
“architecture debt,” and it is an
important and highly costly form of
technical debt. The broad field of
technical debt has been intensively
studied for more than a decade—
24. The Role of
Architects in Projects

I don’t know why people hire

architects and then tell them what to
do.

—Frank Gehry

Any practice of architecture

performed outside of a classroom
takes place in the larger context of a
development project, which is
planned and carried out by people
working in one or more
organizations. Architecture, for all its
importance, is only the means
toward a larger end. In this chapter,
we deal with the aspects of
architecture and the architect’s
25. Architecture
Competence

The lyf so short, the craft so long to

lerne.

—Geoffrey Chaucer

If software architecture is worth

doing, then surely it’s worth doing
well. Most of the literature about
architecture concentrates on the
technical aspects. This is not
surprising; it is a deeply technical
discipline. But architectures are
created by architects working in
organizations that are full of actual
human beings. Dealing with these
humans is a decidedly nontechnical
undertaking. What can be done to
26. A Glimpse of the
Future: Quantum
Computing

[A quantum computer can be

compared] to the airplane the Wright
brothers flew at Kitty Hawk in 1903.
The Wright Flyer barely got off the
ground, but it foretold a revolution.

—wired.com/2015/12/for-google-
quantum-computing-is-like-learning-
to-fly/

What will the future bring in terms

of developments that affect the
practice of software architecture?
Humans are notoriously bad at
predicting the long-term future, but
we keep trying because, well, it’s fun.
 References

[Abrahamsson 10] P. Abrahamsson,

M. A. Babar, and P. Kruchten.
“Agility and Architecture: Can They
Coexist?” IEEE Software 27, no. 2
(March–April 2010): 16–22.

[AdvBuilder 10] Java Adventure

Builder Reference Application.
https://adventurebuilder.dev.java.n
et

[Anastasopoulos 00] M.
Anastasopoulos and C. Gacek.
“Implementing Product Line
Variabilities” (IESE-Report no.
089.00/E, V1.0). Kaiserslautern,
Germany: Fraunhofer Institut