Data mesh: Understanding decentralized domain ownership & realtionships

Data and analytics professionals understand that semantics matter. We have semantic layers, semantic models, and semantic analytics.

We know that communicating meaning effectively requires a shared understanding of words and phrases. If the words we use can have multiple meanings depending on the context, then misunderstanding can occur.

Data mesh's definition of domain

One of the four core principles of data mesh is decentralized domain ownership.

The word “domain” in the context of data management typically refers to customers, products, suppliers, employees, and other domains of business entities. In the context of data governance, “domain” can refer to both business entities and policy domains like ESG (environmental, social, and governance), privacy, and financial reporting regulations.

The data mesh's meaning of domain comes from the software practice of domain-driven design. In this context, domain refers to business capabilities and the activities and entities they contain. The domain has a specific business function and outcomes that it is optimizing for. Some examples include.

Marketing & sales:

Product management:

Order fulfillment:

Customer service:

Payments & billing:

Logistics & shipping:

This difference in domain meaning in the context of data mesh has caused some confusion among data and analytics professionals.

On the positive side, in data mesh terminology, business entities – customers, products, suppliers, etc - have the same meaning as they do in data management and governance terminology.

So, a simple reorientation of phasing from domain to business entities can improve communication and understanding. Not that we have a high-level definition of domain in data mesh, let’s have a closer look at domain boundaries and entity relationships.

Data mesh's domain boundaries & cross-domain entity relationships

Data mesh uses the term “bounded context,” which also comes from the software practice of domain-driven design.

It is simply the boundary where a particular domain model applies. If we use the Order Fulfillment domain as an example, the core domain function is focused on optimizing in-full and on-time order rates.

There are two domain subprocesses, Pick and Pack and Delivery, required to execute order fulfillment. By mapping business entity attributes to the subprocesses and other domains that share those attributes, we might get a relationship diagram that looks something like the following.

 Order fulfillment domain example

We see that the order fulfillment domain requires business entities, like customers, products, third-party shippers, and vehicles, that are also used in other domains.

• Customer Management shares the account number and ships to the address
• Order Management shares purchase order numbers, products, and quantity
• Warehouse Management shares product/Item location, quantity on hand, and packing instructions
• Fleet Management shares vehicle availability and route tracking
• Third-Party Logistics Management shares region, mode of transportation, and customs/duty requirements

That data is used to create a “Data product” for monitoring and managing on-time and in-full delivery rates. Data product or data as a product is another principle of data mesh.

The easiest way to think about it is an analytics component that encapsulates all the functionality required to solve an analytics problem. This could be data pipelines, curated data sets, machine learning algorithms, and visualizations.

However, the attributes representing those entities differ based on domain needs.

For example, the Fleet Management domain will need to represent many physical characteristics of vehicles, such as their maintenance history, mileage, age, model number, performance characteristics, and so on. But when it's time to schedule a delivery, the Order Fulfillment domain only needs to know whether a vehicle is available and the estimated arrival time for pickup and delivery.

Decentralized domain ownership with data mesh

Trying to model data and business logic gets progressively more complex as the modeling scope expands to more business domain areas.

Part of the problem is that different domains use different vocabularies with different contexts and attributes for business entities.

It would be unnecessarily complex if we tried to create a single domain model for Order Fulfillment, Customer Management, Order Management, Warehouse Management, Fleet Management, and Third-Party Logistics Management. As well as being impractical to design and implement, it would also be difficult to manage over time, because any changes must account for multiple domain needs.

With data mesh, responsibility and accountability for data modeling, management, and governance are distributed to domain teams that best understand the business needs and context. The model for a domain only needs to include the necessary business capabilities and activities for the domain. Each model only contains the relevant business entities and attributes within the domain context.

The word “decentralized” in the phrase decentralized domain ownership is another word that is causing misunderstandings, as some people are interpreting it as the domain teams have the authority to do whatever they want for their domain without any consideration for what other domain teams are doing.

While there is local domain autonomy in data mesh, domain ownership includes ensuring interoperability across domains. This is done through another core principle of data mesh federated computational governance.

Best practices for data mesh domain design & management

One of the biggest challenges of data mesh is to design the boundaries of individual domains. The general rule is that a domain should be designed around one business capability, but putting that rule into practice requires careful thought.

During this phase, don’t get overly concerned with technologies or implementation details. Just note the places where domains will need to interoperate.

Remembering that this is an iterative, ongoing process is also important. Domain boundaries aren't set in stone. As your business evolves, you may expand or shrink the bounded context of domains.

Another major hurdle is managing the decentralized domain ownership model. Again, decentralized doesn’t mean domain teams have the authority to do whatever they want.

The goal is to create an effective and efficient operating model that increases quality, consistency and interoperability of data products created across domain teams.

Conclusion

The whole premise of data mesh is to help organizations make business decisions faster by shifting responsibility and accountability for data and analytics to the domain teams that best understand the business situation and context.

Well-designed domain boundaries and decentralized operating models enable speed and flexibility at the domain level, and interoperability and reusability at the global level.