Using a model of the domain (Domain Driven Design) is a well-established method in the design of modern technical architectures. It is also increasingly used in transformation of long-standing technology monoliths. Modelling the domain allows you to see more easily where the logical seams in the code base are (or should be) and helps you work out how to apply architectural patterns such as ‘extract & enhance’ or ‘strangle vine’ to move existing code to a more de-composed architecture.

Domain Driven Organisation Design (DDOD) allows you to take this understanding of the domain and use it to consider and align your technology and potentially business operation teams around key elements of value in your organisation. This has two key benefits. Firstly, it supports and promotes the concept of long lived, stable teams. Secondly, it allows you to reinforce good technology architecture by considering Conways’ Law at the outset and taking advantage of it by designing our technology organisation in line with the desired technology architecture and ultimately business usage/ purpose. This use of Conways’ Law is commonly known as the ‘Reverse Conway Manoeuvre’.

In their book Team Topologies, Manuel Pais and Matthew Skelton talk about using the domain as a key element in finding the seams or boundaries for teams, before applying more context specific factors such as geography, structures and politics (a full list can be found in their book) to work out how to implement your new structure. Our approach to determining your domain is based around 7 key steps which we believe are common to any process aimed at understanding a domain from an organisational perspective. These steps show you how to practically model your domain and identify potential seams and team boundaries as described in Team Topologies.

As you would expect with any approach from practitioners in the Lean and Agile space, each step provides context and validation for the preceding step, with feedback as a core element of the approach. A brief overview of each step is as follows:

1. The first step in our approach is to understand the purpose of the organisation. This may seem like an obvious and easy step, and one that is often overlooked. However, it is one where many organisations struggle. It is not uncommon for executives/leaders to find it difficult to articulate the organisations’ purpose. If it is easy, it will take 5 minutes or less. If it takes longer, it is a question that is worth putting in the time to make clear. A clear purpose will help us in the next step of understanding what the boundaries of our organisation are and should be. Without clear purpose, this is likely to prove difficult.
2. Step 2 is to understand the boundaries of the organisation which you are looking at – where does organisational ownership and responsibility start and end? For many organisations this is comparatively clear. However, for large organisations with close suppliers and partners or federated organisations with shared customers, services and functions (such as the finance or public sectors) this is often a complex and highly political challenge. It is these boundaries along with the products and services identified in Step 3 that allow us to identify our domain or domains.
3. Step 3 is to understand the products and services that the organisation provides to its customers. Looking at the organisations’ products and services allows us to start to understand our customers and what we do to serve their needs. We can use product and service groups or families to map to organisational boundaries in order to help identify whether we are looking at multiple domains or a single domain. Again, Identifying the products or services for an organisation sounds like a simple thing but it is often not as simple as it sounds!
4. Step 4 is to model the domain, channels and business capabilities used to deliver the services. We use the understanding generated in steps 1-3 to identify our individual domains. For straight forward, non-federated organisations with a low number of product/service groups or families (e.g. an organisation that does 1 thing) there is likely to be a single domain to model. For more complex organisations there will be multiple domains. Each domain should have a clear purpose, products/services and business processes. Discussing these will identify the key elements of the domain allowing us to model it. The processing activities associated with our domain model elements are captured as business capabilities, and finally the channels by which our customers/users interact with our domain are added. This should give us a holistic view of the overall domain with current implementation detail stripped away – revealing the ‘what’ and not the ‘current how’.
5. Step 5 is to understand the current method by which the services are delivered technically and the extent to which they share common delivery infrastructure. This is where we start to understand and answer the ‘pipeline vs platform’ question for this organisation. Teams aligned around commercial products/service s typically have a domain and services which are independent; with straight forward technology that can be owned by the team end to end. Teams aligned around platform elements are typically found in more complex domains where key functions are shared by many products and the technology is too large or complex for a single team to support. Organisational size and maturity will be key factors in the pipeline vs platform question, with what is best for the organisation changing as it grows.
6. Step 6 is where we propose an initial team structure for our organisation. This is where the magic happens! We use the understanding of the organisation and domain generated in Steps 1-5 to propose the teams needed to support the domain. This is typically done by looking for natural groupings within the domain elements, and understanding how these groupings relate to the capabilities and business processes. This is also where the political and geographical considerations of the current organisation come into play and bring a view of what is realistic right now based on your current organisation. There may even be a number of transitional designs based on an incremental implementation if needed due to organisational constraints such as an existing code monolith. In such a case the transition path would need to take into account the proposed strategy for overcoming the constraint (for example using the ‘extract & enhance’ or ‘strangle vine’ models to deal with an existing code monolith).
7. Our final step is to apply planned and anticipated work to the teams.  Appling the known and anticipated work to the new structure allows us to test and refine the proposed structure and refine/rework as necessary. This is where real world constraints around team sizes and locations, as well as composition become clear. Challenges are fed into recruitment, resourcing and capability building plans and the outcome of this is used to update transition plans created in Step 6. If you are a start-up or scale-up you are less likely to be concerned with where you are now and how quickly you can move to the desired state. By taking a good look at your planned and anticipated work, we should inevitably consider why we are doing some of it – closing the loop by considering how it meets our organisational purpose.

As with all things agile the overall approach is both iterative and incremental. Each step provides more detail allowing you to refine the pre-ceding one, and the whole process feeds back to the start allowing you to validate the work. The approach is also recursive in that it can be used to drill down to lower levels of detail as necessary until you have got to the level of detail needed.

The approach is also complimentary and consistent with more traditional technology-based Domain Driven Design as it provides an excellent starting point for more in depth modelling around objects, entities and services. In fact, our recommended approach would be to include technical architects as a part of our cross-functional domain modelling team for just this reason.

So that is the basic approach. Where this really comes alive is in looking at applied examples where the DDOD approach has been successfully implemented to create changes within an organisation. In the next article, we will share a Financial Services example to illustrate the 7-step approach along with insight into how some common challenges in large scale enterprises can be overcome.

If you would like to discuss any of this directly, please get in touch.