Modern Enterprise Architecture:

Architecting for Outcomes

Simon Rohrer
My journey
Developer
Enterprise architect
Ways transformation
Agile of workinglead
adoption lead lead
Head of tech arch & WoW
 Modern Enterprise
Architecture

Teams-of- Interact with Change is a Heterogeneous Systems of

Teams-of- Your Constant Environment: Systems of
Teams: > 150 Customers Old/New, Big/Small, Systems
Employees Digitally Slow/Fast,
Monolith/Distributed
Vendors/Internal
Modern Enterprise Architecture
• Conway’s law ++ and reverse Conway manoeuvre

A Aligning Value, People

and Technology
• Removing complexity and increasing autonomy
• Enterprise architecture as politics and diplomacy

Architecting for • Outcomes of quality, ow, safety to balance pure “value”

B Outcomes: Better Value,

Sooner, Safer, Happier
• Happier customers, colleagues, citizens & climate
• Continuous improvement - be the best at being better

Governing Continuously: • A stream of continuous architecture decisions

C Conversational and
Automated
• Moving decisions down into the right level of the org
• Automating common top-level system policies

D Practicing DevOps at • Learning by observing: intention & re ection

Enterprise Scale • Humility in architecture: all decisions are contingent

Curating the Evolution of

E
• Fitness functions for socio-technical architecture at scale
Enterprise Architecture • Evolving fast and slow
and Organisation
fl
fl
Growth vs Fixed
de nitions
fi
 “Agile”
Fixed mindset Growth mindset

Frameworks & certi cations & Uncovering better ways of

coaches developing software by doing it and
helping others do it

Processes & tools Individuals and interactions

over processes and tools

Sprints, standups, user stories, story Early and continuous delivery

points of valuable software

Scrum Continuous attention to technical

excellence and good design
fi
 “DevOps”
Fixed mindset Growth mindset
A DevOps department / team / You build it, you run it (/ you deploy
engineer it / you test it / you design it / etc)

Kubernetes, cloud, automating release Culture, Automation, Lean, Metrics,

pipelines Sharing

CI/CD The 3 ways: Systems Thinking, Amplify

Feedback Loops, Culture of Continuous
Experimentation & Learning

One more hando in tech: Business = Dev, Customer = Ops

Dev -> DevOps -> Ops/SRE
ff
Where are we?
How did we get here?
1990s
1994 1999

1994 1995 1999

Software ate the world
A paradigm shift happened in software development

Plan Code Test Release Operate

• Requirements • Detailed • Test plan • Change • Incidents

• High level design • Test execution request • Problem fixes Days or hours
design • Development • Deployment

months months months weeks forever

Analysis & Development Test team Release team Operations Development/

design team team team operation
team
Not everyone noticed
Complexity in the existing (“legacy”) system
landscape started to dominate the pace of change
Business
service

Technical
service

Database
Patterns were documented to manage complexity
but not everyone used them. They still don’t.

1. Autonomy
2. Explicit boundaries
3. Partitioning of functionality
4. Dependencies de ned by
functionality
5. Asynchronicity [by default]
6. Partitioning of data
7. No cross-fortress transactions
8. Single point security
Autonomous
business 9. Inside trust
capability 10. Keep it simple
2008
fi
 Our problems are similar but different to those in
the 1990s

1990s 2020s
Civil engineering processes are The enterprise software
the best way to deliver any landscape is so complex we need
software change to use project management
techniques to coordinate multiple
teams for simple features

Plan Code Test Release Operate

• Requirements • Detailed • Test plan • Change • Incidents

• High level design • Test execution request • Problem fixes
design • Development • Deployment

months months months weeks forever

Analysis & Development Test team Release team Operations

design team team team
 Enterprise architecture

Fixed mindset Growth mindset

Tell the organization what to do Help the organisation view itself as a
complex sociotechnical system(-of-
systems-of-systems) & reduce that
complexity over time based on
outcomes and learning
 Aligning Value,
A People and
Technology
Conway’s law (very roughly)

Organisation System
Drives
architecture architecture
If the architecture of the system and the
architecture of the organization are at odds,
the architecture of the organization wins.

Ruth Malan
BUT!
Where all hell really breaks loose is when
management decides to reorganise
things… if you try to change the
organisation, the software won’t let it
happen.

Thierry de Pauw
Organisation System
Drives
architecture architecture

System Organisation
Constrains
architecture architecture
???
We shape our
buildings;
thereafter they shape
us

Winston Churchill
We shape our architectures; thereafter
they shape us

Gene Kim
 Constrains

Organisation
Architecture
structure

Constrains
System architects (who we call
architects) and business/
organization architects (who we call
managers) should not work as if one
has no impact on the other.

Ruth Malan, 2008

 Constrains

Organisation
Architecture
structure

Constrains

Organization architects System architects

(“managers”) (“architects”)
 Business
architecture Organisation
Drives
(“value architecture
streams”)

Organization architects
(“managers”)
 Business
architecture
(“value
streams”)
Organization architects System architects
(“managers”) Constrains Constrains (“architects”)
Constrains
Constrains

