Software architecture

for developers

Simon Brown
 Simon Brown
Independent consultant specialising in software architecture,
plus the creator of the C4 model and Structurizr
What is software
architecture?
 Structure
The de nition of software in terms
of its building blocks and their interactions
fi
 Vision
The process of architecting;
making decisions based upon business goals,
requirements and constraints,
plus being able to communicate this to a team
 Enterprise Architecture
Structure and strategy across people, process and technology

System Architecture
High-level structure of a software system
(software and infrastructure)

Application Architecture
The internal structure of an application
“ ”
As a noun, design is the named structure
or behaviour of a system … a design thus
represents one point in a potential
decision space.
Grady Booch
“ ”
All architecture is design, but
not all design is architecture.

Grady Booch
“ ”
Architecture represents the
signi cant decisions, where signi cance
is measured by cost of change.

Grady Booch
fi
fi
 As architects, we de ne
the signi cant decisions
fi
fi
 Architecture Programming language
Monolith, microservices or hybrid approach

Design

Implementation Curly braces on the same or next line

Whitespace vs tabs
What happens if a software
development team doesn’t
think about architecture?
 Chaos
Big ball of mud, spaghetti code, inconsistent
approaches to solving the same problems,
quality attributes are ignored, deployment
problems, maintenance issues, etc
Big design
up front
vs
Software
Architecture
Document
No design
up front
“ ”
Big design up front is dumb.
Doing no design up front
is even dumber.
Dave Thomas
Software architecture
helps us avoid chaos
Architectural
drivers
 Requirements
drive architecture
(use cases, user stories, features, etc)
 Requirement
"a thing that is needed or wanted"
(this includes experiments and hypotheses too)
Don’t start designing software
if you have no inputs
Quality attributes
(also known as non-functional requirements,
cross-cutting concerns, service-level agreements, etc)
What quality attributes
might be relevant for the
”Financial Risk System”?
Performance
Scalability
Availability
Security
Disaster Recovery
Accessibility
Monitoring
Management
Create a checklist of
Audit
Flexibility quality attributes you
Extensibility
Maintainability
Interoperability
regularly encounter
Legal
Regulatory
Compliance
i18n
L10n
Understand how to capture, re ne
and challenge quality attributes

fi
Software lives in the real world,
and the real world has

constraints
 Typical constraints include
time and budget, technology,
people and skills, politics, etc
Constraints can sometimes
be prioritised
 Principles
are selected by the team
Development principles include
coding conventions, naming
guidelines, testing approaches,
review practices, etc
Architecture and design principles
typically relate to modularity
or crosscutting concerns
(architectural layering, separation of concerns,
stateless vs stateful, rich vs anaemic domain,
security, error handling, logging, etc)
 Ensure you have a good
understanding of the requirements,
quality attributes, constraints
and principles to create
su cient foundations
ffi
What about agile,
and agility?
 Agile is about moving fast,
embracing change, releasing often,
getting feedback, …
Agile is about a mindset of
continuous improvement
Inspect and adapt
“ ”
Continuous attention to
technical excellence and
good design enhances agility.
Principle 9 of the Manifesto for Agile Software Development
A good architecture
enables agility
 A good architecture rarely
happens through
architecture-indi erent design
ff
 Modular
Microservices
monolith
Modularity

Monolithic Distributed
big ball of mud big ball of mud

Number of deployment units

 Agility is a
quality attribute
 The software
architecture role
Software development
is not a relay sport

Software
Architecture
Document
 AaaS
Architecture as a Service
The software architecture role
is about the “big picture”
and, sometimes, this means
stepping away from the code
 The software architecture role
(technical leadership, and responsible for the technical success of the project/product)

Architectural drivers Designing software Technical risks

Understanding the goals; Identifying, mitigating and owning
Creating the technical strategy,
capturing, re ning, and challenging the technical risks to ensure that
vision, alignment, and roadmap.
the requirements and constraints. the architecture “works”.

Technical leadership Quality assurance

Introduction and adherence to
Continuous technical leadership
standards, guidelines, principles,
and ownership of the architecture
etc plus management of
throughout the software delivery.
technical debt.
fi
“ ”
Software development teams
don’t need architects
Software development teams
do need technical leadership
 Every team needs
technical leadership
 Continuous
technical leadership
(somebody needs to continuously steer the ship)
Should software architects
write code?
 Production code, prototypes,
