The layperson's guide to software architecture

THE LAYPERSON’S GUIDE TO SOFTWARE
ARCHITECTURE
Liauw Fendy

2
Ready to
make your
mark?
/careers
©ThoughtWorks 2019 Commercial in Confidence

©ThoughtWorks 2019 Commercial in Confidence 5
Motivations for this talk
Uncover:
● What is an architect?
● What is software architecture?
● How does design fit into architecture?
● When is the right time to make technical decisions?
● Who makes technical decisions?
● What should be the primary focus for technical decision making?
Why are you here?

WHAT IS AN ARCHITECT
Original diagram can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 4
(Diagram removed)
There is a diagram here that shows an architect as
someone sitting in the intersection between
business, technology and users.

Investigator Butcher Tactician
Judge
Instructor Entrepreneur

An investigator
An architect interviews, investigates
and defines the problem.
“A problem well-defined is a problem half-solved.”
- Charles Kettering, Head of Research GM

A butcher
An architect splits / partitions the problem into smaller
discrete pieces.
“How do you eat an elephant? One bite at a time.”
- Creighton Abrams, US Army General

A tactician
An architect makes plans according to the big picture
and assigns responsibilities.
“Start small. Think Big.”
- Steve Jobs

A judge
An architect needs to understand trade-offs
and make trade-offs on quality attributes.
“There are no solutions. Only trade-offs.”
- Thomas Sowell, Economist, Social Theorist, Stanford University

TRADE OFF
Taken from: https://www.cybera.ca/news-and-events/tech-radar/understanding-the-cap-theorem/

A mentor
An architect needs to grow architectural capabilities of others.
“A rising tide lifts all boats”
- Regional chamber of commerce - New England Council, or JFK

An entrepreneur
An architect needs to balance risk
and manage technical debt.
“He who is not courageous enough to take risks will
accomplish nothing in life.”
- Muhammad Ali

Architect responsibilities:
● Define the problem
● Partition the system and assign responsibilities
● Keep an eye on the bigger picture
● Decide trade-offs among Quality attributes (CFRs)
● Grow the team’s architecture skills
● Manage technical debt
Adapted from: Design it! - From programmer to Software Architect, 1st Edition, Page 4-7

- Grady Booch
Grady Booch. Taken from https://iasaglobal.org/architecture-vs-design/

- Grady Booch
“All architecture is design
but not all design is architecture. ...”

- Grady Booch
“...Architecture represents the
significant design decisions
that shape a system...”

- Grady Booch
“...where significant is measured by
cost of change.”

- Michael Keeling
Design it! - From programmer to Software Architect, 1st Edition, Page 7

- Michael Keeling
“Software Architecture is a set of
significant design decisions about how the
software is organised to promote desired
quality attributes and other properties."

RULES OF DESIGN THINKING
PRESERVE
AMBIGUITY
ALL DESIGN
IS REDESIGN
MAKE DESIGN
TANGIBLE
DESIGN FOR
HUMANS
Adapted from: Design it! - From programmer to Software Architect, 1st Edition, Page 16

Process should serve people,
not people serve process
DESIGN FOR
HUMANS

DESIGN FOR
HUMANS

DESIGN FOR
HUMANS
Taken from: https://www.sitepoint.com/feature-toggling-explained-with-qandidates-toggle/

DESIGN FOR
HUMANS
Developers

DESIGN FOR
HUMANS
Actionable checklist:
❏ Fill people’s needs?
❏ Easily understood?
❏ Collaborative process?

PRESERVE
AMBIGUITY
Delay decisions
to the last responsible moment

PRESERVE
AMBIGUITY
Past Future
Option C
Option B
Option A
Option C will no longer be viable
beyond this time

PRESERVE
AMBIGUITY
Delay in decision starts to have cost
(Blocked)
Past Future

PRESERVE
AMBIGUITY
Why delay:
❏ Change
❏ Information
❏ Pragmatism
❏ Budget?

PRESERVE
AMBIGUITY

Manu Cornet. Taken from https://bonkersworld.net/organizational-charts

ALL DESIGN
IS REDESIGN
If I have seen further it is only by
standing on the shoulders of
giants.
-Isaac Newton

ALL DESIGN
IS REDESIGN

ALL DESIGN
IS REDESIGN
https://www.michielrook.nl/2016/11/strangler-pattern-practice/

ALL DESIGN
IS REDESIGN
One new report
One additional report
One new report
One additional report
Build from scratch
Create report engine
Build from scratch
Create report engine

ARCHITECTURAL PATTERNS
https://gcp.solutions
https://azure.microsoft.com/en-au/solutions/architecture/
https://aws.amazon.com/architecture/