Constrains

Organisation System
architecture architecture

Constrains
 Aligning all 3 Value
OKRs looking forward (Dev)

for sustainable KPIs & OLIs right now &

looking back (Ops)

ow
Outcomes,
hypotheses, bets

Work
User stories, tasks,
changes, problems,
incidents

Organization Technology & processes

People, teams, Business services &
teams-of-teams, business processes,
departments IT services & IT
components
fl
Level 0: an Value
OKRs looking forward (Dev)

ideal 2-
KPIs & OLIs right now &
looking back (Ops)

pizza
stream-
Outcomes,
hypotheses, bets

aligned
team User stories, tasks,
changes, problems,
incidents

2 pizza team Software that fits

- <?20 people inside the team’s head
Full stack, full DDD
lifecycle, full burrito, Eventually consistent
T-shaped people - Independently deployable & testable
YBIYRI “Monolith vs Microservice is missing the point”
Self-organizing Emergent design & evolutionary* architecture
 Value
OKRs looking forward (Dev)
KPIs & OLIs right now &
looking back (Ops)

Outcomes,
hypotheses, bets

User stories, tasks,

changes, problems,
incidents

pizza team Software that fits

<?20 people inside the team’s head
Full stack, full DDD
ecycle, full burrito, Eventually consistent
-shaped people - Independently deployable & testable
YBIYRI “Monolith vs Microservice is missing the point”
Self-organizing Emergent design & evolutionary* architecture
 Value
Level 1: an OKRs looking forward (Dev)
KPIs & OLIs right now &
looking back (Ops)
ideal team-
of-teams Outcomes,
hypotheses, bets

User stories, tasks,

changes, problems,
incidents

Team-of-teams System-of-systems & domain

Dunbar number - <150 that fits inside the team’s head
“Tribe” Nested DDD
Nested value Shared data model?
Self-organizing? Eventually consistent
Each component independently deployable & testable
Level 2: an Value
Value Value Value
OKRs looking forward (Dev)
OKRs looking forward (Dev)(Dev)
ideal
OKRs looking forward
OKRs (Dev)
looking forward
KPIs
KPIs & OLIsKPIs &&OLIs
right OLIs
now right
& rightnow
now &&
KPIs & OLIs right now &
looking
looking
looking back (Ops) back
back (Ops)
(Ops)(Ops)
looking back

business line

Team-of-team-of-teams
Team-of-team-of-teams
Team-of-team-of-teams
Team-of-team-of-teams
Teams-of-
Teams-of-
System-of-system-of-systems
System-of-system-of-systems
System-of-system-of-systems Systems of
System-of-system-of-systems
Systems of
Teams: >1000–2000
1000–2000 Does
Does this
thisfit
fitin
in anyone’s
anyone’s
Systems head?
head?
1000–2000 150
Employees Does
1000–2000 this fit
Does in anyone’s
this fit in head?
anyone’s head?
Department
Department
Department / Department / / / Further
Further
Further nested DDD nested
nested DDD
DDD DDD
Further nested
business
business linebusiness line
line Minimally Minimally
Minimally
shared shared
datashared
model data
data
- model
model
just keys?- just
- keys?
just keys?
business line Minimally shared data model - just keys?
Nested valueNested
Nested value
value Eventually
Eventuallyconsistent
consistent between
between subdomains
subdomains
Nested value Eventually consistent between
Eventually subdomains
consistent between subdomains
Self-organizing???
Self-organizing???
Self-organizing??? Key paths Key
Key
and paths
paths
failureand
and failure
modesfailuremodes
modes
should be should
should
known be
be known
known
Self-organizing??? Key paths and failure modes should be known
The best architectures, requirements, and
designs emerge from self-organizing teams.

[Link]/[Link]
 Value
Self-organizing teams?
Value
OKRs looking forward (Dev)
Value
OKRs looking forward (Dev)
OKRs looking forward (Dev)
KPIs & OLIs right now &
KPIs & OLIs right now & KPIs & OLIs right now &
looking back (Ops)
looking back (Ops) looking back (Ops)

Outcomes, Outcomes,
hypotheses, bets hypotheses, bets

User stories, tasks,

User stories, tasks,
changes, problems,
changes, problems,
incidents
incidents

zza team Software that

Team-of-teams fits Team-of-team-of-teams
System-of-systems & domainSystem-of-sys
20 people inside the team’s head 1000–2000 Does
Dunbar number - <150 that fits inside the team’s head this fit in
stack, full DDD Department / Further n
“Tribe” Nested DDD
le, full burrito, Eventually consistent business line Minimally shared da
Nested value Shared data model?
ped people - Independently deployable & testable Nested value Eventually consistent
Self-organizing? Eventually consistent
YBIYRI “Monolith vs Microservice is missing the point” Self-organizing??? Teams-of-Key paths and failure m
Each component independently deployable & testable
Teams-of-
-organizing Emergent design & evolutionary* architecture Teams: > 150
Employees
 Architecting for
Outcomes:
B Better Value,
Sooner, Safer,
Happier
 Antipattern: traditional EA outcomes