frameworks, foundations, code
reviews, experimenting, etc
Don’t code all of the time!
There is often a tension between
being “senior” and writing code…
Software architects
should be
master builders
Progress Toward an Engineering Discipline of Software
Mary Shaw
 Experience is important …
software architecture is not a rank!
Software architecture is not a
“post-technical” career option!
Technology
skills
Good software architects
are typically
good software developers
The people designing software must
understand technology …
all decisions involve trade-o s

ff
 Soft skills
(leadership, communication, presentation, in uencing,
negotiation, collaboration, coaching and mentoring,
motivation, facilitation, political, etc)

fl
Domain knowledge
(or the ability to learn quickly)
The software architecture role
is multi-faceted
(technology, soft skills, domain knowledge)
Software architects,
solution architects,
tech leads,
principal engineers?
Technical priorities
vs
product priorities?
 The product owner(s) and
software architect(s) are peers
(“Architecture Owner” is another term you can use)
“ ”
Everybody should
be an architect
 “everybody is responsible for architecture”
!=
everybody being responsible for architecture
 Everybody should
*

own the architecture

“ ”
teams should be
agile, autonomous,
and self-organising
“ ”
just hire good people
and trust them to do
the right thing
 Does everybody have the skills
and motivation to collaborate
on the software architecture role?
 Team A Team B Team C
(original authors) (adding code to support business capability 1) (adding code to support business capability 2)

Service X

Product vs stream leadership

 Hierarchies of architects,
central architecture groups,
technical design authorities,
etc?
Decision making
Centralised vs decentralised
Tactical vs strategic
Introducing control?
Avoiding chaos?
How much control do you need?
 Di erent types of teams need
di erent leadership styles
ff
ff
Pair architecting
Collaborative technical leadership
is not easy
Collaborate
or fail
 Draw one or more
software architecture
diagrams to describe a
solution for the
”Financial Risk System”

simonbrown.je
Did you nd anything
about this exercise
challenging?
fi
Take a quick look at the diagrams:
1. Does the solution satisfy the architectural drivers?
2. If you were the bank, would you buy this solution?
Swap your diagrams
with another group
Review the diagrams
Focus on the diagrams rather than the design
… notation, colour coding, symbols, etc

3 things you like

3 things that could be improved
A score between 1-10
1 1 1 2 2 2
 Information is likely
still stuck in your heads
“ ”
This doesn’t make sense,
but we’ll explain it.
• What is this shape/symbol?
• What is this line/arrow?
• What do the colours mean?
• What level of abstraction is shown?
• Which diagram do we read rst?
fi
 The producer-consumer con ict
of software architecture diagrams
I don’t want to put
technology choices on
the diagrams…
I wish these diagrams
included technology
choices…
Software design should
be technology
independent…

Producer Consumer

fl
7
7
7
7
7
7
6
If you’re going to use “boxes & lines”,
at least do so in a structured way,
using a self-describing notation
Moving fast in the same direction
as a team requires

good communication
Do you use UML?
 In my experience,

few people use UML

 #2 “Not everybody else on the team knows it.”
#3 “I’m the only person on the team who knows it.”
#36 “You’ll be seen as old.”
#37 “You’ll be seen as old-fashioned.”
#66 “The tooling sucks.”
#80 “It’s too detailed.”
#81 “It’s a very elaborate waste of time.”
#92 “It’s not expected in agile.”
#97 “The value is in the conversation.”
 If you’re using UML, ArchiMate,
SysML, BPML, DFDs, etc
and it’s working … keep doing so!
Who are the stakeholders that
you need to communicate
software architecture to;
what information do they need?
There are many di erent audiences for diagrams
and documentation, all with di erent interests
(software architects, software developers, operations and support sta , testers,
Product Owners, project managers, Scrum Masters, users, management,
business sponsors, potential customers, potential investors, …)
ff
ff
ff
 The primary use for
diagrams and documentation is
communication and learning
Would you code it that way?
(ensure that your diagrams re ect
your implementation intent)

fl
Is that how it really works?
(ensure that your diagrams re ect
your actual codebase)

fl
 When drawing software
architecture diagrams,
think like a software developer
If software developers created building architecture diagrams…

Stairs Bed1 Bathroom

Off-peak electricity
Peak electricity
Hallway

Water out
Water in
Stairs Bathroom Bed2 Bed3

Kitchen Living Room

“ ”
To describe a software architecture,
we use a model composed of
multiple views or perspectives.
Architectural Blueprints - The “4+1” View Model of Software Architecture
Philippe Kruchten
“Viewpoints and Perspectives”
Why is there a separation
between the logical and
development views?
“ ”
Our architecture diagrams
don’t match the code.
“model-code gap”
 We lack a common vocabulary