MAKE DESIGN
TANGIBLE
We favor the visible, the embedded, the
personal, the narrated, and the tangible;
we scorn the abstract.
-Nassim Nicholas Taleb

MAKE DESIGN
TANGIBLE
Abstract = Theoretical
Ambiguous = Not “locked in”

MAKE DESIGN
TANGIBLE
Taken from: https://c4model.com/

MAKE DESIGN
TANGIBLE
Taken from: https://medium.com/zenuml/zenuml-sequence-diagram-examples-4e54e3bdca3b

MAKE DESIGN
TANGIBLE
Taken from: https://martinfowler.com/bliki/BoundedContext.html

MAKE DESIGN
TANGIBLE
Taken from: http://www.bredemeyer.com/whatis.htm

DESIGN MINDSET
Taken from: Design it! - From programmer to Software Architect, 1st Edition, Page 19
The four design mindset according to the Design it! Book
(order does not matter):
- Understand
- Explore
- Make
- Evaluate

Original diagram in Design it! - From programmer to Software Architect, 1st Edition, Page 22
DESIGN MINDSET
(Diagram removed)
The diagram shows that you need to understand
business goals, explore technology, make
prototype and evaluate prototype against
business goals

DESIGN MINDSET: UNDERSTAND
● Empathy
○ Choose one thing / Trade-off slider
○ Empathy map
○ Stakeholder map
○ Interview stakeholders
○ CFR requirements gathering
Taken from: https://pragprog.com/book/mkdsa/design-it

DESIGN MINDSET: EXPLORE
● Vision / Big picture
○ Divide and Conquer
○ Group Poster
○ Round Robin Design
○ Whiteboard jam
○ Event Storming
○ Concept Map

DESIGN MINDSET: MAKE
● Concept to artefacts.
Models, prototypes, documents.
○ Architecture Decision Records
○ Greatest hits reading list (curated list)
○ Inception deck
○ Spike (prototype to learn / decide)
○ Sequence diagram
○ Modular decomposition diagram

DESIGN MINDSET: EVALUATE
● Risks analysis
○ Architecture Briefing
○ Code Review
○ Risk Storming
○ Decision Matrix
○ Sanity Check
○ Scenario Walkthrough

WHO MAKES DECISIONS?
R
A
C
I
Responsible Who is performing the task?
Accountable Who makes decisions and liable?
Consulted Who has information to help?
Informed Who needs to be updated on
progress?

WHO MAKES DECISIONS?
Accountable
Consulted
Responsible

Quality Attributes
WHO MAKES WHAT DECISIONS?
Accountable
Consulted
Responsible

Inertia
Accountable
Consulted
Responsible

Risk
Accountable
Consulted
Responsible

ARCHITECTURAL GUARDRAIL
“Manual Fitness Functions”

SENSIBLE DEFAULTS
“f.a.q.”

DESIGN DECISIONS: HOW?
Quality attr.
Risk
Inertia

TIME INVESTMENT
Original Equation can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 29
(Equation removed)
There is an equation here that shows total project
time as a sum of architecture time, development
time and rework time.

Original diagram can be found in Design it! - From programmer to Software Architect, 1st Edition, Page 30
TIME INVESTMENT
(Diagram removed)
There is a diagram here that shows the sweet spot
of how much time you should spend on
architecting type activities.
The sweet spot really depends on the size of the
project. The larger the project, the more time
you should spend due to the reduction in
rework time.

TIME INVESTMENT
However, please consider:
● Cost of change:
○ Sunk cost of analysis effort
○ Sunk cost of existing work
● Wrench in the works:
○ Incomplete information “We did not know..”
○ Incorrect assumptions “We thought we knew..”
○ Changing environments “What we knew is obsolete..”

©ThoughtWorks 2019 Commercial in Confidence 100
Did you get what you came here for?
Did you uncover:
● What an architect is?
● What software architecture is?
● How design fits into architecture?
● When the right time to make technical decisions is?
● Who makes what technical decisions?
● What the primary focus for technical decision making is?
Was is worth your 45+ minutes?

WHAT IS
SOFTWARE ARCHITECTURE
Software architecture:
● Significant design decisions
○ Significant = cost of change
○ Design = intentional
● Software organisation (patterns)
● Quality attributes

Accountable
Consulted
Responsible
Quality attr.
Risk
Inertia

TIME INVESTMENT
(Diagram removed)
There is a diagram here that shows the sweet spot
of how much time you should spend on
architecting type activities.
The sweet spot really depends on the size of the
project. The larger the project, the more time
you should spend due to the reduction in
rework time.

Thank you
112
Liauw Fendy
lfendy@thoughtworks.com
@lfendy

The layperson's guide to software architecture

More Related Content

Similar to The layperson's guide to software architecture

More from Thoughtworks

Recently uploaded

The layperson's guide to software architecture