SEI Software Architecture

Principles and Practices

Overview Training

Andrew Kotov and John Klein

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 1
Copyright 2021 Carnegie Mellon University.

This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-
0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research
and development center.

The view, opinions, and/or findings contained in this material are those of the author(s) and should not be construed as an
official Government position, policy, or decision, unless designated by other documentation.

NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS
FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF
FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE
MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO
FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
[DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribution. Please see
Copyright notice for non-US Government use and distribution.

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual
study.

Except for any U.S. government purposes described herein, this material SHALL NOT be reproduced or used in any other
manner without requesting formal permission from the Software Engineering Institute at [email protected].
Although the rights granted by contract do not require course attendance to use this material for U.S. Government
purposes, the SEI recommends attendance to ensure proper understanding.

Architecture Tradeoff Analysis Method® and ATAM® are registered in the U.S. Patent and Trademark Office by Carnegie
Mellon University.

TSPSM is a service mark of Carnegie Mellon University.

DM21-0242

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 2
Rules of Engagement

We will be very busy over the next three days. To complete

everything and get the most from the course, we will need to follow
some rules of engagement:
• Your participation is essential.
• Feel free to ask questions at any time.
• Discussion is good, but we may need to cut some discussions
short in the interest of time.
• Please try to limit side discussions during the lectures.
• Please turn off your cell phone ringers and computers.
• Let’s start on time.
• Participants must be present for all sessions to earn a course
completion certificate.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 3
Agenda

Day 1:
• Definition and importance of architecture
• Architectural drivers, quality attribute scenarios
Day 2:
• Architecture Documentation: Views – Structure and Behavior,
Principles of Sound Documentation, Architecture Decision
Records
• Architecture-centric Engineering
Day 3:
• Architecture analysis
- Evaluation approaches, lightweight evaluation
• Architecture design
- Design process, Attribute-Driven Design

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 4
Logistics

Tuesday 16 Mar. 2021 → Thursday 18 Mar. 2021

• Start each day at 11:30 a.m. EDT
• End each day by 3:00 p.m. EDT
• Break every hour for 10 minutes
Zoom teleconference:
• https://sei.zoomgov.com/j/1605424743?pwd=QXAwdytsd0NUck9ieDREb2RYR3lYUT09&from=addon

Meeting ID: 160 542 4743

Passcode: 099303 One tap mobile
+16692545252,,1605424743#,,,,*099303# US (San Jose)
+16468287666,,1605424743#,,,,*099303# US (New York)

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 5
What is software architecture?

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 6
Software Architecture
What is software architecture? The software architecture of a
system is the set of structures needed to reason about the
system, which comprises software elements, relations among
them, and properties of both.

• Every system has an architecture!

• Architecture is an abstraction of a system
• Architecture defines the system elements and how they interact
via interface
• Architecture doesn’t include implementation details of the
elements
• Properties of components are assumptions that one component
can make about another (provided/required services,
performance, how it handles faults or consumes resources, etc.)

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 7
Some Implications of Our Definition

Every system has an architecture.

• Every system is composed of elements, and there are
relationships among them.
• In the simplest case, a system is composed of a single element,
related only
to itself.
Just having an architecture is different from having an architecture
that is known
to everyone:
• Is the “real” architecture the same as the specification?
• What is the rationale for architectural decisions?

If you don’t explicitly develop an architecture, you will get one

anyway—and you might not like what you get!

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 8
More Implications of Our Definition

Box-and-line drawings alone are not architectures: they are just a

starting point.
• You might imagine the behavior of a box or element labeled
“database”
or “executive.”
• You need to add specifications and properties to the elements
and relationships.
Finally, the definition of architecture is indifferent as to whether the
architecture of a system is a good one or a bad one.
• A good architecture is one that allows a system to meet its
functional, quality attribute, and lifecycle requirements.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 9
Role of Software Architecture

If the only criterion for software was to get the right answer, we
would not need architectures―unstructured, monolithic systems
would suffice.
But other things also matter, such as
• modifiability
• time of development
• performance
• coordination of work teams

Quality attributes such as these are largely dependent on

architectural decisions.
• All design involves tradeoffs among quality attributes.
• The earlier we reason about tradeoffs, the better.
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 10
Why Is Software Architecture Important?

Architecture is important for three primary reasons:

1.It provides a vehicle for communication among stakeholders.

2.It is the manifestation of the most important design decisions

about a system.

3.It is a transferable, reusable abstraction of a system.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 11
Vehicle for Communication

Architecture provides a common frame of reference in which

competing interests can be exposed and negotiated. These
interests include
• negotiating requirements with users
• keeping the customer informed of progress and cost
• implementing management decisions and allocations

Architects and implementers use the architecture to guide

development.
• Doing so supports architectural analysis.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 12
Most Important Design Decisions – 1

Architecture defines constraints on implementation:

• The implementation must conform to prescribed design
decisions such as those regarding
- elements
- interactions
- behaviors
- responsibilities
• The implementation must conform to resource allocation
decisions such as those regarding
- scheduling priorities and time budgets
- shared data and repositories
- queuing strategies
Architectures are both prescriptive and descriptive.
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 13
Most Important Design Decisions – 2

Architecture dictates the structure of the organization.

• Architecture represents the highest level decomposition of a
system and is used as a basis for
- partitioning and assigning the work to be performed
- formulating plans, schedules, and budgets
- establishing communication channels among teams
- establishing plans, procedures, and artifacts for configuration
management, testing, integration, deployment, and maintenance

For managerial and business reasons, once established, an

architecture becomes very difficult to change.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 14
Most Important Design Decisions – 3

Architecture permits/precludes the achievement of a system’s

desired quality attributes. The strategies for achieving them are
architectural.
If you desire… you need to pay attention to…
high performance minimizing the frequency and volume of inter-element communication

modifiability limiting interactions between elements

security managing and protecting inter-element communication

reusability minimizing inter-element dependencies

subsetability controlling the dependencies between subsets and, in particular,
avoiding circular dependencies
availability the properties and behaviors that elements must have and the
mechanisms you will employ to address fault detection, fault prevention,
and fault recovery
and so forth …

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 15
Most Important Design Decisions – 4

Architecture allows us to predict system quality attributes without

waiting until the system is developed or deployed.
• Since architecture influences quality attributes in known ways, it
follows that we can use architecture to predict how quality
attributes may be achieved.
• We can analyze an architecture to evaluate how well it meets its
quality attributes requirements.
- These analysis techniques may be heuristic (e.g., back-of-the-
envelope calculations, experience-based analogy) and inexpensive.
- They may be precise (e.g., prototypes, simulations, instrumentation)
and expensive.
- Or they may fall in between (e.g., scenario-based evaluation).

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 16
Most Important Design Decisions – 5

Architecture helps us reason about and manage changes to a

system during its lifetime.
All systems accumulate technical debt over their lifetimes. When
this debt is attributable to architectural degradation, we call it
architecture debt.
Fortunately, by analyzing an architecture we can monitor and
manage architectural debt.
Typically, refactoring is used to pay down architecture debt. When
to refactor is a decision that includes both technical and business
considerations.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 17
Most Important Design Decisions – 6

Once an architecture has been defined, it can be analyzed and

prototyped as a skeletal system. Doing so aids the development
process in three ways:
1. The architecture can be implemented as a skeletal framework
into which elements can be “plugged.”
2. Risky elements of the system can be identified via the
architecture and mitigated with targeted prototypes.
3. The system is executable early in the product’s lifecycle. The
fidelity
of the system increases as prototyped parts are replaced by
completed elements.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 18
Most Important Design Decisions – 7

Architecture enables more accurate cost and schedule estimates,

project planning, and tracking:
• The more knowledge we have about the scope and structure of
a system, the better our estimates will be.
• Teams assigned to individual architectural elements can provide
more accurate estimates.
• Project managers can roll up estimates and resolve
dependencies and conflicts.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 19
Transferable, Reusable Abstraction – 1

Software architecture constitutes a model that is transferable

across similar systems.

Software architecture can serve as the basis of a strategic reuse

agenda that includes the reuse of
• requirements
• development-support artifacts (templates, tools, etc.)
• code
• components
• experience
• standards

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 20
Transferable, Reusable Abstraction – 2

Architecture supports building systems using large, independently

developed components.

• Architecture-based development focuses on composing

elements rather than programming them.
• Composition is possible because the architecture defines which
elements can be incorporated into the system and how they are
constrained.
• The focus on composition provides for component
interchangeability.
• Interchangeability is key to allowing third-party software
elements, subsystems, and communication interfaces to be
used as architectural elements.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 21
Architecturally Significant
Requirements

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 22
Where Do Architectures Come From?

Software architecture is based on much more than requirements

specifications.

It is the result of many different technical, business, and social

influences.

Its existence, in turn, influences the technical, business, and social

environments that subsequently affect future architectures.

Architects need to know and understand the nature, source, and

priority of these influences as early in the process as possible.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 23
Factors Influencing Architectures

Architectures are influenced by

• system stakeholders
• the development organization’s business environment
• the technical environment
• the architect’s professional background and experience

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 24
Concerns of System Stakeholders

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 25
Architecture Influence Cycle (AIC)

Source: Bass et al. Software Architecture in Practice. Addison-Wesley, 2012.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 26
Architectural Drivers

Architectural drivers are the combination of

• design purpose,
• quality attribute requirements,
• primary functional requirements,
• architectural concerns, and
• constraints
that shape an architecture.

And these are driven, in turn, by business goals.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 27
Design Purpose

Before you can begin you need to be clear about why you are
designing.
Your objectives will change what and how you design; some
examples include
• part of a project proposal (e.g., pre-sales)
• part of creating an exploratory prototype
• during development: greenfield, refactoring, refresh, …

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 28
Quality Attributes or Non-Functional
Requirements (NFRs)
Quality attributes are properties of work products or goods by
which stakeholders judge their quality.

Some examples of quality attributes by which stakeholders judge

the quality of software systems are

• performance • availability
• security • adaptability
• modifiability • throughput
• reliability • configurability
• usability • subsetability
• calibratability • reusability

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 29
Quality Attribute Requirements

Quality attribute (QA) requirements have the most profound effect

on shaping the architecture.
Why is this?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 30
Quality Attribute Requirements

If a functional requirement is “When the user presses the green

button, the Options dialog appears”…
• a performance QA annotation might describe how quickly the
dialog will appear;
• an availability QA annotation might describe how often this
function will fail, and how quickly it will be repaired;
• a usability QA annotation might describe how easy it is to learn
this function.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 31
Functional Requirements

The way the system is structured normally does not inhibit the
satisfaction of functional requirements.
• Functionality and quality are orthogonal concerns.

When designing the architecture, it is obviously important to ensure

that the chosen design elements can satisfy the functional
requirements.

Functional requirements are often documented as use cases or

user stories.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 32
Primary Functional Requirements

Primary use cases

• are critical to the achievement of business goals
• are associated with an important QA scenario
• may imply a high level of technical difficulty
• exercise many architectural elements
• represent a “family” of use cases

Usually only 10-20% of the use cases are primary.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 33
Functionality and Architecture

Functionality is the ability of a system to do the work it was

intended
to do.
• Functionality often has associated quality attribute requirements
(e.g., a function is required to have a certain level of availability,
reliability, and performance).
• We can achieve functional requirements and yet fail to meet
their associated quality attribute requirements.
• Functionality can be achieved using many different
architectures.
• Achieving quality attribute requirements can be achieved only
through judicious choice of architectures.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 34
Architectural Concerns - 1

Architectural concerns are design decisions that should be made

whether they are expressed as requirements or not.

We divide them into four categories:

• general concerns
• specific concerns
• internal requirements
• issues

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 35
Architectural Concerns - 2

General concerns: “broad” issues that every architect deals with in

creating an architecture.

Specific concerns: system-internal issues that an architect must

address

Internal requirements: These are derived requirements that are

typically not specified in requirement documents.

Issues: These result from analysis activities, such as a design

review, so they may not be present initially.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 36
Constraints
Constraints limit the range of possibilities when making design
decisions.
• In some cases they are decisions about which you have zero
choice.
Before commencing design, identify and justify constraints.
• Technical constraints
- Use of a legacy database
- Compliance with a vendor's interface
- Corporate or industry technical standards
• Other constraints
- Development team only familiar with Java
- Obey Sarbanes-Oxley
- Ready in time for April 15th

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 37
Capturing System Requirements

Question: What do we need to define the software architecture?

• Functional requirements. They define what the application
must do to behave properly.
• Quality attributes or NFRs. Quality attributes serve as
qualifications of functional requirements or the overall
application. They are also called non-functional requirements
(NFRs). The can qualify how fast an application operation
should be performed or define its service-level agreement.
• Constraints. These reflect design decisions that have already
been made and cannot be changed. A choice of a specific
migration platform, such as ACS, is an example.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 38
Capturing Architecturally Significant
Requirements
Not all requirements are created equal for architectural purposes.

Architecturally significant requirement (ASR):

• A profound impact on the architecture – this requirement will
likely result in a different architecture than if it were not included
• A high business value – if the architecture is going to satisfy this
requirement, it must be of high value to important stakeholders

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 39
Architecture and Design Decisions

The architecture of a system is the result of design decisions.

Design decisions influence achievement of desired qualities.

If you desire… you need to pay attention to…

High performance minimizing the frequency and volume of inter-
element communication
Modifiability/Flexibility limiting interactions between elements
Security managing and protecting inter-element
communication
Reusability minimizing inter-element dependencies
Subsetability controlling the dependencies between subsets
and, in particular, avoiding circular dependencies
Availability the properties and behaviors that elements must
have and the mechanisms you will employ to
address fault detection, fault prevention, and fault
recovery
And so forth …
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 40
Eliciting the Target System Qualities

Requirements elicitation methods elicit quality attribute

requirements.

For more information, see Bass, L., Bergey, J., Clements, P., Merson, P., Ozkaya, I., Sangw an, R. A Comparison of Requirements Specification Methods from a Software
Architecture Perspective (CMU/SEI-2006- TR-013). Softw are Engineering Institute, Carnegie Mellon University, 2006.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 41
Stakeholders and Quality Attributes

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 42
Quality Attribute Data from SEI Architecture
Evaluations:
Top 20 QA Concerns1
1. Modifiability: Reduce coupling 11.Deployability: Minimize build, test, release duration
2. Performance: Latency 12.Modifiability: Reusability

3. Interoperability: Upgrade and integrate with other 13.Availability: Prevent faults

system components 14.Scalability: Increased processing demands
4. Modifiability: Designing for portability 15.Security: Authorization
5. Usability: Ease of operation 16.Interoperability: Resource and data sharing
6. Availability: Detect faults 17.Security: Resist attack

7. Interoperability: Ease of interfacing with other 18.Deployability: Configuration and/or dependency

systems management

8. Modifiability: Designing for extensibility 19.Modifiability: Configurability/composability

20.Deployability: Backward compatibility and/or
9. Availability: Recover from faults
rollback strategy
10.Performance: Resource management
1 Bellomo, S.; Gorton, I.; & Kazman, R. “Insights from 15 Years of ATAM Data: Tow ards Agile Architecture”, IEEE Software, September/October, 2015, 32:5, 38-45.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 43
Quality Attribute Data from SEI Architecture
Evaluations:
QA Concerns Grouped by QA1
Modifiability Performance Interoperability Availability
• Designing for • Latency • Upgrade and • Detect faults
portability integrate with other
• Resource • Recover from faults
system components
• Designing for management
• Prevent faults
extensibility • Ease of interfacing
• Throughput
with other systems or • Transaction auditing
• Reusability • Performance components and logging
monitoring
• Configurability/compo • Resource and data • Graceful degradation
sability • Initialization sharing
• Increase cohesion • Accuracy • Data integrity

• Add or modify • Compliance with

functionality standards/protocols

1 Bellomo, S.; Gorton, I.; & Kazman, R. “Insights from 15 Years of ATAM Data: Tow ards Agile Architecture”, IEEE Software, September/October, 2015, 32:5, 38-45.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 44
Describing Quality Attributes

Quality attribute names by themselves are not enough.

• Quality attribute requirements are often non-operational.
- For example, it is meaningless to say that the system shall be
“modifiable.” Every system is modifiable with respect to some set of
changes and not modifiable with respect to some other set of
changes.
• Heated debates often revolve around the quality attribute to
which a particular system behavior belongs.
- For example, system failure is an aspect of availability, security, and
usability.
• The vocabulary describing quality attributes varies widely.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 45
Parts of a Quality Attribute Scenario

We specify the most important quality attribute requirements as

quality attribute scenarios, using a 6-part structure:

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 46
Quality Attribute Example Scenario

An unanticipated external message is received by a process during

normal operation. The process informs the operator of the message’s
receipt, and the system continues to operate with no downtime.

Source External to the system

Stimulus Unanticipated message
Artifact(s) Process
Environment Normal operation
Response Inform operator; continue to operate
Response No downtime
Measure

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 47
Prioritizing QA Scenarios

Before commencing design, prioritize quality attribute scenarios.

• Typically only the most important scenarios can be considered
early in architectural design.
• Choose the top 5-7 scenarios in the initial design round.

If a Quality Attribute Workshop was performed, the scenarios will

already be prioritized.

Or you could create a utility tree, where scenarios are prioritized

across two dimensions:
• importance to the success of the system, ranked by the
customer (H, M, L)
• degree of technical risk, ranked by the architect (H, M, L)
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 48
What Are Quality Attribute Utility Trees?

You can identify, prioritize, and refine the most important quality
attribute goals by building a utility tree.
• A utility tree is a top-down vehicle for characterizing the “driving”
attribute-specific requirements.
• The highest level nodes are typically quality attributes such as
performance, modifiability, security, availability, and so forth.
• Scenarios are the leaves of the utility tree.

The utility tree is a characterization and a prioritization of specific

quality attribute requirements.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 49
Example of Quality Attribute Utility Tree

Replace middleware in
< 20 person-months

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 50
How Scenarios Are Used

Scenarios are used to

• represent stakeholders’ interests
• understand quality attribute requirements

Scenarios should cover a range of

• anticipated uses of the system (use case scenarios)
• anticipated changes to the system (growth scenarios)
• unanticipated stresses on the system (exploratory scenarios)

Scenarios are linked to business goals, for traceability.

A good scenario clearly states the stimulus and the responses of
interest.
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 51
Examples of Scenarios

Use case scenario

• A remote user requests a database report via the Web during a
peak period and receives it within 5 seconds.

Growth scenario
• During maintenance, add an additional data server within 1
person-week.

Exploratory scenario
• Half of the servers go down during normal operation without
affecting the overall system availability.

Scenarios should be as specific as possible.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 52
Stimulus, Environment, Response

Use case scenario

• The remote user requests a database report via the Web during
a peak period and receives it within 5 seconds.

Growth scenario
• During maintenance, add an additional new data server within
1 person-week.

Exploratory scenario
• Half of the servers go down during normal operation without
affecting the overall system availability.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 53
Quality Attribute Requirements –
Elicitation Approaches
Goal: Broad coverage through stakeholder engagement and
representation

Approaches:
• Quality Attribute Workshop – Original method, synchronous in-
person collaborative working meeting
• Virtual QAW – Synchronous working telemeeting
• Interviews – Variation to avoid holding a single event, can by in-
person and/or telemeeting
• Seeded Crowdsourcing – Create initial set of scenarios based
on experience or interviews, open to broader asynchronous
contributions

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 54
Quality Attribute Workshop (QAW)

The QAW is a facilitated method that engages system stakeholders

early in the lifecycle to discover the driving quality attribute
requirements of a software-reliant system.
Key points about the QAW are that it is
• system-centric
• stakeholder focused
• held before a major software architecture design exercise
• scenario based

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 55
Exercise –
Quality Attribute Scenarios for DIP System
Stimulus, Environment, Response

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 56
Start of Day 2

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 57
Agenda

Day 1:
• Definition and importance of architecture
• Architectural drivers, quality attribute scenarios
Day 2:
• Architecture Documentation: Views – Structure and Behavior,
Principles of Sound Documentation, Architecture Decision
Records
• Architecture-centric Engineering
Day 3:
• Architecture analysis
- Evaluation approaches, lightweight evaluation
• Architecture design
- Design process, Attribute-Driven Design

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 58
Structures, Views, Documentation

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 59
Why Document an Architecture?

Architecture documentation has three

fundamental uses.
• Education, introducing people to the
system: new members of the team,
external analysts, the customer, or even a
new architect.
• Communication vehicle among
stakeholders and to/from the architect.
• Analysis, especially for the quality
attributes that the architecture is
designed to provide.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 60
Stakeholders for Documentation

Who are the stakeholders for

architecture documentation?

What do they need to know?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f orModule

public release
3 and unlimited distribution.
© 2021 Carnegie Mellon University 61
 A Business Case for
Architecture Documentation

Benefit of documentation =
1. Project activities will be less costly with high-
quality, up-to-date documentation than they would
otherwise.

(
over all
Cost of performing A without
architecture documentation –
Cost of performing A with
architecture documentation )
activities A

2. The effort saved from architecture documentation should outweigh

the cost to create it.

Benefit > Cost to produce/maintain the documentation.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 62
Architectural Structures

What is Software Modern software systems are too complex

Architecture? to grasp all at once. At any moment, we
restrict our attention to a small number of a
software system’s structures.

To communicate meaningfully about an

architecture, we must make clear which
structure or structures we are discussing.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 63
Architectural Structure Types

Architectural structures for software systems can be divided into

three types:

1. Module structures – consisting of elements that are units of

implementation
called modules and the relationships among them
2. Component-and-connector structures – consisting of runtime
components
(units of computation) and the connectors (communication paths)
between them
3. Allocation structures – consisting of software elements and
their relationships to elements in external environments in which
the software is created and executed

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 64
Documenting Software Architecture Using
Views
• Software architecture needs to be communicated to the team and
key stakeholders. It must be documented!
• A single diagram that showed the entire architecture would
contain too much information to present all at once.
• To break an architecture into digestible chunks, we create
diagrams that we refer to as views.
• These views illustrate Search

ItemEntry
Online
Services[1..5]

Admin
Services[1]
SearchEngine

CatalogMgr
Catalog

Data
Cache

Dava
Validation

Notation:
DataAccess

Authorized
User
<<artifact>>

structures in the architecture.

UML 2.0 DukesBankApp.ear
Notation: <<artifact>>
UML 2.0 DukesBankApp.ear

<<manifest>> <<manifest>> <<manifest>>

Notation: <<artifact>>
UML 2.0 DukesBankApp.ear

<<manifest>>

<<manifest>> <<manifest>> <<manifest>>

<<artifact>>
account-ejb.jar
<<artifact>>
customer-ejb.jar
<<artifact>>
account-ejb.jar
<<manifest>> <<artifact>>
<<manifest>>

tx-ejb.jar
<<artifact>>
customer-ejb.jar
<<manifest>>

<<artifact>>
tx-ejb.jar
<<manifest>>

<<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>>

<<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>>

<<session bean>> <<entity bean>> <<session bean>> <<entity bean>> <<entity bean>>
<<session bean>>
Account AccountEJB Customer CustomerEJB TxEJB
TxControllerEJB
ControllerEJB ControllerEJB

<<artifact>>
<<session bean>> <<entity bean>> <<session bean>> <<entity bean>>
<<artifact>>
app-client.jar
Shorthand for
all JSP files
web-client.war <<entity bean>>
<<session bean>>
Account AccountEJB Customer CustomerEJB <<manifest>> TxEJB
<<manifest>> <<manifest>> TxControllerEJB <<manifest>>
<<manifest>>
<<manifest>>
<<manifest>>

ControllerEJB ControllerEJB
<<artifact>> <<artifact>> <<artifact>>
<<manifest>>
<<artifact>>
<<artifact>>

<<artifact>>
<<J2EE app.client>> AdminMessages <<servlet>> <<JSP>> *.tld, *.gif, WebMessages.
struts.jar
BankAdmin .properties Dispatcher *.jsp *.html properties

<<artifact>>
account-ejb.jar customer-ejb.jar <<artifact>>
app-client.jar tx-ejb.jar
Shorthand for
all JSP files
<<artifact>>
web-client.war

<<manifest>>
<<manifest>> <<manifest>>
<<manifest>> <<manifest>> <<manifest>> <<manifest>>

<<artifact>> <<artifact>> <<artifact>>

<<artifact>>
<<J2EE app.client>> AdminMessages <<servlet>> <<JSP>> *.tld, *.gif, WebMessages.
struts.jar
BankAdmin .properties Dispatcher *.jsp *.html properties

<<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>>

<<session bean>> <<entity bean>> <<session bean>> <<entity bean>> <<entity bean>>
<<session bean>>
Account AccountEJB Customer CustomerEJB TxEJB
TxControllerEJB
ControllerEJB ControllerEJB

<<artifact>>
<<artifact>> Shorthand for
app-client.jar web-client.war Notation: <<artifact>>
all JSP files UML 2.0 DukesBankApp.ear

<<manifest>> <<manifest>> <<manifest>>

<<manifest>>
<<manifest>> <<manifest>> <<artifact>> <<artifact>> <<artifact>>
<<manifest>>

<<manifest>> <<manifest>> <<manifest>> <<manifest>>

account-ejb.jar customer-ejb.jar tx-ejb.jar

<<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>> <<manifest>>

<<artifact>> <<artifact>> <<artifact>> <<session bean>> <<entity bean>> <<session bean>> <<entity bean>>
<<session bean>>
<<entity bean>>

<<artifact>> Account AccountEJB Customer CustomerEJB

TxControllerEJB
TxEJB

<<J2EE app.client>> AdminMessages <<servlet>> <<JSP>> *.tld, *.gif, WebMessages. ControllerEJB ControllerEJB

struts.jar
BankAdmin .properties Dispatcher *.jsp *.html properties
<<artifact>>
<<artifact>> Shorthand for
app-client.jar web-client.war
all JSP files

<<manifest>>
<<manifest>> <<manifest>>
<<manifest>> <<manifest>> <<manifest>> <<manifest>>

<<artifact>> <<artifact>> <<artifact>>

<<artifact>>
<<J2EE app.client>> AdminMessages <<servlet>> <<JSP>> *.tld, *.gif, WebMessages.
struts.jar
BankAdmin .properties Dispatcher *.jsp *.html properties

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 65
View-Based Documentation

Views give us our basic principle of architecture documentation:

Documenting a software architecture is a matter

of documenting the relevant views and then adding
information that applies to more than one view.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 66
Recognizing Types of Views - 1

An architect must consider the system in

three ways:
1. How is it structured as a set of
implementation units?
2. How is it structured as a set of
elements having runtime
behaviors and interactions?
3. How does it relate to non-software
structures in its environment?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f orModule

public release
3 and unlimited distribution.
© 2021 Carnegie Mellon University 67
Recognizing Types of Views - 2
Different types of views show different types
of information:
• Module views show how the
system is structured as a set of
implementation units.
• Component-and-connector views
show how the system is structured
as a set of elements with runtime
behaviors and interactions.
• Allocation views show how the
system relates to non-software
structures in its environment.
Every view contains information from at
least one of these categories.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f orModule

public release
3 and unlimited distribution.
© 2021 Carnegie Mellon University 68
Modules vs. Components: A simple example
This client-server system has 3 modules and 11 components.

C10
C9 C1
Client
Server C8 C2
S1
C7 C3
Common
C6 C4
C5

Key: Module
Key: Component
uses
Request-reply

Module uses view Client-server view

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 69
Standard View Types for Documenting
Architecture
With a clear understanding of requirements, architects then select
structures that promote those qualities. There are many to choose
from!
Module

Uses …
Decomposition Class/Generalization

Layered
Component-and-Connector Allocation

Client-Server … Work Assignment …

Concurrency Shared-Data Deployment Implementation
Process

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 70
Module View Example
Uses Style: UML

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 71
Module View Example – Extract from Fuser
Uses Style: Outline
fuser-parent + com.mosaicatm.matmdata.airline asdex-parent
+ com.codahale.metrics + com.mosaicatm.matmdata.common + com.mosaicatm.aptcode
+ com.google.gson + com.mosaicatm.matmdata.envelope + com.mosaicatm.gufi.plugin
+ com.matm.actypelib + com.mosaicatm.matmdata.flight + com.mosaicatm.guficlient
+ com.mosaicatm.adaptation + com.mosaicatm.matmdata.fusersurveillance
+ com.mosaicatm.gufiservice
+ com.mosaicatm.adsb.data + com.mosaicatm.matmdata.heartbeat
+ com.mosaicatm.adsbplugin + com.mosaicatm.matmdata.position
+ com.mosaicatm.lib.bulk2
+ com.mosaicatm.aircraftmanagement + com.mosaicatm.matmdata.positionenvelope + com.mosaicatm.lib.camel.jms
+ com.mosaicatm.aodbplugin.matm + com.mosaicatm.matmdata.sector + com.mosaicatm.lib.fitnesse
+ com.mosaicatm.aptcode + com.mosaicatm.matmdata.util + com.mosaicatm.lib.playback
+ com.mosaicatm.container.io + com.mosaicatm.matmplugin.matm + com.mosaicatm.lib.text
+ com.mosaicatm.data.flightstate + com.mosaicatm.performancemonitor.common + com.mosaicatm.lib.wrap
+ com.mosaicatm.faa.util + com.mosaicatm.rmasplugin.matm + com.mosaicatm.lib.xml
+ com.mosaicatm.flighthubplugin.matm + com.mosaicatm.rollingfile + com.mosaicatm.rollingfile
+ com.mosaicatm.flightmanagement + com.mosaicatm.sector.geometry
+ com.mosaicatm.fmccommon + com.mosaicatm.sfdps.data.transfer;
+ com.mosaicatm.fmcplugin + com.mosaicatm.sfdps.data.transfer
+ com.mosaicatm.guficlient + com.mosaicatm.sfdpsplugin.matm
+ com.mosaicatm.lib.camel + com.mosaicatm.smes.transfer
+ com.mosaicatm.lib.coord + com.mosaicatm.smesplugin.matm
+ com.mosaicatm.lib.database + com.mosaicatm.surveillanceplugin.matm
+ com.mosaicatm.lib.jaxb + com.mosaicatm.tfm.thick.flight.mtfms.data
+ com.mosaicatm.lib.messaging + com.mosaicatm.tfmplugin.matm
+ com.mosaicatm.lib.playback + com.mosaicatm.tfmplugin
+ com.mosaicatm.lib.spring + com.mosaicatm.tfmtfdmplugin
+ com.mosaicatm.lib.text + com.mosaicatm.tma.common
+ com.mosaicatm.lib.time + com.mosaicatm.tmaplugin
+ com.mosaicatm.lib.util + com.mosaicatm.ttp.util
+ com.mosaicatm.matmdata.aircraft + com.mosaicatm.ttpplugin
+ com.mosaicatm.matmdata.aircraftcomposite + com.mosiacatm.ifile
+ org.apache.commons.logging

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 72
Component-and-Connector View:
Pipe-and-Filter Style

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 73
 Deployment
View
1. Internet Gateway: Allows
communication between Virtual Private
Cloud (VPC) and the internet.
2. Application Load Balancer
(ALB): ALB manages traffic within the
implementation and from external
connections.
3. Front-end Server (EC2): Is placed in
an auto-scaling group where the front-
end web server is deployed on EC2
instances and serves as an application
user interface (UI).
4. Back-end Server: Back-end web
services are placed in a private subnet,
deployed on EC2 instances.
5. Amazon RDS (Database): Application
database is kept in a restricted subnet
that interacts with back-end services.
6. AWS CloudTrail: Provides
compliance, governance, operational
and risk auditing of the AWS accounts.
•••
https://notsosecure.com/security-architecture-review-of-a-cloud-native-environment/

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 74
Seven Principles of Sound Documentation

Certain principles apply

to all documentation,
not just that for
software architectures.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 75
Avoid Ambiguity - 1

Documentation is for communicating information and ideas.

If the reader misunderstands because of ambiguities,
the documentation has failed.

Even “simple” concepts can confuse. Here, what does the arrow mean?
• C1 calls C2
• Data flows from C1 to C2
• C1 instantiates C2
• C1 sends a message to C2
• C1 is a subtype of C2
• C2 is a data repository and C1 is writing data to C2
• C1 is a repository and C2 is reading data from C1

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 76
Avoid Ambiguity - 2

Precisely defined notations/languages help avoid ambiguity.

If your documentation uses a graphical language, always include a
key!
• It can point to the language’s formal definition
• It can give the meaning of each symbol. (Don’t forget the lines!)
If color or position is significant, indicate how.

Be sure to make the key

meaningful: don’t just say
“element” and “relation.”
Different element and
relation types should have
different symbols.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 77
Avoid Ambiguity - 3

SOAP request
(web services URL) Examples of keys
Thick Axis + ATIA WebLogic 6.1
services Oracle admin. server Oracle 9i
client Web (servlet) Web Windows 2000
DB Server
Web
browser
Web
browser
Database
WebLogic
TDDT IBM x345
SOAP
browser
browser
.NET 6.1
CMP or ATIA-M
response Façade Enterprise
WebLogic
SLSB BMP entity
HTTP(S) 6.1 Database

interserver coordination over IP

bean
ports 80, 443
Windows 2000 IBM AIX 4.3.3
HTTPS SOAP IBM x235
Front IBM H80
http Controller
WebLogic Oracle RAC
request (servlet) synch.
6.1

JDBC over TCP

Portal
forward or WebLogic
web Oracle 9i
sendRedirect HTTP(S) Product
6.1 DB Server
page ports 80, 443
WindowsFiles
2000
http Result IBM x235
response ATIA-M
Page Enterprise
HTTPS HTTPS WebLogic
NIPRNET (JSP or HTML) 6.1
Database

F5 Networks WebLogic IBM AIX 4.3.3

Client Tier Firewall
Web Tier EJB Tier HTTP(S) Backend Tier IBM H80
BIG-IP 540 with 6.1
SSL accelerator ports 80, 443
Windows 2000
Load balancing IBM x235
LDAP
Key: (sticky connections);
using
MS.NET Windows HTML
automatic and
failover web com- Key M - module
application JavaScript ponent Helix Server
SSL
- uses File RDL-M
logical tier documents
Data I/O
EJB (not a html, self-
repository ASAT multimedia
component)
HTTP, RTSP, extracting zip,
AKO repository Real Media, Windows Media, pdf, jpeg, etc.
LDAP MMS Flash, QuickTime, MPEG
HTTP-based Java method
File I/O
ports 80, 554, JDBC
communication call (local) 1755 Windows 2000
Windows 2000 - IBM x235 IBM x345

Key: User
Communi- Server software Data repository
Server cation
machine running on a residing on a
machine protocol machine machine

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 78
Avoid Ambiguity - 4

Box-and-line diagrams
are a common form of
architectural notation.

But what do they mean?

If you use a box-and-line

diagram, always define
precisely what the boxes
and lines mean.

If you see an ambiguous box-and-line diagram, ask the owner what

it means. (The result is often entertaining!)

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 79
Use a Standard Organization

Establish it, make sure that your

documents follow it, and make sure that
readers know what it is.
A standard organization
• helps the reader navigate and find
information
• tells the writer what to document,
where it belongs,
• helps plan the work, and
measure the work left to be done
• lets the writer record information as
soon as it is known, in whatever order it is
discovered
• embodies completeness rules and helps with
validation
Examples:
• SEI Views and Beyond
• ISO-42010
• Others, e.g., arc42.org, Simon Brown’s
Visualize book, …

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 80
What Is the “Right” Set of Views?

Unlike approaches that prescribe a fixed set of views, Views and

Beyond is a more general approach:

Choose the best views for each situation.

ISO/IEC 420101 concurs – It prescribes creating your own views to

serve specific stakeholder concerns.
Which views are “right” depends on
• the structures that are inherent in the software
• who the stakeholders are and how they will use the
documentation

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 81
Standard View Types for Documenting
Architecture
With a clear understanding of requirements, architects then select
structures that promote those qualities. There are many to choose
from!
Module

Uses …
Decomposition Class/Generalization

Layered
Component-and-Connector Allocation

Client-Server … Work Assignment …

Concurrency Shared-Data Deployment Implementation
Process

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 82
Behavior: Beyond Structure

Structural diagrams
show all the potential
interactions among
software elements.

Behavioral diagrams
describe specific patterns
of interaction—the system’s
response to stimuli.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 83
Two Classes of Languages
Trace-oriented Comprehensive
languages languages
• describe how the system • show the complete behavior of
reacts when a specific stimulus a system
arrives and the system is in a • are usually state based (e.g.,
specific state statecharts)
• are easy to use because of • can be used to express all
their narrow focus traces
• do not completely capture • support the documentation of
behavior unless you collect all alternatives
possible traces

Both can show the behavior of the whole system, parts of the
system, or individual elements.
Traces can correspond to use cases, so behavioral documentation
can show satisfaction of requirements.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 84
Which Is Which?

Trace-Oriented Comprehensive
• use cases* • State machine diagrams*
• communication diagrams* • SDL diagrams
• sequence diagrams* • Z specifications
• message sequence charts • some ADLs
• activity diagrams* • CSP (communicating
• timing diagrams* sequential processes)
• Business Process Execution •…
Language (BPEL) and
Business Process Modeling
Notation (BPMN)
•…

* available in UML
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 85
Documenting Rationale:
Architectural Decisions
Developing a complex software architecture involves making
hundreds or thousands of big and small decisions.

The results of these decisions are reflected in

the views that document the architecture—the
structures with their elements and relations
and properties, and the interfaces and
behavior of those elements.

Rationale is the explanation of the reasoning

that lies behind an architectural decision.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 86
Architecture Decision Record (ADR)
Template - 1
1. Issue. State the architectural design issue being addressed.
2. Decision. State the solution chosen among the alternatives that the
architect evaluated.
3. Status. State the status of the decision, such as pending, decided, or
approved. (This is not the status of implementing the decision.)
4. Group. Name a containing group. Grouping allows for filtering based
on the technical stakeholder interests. Examples: “integration,”
“presentation,” “data,” etc.
5. Assumptions. Describe the key assumptions under which a decision
was made:
- About the environment. Examples: accepted technology standards, an
enterprise architecture, commonly employed patterns, team size and
skill set available, cost and schedule, etc.
- About need. Example: “The system will only be used in the USA”
(justifies why the design has no support for internationalization)

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 87
Architecture Decision Record (ADR)
Template - 2
6. Alternatives. List alternatives (that is, options or positions)
considered. Explain with sufficient detail to judge their
suitability. Listing alternatives espoused by others helps them
know that their opinions were heard.
7. Argument. Outline why a position was selected. This can
include items such as implementation cost, total cost of
ownership, time to market, and availability of required
development resources.
8. Implications. Describe the decision’s implications. E.g., it may
- Introduce a need to make other decisions
- Create new requirements or modify existing requirements
- Pose additional constraints to the environment
- Require renegotiation of scope or schedule

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 88
Architecture Decision Record (ADR)
Template - 3
9. Related Decisions. List decisions related to this one. Useful relations
among decisions include causality (which decisions caused other
ones), structure (showing decisions’ parents or children), or
temporality (which decisions came before or after others).
10. Related Requirements. Map decisions to objectives or requirements,
to show accountability.
11. Affected Artifacts. List the architecture elements and/or relations
affected by this decision. You might also include external artifacts
upstream and downstream of the architecture, as well as
management artifacts such as budgets and schedules.
12. Notes. Capture notes and issues that are discussed during the
decision process.

As in all cases, choose the parts of this template appropriate for your
situation.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 89
Exercise – View selection for DIP

Who is going to use the architecture documentation? For what

purpose? What types of views would be beneficial?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 90
Architecture design and
analysis

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 91
Architecture-Centric Approach
The SEI architecture-centric approach can add value, building on
the fundamental concepts of
• business goals: Systems are built to satisfy business goals.
Business goals determine requirements.
• quality attributes: Quality attribute requirements exert the
strongest influence on architectural design.
• architectural design primitives: Architectural tactics and patterns
are the basic building blocks of design used by practitioners.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 92
What Is Design and Analysis?

Design is making the decisions that lead to the creation of

architecture.
• Which design decisions will lead to a software architecture that
successfully addresses the desired system qualities?

Analysis ensures that the architecture used is the right one.

• How do you know if a given software architecture is deficient or
at risk relative to its target system qualities?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 93
Implications for Software Architecture Design
and Analysis
The degree to which a system meets its quality attribute
requirements is dependent on architectural decisions.
• A change in structure improving one quality often affects the
other qualities.
• Architecture is critical to the realization of quality attributes.
These quality attributes should be designed into the
architecture.
• Architecture can only permit, not guarantee, any quality
attribute.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 94
Use of Analysis in Design Methods

- Concerns
- Design Purpose

For More Information: Hofmeister, C.; Kruchten, P.; Nord, R.L.; Obbink, H.; Ran, A.; America, P. “A General Model of Softw are
Architecture Design Derived from Five Industrial Approaches.” Journal of Systems and Software, 2007.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 95
Architectural Analysis and Design

Architectural analysis and design are tightly coupled.

The word analysis is defined by Merriam-Webster
as
• the careful study of something to learn about its
parts, what they do, and how they are related to
each other
• an explanation of the nature and meaning of
something

Both of these definitions apply to architecture

analysis.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 96
Analysis and Documentation
as a Portion of Design
1: Focus on
architectural
drivers to create
design concept.

2: Focus on functional
requirements to create
instantiated design.

3: Verify requirements
and complete architecture
description.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 97
Analysis and Documentation
as a Portion of Design – Iterative Process
1: Focus on
architectural
drivers to create
design concept.

2: Focus on functional
requirements to create
instantiated design.

3: Verify requirements
and complete architecture
description.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 98
Architecture Centric Engineering

BUSINESS
AND MISSION ACE/TSP ARCHITECTURE ACE/TSP SYSTEM
GOALS

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 99
Architecture Centric Engineering - Methods

Attribute Driven TSP launch, release Active Design

Quality Attribute Design planning, checkpoints Review
Workshop
Business Thread
Workshop

BUSINESS
AND MISSION ACE/TSP ARCHITECTURE ACE/TSP SYSTEM
GOALS

Conformance
Review

Views and
Beyond

Architecture Trade-off
Analysis Method

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 100
QAW, ADD, V&B, and ATAM Together

QAW Patterns and Lightweight view Chosen, combined

tactics packets; views views plus
determined by documentation
patterns beyond views
Client
Teller 1

Account Account
Server-Main Server-Backup

ASTER V0
Gateway Gateway

Account
Database Administrative

Maintenance
KEY Component Types:
Tool
Attachment
Client
Connector Types:
Server Publish-Suscribe

Database Client-Server
Request/Reply
Database Database Access
Application
SYBASE DS <<layer>> A <<layer>> A

<<layer>> A
<<allowed to use>>
<<layer>> A
<<allowed to use>>
KEY Repository Component SQL

RPC Exposed RPC Exposed SQL

Interface Interface <<layer>> B <<layer>> B

<<allowed to<<allowed
use>> to <<layer>>
use>> A <<layer>> A
<<allowed to use>>

<<layer>> B <<layer>> B
<<segment>> <<segment>> <<segment>> <<segment>> <<segment>> <<segment>>
B1 B2<<allowed to<<allowed
B3
use>> to use>> B1 B2 B3
<<allowed to use>>

<<layer>>
<<allowed to use>>B <<layer>>
<<allowed B
to use>>
<<segment>> <<segment>> <<segment>> <<segment>> <<segment>> <<segment>>
B1 B2<<allowed to B3
use>> B1 B2 B3

<<allowed to use>> <<allowed to use>>

<<segment>> <<segment>> <<segment>> <<segment>> <<segment>> <<segment>>
<<layer>> B1
C B2 B3 B1
<<layer>> C B2 B3

<<allowed to use>> <<allowed to use>>

<<layer>> C <<layer>> C

<<layer>> C <<layer>> C

ADD

Prioritized
QA scenarios Views &
Beyond
ATAM
Requirements,
constraints

Stakeholders

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 101
Start of Day 3

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 102
Agenda

Day 1:
• Definition and importance of architecture
• Architectural drivers, quality attribute scenarios
Day 2:
• Architecture Documentation: Views – Structure and Behavior,
Principles of Sound Documentation, Architecture Decision
Records
• Architecture-centric Engineering
Day 3:
• Architecture analysis
- Evaluation approaches, lightweight evaluation
• Architecture design
- Design process, Attribute-Driven Design

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 103
Architecture Analysis

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 104
What Is Analysis?

Architectural analysis is the separation of a software architecture

into its constituent parts for individual study.

Analysis ensures that the architecture used is the right one.

• How do you know if a given software architecture is deficient or
at risk relative to its target system qualities?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 105
Why Analyze?

We analyze because we can.

We analyze because it is a prudent way of informing decisions and

managing risk.

Analysis is the key to evaluation.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 106
Analyze Early and Often

The decisions that you make when designing an architecture are

critical to achieve your quality attribute goals.
And the cost associated with correcting them at a later time can be
significant.
Thus, it is important to perform analysis during the design process,
so problems can be identified and corrected quickly.
If you have followed the ADD process, you should be able to
perform analysis (by yourself or with peers) using the sketches and
views that you produced.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 107
Analysis Techniques: Cost and Confidence

In general there is a correlation between the cost of the technique

and our resulting confidence in its analysis results.

Lifecycle Stage Form of Analysis Cost Confidence

Requirements Experience-based analogy Low Low-High
Requirements Back-of-the-envelope analysis Low Low-Medium
Architecture Thought experiment/reflective questions Low Low-Medium
Architecture Checklist-based analysis Low Medium
Architecture Tactics-based analysis Low Medium
Architecture Scenario-based analysis Low-Medium Medium
Architecture Analytic model Low-Medium Medium
Architecture Simulation Medium Medium
Architecture Prototype Medium Medium-High
Implementation Experiment Medium-High Medium-High
Fielded System Instrumentation Medium-High High

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 108
Techniques for Analysis

• Experience-based analogy •Scenario-based analysis

• Back-of-the-envelope analysis •Analytic models
• Thought experiments •Simulations
• Reflective questions •Prototypes
• Tactics-based questionnaires •Instrumentation of fielded
• Checklists systems

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 109
Lightweight Analysis Techniques

Early in the lifecycle, some lightweight techniques have proven to

be useful and relatively low-cost:
• Reflective question-based analysis
• Tactics-based analysis
• Checklist-based analysis
• Scenario-based analysis

Examples:
• Maintainability: https://resources.sei.cmu.edu/library/asset-
view.cfm?assetid=650480
• Integrability: https://resources.sei.cmu.edu/library/asset-
view.cfm?assetid=637375
• Software Architecture in Practice, 3rd. Edition

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 110
Reflective Questions

The practice of asking (and answering) reflective questions can

augment analysis and design processes.
We think differently when we are problem-solving and when we are
reflecting.
For this reason, researchers have advocated a distinct “reflection”
activity that challenges the decisions made, and that challenges us
to examine our biases.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 111
Reflective Question Examples

• What assumptions are made? Do the assumptions affect the design

problem? Do the assumptions affect the solution option? Is an
assumption acceptable in a decision?
• What are the risks that certain events would happen? How do the risks
cause design problems? How do the risks affect the viability of a
solution? Is the risk of a decision acceptable? What can be done to
mitigate the risks?
• What are the constraints imposed by the contexts? How do the
constraints cause design problems? How do the constraints limit the
solution options? Can any constraints be relaxed when making a
decision?
• What are the contexts and the requirements of this system? What does
this context mean? What are the design problems? Which are the
important problems that need to be solved? What does this problem
mean? What potential solutions can solve this problem? Are there other
problems to follow up in this decision?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 112
Tactics-Based Questionnaires
We can employ tactics as an a guide to analysis. By turning every tactic
into a question, we create a set of QA-specific questionnaires. These are
employed as follows:
1. The reviewers determine a number of quality attributes to drive the
review. These quality attributes will determine the selection of tactics-
based questionnaires to use.
2. The architect presents the portion of the architecture to be evaluated.
The reviewers individually ensure that they understand the
architecture. Questions at this point are just for understanding.
3. For each question from the questionnaire, the designer walks through
the architecture and explains whether and how the tactic is addressed.
The reviewers ask questions to determine how the tactic is employed,
the extent to which it is employed, and how it is realized.
4. Potential problems are captured. Real problems must be fixed, or a
decision must be explicitly made to accept the risks.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 113
Example: Availability

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 114
Tactics-Based Questions for Availability
• Does the system use ping/echo to detect a failure of a
component or connection, or network congestion?
• Does the system use a component to monitor the state of health
of other parts of the system? A system monitor can detect failure
or congestion in the network or other shared resources, such as
from a denial-of-service attack.
• Does the system use a heartbeat—a periodic message
exchange between a system monitor and a process—to detect a
failure of a component or connection, or network congestion?
• Does the system use a timestamp to detect incorrect sequences
of events in distributed systems?
• Does the system employ rollback, so that it can revert to a
previously saved good state (the “rollback line”) in the event of a
fault?
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 115
Checklists
Architecture design is a systematic approach to making design
decisions.
We categorize the design decisions that an architect needs to
make as follows:
1. Allocation of responsibilities
2. Coordination model
3. Data model
4. Management of resources
5. Mapping among architectural elements
6. Binding time decisions
7. Choice of technology

Each of these categories applies to every quality attribute.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 116
Example Design Checklist for Availability:
Allocation of Responsibilities
Determine the system responsibilities that need to be highly
available.
Ensure that additional responsibilities have been allocated to
detect an omission, a crash, incorrect timing, or an incorrect
response.
Ensure that there are responsibilities to
• log the fault
• notify appropriate entities (people or systems)
• disable source of events causing the fault
• be temporarily unavailable
• fix of mask the fault/failure
• operate in a degraded mode

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 117
Example Design Checklist for Availability:
Coordination Model
Determine the system responsibilities that need to be highly available.
With respect to those responsibilities,
• ensure that coordination mechanisms can detect an omission, a crash,
incorrect timing, or an incorrect response. Consider, for example,
whether guaranteed delivery is necessary. Will the coordination work
under degraded communication?
• ensure that coordination mechanisms enable the logging of the fault,
notification of appropriate entities, disabling of the source of the events
causing the fault, fixing or masking the fault, or operating in a degraded
mode
• ensure that the coordination model supports the replacement of the
artifacts (processors, communications channels, persistent storage,
and processes). For example, does replacement of a server allow the
system to continue to operate?
• determine if the coordination will work under conditions of degraded
communication, at startup/shutdown, in repair mode, or under
overloaded operation. For example, how much lost information can the
coordination model withstand and with what consequences?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 118
Scenario-Based Analysis

In scenario-based analysis, QA scenarios drive the analysis by

guiding the analysts to examine whether and how the scenario’s
response goal can be satisfied.
The ATAM is the best known scenario-based analysis method.
The ATAM can be run as a "milestone" evaluation, or lightweight
versions of the ATAM can be employed during the design process.

In the ATAM we
• precisely capture architectural requirements as 6-part scenarios
• prioritize those scenarios
• map the highest-priority scenarios onto representations of the
architecture to understand their consequences

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 119
The Architecture Tradeoff Analysis Method
(ATAM)
The purpose of the ATAM is to assess the consequences of
architectural decisions in light of quality attribute requirements and
business goals.

The ATAM helps stakeholders ask the right questions to discover

potentially problematic architectural decisions.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 120
Conceptual Flow of the ATAM

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 121
Example Scenario Walkthrough

An external client queries the travel database during normal

operations and receives a result in < 2 seconds.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 122
Continuous Architecture Evaluation

ATAM (Architecture Tradeoff Analysis Method) evaluations are

substantial undertakings
• 20 to 30 person-days of effort from evaluation team
• Only makes sense for large/expensive projects where
architecture mistakes are unacceptable
For small, less risky projects, use Lightweight Architecture
Evaluation (1/2 to 1 day meeting or less)
• Participants are fewer and internal to organization, so process &
technologies are familiar to all

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 123
Lightweight Architecture Evaluation

1: Present Business 0.25 hrs Expected to understand, quick refresher

Drivers
2: Present Architecture 0.5 hrs Brief overview with 1 to 2 scenarios
3: Identify Architectural 0.25 hrs Create architecture approaches for specific
Approaches quality attribute concerns
4: Generate Quality 0.5-1.5 hrs Create or update scenarios
Attribute Utility Tree
5: Analyze Architectural 2-3 hrs Map scenarios to architecture
Approaches
6: Present Results 0.5 hrs Review and update risks & tradeoffs

Steps 1 – 5 are done offline ahead of time by the development

team. Evaluators review ahead of design review meeting, and the
2 - 3 hour period is used for discussion of architectural
approaches and Step 6.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 124
Summary

Functional requirements are important, but quality attributes define how

your system is measured by stakeholders (e.g., fast, secure, reliable)
Architectures have significant impact on achievement of quality attribute
requirements
ATAM is an established architectural evaluation method that uses quality
attribute scenarios as measuring sticks against which to evaluate design
decisions
ATAM is a foundation for incremental design reviews
The main output of design reviews is a set of design risks
Design risks with long-term negative consequences that accumulate are
referred to as technical debt
Technical debt with non-local or enterprise impact is particularly important
to watch and pay down

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 125
Exercise

Fuser Architecture Analysis

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 126
Fuser Deployment Views
(Primary Presentation)

Alternative #1 Alternative #1

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 127
Tradeoffs

Concern Alt. Alt. Scenario

#1 #2

Fuser rule
maintainability

Fuser core message

processing throughput

Client connection
workload impact on
Fuser

Operations complexity

Data uniformity to
clients

Feed customizability
for clients

Cloud data egress

costs

+ Alternative helps address this concern

- Alternative is less helpful is addressing this concern

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 128
Architecture Design

Software Engineering Institute

Carnegie Mellon University
Pittsburgh, PA 15213

NSAS DIP Architecture Training [Distribution

[Distribution Statement
Statement A] Approv ed
A] Approved forf or publicrelease
public releaseand
andunlimited
unlimited distribution.
distribution.
© 2021 Carnegie Mellon University 130
What Is Design?

Design is making the decisions that lead to the creation of

architecture.
We make decisions to achieve goals and satisfy requirements and
constraints.

Why does a yurt look like a yurt, which is different from an igloo or
a chalet or a longhouse?
The architectures of these styles of houses have evolved, over the
centuries, to reflect their unique sets of goals, requirements and
constraints.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 131
Is Design Hard?
Yes and no.
Novel design is hard.
But the vast majority of design is not novel.
There are ample proven designs and design fragments, that we
call design concepts, that can be reused and combined to reliably
achieve your goals for most designs.

Traditional American House Frank Lloyd Wright’s Fallingwater

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 132
Architectural Design

In architectural design, we make decisions to transform our design

purpose, quality attributes, functionality, constraints, and
concerns—the drivers—into structures.

Design Concepts
Module
<<selects and
instantiates>>
Uses …
Des ign Purpose
Decomposition Class/Generalization
Layered
Pri ma ry Functionality
Component-and-Connector
<<uses>> <<produces>>
Qua l ity Attri butes Client-Server
…
Concurrency Shared-Data
Cons traints Process

Allocation
Archi tectural Concerns
Work Assignment
…
Deployment Implementation
Architectural Drivers The Architect
Structures

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 133
What Makes a Decision “Architectural”?

A decision is architectural if it has non-local consequences and

those consequences matter to the achievement of an architectural
driver.
No decision is, therefore, inherently architectural or non-
architectural.
Consider the choice of a buffering strategy.
Is this architectural or not?

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 134
Architectural Drivers

As mentioned earlier, architectural drivers consist of

• design purpose
• quality attributes
• primary functionality
• architectural concerns
• constraints
These are critical to the success of the system and, as such, they
drive the architecture.
Architectural drivers need to be baselined and managed
throughout the architecture influence cycle.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 135
Design Concepts

We have identified six broad, reusable categories of design

concepts that aid an architect:
• design principles
• reference architectures
• externally developed components
• deployment patterns
• architectural design patterns
• tactics

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 136
The Output of the Design Process

The output of the design process is a set of architectural structures

resulting from design decisions.
These structures will guide
• analysis and construction
• the education of a new project
member
• cost and schedule estimation
• team formation
• risk analysis and mitigation
• (and of course) implementation

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 137
Design Principles

Design principles are basic tenets that guide us toward good

designs.

There are general design principles, e.g.:

• Information hiding—hide data structures, hide details, hide
variations
• Low coupling, high cohesion

There are more specific design principles. For example, the SOLID
principles aid in designing modifiable, extensible OO-based
architectures.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 138
Design Principles

SOLID principles:

• Single Responsibility Principle: There should be only one reason

for a class to change.
• Open/Closed Principle: Classes and methods should be open
for extension but closed for modification.
• Liskov Substitution Principle: Every function or method that
expects an object parameter of class A must be able to accept a
subclass of A as well, without knowing it.
• Interface Segregation Principle: Classes should not be forced to
depend on interfaces that they do not use.
• Dependency Inversion Principle: High-level classes should not
depend on low-level classes. Both should depend on
abstractions.
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 139
Reference Architectures

Reference architectures are

archetypes that provide an
overall logical structure for
specific
types of applications, e.g.,
• Web application
• mobile application
• lambda architecture
They typically employ and
combine patterns.

They aid in planning and

Source: Microsoft Patterns and Practices Team. Microsoft
reasoning.
Application Architecture Guide, 2nd ed. Microsoft Press. 2009.
https://msdn.microsoft.com/en-us/library/ff650706.aspx
Used with permission from Microsoft.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 140
 Reference Architecture for
Big Data Systems

J. Klein, R. Buglak, D. Blockow, et al., “A Reference Architecture for Big Data Systems in the National Security Domain,” in Proc. 2nd Int. Work shop on BIG
Data Software Eng. (BIGDSE'16), Austin, TX, USA, 2016, pp. 51-57. URL: https://resources.sei.cmu.edu/library/asset- view.cfm?assetid=454876

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 141
Externally Developed Components

Products: A product (or software package) refers to a self-contained

functional piece of software that can be integrated into the system that is
being designed and that requires only minor configuration or coding.
Example: MySQL

Application frameworks: An application framework (or just framework) is a

reusable software element, constructed out of patterns and tactics, that
provides generic functionality addressing recurring domain and quality
attribute concerns across a broad range of applications. Example:
Hibernate

Technology families: A technology family represents a group of specific

technologies with common functional purposes. Example: ORM

Platforms: A platform provides a complete infrastructure upon which to

build and execute applications. Example: Google Cloud

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 142
Architectural Design Decisions

In the early stages of design, decisions are focused on the biggest,

most critical choices that will have substantial downstream
consequences: reference architectures, major technologies (such
as frameworks), and patterns.
Once a design decision has been made, you should think about
how you will document that decision.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 143
Documenting During Design

As you instantiate design concepts you will typically create

sketches. These are initial documentation for your architecture.
• Capture them and flesh them out later.
• If you use an informal notation, be consistent.
• Develop a discipline of writing down the responsibilities that you
allocate to elements.
• Writing it down ensures you won’t have to remember it later.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 144
Tracking Progress

When designing there are three key questions to answer:

• How much design do we need to do?
• How much design has been done so far?
• Are we finished?
Agile practices such as the use of backlogs and kanban boards
can help you track design progress and answer these questions.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 145
Design Backlog

You should create a list of the actions that still need to be

performed as part of the architecture design process.
Initially, populate the design backlog with your drivers, but other
activities such as the following can be included:
• Creation of a prototype to test a particular technology or to
address a specific quality attribute risk
• Exploration and understanding of existing assets (possibly
requiring reverse engineering)
• Issues uncovered in a review of the design (recall that we
analyze as we are designing)
• Review of a partial design that was performed on a previous
iteration

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 146
Using a Design Kanban Board

One possible tool for

tracking progress
is a Kanban board.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 147
Termination Criteria

The design process continues across several iterations:

• until the most important technical risks have been mitigated; or
• until design decisions have been made for all of the driving
architectural requirements; or
• until the time allotted for architecture design is consumed (not
very desirable!).

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 148
Attribute-Driven Design (ADD) Method

The ADD method is an approach to defining software architectures

by basing the design process on the architecture’s quality attribute
requirements.
It follows a recursive decomposition process where, at each stage
in the decomposition, tactics, patterns, and technologies are
chosen to satisfy a set of architectural drivers.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 149
Recall: The Architecture Influence Cycle
(AIC)

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 150
Design Is a Transformation
In architectural design, we make decisions to transform our design
purpose, quality attributes, functionality, constraints, and
concerns—the drivers—into structures.

Design Concepts
Module
<<selects and
instantiates>>
Uses …
Des ign Purpose
Decomposition Class/Generalization
Layered
Pri ma ry Functionality
Component-and-Connector
<<uses>> <<produces>>
Qua l ity Attri butes Client-Server
…
Concurrency Shared-Data
Cons traints Process

Allocation
Archi tectural Concerns
Work Assignment
…
Deployment Implementation
Architectural Drivers The Architect
Structures

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 151
On the Need for an Architecture Design Method

Architecture design is notoriously difficult to master

• Design can (and should) be performed in a systematic way.
• Design decisions should be justified.
The architect is accountable for design decisions
• Design decisions should be recorded.
Otherwise, architecture design may end up being a mystic activity
performed by gurus.
To make any activity more predictable and repeatable, we need
methods.
ADD 3.0 (henceforth just ADD) is the result of more than a decade
of evolution and practice.
Let’s look at its steps in detail…
NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 152
ADD
Design purpose Primary functional Quality attribute Architectural
Constraints
requirements scenarios Concerns

Step 1: Review Inputs

Step 2: Establish iteration goal by selecting drivers

Step 3: Choose one or more elements of the system to refine

From prev ious round of iterations or from existing system

Step 4: Choose one or more design concepts that satisfy the selected drivers
Iterate if necessary

Step 5: Instantiate architectural elements, allocate responsibilities and define

interfaces

Step 6: Sketch views and record design decisions Driver

Architecture
design
Step 7: Perform analysis of current design and review iteration goal and
achievement of design purpose Process step
Precedence

(Refined) Software
Artifact flow
architecture design

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 153
ADD Step 1

Primary functional Quality attribute Architectural

Design purpose Constraints
requirements scenarios Concerns

Step 1: Review Inputs

Step 2: Establish iteration goal by selecting drivers

From prev ious round of iterations or from existing system

Step 3: Choose one or more elements of the system to refine

Step 4: Choose one or more design concepts that satisfy the

Before starting with
Iterate if necessary

selected drivers

design, ensure that

Step 5: Instantiate architectural elements, allocate
there is clarity on the responsibilities and define interfaces
overall design problem
that needs to be solved. Step 6: Sketch views and record design decisions
Driver
Architecture
Step 7: Perform analysis of current design and review iteration design
goal and achievement of design purpose Process step
Precedence
(Refined) Software Artifact
architecture design
flow

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 154
Recall: Prioritizing QA Scenarios
Before commencing design, prioritize quality attribute scenarios.
• Typically only the most important scenarios can be considered in
architectural design.
• Choose the top 5-7 scenarios.

If a QAW was performed, the scenarios will already be prioritized.

One could also use the ATAM technique where scenarios are
prioritized across two dimensions.
• Importance (high, medium, or low) to the success of the system,
ranked by the customer.
• Degree of technical risk (high, medium, or low), ranked by the
architect.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 155
Recall: Functional Requirements

The way the system is structured normally does not inhibit the
satisfaction of functional requirements. Functionality and quality
are orthogonal concerns.

When designing the architecture, however, it is important to ensure

that the structure contains the necessary elements to satisfy
functional requirements.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 156
Recall: Prioritizing Functional Requirements

Primary use cases

• are critical to achieve business goals
• are associated with an important quality attribute scenario.
• may imply a high level of technical difficulty
• exercise many architectural elements
• represent a “family” of use cases

Usually only 10-20% of the use cases are primary.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 157
Recall: Constraints

Constraints limit the range of possibilities when making design

decisions.
• In some cases they are decisions about which you have zero
choice.
Before commencing design, identify, justify, and (ideally) prioritize
constraints.
• Technical constraints
- Use of a legacy database
- Use of Eclipse IDE
• Other constraints
- Development team only familiar with Java
- Obey Sarbanes-Oxley
- Ready in time for April 15th

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 158
ADD Step 2

Primary functional Quality attribute Architectural

Design purpose Constraints
requirements scenarios Concerns

Step 1: Review Inputs

Step 2: Establish iteration goal by selecting drivers

From prev ious round of iterations or from existing system

Step 3: Choose one or more elements of the system to refine

The design problem is

Step 4: Choose one or more design concepts that satisfy the
divided into several
Iterate if necessary

selected drivers

sub-problems.
Step 5: Instantiate architectural elements, allocate
responsibilities and define interfaces

An iteration starts with

deciding which sub- Step 6: Sketch views and record design decisions
Driver
problem to address. Architecture
Step 7: Perform analysis of current design and review iteration design
goal and achievement of design purpose Process step
Precedence
(Refined) Software Artifact
architecture design
flow

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 159
Recall: Scenario Prioritization
If the quality attribute scenarios haven’t been prioritized, a
technique can be borrowed from the ATAM.
Scenarios are prioritized across two dimensions:
• importance to the success
of the system
• degree of technical risk

Scenario ID Importance Technical Risk Prioritized?

QA-001 H H Yes
QA-002 H M Yes
QA-003 H L Maybe
QA-004 M H Yes
QA-005 M M Yes
QA-006 M L No
QA-007 L H No
QA-008 L M No
QA-009 L L No

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 160
ADD Steps 3-5

Primary functional Quality attribute Architectural

Design purpose Constraints
requirements scenarios Concerns

3 types of decisions Step 1: Review Inputs

are made to address

the sub-problem: Step 2: Establish iteration goal by selecting drivers
From prev ious round of iterations or from existing system

1. Select the parts that

need to be Step 3: Choose one or more elements of the system to refine
decomposed
2. Identify and select Step 4: Choose one or more design concepts that satisfy the
Iterate if necessary

selected drivers
existing solutions
that support the Step 5: Instantiate architectural elements, allocate
decomposition responsibilities and define interfaces

3. Create elements Step 6: Sketch views and record design decisions

from the existing Driver
Architecture
solution and Step 7: Perform analysis of current design and review iteration design
establish their goal and achievement of design purpose Process step
responsibilities and Precedence
interfaces (Refined) Software Artifact
architecture design
flow

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 161
ADD Step 6

Primary functional Quality attribute Architectural

Design purpose Constraints
requirements scenarios Concerns

Step 1: Review Inputs

Step 2: Establish iteration goal by selecting drivers

From prev ious round of iterations or from existing system

The “blueprint” is Step 3: Choose one or more elements of the system to refine
refined. This may be
done in parallel with Step 4: Choose one or more design concepts that satisfy the
Iterate if necessary

selected drivers
Step 5.
Step 5: Instantiate architectural elements, allocate
responsibilities and define interfaces
Note: This is not full
documentation but
Step 6: Sketch views and record design decisions
Driver
rather sketches.
Architecture
Step 7: Perform analysis of current design and review iteration design
goal and achievement of design purpose Process step
Precedence
(Refined) Software Artifact
architecture design
flow

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 162
ADD Step 7

Primary functional Quality attribute Architectural

Design purpose Constraints
requirements scenarios Concerns

Step 1: Review Inputs

Step 2: Establish iteration goal by selecting drivers

Decisions made at this
From prev ious round of iterations or from existing system

point are analyzed,

Step 3: Choose one or more elements of the system to refine
along with the advances
in the overall design
Step 4: Choose one or more design concepts that satisfy the
process, to decide if
Iterate if necessary

selected drivers
more iterations are
necessary. Step 5: Instantiate architectural elements, allocate
responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Driver
Architecture
Step 7: Perform analysis of current design and review iteration design
goal and achievement of design purpose Process step
Precedence
(Refined) Software Artifact
architecture design
flow

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 163
ADD Output/Iteration

Primary functional Quality attribute Architectural

Design purpose Constraints
requirements scenarios Concerns

Step 1: Review Inputs

Step 2: Establish iteration goal by selecting drivers

From prev ious round of iterations or from existing system

Step 3: Choose one or more elements of the system to refine

Step 4: Choose one or more design concepts that satisfy the

Iterate if necessary

selected drivers

The design is produced. Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Note: This may be only

a partial architecture Step 6: Sketch views and record design decisions
Driver
design and is not Big Architecture
Step 7: Perform analysis of current design and review iteration design
Design Up Front! goal and achievement of design purpose Process step
Precedence
(Refined) Software Artifact
architecture design
flow

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 164
Design Decisions

The design process involves making different design decisions

• Step 3: Selecting elements to refine
• Step 4: Choosing one or more design
concepts that satisfy the selected drivers
• Step 5: Instantiating architectural elements,
allocating responsibilities and defining interfaces

Step 4 (selecting design concepts) can be particularly

challenging…

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 165
Design Concepts

Most sub-problems that are addressed during an iteration can be solved

using existing solutions (i.e., design concepts)
• We want to avoid re-inventing the wheel.
• It is better (and faster) to use a proven solution to a problem for which we
may not be experts.
• Creativity in design involves identifying, adapting, and combining
solutions.

There are several categories of design concepts, some abstract and some
more concrete.
Here we consider
• reference architectures
vs.
• deployment patterns
• architectural/design patterns
• tactics
• externally developed
components (e.g., frameworks)

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 166
Reference Architectures

Reference architectures provide a blueprint for structuring an

application. Examples for the enterprise application domain include
• mobile applications
• rich client applications
• rich internet applications
• service applications
• web applications

Source: Microsoft Patterns and Practices Team. Microsoft Application

Architecture Guide, 2nd ed. Microsoft Press. 2009.
https://msdn.microsoft.com/en-us/library/ff650706.aspx
Used with permission from Microsoft.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 167
Deployment Patterns

Deployment patterns provide guidance on how to structure the

system from a physical standpoint. Good decisions with respect to
the deployment of the software system are essential to achieve
quality attributes such as availability.

Examples
• 2, 3, 4 and n-tier deployment
• Load-balanced cluster
• failover cluster
• private/public cloud

Source: Microsoft Patterns and Practices Team. Microsoft

Application Architecture Guide, 2nd ed. Microsoft Press.
2009. https://msdn.microsoft.com/en-us/library/ff650706.aspx
Used with permission from Microsoft.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 168
Tactics - 1

What are tactics?

• Design decisions that influence the control
of a quality attribute response.
There are tactics categorizations for
the quality attributes of
• availability
• interoperability
• modifiability
• performance
• security
• testability
• usability

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 169
Tactics - 2

What if there are no tactics for my QA?

• You can create your own,
based on your experience.
• This is a useful organizational
knowledge base.
• Consider this categorization of
DevOps tactics1.

Chen, H-M, Kazman, R., Haziyev, S., Kropov, V., Chtchourov, D. “Architectural Support for DevOps in a Neo-Metropolis BDaaS
Platform”, IEEE 34th Symposium on Reliable Distributed Systems Workshop (SRDSW), (Montreal, Canada), Sept. 2015

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 170
Architectural / Design Patterns
Patterns are proven (conceptual)
solutions to recurring design problems.
Patterns originated in building architecture.
Many patterns exist (thousands), and they are
documented across several pattern catalogs.
It is difficult to draw a clear boundary between
“design” and “architectural” patterns.

Cover art for SOA Design Patterns used w ith permission from Thomas Erl.
Cover art used w ith permission of John Wiley & Sons, Inc., from Security
Patterns in Practice, Eduardo Fernandez-Buglioni, 1st edition, 2013, and
Pattern-Oriented Software Architecture, Douglas Schmidt et al., volume 2, 1st
edition, 2000; permission conveyed through Copyright Clearance Center, Inc..

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 171
Externally Developed Components

These are reusable code solutions

• Examples include middleware and frameworks.

A framework is a reusable software element that provides generic

functionality, addressing recurring concerns across a range of
applications.
• Examples for Java:

Concern Framework Usage

Local user interface Swing Inheritance
Web UI Java Server Faces (JSF) XML, Annotations
Component connection Spring XML, Annotations
Security (authentication, auth) Spring-Security XML, Annotations
OO–Relational Mapping Hibernate XML, annotations

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 172
Selecting Design Concepts (Step 4)

Design concept

Design concept

Design concept

Design concept

Iteration goal Design concept

Design concept

Design concept

Design concept

Design concept

Generation of candidates Selection

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 173
Continuous Architecture Evaluation

ATAMs are substantial undertakings

• 20 to 30 person-days of effort from evaluation team
• Only makes sense for large/expensive projects where
architecture mistakes are unacceptable
For small, less risky projects, use Lightweight Architecture
Evaluation (1/2 to 1 day meeting or less)
• Participants are fewer and internal to organization, so process &
technologies are familiar to all

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 174
Design Decisions and Technical Debt

• We refer to design decisions

with long-term negative
consequences, such as
increased cost of change or
reduced customer
responsiveness, as technical
debt

• Technical debt, if not paid

down, can increase over time

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 175
Summary
Architecture design transforms drivers into structures.
Architectural drivers include functional requirements, quality
attributes, and constraints but also design purpose and
architectural concerns.
ADD is a method that structures architecture design so it may be
performed systematically.
Design concepts are building blocks from which the design is
created. There are several important types: reference
architectures, deployment patterns, architectural patterns, tactics,
and externally developed components such as frameworks.
ADD can be performed in an agile way by using initial
documentation (sketches) and a design Kanban board to track
design advancement.

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 176
Final Discussion and Questions

NSAS DIP Architecture Training [Distribution Statement A] Approv ed f or public release and unlimited distribution.
© 2021 Carnegie Mellon University 177