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