to describe software architecture
https://en.wikipedia.org/wiki/Circuit_diagram
https://en.wikipedia.org/wiki/Component_diagram
“ ”
Component
a modular unit with well-de ned Interfaces
that is replaceable within its environment
https://www.omg.org/spec/UML/2.5.1/PDF

fi
Software System

Web
Application

Logging
Component

Relational
Database
Ubiquitous
language
A common set of abstractions
is more important
than a common notation
Abstractions
 Software System

Container Container Container

lient-side web app, server-side web app, console application, (e.g. client-side web app, server-side web app, console application, (e.g. client-side web app, server-side web app, console applic
obile app, database schema, mobile app, database schema, le system, object store, etc) mobile app, database schema,

Component Component Component

Code Code Code

A software system is made up of one or more containers (applications and data

stores), each of which contains one or more components, which in turn are
implemented by one or more code elements (classes, interfaces, objects, functions, etc).
fi
fi
fi
Static structure diagrams
C4
c4model.com
 The C4 model for visualising
software architecture
c4model.com

Zoom in

Zoom in

Zoom in

Level 1 Level 2 Level 3 Level 4

Context Containers Components Code
 Diagrams are maps
that help software developers navigate a large and/or complex codebase
 1. System Context
The system plus users and system dependencies.

Overview
2. Containers
The overall shape of the architecture and technology choices.

3. Components Zoom &

Logical components and their interactions within a container.

4. Code (e.g. classes) Details on demand

Component implementation details.
fi
fi
 Example
(Internet Banking System)
 Level 1
System Context diagram
 Level 2
Container diagram
The container diagram shows the
containers that reside inside
the software system boundary
 Level 3
Component diagram
The component diagram
shows the components
that reside inside an
individual container
 Level 4
Code diagram
The code level diagram shows the code
elements that make up a component
Notation
 The C4 model is
notation independent
 The C4 model is
notation independent
 Titles
Short and meaningful, include the diagram type,
numbered if diagram order is important; for example:

System Context diagram for Financial Risk System

[System Context] Financial Risk System
 Visual consistency
Try to be consistent with notation
and element positioning across diagrams
 Acronyms
Be wary of using acronyms, especially those related
to the business/domain that you work in
 Boxes
Start with simple boxes containing the element name, type,
technology (if appropriate) and a description/responsibilities
 Personal Banking Internet Banking System
Customer [Software System]

[Person]
Allows customers to view information
A customer of the bank, with about their bank accounts,
personal bank accounts. and make payments.

Mainframe Banking
API Application
[Container: Java and Spring MVC] System Facade
[Component: Spring Bean]

Provides Internet banking functionality

via a JSON/HTTPS API. A facade onto the mainframe
banking system.
 Lines
Favour uni-directional lines showing the most important
dependencies or data ow, with an annotation to be explicit
about the purpose of the line and direction

No Yes
fl
Single Page Application Makes an API request to API Application
[Container] [Container]
Sends an API response to

Single Page Application API Application

[Container] [Container]

Makes API calls using

Summarise the intent of the relationship

Single Page Application API Application
[Container] [Container]
Uses

Single Page Application API Application

[Container] [Container]

Makes API calls using

Summarise, yet be speci c

fi
 Requests a list of customers from
[JSON/HTTPS]
Service A Service B
[Container] [Container]

Sends new customers to

[Kafka topic]

Show both directions when

the intents are di erent
ff
 Trade Data System Financial Risk System
[Software System] [Software System]

Trade data

Trade Data System Financial Risk System

[Software System] [Software System]

Sends trade data to

Add more words to make the intent explicit

 If in doubt, read the relationship

Web Application Database

[Container] [Container]

Reads from and writes to

Web Application Database

[Container] [Container]

Reads from and writes to

 Key/legend
Explain shapes, line styles, colours, borders, acronyms, etc
… even if your notation seems obvious!
 Arrowheads
Be careful, using di erent
arrowheads is very subtle;
readers may miss them
ff
Use shape, colour and size
to complement a diagram
that already makes sense
Be careful with icons
 Increase the readability of
software architecture diagrams,
so they can stand alone
Any narrative should complement
the diagram rather than explain it
c4model.com
 Abstractions rst,
notation second
Ensure that your team has a ubiquitous
language to describe software architecture
fi
 The C4 model is…

A set of hierarchical A set of hierarchical

abstractions diagrams
(software systems, containers, (system context, containers, components,
components, and code) and code)

Notation independent Tooling independent

Draw System Context
and Container
diagrams to describe a
solution for the
”Financial Risk System”

simonbrown.je
Designing software is where
the complexity should be,
not communicating it!
Similar levels of abstraction provide
a way to easily compare solutions
The diagrams should spark
meaningful questions
 No
“What does that arrow mean?”
“Why are some boxes red?”
“Is that a Java application?”
“Is that a monolithic application, or a collection of microservices?”
“How do the users get their reports?”
 Yes
“What protocol are your two Java applications using
to communicate with each other?”
“Why do you have two separate C# applications instead of one?”
“Why are you using MongoDB?”
“Why are you using MySQL when our standard is Oracle?”
“Should we really build new applications with .NET Framework
rather than .NET Core?”
 Richer diagrams lead to
richer design discussions
 Richer diagrams lead to
better communication,
making it easier to scale teams
System landscape diagrams
Runtime/behavioural diagrams
Static structure diagrams
are very useful, but they
don’t tell the whole story
Use dynamic diagrams to describe
patterns or complex interactions
Deployment diagrams
Deployment is about the mapping
of containers to infrastructure
 Deployment Node
Physical infrastructure (a physical server or device),
virtualised infrastructure (IaaS, PaaS, a virtual machine),
containerised infrastructure (a Docker container),
database server, Java EE web/application server,
Microsoft IIS, etc
 A deployment node can contain
other deployment nodes or
software system/container instances
 Infrastructure Node
Routers, rewalls, load balancers,
DNS providers, edge caches, etc
fi
FAQ
Part 1
“ ”
C4 has been around over a decade
- if it was truly useful, it would have
replaced UML in most teams
C4 wasn't designed
to replace UML
C4 was designed to bring structure to
the typical ad hoc "boxes and arrows"
diagrams teams typically create
because they are no longer using UML
 I've seen more interest than ever in
C4 over the past few years; many
organisations have adopted it as their
preferred approach for software
architecture diagramming
I’ve run software architecture
workshops
in 30+ countries
for 10,000+ people
across most industry sectors
 My C4 model book is also
used as course material
in many other universities
Tooling?
What tooling do you recommend
for long-lived diagrams?
c4model.com
FAQ
Part 2
Message-driven
architectures
Shared libraries
Microservices
“ ”
C4 is more suited to monolithic
architectures, and doesn’t support
distributed architectures well
“ ”
We’re modelling microservices as
containers, with APIs and database
schemas as components
A microservice should be modelled
as one of the following:

1. A software system
2. A container
3. A group of containers
 What is a
“microservice”?
 Stage 1: 💵
(monolithic architecture)
Stage 2: 💵 💵
(microservices)
software system
Stage 3: 💵 💵 💵
(Conway’s Law)
 Dependencies to
“external” containers
My recommendation is that container
diagrams only show containers inside
the software system that is the scope
of the diagram
Container diagram for software system A

container a {
include *
}
Container diagram for software system B

container b {
include *
}
I don’t recommend showing
“external” containers
Container diagram for software systems A and B

container a {
include a.app b.api
}
Showing “external” containers implies
some understanding of
implementation details, which makes
the diagrams more volatile to change
This is a form of coupling
There may some useful exceptions
to this guidance…
Container diagram for software system A, showing a shared DB

container a {
include a.app c.db
}
Container diagram for software system B, showing a shared DB

container b {
include b.api c.db
}
“ C4 doesn't scale

”
 In this example,
a microservice is
a combination of
an API and
a database schema
container softwareSystem {
include user
Include ->service1->
}
container softwareSystem {
include ->service2->
}
container softwareSystem {
include ->service3->
}
 A nal note...
fi
 Level 1 Level 2 Level 3 Level 4 Level 5

Initial Ad hoc De Modelled Optimising

No software architecture Software architecture Software architecture Software architecture - Model elements are shared
diagrams. diagrams with ad hoc diagrams with de diagrams with de between teams.
abstractions and notation, - Centralised system
in a general purpose landscape views are
diagramming tool. generated by aggregating
decentralised team-based
models.
- Model elements are
reverse-engineered from
source code, deployment
environment, logs, etc.
- Alternative visualisations
are used for di

- Models are used as

queryable datasets.
…

Software architecture diagramming maturity model

fi
ff
fi
fi
 Level 1 Level 2 Level 3 Level 4 Level 5

Initial Ad hoc De Modelled Optimising

No software architecture Software architecture Software architecture Software architecture - Model elements are shared
diagrams. diagrams with ad hoc diagrams with de diagrams with de between teams.
abstractions and notation, - Centralised system
in a general purpose landscape views are
diagramming tool. generated by aggregating
decentralised team-based
models.
- Model elements are
reverse-engineered from
source code, deployment
environment, logs, etc.
- Alternative visualisations
are used for di

- Models are used as

queryable datasets.
…

Software architecture diagramming maturity model

fi
ff
fi
fi
 Level 1 Level 2 Level 3 Level 4 Level 5

Initial Ad hoc De ned Modelled Optimising

No software architecture Software architecture Software architecture Software architecture - Model elements are shared
diagrams. diagrams with ad hoc diagrams with de ned diagrams with de between teams.
abstractions and notation, abstractions and notation, in - Centralised system
in a general purpose a general purpose landscape views are
diagramming tool. diagramming tool. generated by aggregating
decentralised team-based
models.
- Model elements are
reverse-engineered from
source code, deployment
environment, logs, etc.
- Alternative visualisations
are used for di

- Models are used as

queryable datasets.
…

Software architecture diagramming maturity model

fi
ff
fi
fi
 Level 1 Level 2 Level 3 Level 4 Level 5

Initial Ad hoc De Modelled Optimising

No software architecture Software architecture Software architecture Software architecture - Model elements are shared
diagrams. diagrams with ad hoc diagrams with de diagrams with de ned between teams.
abstractions and notation, abstractions and notation, in - Centralised system
in a general purpose a modelling tool, authored landscape views are
diagramming tool. manually. generated by aggregating
decentralised team-based
models.
- Model elements are
reverse-engineered from
source code, deployment
environment, logs, etc.
- Alternative visualisations
are used for di

- Models are used as

queryable datasets.
…

Software architecture diagramming maturity model

fi
ff
fi
fi
 Level 1 Level 2 Level 3 Level 4 Level 5

Initial Ad hoc De Modelled Optimising

No software architecture Software architecture Software architecture Software architecture - Model elements are shared
diagrams. diagrams with ad hoc diagrams with de diagrams with de between teams.
abstractions and notation, - Centralised system
in a general purpose landscape views are
diagramming tool. generated by aggregating
decentralised team-based
models.
- Model elements are
reverse-engineered from
source code, deployment
environment, logs, etc.
- Alternative visualisations
are used for di erent use
cases (e.g. communication
vs exploration).
- Models are used as
queryable datasets.
…

Software architecture diagramming maturity model

fi
ff
fi
fi
 Documenting
software architecture
Enough detail to
start exploring
“ ”
Working software
over
comprehensive
documentation
Manifesto for Agile Software Development
The code doesn’t tell
the whole story
 Software
Architecture Useful information
Document spread across
hundreds of pages;
rarely read or updated
 Travel Guidebook
(maps, points of interest, sights, itineraries,
history, culture, practical information, etc)
 Software Guidebook
(maps, points of interest, sights, itineraries,
history, culture, practical information, etc)
https://leanpub.com/documenting-software-architecture/c/free
The scope is a single
software system
 Describe what you
can’t get from the code
Documentation should
be constantly evolving
 Functional
Overview Quality Attributes Constraints Principles
Context An overview of the software A list of the development and
A list of the quality attributes A list of the environmental
A system context diagram, system; perhaps including architecture principles (e.g.
(non-functional requirements; constraints (e.g. timescales,
plus some narrative text to wireframes, UI mockups, coding conventions,
e.g. performance, scalability, budget, technology,
“set the scene”. screenshots, work ow separation of concerns,
security, etc). team size/skills, etc).
diagrams, business process patterns, etc).
diagrams, etc.

Software
Code Data
Architecture Data models, entity
A description of the software A description of important or
relationship diagrams,
This is a starting point; add and
architecture, including static complicated component
structure (e.g. containers and implementation details,
security, data volumes, remove sections as necessary.
archiving strategies, backup
components) and dynamic/ patterns, frameworks, etc.
strategies, etc.
runtime behaviour.

Infrastructure Development Operation and Decision Log

Architecture Deployment Support A log of the major decisions
The mapping of software (e.g.
Environment made; e.g. as free format text
A description of the An overview of how the
containers) to infrastructure. A description of how a new or a collection of “Architecture
infrastructure available software system is operated,
developer gets started. Decision Records”.
to run the software system. supported, monitored, etc.
fl
 “Architecture
Decision Record”
A short description of an
architecturally signi cant decision

http://thinkrelevance.com/blog/2011/11/15/documenting-
architecture-decisions (Michael Nygard)
fi
Documentation format?
Microsoft Word, Microsoft SharePoint,
Atlassian Con uence, Markdown or AsciiDoc, etc
fl
 How long?
Something I can read in 1-2 hours;
a good starting point for exploring the code
 How do you keep software
architecture documentation
up to date?
 C4 model diagrams
+

software guidebook/arc42
+

architecture decision records

Software architecture
in practice
Big design
up front
vs
Software
Architecture
Document
No design
up front
“ ”
Big design up front is dumb.
Doing no design up front
is even dumber.
Dave Thomas
Evolutionary
architecture
How much up front design
should you do?

0% 100%
“ ”
it depends
Sometimes requirements are known,
and sometimes they aren’t
(enterprise software development vs product companies and startups)
“ ”
just enough
 Up front design is not
necessarily about creating a
perfect end-state or
complete architecture
Iteration (via prototyping and experimentation) is great for product design but…

you don’t just “build the car”

Evolutionary Design
Beginning With A Primitive Whole
Evolutionary Design
Beginning With A Primitive Whole
We’re not trying to
make every decision
“ ”
I think there is a role for a broad starting point architecture. Such things as
stating early on how to layer the application, how you'll interact with the
database (if you need one), what approach to use to handle the web server.

Martin Fowler
https://martinfowler.com/articles/designDead.html
A starting point
adds value
If you don’t engage in the problem, you end up with
a very simpli ed and super cial view of the solution
fi
fi
Part of the design activity is about
discovering “unknown unknowns”
 Plateau

Accelerated learning

Slow initial progress

The typical s-curve of learning

1. Is that what we’re going to build?

2. Is it going to work?
Diagrams are a visual checklist
for design decisions
 System Context diagram
What is the scope of the software system we’re building?
Who is using it? What are they doing?
What system integrations does it need to support?
 Container diagram
What are the major technology building blocks?
What are their responsibilities?
How do they communicate?
Understand the
structure
and create a
shared vision
1. Is that what we’re going to build?

2. Is it going to work?
Teams need to explicitly
manage technical risk
 Problems with new technology

An example timeline from “Beyond Retrospectives”

Linda Rising, GOTO Aarhus 2011
 Identify and mitigate
your highest priority risks
 Probability

Low Medium High

1 2 3

Low
1 2 3
Impact

Medium
2 4 6
2

High
3 6 9
3
The software architecture role
should own the technical risks
Architecturally signi cant?
costly to change | complicated | new

fi
 Like estimates,
risks are subjective
Visual and collaborative “games”
 Risk-storming
A visual and collaborative technique for identifying risk
Threat modelling
(STRIDE, LINDDUN, Attack Trees, etc)
“ ”
Base your architecture on
requirements, travel light
and prove your architecture
with concrete experiments.
Agile Architecture: Strategies for Scaling Agile Development
Scott Ambler
Concrete experiment
Proof of concept, prototype, spike, tracer, vertical slice,
walking skeleton, executable reference architecture, …
 Just enough up front design to create
rm and su cient foundations
fi
ffi
How much up front design
should you do?
 #52

“I’m good with

maybe a day
for a one-year
e ort.”
ff
 Up front design is an iterative and
incremental process; stop when:
You understand the signi cant
You have a way to communicate your
architectural drivers (requirements,
technical vision to other people.
quality attributes, constraints).

You understand the context and scope You are con dent that your design
of what you’re building. satis es the key architectural drivers.

You understand the You have identi ed, and are

signi cant design decisions comfortable with, the risks associated
(i.e. technology, modularity, etc). with building the software.

Techniques: Workshops, interviews, Event Storming, Impact Mapping, domain modelling, OOAD, CRC, DDD,
architecture reviews, ATAM, architecture dry runs, Risk-storming, concrete experiments, C4 model, ADRs, etc.
fi
fi
fi
fi
fi
 How long?
Hours, days or weeks … not months or years
Some Design Up Front
+ Evolutionary Design
Some up front design to create a
starting point and direction
for further evolutionary design
Estimates?
“ ”
we used to do things like this,
it worked but we stopped doing
it when we became agile
Adopt an agile mindset
Choose a starting point and continuously improve
to discover what works for you
 Thank you!

https://leanpub.com/b/software-architecture

Simon Brown