Standardisation
These are
Consistency not the
outcomes
Predictive planning you’re
looking for
Cost reduction
 Antipattern: “newer” EA outcomes

Cloud These are

not the
Kubernetes outcomes
you’re
Microservices
looking for
 Pattern: align to business agility
Quality
Flow

Customers
Security
Colleagues
Privacy
Citizens
Minimum
Climate
viable
compliance
We shape our architectures; thereafter
they shape us

Gene Kim
As the systems we build become larger, the
coordination increases…

Gene Kim
…It can grow so so large that all our time
and energy is spent coordinating - it is at
the expense of our value creating activities

Gene Kim
“Hello world” with tightly coupled complex
architecture
“!”
UI

API LAYER
/api

“Hello “Hello
world!” wrld!”

¥$€
Hello

GREETINGS
SOLUTION TESTING
SERVICE
ARCHITECTS TEAM
World

PLANET
SERVICE
T_HW
Autonomous team with their own valuable business capability

]
EARTH GREETER EARTH GREETER EARTH GREETER
“Hello MICROFRONTEND MICROSERVICE MICROSERVICE DB “Hello
world!”
world!”

¥$€
Refactored Restructured organization
and architecture
 Governing

C Continuously:
Conversational
and Automated
Creating and reducing complexity may
sound like perfect opposites. But in fact
fundamental asymmetries exist between
the two.

[Link]
Architecture governance to
the rescue?
Antipattern:
Architecture Review Boards
How we used to govern architecture
A project: waterfall / wagile / water-scrum-fall / “hybrid”

Initiate Plan Execute Close

Review Review

Analysis Design Build/Test Release

Architecture Architecture
board board
How does this work with modern delivery?
An agile or lean project

Plan
Initiate Close

Review Execute

Analysis

Test/design/build

Release Release Release Release Release Release Release

Architecture
board
How does this work with modern delivery?
A product

Architecture
board
Pattern:
Black box architecture
governance
Govern realised architectures, not (just) designs on paper

“I think I need an new service”

EA approve new services, new

namespaces in Kubernetes (etc.)
“I want an exception to
automated governance - e.g.
“I think my service needs to synchronous request/response”
access data or functionality from EA approve:
another service” • Exceptions
• Tech debt
EA approve:
• Service-to-service IAM
• Firewalls

Enterprise Architecture as GitOps

Pattern:
Continuous conversational
“governance”
Continuous conversational governance
Agile/lean/DevOps/Continuous Delivery driven project

Plan
Initiate Close
Execute

Analysis

Test / Design / Build

Release Release Release Release Release Release Release

Continuous conversation
Architecture
C.o.P.
Continuous conversational governance
A single product

Continuous conversation
Architecture
C.o.P.
Continuous conversational governance across value streams
Business unit
Value stream M
Value stream A

Architecture
centre of
Value stream B Value stream C excellence

Value stream N
Value stream D

Architecture
C.o.P.
Value stream E Value stream F
 Practicing
D DevOps at
Enterprise Scale
Continuous conversational governance
Service
management
C.o.E.
Enterprise
Architecture
centre of
scope excellence

Architecture
C.o.P.

Longer term
timeframe
Continuous conversational governance (after Ruth Malan)

Intention Reflection
Architecture
decision records
Whiteboard
sessions

Emergent design
Continuous
refactoring
Model
storming Discoverability &
observability
tooling

Test-driven
design
Working code Infrastructure-as-
code
deployed as
running system
 Curating the
Evolution of
E Enterprise
Architecture and
Organisation
Continuous attention to technical excellence
and good design enhances agility.
Evolutionary architecture fitness functions at
enterprise level (“macro architecture”)

•Number of 2-pizza teams required to implement a typical business feature

- sociotechnical coupling & cohesion

•Asynchronous connections ÷ synchronous connections

Theory #1 gradual evolution

Evolution

Time
:
Theory #2 punctuated equilibria

Evolution

Time
:
Reconciled: punctuated gradualism

Continuous attention to
complexity debt pay down
and continuous
improvement.
Evolution
Continuous funding.

A step change: a business case explicitly to

rewrite (or buy, or outsource, or write something
new).

Standalone funding.

Time
Strangler g pattern
fi
Modern Enterprise Architecture
• Conway’s law ++ and reverse Conway manoeuvre

A Aligning Value, People

and Technology
• Removing complexity and increasing autonomy
• Enterprise architecture as politics and diplomacy

Architecting for • Outcomes of quality, ow, safety to balance pure “value”

B Outcomes: Better Value,

Sooner, Safer, Happier
• Happier customers, colleagues, citizens & climate
• Continuous improvement - be the best at being better

Governing Continuously: • A stream of continuous architecture decisions

C Conversational and
Automated
• Moving decisions down into the right level of the org
• Automating common top-level system policies

D Practicing DevOps at • Learning by observing: intention & re ection

Enterprise Scale • Humility in architecture: all decisions are contingent

Curating the Evolution of

E
• Fitness functions for socio-technical architecture at scale
Enterprise Architecture • Evolving fast and slow
and Organisation
fl
fl
Thank you!

@sirohrer