Aligning Teams
and
Architecture for
Fast Flow
- A Use Case at Alliander
1
Slide 2
Slide 2 text
Paul van der Slot
2
Freelance Hands-on Architect
- Domain-Driven Design Enthusiast
Started working for Alliander in 2021
- First as a Software Engineer,
later as an (Socio Technical) Architect
Alliander
Background: Alliander Kleinverbruik
4
-
Biggest energy network
operator in The Netherlands
-
Almost 6 million connections at
customers
Slide 5
Slide 5 text
Kleinverbruik (KV)
small consumption
Background: Alliander Kleinverbruik
5
-
Connections of households and
small businesses
-
Main Process:
customer request to energy
supply
Slide 6
Slide 6 text
6
Background: Alliander Kleinverbruik
Main process Kleinverbruik (KV)
Slide 7
Slide 7 text
7
Background: Alliander Kleinverbruik
The world changed
Slide 8
Slide 8 text
8
Challenges changed
7,5% more work each year ->
from reducing cost to being able to handle the work
Background: Alliander Kleinverbruik
Slide 9
Slide 9 text
9
Doing the work gets harder -> scarcity on electrical network
Background: Alliander Kleinverbruik
Slide 10
Slide 10 text
10
Situation at Kleinverbruik
What did I
encounter
at KV?
Slide 11
Slide 11 text
11
Situation at Kleinverbruik
Second
Quarterly
Planning
Slide 12
Slide 12 text
12
Situation at Kleinverbruik
First PI
Planning
How is
the work
divided?
Slide 13
Slide 13 text
13
History: Teams and pieces of software
Before 2018
Situation at Kleinverbruik
Slide 14
Slide 14 text
14
Situation at Kleinverbruik
History: Teams and pieces of software
2019
Slide 15
Slide 15 text
15
Situation at Kleinverbruik
History: Teams and pieces of software
2022
Slide 16
Slide 16 text
17
Situation at Kleinverbruik
Could this be fixed
with Aligning Teams
and Architecture
around business
domains?
Slide 17
Slide 17 text
A bit of theory:
Why Aligning
Teams and
Architecture?
Why Aligning Teams and Architecture?
18
Slide 18
Slide 18 text
—Melvin E. Conway
Conway’s Law
“An organizations system
design, will be a copy of the
organizations communication
structure”
Why Aligning Teams and Architecture?
19
Slide 19
Slide 19 text
20
Why Aligning Teams and Architecture?
Ruth Malan
“If the architecture
of the system and
the architecture of
the organization
are at odds, the
architecture of the
organization
wins”.
Slide 20
Slide 20 text
21
Why Aligning Teams and Architecture?
Databases
Business logic
UIs
Frontend devs
Backend devs
DBAs
Teams Architecture
Conway’s Law
Fast Flow
Slide 21
Slide 21 text
22
Importance of
managing complexity
Why Aligning Teams and Architecture?
Coupling Cohesion Modularity
Dave Farley
Slide 22
Slide 22 text
—Kent Beck
“Pull the things that are
unrelated further apart, and
put the things that are related
closer together”
Why Aligning Teams and Architecture?
23
Slide 23
Slide 23 text
24
Architecture aligned with Business
Why Aligning Teams and Architecture?
Problem space Solution space
Slide 24
Slide 24 text
25
Why Aligning Teams and Architecture?
Problem space Solution space
Architecture aligned with Business
Slide 25
Slide 25 text
26
Why Aligning Teams and Architecture?
Teams Architecture
Support
Sales
Billing
Fast Flow
Slide 26
Slide 26 text
27
Why Aligning Teams and Architecture?
Teams Architecture
Support
Sales
Billing
Billing team
Sales team
Support team
Conway’s Law
Inverse Conway Maneuver
Fast Flow
Slide 27
Slide 27 text
29
Need for
(Business) Socio technical
architecture!!
Both the technical and social
(organizational) aspects of
architecture need to be
co-designed for the joint optimal
solution.
Why Aligning Teams and Architecture?
Slide 28
Slide 28 text
How do I
know if
I have a
problem?
30
Problem Indicators
Slide 29
Slide 29 text
31
The goal is fast flow
Problem Indicators
Delivering valuable software quickly and efficiently
Slide 30
Slide 30 text
32
Problem
indicators we are
not looking at
Problem Indicators
Slide 31
Slide 31 text
33
● Improving inside your team
doesn’t help
● Need to zoom out ->
holistic view of the system
Problem Indicators
Problem
indicators we are
looking at
Slide 32
Slide 32 text
34
Problem Indicators
Dependencies /
Meetings
Shared
codebase
No clear
purpose
Cognitive load
to high
Context
switching
Slide 33
Slide 33 text
35
Problem Indicators
Dependencies /
Meetings
Slide 34
Slide 34 text
36
Problem Indicators
Cognitive load
to high
It is getting too much for your
brain!
Slide 35
Slide 35 text
37
Problem Indicators
Cognitive load
to high
It is getting too much for your
brain!
● How long does is take to onboard new team members?
● How long does it take to implement/coordinate changes?
● How often are there faults during deployments?
Slide 36
Slide 36 text
38
Problem Indicators
Context
switching
Too many responsibilities
You’ll work on unrelated features
Slide 37
Slide 37 text
39
Problem Indicators
Context
switching
Too many responsibilities
You’ll work on unrelated features
●
Too many concepts
●
Unrelated information
●
Hard to see the bigger picture
Slide 38
Slide 38 text
40
Problem Indicators
No clear
purpose
Not empowered around a purpose
Slide 39
Slide 39 text
41
Problem Indicators
●
Lack of focus
●
Motivation drops
●
No Mastery on the domain
●
No Autonomy on optimizing software
around that purpose
No clear
purpose
Not empowered around a purpose
Slide 40
Slide 40 text
42
Problem Indicators
Why do they block
fast flow?
Slide 41
Slide 41 text
43
Problem Indicators
Teams not organized around independent value streams:
An end-to-end process with value.
Why do they block
fast flow?
Slide 42
Slide 42 text
44
Problem Indicators
Independent value streams have fast flow because
the team is empowered to make nearly all of the
decisions within the value stream.
From discovery, to implementing in code, to deploying into
production, to getting feedback
Why do they block
fast flow?
Slide 43
Slide 43 text
45
Problem Indicators
2 options for a team:
Why do they block
fast flow?
Slide 44
Slide 44 text
46
Problem Indicators
2 options for a team:
- Team is responsible for a value stream.
Why do they block
fast flow?
Slide 45
Slide 45 text
47
Problem Indicators
2 options for a team:
- Team is responsible for a value stream.
- Team is reducing complexity of a value stream
via a platform or complicated subsystem.
Why do they block
fast flow?
Slide 46
Slide 46 text
Alliander:
Assessing the
current situation
48
Assessing the current situation
Slide 47
Slide 47 text
49
Assessing the current
situation
Blue team as a bottleneck
(first team, very ambitious)
Slide 48
Slide 48 text
50
Extra:
Some of the other teams didn’t feel
empowered to get creative and
innovative around a business
problem
Assessing the current
situation
Slide 49
Slide 49 text
51
Team Topology once made
Assessing the current situation
● Some problem indicators where noticed
● No clear view on how to improve
● Just never revisited the team topology
Slide 50
Slide 50 text
Improving,
where to
start?
52
Improving, where to start?
Slide 51
Slide 51 text
53
Improving, where to start?
Nick Tune – Architecture Modernization
Slide 52
Slide 52 text
54
Improving, where to start?
Nick Tune – Architecture Modernization
Slide 53
Slide 53 text
55
Improving, where to start?
Nick Tune – Architecture Modernization
Slide 54
Slide 54 text
56
Improving, where to start?
Nick Tune – Architecture Modernization
Slide 55
Slide 55 text
57
It is all about designing loosely
coupled domains!!
Improving, where to start?
Slide 56
Slide 56 text
58
Splitting
anti-patterns
Improving, where to start?
nick-tune-tech-strategy-blog
Slide 57
Slide 57 text
59
Splitting
anti-patterns
Improving, where to start?
Split by Layer ->
DBA team,
Backend team,
Frontend team
Split by Entity ->
Customer,
Product, Case
nick-tune-tech-strategy-blog
Layer / Entity
Slide 58
Slide 58 text
60
Splitting
anti-patterns
Improving, where to start?
Split by Layer ->
DBA team,
Backend team,
Frontend team
Split by Entity ->
Customer,
Product, Case
nick-tune-tech-strategy-blog
Layer / Entity
Slide 59
Slide 59 text
How to identify
loosely coupled
domains?
61
How to identify loosely coupled domains?
Slide 60
Slide 60 text
62
Create a shared
business view
Created a prototype of how we
wanted to solve the KV problems.
-by Business & Tech
How to identify loosely coupled domains?
Slide 61
Slide 61 text
63
Create a shared business view
https://www.agilealliance.org/the-power-of-eventstorming/
Common
Alternative
How to identify loosely coupled domains?
Slide 62
Slide 62 text
64
Finding domain boundaries
Input: prototype
Goal:
- How would the prototype work
- Finding the domain boundaries
How to identify loosely coupled domains?
Slide 63
Slide 63 text
65
Finding domain boundaries –
where to pay attention to?
How to identify loosely coupled domains?
Slide 64
Slide 64 text
66
Finding domain boundaries –
where to pay attention to?
Example Heuristics:
● Language changed
How to identify loosely coupled domains?
Slide 65
Slide 65 text
67
Finding domain boundaries –
where to pay attention to?
Example Heuristics:
● Language changed
● Purpose changed
How to identify loosely coupled domains?
Slide 66
Slide 66 text
68
Finding domain boundaries –
where to pay attention to?
Example Heuristics:
● Language changed
● Purpose changed
● User group changed
How to identify loosely coupled domains?
Slide 67
Slide 67 text
69
Finding domain
boundaries –
where to pay
attention to?
How to identify loosely coupled domains?
Pivotal events!
Event Storming – Alberto Brandolini
Slide 68
Slide 68 text
70
Finding domain
boundaries –
where to pay
attention to?
How to identify loosely coupled domains?
Pivotal events!
Event Storming – Alberto Brandolini
Quotation
Signed
Intake
Work
Preparation
Slide 69
Slide 69 text
71
Finding domain boundaries –
where to pay attention to?
How to identify loosely coupled domains?
Event Storming – Alberto Brandolini
Slide 70
Slide 70 text
74
Steps taken at Kleinverbruik
How to identify loosely coupled domains?
1 – Identify Core process steps
2 – Centralize common concepts
3 – Reduce complexity in most important domain
Slide 71
Slide 71 text
75
How to identify loosely coupled domains?
Purpose: Agreement of the work and certainty of realisation date
1 – Core process steps
Slide 72
Slide 72 text
76
2 – centralize common concepts
How to identify loosely coupled domains?
Goal: creating ownership for common concepts &
reducing complexity for the core process
Slide 73
Slide 73 text
77
Centralize common concepts
Slide 74
Slide 74 text
78
Second iteration
Benefits!
Slide 75
Slide 75 text
79
3 – Reduce complexity in most
important domain
Look at cognitive load!
How to identify loosely coupled domains?
Intake domain:
● Core domain
● Still quite big
● Majority of the new differentiating features in this domain
Slide 76
Slide 76 text
80
Second iteration
Slide 77
Slide 77 text
81
Second iteration
Slide 78
Slide 78 text
82
Domains are not static
How to identify loosely coupled domains?
Business priority and understanding will evolve
Slide 79
Slide 79 text
83
Finding the right boundaries
is not easy.
How to identify loosely coupled domains?
Don’t rush into decisions!
Changing the boundaries is
not for free.
Slide 80
Slide 80 text
84
Validating domain boundaries
How to identify loosely coupled domains?
Independent service heuristics (ISH)
Slide 81
Slide 81 text
Mapping
teams on the
domains
86
Mapping teams on the domains
Slide 82
Slide 82 text
87
Heuristics
Mapping teams on the domains
●
1 team per domain (ownership)
Slide 83
Slide 83 text
88
Heuristics
Mapping teams on the domains
●
1 team per domain (ownership)
●
Use cognitive load to determine if a team
can handle (multiple) domains
Slide 84
Slide 84 text
89
Heuristics
Mapping teams on the domains
●
1 team per domain (ownership)
●
Use cognitive load to determine if a team
can handle (multiple) domains
●
Decide together with the teams!
Slide 85
Slide 85 text
90
What did we do at KV
Place current software in newly designed domains
Slide 86
Slide 86 text
91
What did we do at KV
Assign teams (easy choices)
Slide 87
Slide 87 text
92
What did we do at KV
New team
New domain,
no team yet
Assign teams (hard choices)
Slide 88
Slide 88 text
93
Slide 89
Slide 89 text
94
Slide 90
Slide 90 text
95
Slide 91
Slide 91 text
96
Do it bit by bit
Most urgent first
Learn along the way
Mapping teams on the domains
Slide 92
Slide 92 text
One Year later
97
What are the benefits?
Slide 93
Slide 93 text
One Year later
98
Slide 94
Slide 94 text
What are the
benefits?
99
What are the benefits?
Slide 95
Slide 95 text
What are the benefits?
Dependencies
100
Slide 96
Slide 96 text
What are the benefits?
Dependencies
Flow of
changes
101
Slide 97
Slide 97 text
What are the benefits?
Dependencies Clear purpose
Flow of
changes
102
Slide 98
Slide 98 text
What are the benefits?
Dependencies Clear purpose
Learning /
innovation
Flow of
changes
103
Slide 99
Slide 99 text
What are the benefits?
Dependencies
Team
Happiness
Clear purpose
Learning /
innovation
Flow of
changes
104
Slide 100
Slide 100 text
Feedback
from the
teams
105
What are the benefits?
Slide 101
Slide 101 text
“We are able to deliver more,
because of the reduced
dependencies”
- Product Owner
What are the benefits?
106
“It strengthens my feeling of
ownership, so I can create a clear
product vision on my domain”
- Product Owner
Slide 102
Slide 102 text
“We are able to deliver more,
because of the reduced
dependencies”
- Product Owner
What are the benefits?
107
“It strengthens my feeling of
ownership, so I can create a clear
product vision on my domain”
- Product Owner
“Teams are empowered to own
their architecture inside a
domain. Architects mostly have
to think about inter-domain /
extra-domain problems”
- Solutions Architect
Slide 103
Slide 103 text
“We are able to deliver more,
because of the reduced
dependencies”
- Product Owner
What are the benefits?
108
“It strengthens my feeling of
ownership, so I can create a clear
product vision on my domain”
- Product Owner
“Teams are empowered to own
their architecture inside a
domain. Architects mostly have
to think about inter-domain /
extra-domain problems”
- Solutions Architect
“I understand the purpose of my
domain better. I can get creative in
solving real business problems”
- Software Developer
“Because we own the whole domain,
tackling tech debt becomes easier”
- Software Developer
Slide 104
Slide 104 text
Aligning Teams and Architecture for Fast Flow
109
Team Topology makers
Business
Architecture
You cannot create
fast flow alone!
Co-design!
Slide 105
Slide 105 text
110
Resources Aligning Teams and Architecture for Fast Flow
Slide 106
Slide 106 text
111
Resources Aligning Teams and Architecture for Fast Flow
Slide 107
Slide 107 text
112
Resources
github.com/ddd-crew
Aligning Teams and Architecture for Fast Flow
Slide 108
Slide 108 text
CREDITS: This presentation template was created by Slidesgo, including icons
by Flaticon, and infographics & images by Freepik
Thanks!
113
Aligning Teams
and Architecture
for Fast Flow