Domain-Driven Organizations
Weaponize Conway's Law and Domain Modeling to produce a strong socio-technical system fully aligned with your business needs
Conway’s law is a specter in the software engineering world. It’s always there, influencing your organization and your software, but rarely seen or acknowledged. For those unfamiliar, Conway’s law is based on the following quotation from Melvin Conway, a pioneer in the field of software development.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway
While not based on any mathematical theory of systems, this Law has proven true in the real world consistently enough that it’s safe to treat as an axiom of organizations.
This often manifests negatively, with people bemoaning Conway’s Law as the driver of their poor software architecture and ownership. It brings with it a rather sobering conclusion: the true software architects in your organization are not the expensive engineers or systems specialists… they are the HR department and executives. The problem is that they don’t generally understand that they are doing systems engineering when designing an organization, nor are they typically trained in it.
Fortunately, there is a simple approach we can implement that will instantly align your organization from top to bottom, enabling you to build a truly agile business. That tool is called domain modeling, as popularized in Domain-Driven Design.
Using Domain-Driven Design principles allows you to build a Domain-Driven Organization that uses Conway’s Law to constantly reinforce a strong socio-technical system aligned with your business needs.
Use domain modeling to deeply understand the space in which you operate
Using that new understanding, structure your organization along the domains and document the dependencies and communication lines
Recurse into each domain and continue modeling
Let Conway’s Law do the work of keeping your business aligned with the model from top to bottom, empowering your teams to have full ownership over their space of the domain model while still driving towards a common purpose
Domain Modeling
For the purposes of this article, we’re going to use a mock domain model I did recently for a genetics testing service similar to 23andMe. Let’s look at some of the functions we need:
Sample Collection - Get samples from a customer
Sample Processing - Process the physical samples to produce a genome
Genome Analysis - Run tests against the genome data, checking for the presence of specific genes
Reporting - Collect the results from the analysis and store them
Customer Experience - Present the results to the customer
Sample Collection and Sample Processing are deeply intertwined, because the type of sample needed, how they are stored, how they are transported, what equipment is needed to process them, and so on, are all related. We’ll bundle these into a Sampling domain.
Genome Analysis is unique enough as a domain. It’s responsible for taking a specific input, the genome, and producing a specific output, the analysis results.
Reporting, similarly, is unique. What do we do with those results? How do we analyze them, share them, and do research against them?
Customer Experience manages the front-end customer experience, from the packaging of the kits to the front-end website.
Let’s map these out in a domain model, along with some of the basic entities inside each domain.
The dependencies are as follows:
Customer Experience depends on Sampling for the sample containers and instructions for use.
Customer Experience depends on Reporting for the analysis results so they can be presented to the customer.
Sample Collection depends on Genome Analysis to specify the genome format, storage location, and upload procedure for the genome data.
Genome Analysis depends on Reporting to specify the result format and storage location
That’s it. For this whole business, we have four dependencies and thus four organizational relationships to be managed.
Next up, let’s look at the skill sets we’ll need in each domain.
The Customer Experience domain needs designers, both computer interface and packaging designers, logistics specialists, manufacturing experts, and software engineers.
The Sampling domain needs lab specialists, people who know how to design a testing lab, lab technicians, equipment and facilities managers, sequencer device specialists, and software engineers.
The Genome Analysis domain needs scientists, bioinformatics engineers, and software engineers.
The Reporting domain needs researchers and software engineers.
Notice that, aside from software engineers, almost every domain has unique needs. This is a good sign that we’ve defined a strong domain model - specialist knowledge is contained within a single domain.
The Domain-Driven Organization
In order to weaponize Conway’s law and align our entire organization, we need to align the organization to the domain model. Let’s hire a Director for each area of the business. We also need to revisit our communication channels and make sure that those are all managed by a single owner. That will typically be a Product Manager for each domain who is responsible for ensuring that these domains all work well together. Aside from these interactions, the organizations can operate largely independently.
Now we need to break things down further, because you need more than two people for each domain. We’ll pick the Genome Analysis domain to look at as an example.
One of my favorite parts of the domain modeling approach is that it’s recursive. As the Director of Genome Analysis, I need to figure out what my organization structure looks like. Let’s do a domain model for this specific domain.
Genome Storage - We need to securely ingest, store, and audit access to genome data, including custodianship requirements
Bioinformatics - Specialists who understand genome data and can build the analysis jobs
Analysis Platform - We need a way to run arbitrary analysis jobs against a genome
Mapping out their interactions, we get the following:
There are two primary interactions:
The Analysis Platform domain needs to provide a common interface for the analysis jobs, as well as define a way to ingest and execute those jobs
The Genome Storage domain needs to define how the Analysis Platform can access genome data
We’ll need Product Managers to manage those dependencies.
Now let’s build an organization structure.
Those accustomed to traditional organizations will notice something odd here. We have Product Managers and Security Engineers embedded into two of our domains.
This is intentional.
It’s been proven time and time again that building a multi-disciplinary team focused on one common goal drives results because it gives that team complete ownership. That stack of people under the Genome Storage manager is wholly and entirely in control of how genome data is stored, accessed, and audited. They are running their own little business-within-a-business and are empowered to do what’s necessary to succeed.
This is the end goal of the domain-driven organization. Ownership and empowerment for everyone with a clear scope and vision that aligns with the overall business, held in place with a seemingly inevitable law of organizations.
Mitigating the Side Effects
This model does have some downsides. Namely, your specialist groups of software engineers, product managers, and security engineers are isolated from each other. This could lead to drift or inconsistent standards across the organization, especially as it grows. In other words, how do we ensure that these job functions are staying unified in their approach and standards?
This is where treating your organization as a system instead of a hierarchy becomes valuable. The diagram above operates on a single vertical axis, enforcing superiority of one individual over another. Let’s get creative and add a second axis, this time looking at what job specializations there are.
We’ve added a second form of organization here, the Guild. While not the only approach to solving this problem, the Guilds serve as job function specific organizations that evolve independently of the business-domain oriented structures. This empowers the Security Guild to decide “We are going to deprecate TLS 1.2” and that decision have force across the organization. The Product Management guild may decide they want to track goals using a specific tool.
While the above chart is just the Genome Analysis domain, it should be understood that these guilds span the entire organization. Guilds are responsible for training and improving their job specialization, while the Managers operate their business function. As the organization grows, it may be wise to hire dedicated heads of these guilds whose entire function is to improve their job specialization across the organization.
Managing Growth
Eventually, your organization will scale or extend into some new line of business that doesn’t align with the previous model. Maybe we want to support Ancestry now instead of just simple gene presence checks.
When situations like this arise, start the process over with the top level domain model. Analyze how the additions impact the existing model and continue down recursively. This can happen at any level of the organization, and the owners of that domain must be empowered to do this analysis and modify their portion of the organization as needed.
How to Get There
This example is a new organization, but you may already have one in place that needs to be migrated. I’ve been through this process myself as an engineer who did the domain modeling that led to organizational change.
The first step is to model what you actually have. Map out your socio-technical system along with its communication lines. It is critical that you involve key people of all specialization at all levels in this exercise. You need depth and breadth here to produce an accurate model of where you’re at currently. You need to be self critical here. You’re going to find silly things. Write them down in the model and move on.
The second step is to model where you want to be. It’s important that this is the second step, as you don’t want your idealized model to bias your current state model from the first step.
The third step is to figure out what the minimal set of changes is to get from where you are to where you want to be. Prioritize these changes to target areas that are known problems. Communicate these changes broadly and explain them so that everyone understands what’s happening and what the goal is.
Finally, start making changes. Do one change at a time, see how it works, and continue. Do not attempt to reorganize your entire organization at once. This will cause massive amounts of friction and decrease morale and productivity. You may need to hire people or move people around. Do not be rash and layoff entire organizations. Be slow and strategic. You are playing an infinite game, so act like it.
Over time, you’ll slowly align with the idealized domain model.
Conclusion
Domain-Driven Organizations empower small units to fully own their space while still remaining aligned to the overall model of the business. It enables you to think about your organization as a complex system instead of as a hierarchy, allowing you to apply systems design and analysis to it. It produces high quality software and human systems with clear boundaries that align with the business.