Designing For Team Autonomy: Tools For Business & Technical Architecture Alignment
Most software developers thrive in environments where they have freedom and flexibility to put their creative minds to work and solve challenging business problems. The organisations they work for benefit too, through a motivated workforce, and a reduction in people management.
Freedom necessitates judicious boundaries, though. Team boundaries and technical boundaries. If teams are constantly relying on each other, or constantly having to coordinate themselves around shared resources such as code or databases, freedom diminishes and the overheads of people management increase.
Unquestionably, the top organisations in tech love team autonomy and freedom. The very best of organisations, including Amazon, Netflix and Spotify, frequently proclaim the overwhelming benefits of their empowered two pizza teams or their tribes, squads and guilds.
But what tools do we have for carving out these judicious boundaries for productivity, autonomy and freedom? Are microservices the answer? What about bounded contexts? Or should we be understanding more about our problem domain first?
Visualising Domain Boundaries (Subdomains)
Autonomy starts by understanding boundaries in the problem domain — understanding where cohesive changes occur and then putting technical boundaries and team boundaries around them. In the DDD community, these are called subdomains.
For example, a typical organisation has many organisational departments. Most of the time, most of the changes, happen, within a single department. Each with its own specific backlog of work and strategic goals.
Some business processes span multiple departments. Accordingly, some cross-departmental collaboration is vital for the health of the organisation. And while this type of collaboration requires more coordination and is less efficient, fortunately, in many organisations it is less frequent than the constant churn of work that happens within a department.
So as a first pass, we could uncover the different boundaries in our domain by having one product delivery team per-department. Enabling them to efficiently self-organise and make decisions in the common case, having to incur the coordination costs of collaborating with other teams as infrequently as possible.
For an organisation that provides a digital media streaming & downloads platform, their department boundaries may look like this:
Note: Organisational departments can often be a naive and suboptimal attempt at uncovering boundaries in the domain. Understanding the domain and business capabilities provides deeper insights, but would make this example unnecessarily complicated.
Context Map: Visualising Technical Boundaries
To provide a clear shared vision of how the technical boundaries in our solution space align with those of the domain and support the goal of autonomy, a traditional, but rarely-used strategic Domain-Driven Design tool — the Context Map, can be used.
Contexts Maps show the different bounded contexts — the technical boundaries — in the solution space. Accordingly, if the goal is autonomy, bounded contexts should be aligned with the boundaries in the problem domain, so that most changes will happen within a bounded context. Accordingly, decision making will be owned by the single team that owns the context.
DDD practitioners, those who use Context Maps, tend to be quite creative in the information they show on context maps. In general, it’s about highlighting dependencies between the different contexts to optimise organisational efficiency.
In the Context Map above, for the digital media streaming organisation, the collaborative relationship between contexts is shown & the team that owns each context is shown. It’s also possible to show other useful information, including collaboration bandwidth and integration strategies on a Context Map.
But there’s a problem with Context Maps. What if the granularity of bounded contexts doesn’t align with the subdomains in the problem space? What if a single department wants to build and run multiple different services (or microservices for the pop culture crowd)?
Architectural Abstraction Tools
To efficiently design and communicate organisational and technical boundaries, a set of architectural abstraction tools that precisely convey intentions are needed. Currently, there is too much ambiguity, especially around the term bounded context, inhibiting articulate communication.
We first need an abstraction that clearly and unambiguously describes a single codebase that is deployed and runs independently. Currently, we have multiple names for this concept. Some call this a service/microservice, some call this a bounded context. And some say a microservice should be a bounded context.
We also need an abstraction that describes a group of these units of deployment that have some cohesive relationship or symmetry that exists in the domain. It may be that collectively they represent a subdomain, or it may be they only partially represent a subdomain. For some, this is also in fact, a bounded context.
We then need an abstraction at the level above, which collectively describes each of the technical pieces in the solution space that represent a subdomain in the problem space. As you guessed, some would also call this a bounded context.
How do we name these three abstractions?
So What Do We Call These Things?
Perhaps the naming of these abstractions can take inspiration from Udi Dahan’s vision of applying DDD to distributed systems.
Udi already has three abstraction tools that perfectly fit the bill (some of the main microservices folk borrowed Udi’s ideas). Unfortunately, Udi labels the highest-level abstraction a bounded context, which has multiple meanings (as previously discussed).
Udi Dahan’s terminology for these three abstractions
Would it be beneficial to rename bounded contexts in Udi’s model to subdomain contexts? There’s a direct relationship due the inclusion of subdomain in the name, which helps to avoid ambiguity. But might it lead to ambiguity when distinguishing between a subdomain and a subdomain context?
The most granular of Udi’s abstractions is the autonomous component. This is the unit of deployment. A piece of software that can be deployed and run on its own. An almost watertight definition that leaves almost zero room for ambiguity. To increase precision, they could even be referred to as deployables or deployable services.
Visualising Context Maps becomes more interesting with three levels of abstraction to play with. If the focus is on strategic boundaries, then Context Maps would show subdomain contexts and possibly significant business components; perhaps where team boundaries do not align with subdomain contexts.
We Can Now Reason Articulately
With clearer definitions, communication can be far more precise and far less ambiguous. This is a positive step… unless your business model is based around exploiting naivety and ambiguity (which many devs are blind to).
When we want to talk about strategically aligning technical, team and organisational boundaries, often with the goal of autonomy, there are three clear levels of abstraction we should care about. And to avoid ambiguity, we should refer to none of them as a Bounded Context if precise communication is our goal.
Hypothetically, we start out with the goal of having each subdomain context owned by a single team. Most changes happen within a subdomain, and so most technical changes will happen within the boundary of a subdomain context. The team that owns the subdomain context will, therefore, be highly autonomous.
A subdomain context will ultimately compromise of one or more cohesive units of deployment. Rules within a subdomain context are on a per-team basis. But rules between subdomain contexts are global — no impediments to autonomy (e.g. no sharing).
There’s also a layer in-between subdomain context and deployables. Udi Dahan calls them business components. These are a way of grouping highly-related deployables within a subdomain context according to domain synergies.
Business components are a little fuzzy, but if you frequently find yourself talking about multiple units of deployment as a single thing, you may have a business component. Identifying its a name will add extra expressiveness and clarity to your shared understanding.
Attributions:
https://www.iconfinder.com/iconsets/office-icon-set-3
