Aligning Teams and Architecture for Fast Flow - A Use Case

Are you always in meetings with other teams to get things done? Are changes in your software system time-consuming? Is your software system getting too complex?

Delivering valuable software quickly and efficiently is often the goal of software projects. However, achieving fast flow can be challenging, especially as a software product grows in complexity and size. I had the same experience at a Dutch energy network operator.

Clearly, this was not where we wanted to be. We wanted to empower teams and create value continuously. To do this, we had to restructure the architecture and the team's responsibilities. In this talk, I will share how you can recognise that the current alignment of teams and architecture is problematic. After that, I will show the actions we took in our journey of improvement (and the reasoning behind them). Our approach has influences from Domain-Driven Design, Conway's Law, Team Topologies, and more.

This talk will be a combination of theory and practice. In that way, you can take advantage of our lessons learned!

Transcript

1. Aligning Teams and Architecture for Fast Flow - A Use Case at Alliander 1
2. 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
3. Background: Alliander Kleinverbruik Background: Alliander Kleinverbruik 3
4. Alliander Background: Alliander Kleinverbruik 4 - Biggest energy network operator in The Netherlands - Almost 6 million connections at customers
5. Kleinverbruik (KV) small consumption Background: Alliander Kleinverbruik 5 - Connections of households and small businesses - Main Process: customer request to energy supply
6. 6 Background: Alliander Kleinverbruik Main process Kleinverbruik (KV)
7. 7 Background: Alliander Kleinverbruik The world changed
8. 8 Challenges changed 7,5% more work each year -> from reducing cost to being able to handle the work Background: Alliander Kleinverbruik
9. 9 Doing the work gets harder -> scarcity on electrical network Background: Alliander Kleinverbruik
10. 10 Situation at Kleinverbruik What did I encounter at KV?
11. 11 Situation at Kleinverbruik Second Quarterly Planning
12. 12 Situation at Kleinverbruik First PI Planning How is the work divided?
13. 13 History: Teams and pieces of software Before 2018 Situation at Kleinverbruik
14. 14 Situation at Kleinverbruik History: Teams and pieces of software 2019
15. 15 Situation at Kleinverbruik History: Teams and pieces of software 2022
16. 17 Situation at Kleinverbruik Could this be fixed with Aligning Teams and Architecture around business domains?
17. A bit of theory: Why Aligning Teams and Architecture? Why Aligning Teams and Architecture? 18
18. —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
19. 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”.
20. 21 Why Aligning Teams and Architecture? Databases Business logic UIs Frontend devs Backend devs DBAs Teams Architecture Conway’s Law Fast Flow
21. 22 Importance of managing complexity Why Aligning Teams and Architecture? Coupling Cohesion Modularity Dave Farley
22. —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
23. 24 Architecture aligned with Business Why Aligning Teams and Architecture? Problem space Solution space
24. 25 Why Aligning Teams and Architecture? Problem space Solution space Architecture aligned with Business
25. 26 Why Aligning Teams and Architecture? Teams Architecture Support Sales Billing Fast Flow
26. 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
27. 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?
28. How do I know if I have a problem? 30 Problem Indicators
29. 31 The goal is fast flow Problem Indicators Delivering valuable software quickly and efficiently
30. 32 Problem indicators we are not looking at Problem Indicators
31. 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
32. 34 Problem Indicators Dependencies / Meetings Shared codebase No clear purpose Cognitive load to high Context switching
33. 35 Problem Indicators Dependencies / Meetings
34. 36 Problem Indicators Cognitive load to high It is getting too much for your brain!
35. 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?
36. 38 Problem Indicators Context switching Too many responsibilities You’ll work on unrelated features
37. 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
38. 40 Problem Indicators No clear purpose Not empowered around a purpose
39. 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
40. 42 Problem Indicators Why do they block fast flow?
41. 43 Problem Indicators Teams not organized around independent value streams: An end-to-end process with value. Why do they block fast flow?
42. 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?
43. 45 Problem Indicators 2 options for a team: Why do they block fast flow?
44. 46 Problem Indicators 2 options for a team: - Team is responsible for a value stream. Why do they block fast flow?
45. 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?
46. Alliander: Assessing the current situation 48 Assessing the current situation
47. 49 Assessing the current situation Blue team as a bottleneck (first team, very ambitious)
48. 50 Extra: Some of the other teams didn’t feel empowered to get creative and innovative around a business problem Assessing the current situation
49. 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
50. Improving, where to start? 52 Improving, where to start?
51. 53 Improving, where to start? Nick Tune – Architecture Modernization
52. 54 Improving, where to start? Nick Tune – Architecture Modernization
53. 55 Improving, where to start? Nick Tune – Architecture Modernization
54. 56 Improving, where to start? Nick Tune – Architecture Modernization
55. 57 It is all about designing loosely coupled domains!! Improving, where to start?
56. 58 Splitting anti-patterns Improving, where to start? nick-tune-tech-strategy-blog
57. 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
58. 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
59. How to identify loosely coupled domains? 61 How to identify loosely coupled domains?
60. 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?
61. 63 Create a shared business view https://www.agilealliance.org/the-power-of-eventstorming/ Common Alternative How to identify loosely coupled domains?
62. 64 Finding domain boundaries Input: prototype Goal: - How would the prototype work - Finding the domain boundaries How to identify loosely coupled domains?
63. 65 Finding domain boundaries – where to pay attention to? How to identify loosely coupled domains?
64. 66 Finding domain boundaries – where to pay attention to? Example Heuristics: • Language changed How to identify loosely coupled domains?
65. 67 Finding domain boundaries – where to pay attention to? Example Heuristics: • Language changed • Purpose changed How to identify loosely coupled domains?
66. 68 Finding domain boundaries – where to pay attention to? Example Heuristics: • Language changed • Purpose changed • User group changed How to identify loosely coupled domains?
67. 69 Finding domain boundaries – where to pay attention to? How to identify loosely coupled domains? Pivotal events! Event Storming – Alberto Brandolini
68. 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
69. 71 Finding domain boundaries – where to pay attention to? How to identify loosely coupled domains? Event Storming – Alberto Brandolini
70. 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
71. 75 How to identify loosely coupled domains? Purpose: Agreement of the work and certainty of realisation date 1 – Core process steps
72. 76 2 – centralize common concepts How to identify loosely coupled domains? Goal: creating ownership for common concepts & reducing complexity for the core process
73. 77 Centralize common concepts
74. 78 Second iteration Benefits!
75. 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
76. 80 Second iteration
77. 81 Second iteration
78. 82 Domains are not static How to identify loosely coupled domains? Business priority and understanding will evolve
79. 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.
80. 84 Validating domain boundaries How to identify loosely coupled domains? Independent service heuristics (ISH)
81. Mapping teams on the domains 86 Mapping teams on the domains
82. 87 Heuristics Mapping teams on the domains • 1 team per domain (ownership)
83. 88 Heuristics Mapping teams on the domains • 1 team per domain (ownership) • Use cognitive load to determine if a team can handle (multiple) domains
84. 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!
85. 90 What did we do at KV Place current software in newly designed domains
86. 91 What did we do at KV Assign teams (easy choices)
87. 92 What did we do at KV New team New domain, no team yet Assign teams (hard choices)
91. 96 Do it bit by bit Most urgent first Learn along the way Mapping teams on the domains
92. One Year later 97 What are the benefits?
93. One Year later 98
94. What are the benefits? 99 What are the benefits?
95. What are the benefits? Dependencies 100
96. What are the benefits? Dependencies Flow of changes 101
97. What are the benefits? Dependencies Clear purpose Flow of changes 102
98. What are the benefits? Dependencies Clear purpose Learning / innovation Flow of changes 103
99. What are the benefits? Dependencies Team Happiness Clear purpose Learning / innovation Flow of changes 104
100. Feedback from the teams 105 What are the benefits?
101. “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
102. “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
103. “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
104. Aligning Teams and Architecture for Fast Flow 109 Team Topology makers Business Architecture You cannot create fast flow alone! Co-design!
105. 110 Resources Aligning Teams and Architecture for Fast Flow
106. 111 Resources Aligning Teams and Architecture for Fast Flow
107. 112 Resources github.com/ddd-crew Aligning Teams and Architecture for Fast Flow
108. 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