Visualising Socio-Technical Architecture with DDD and Team Topologies
I’ve been disappointed for a long time with the way in which companies organise software development teams.
I remember as a young, naive software developer, I assumed there would be structured processes and patterns similar to those used for designing a software architecture. I crave structure and analytical thinking patterns to design optimal solutions.
It was shocking for me to realise that managers were basically just making it up as they went along. Arbitrarily choosing team boundaries based on what appeared to be their gut instinct. This wasn’t isolated to a single company.
This void in how to organise teams explains why The Spotify Model became so popular. Finally a model for organising teams. Instead of guessing, managers could apply this ‘proven’ technique. With no competing approaches, The Spotify Model became the de-facto way of structuring teams.
What companies have realised since is that you can’t just copy and paste Spotify’s organisation design. There are too many variables involved. We can take inspiration from Spotify’s Model but there is a still a huge need for techniques which allow an organisation to strategically design the most effective sociotechnical architecture to achieve its unique goals.
Somewhat surprisingly, I’ve been really excited with the momentum that’s growing in this space. With the combination of Team Topologies, Wardley Mapping, Dynamic Reteaming, and Domain-Driven Design, I feel we’re starting to develop the tools necessary to design modern technology organisations purposefully and effectively.
Visualising Sociotechnical Architecture as Strategy vs Investment
Laying out your technical capabilities on a core domain chart communicates aspects of your technology strategy. It shows which capabilities you believe are key to achieving your business goals.
Your core domains are your key battlegrounds which are vital to delivering an offering more compelling than your competitors. Your generic services form the platform for enabling teams working on core domains to deliver value more frequently and more cost-effectively.
Visualising core, generic, and supporting domains alone expresses only beliefs about where value lies. But strategy is about making choices, about allocation of resources, choosing to focus on some things at the expense of others.
It is therefore necessary to visualise how commitments align with vision and beliefs — does what we say is important align with how we are actually investing our time and resources?
You can communicate this on your core domain chart by adding a commitment rating for each of your capabilities. As a starting point, this could be the number of FTE (full time equivalent employees) you would ideally allocate to each capability. You could instead use budget or other measures of commitment.
How many companies have you worked with that could articulate their technology strategy like this, in a visual, quantified, structured way?
As always, a large chunk of explicit and implicit influence comes from the fantastic Wardley Mapping.
Optimising Investments
When you visualise your technology vision and investments, a slew of questions and options jump out at you. For example, the diagram below is screaming: “Why are we allocating double the number of FTEs to our supporting vs our core domains?”.
Using this visualisation technique, potential solutions to this problem also jump out at us — the Y-axis of the chart shows complexity, and we can see that the supporting capabilities have higher levels of complexity than our core domains. A clear warning sign. Further investigation is required.
Upon discussion with software engineers, we may discover that the accidental complexity is high — “those are our legacy codebases which are so painful to work with. We would only need half of the people if the code was simpler to change, and required less live support.”.
By reducing the accidental complexity, FTEs will be freed up to work on the core domains.
The next step is to anticipate the cost of reducing accidental complexity and measure the expected benefits. We know the numbers won’t be fully accurate, but we can make more informed risk/reward decisions.
There are infinite strategic plays we could imagine. The key point is that I believe there is a huge advantage in visualising beliefs vs commitments, and using a visualisation where it is possible to collaboratively simulate and evaluate strategic plays.
The bar is so low in my experience that even a simple approach of this nature would be a big improvement for many companies.
Analysing Relationships Between Teams
No matter how hard we try, there are always going to be dependencies between software components and the teams that manage them. Large business-level initiatives will result in programs of work that span multiple teams.
We need to visualise dependencies between teams and quantify how that is going to impact our ability to execute on our strategy — to invest most of our effort in our core domains.
I like to use the Team Topologies interaction modes as a language for describing the types of relationship between teams. If you’re not familiar, here’s a quick introduction:
- X-as-a-Service: One team provides some technical capability, such as an API, which other teams consume with minimal support and collaboration.
- Collaborating: Multiple teams are working together closely in order to deliver a large piece of work
- Facilitating: One team is temporarily helping another to achieve their goals
Showing these relationships on a core domain chart accentuates major problems or opportunities we might otherwise not have realised existed.
Defining Team and Tribe Boundaries
Accentuating dependencies between team and software boundaries provides the foundation for higher levels of organisation design. Knowing what changes together in the software is the key to determining how teams should be organised.
Unfortunately, co-change in systems is multi-dimensional. Different parts of a system will co-change and different times, depending on what’s in the backlog. By visualising these dependencies, we can make strategic decisions about which type of co-change we want to optimise for — we organise our teams in a way that best enables us to improve our core domains.
There’s another aspect to organising teams which goes beyond physical boundaries. It’s the mindset of the teams based on the evolution of the concepts they are developing.
A big bet core domain in a highly unknown space with a highly unpredictable outcome requires a discovery mindset. Speed of learning is key, meaning processes and technical practices change.
Should teams be grouped by physical coupling or the mindset of the products they are developing (this is what Simon Wardley refers to as Pioneers, Settlers, and Town Planners).
What is clear, is that visualising these relationships forces us to think about the resulting dynamics and how they impact our strategic choices. To fully exploit the opportunities of our core domain(s), we need to carefully and consciously think about all aspects of sociotechnical architecture.
Evolving Sociotechnical Architecture Techniques
For a long time I’ve been discontent with the approaches we use to align technical strategy with business strategy, and especially how we organise development teams.
But in the past couple of years I feel a momentum is building. The Team Topologies book has made a huge impact. Simon Wardley has put evolution at the forefront of everything we do. And these new approaches combine extremely well with more traditional concepts like DDD which place an emphasis on complexity.
Strategic Domain-Driven Design with context maps always seemed like a good idea, but was missing something. With the influence of Team Topologies and Wardley Mapping, I feel like we might finally start to unlock their true power.
I’m really keen to talk to other people from any background or discipline who are also thinking about these challenges and how we can address them. Please feel free to contact me.
