Data Mesh is in your future
I’m quite certain you have either already heard about data mesh and done some googling or, you’re about to. There are a few architectural patterns, for example, dimensional models, that all data professionals will encounter on a regular basis. If data mesh is not yet one of those for you, it will be.
Mesh brings forward a well understood and successful strategy to manage complex things. The methods are not new. They’ve been used for years to quickly iterate on product design for all kinds of products. It applies equally well for hardware and consumer products as it applies to software. Software, of course, can iterate at a dizzying pace. The strategy is primarily composed of 1) a Product Mindset, and 2) a Bounded Context (for “data” people, we typically rename a bounded context to a “data domain” or “business domain”).
Adopting a data mesh is a journey. There are very few right or wrong answers because each business manages their domains in different ways. I get most excited when I talk to data professionals who have found the experience transformational for both their business and themselves.
Let’s explore Product Mindset and Bounded Context.
Benefits of a Product Mindset
Transitioning to a Product Mindset can offer speed and other focus related benefits to your team. Thinking about data as a “product” means that you will need to care about how your product is valued by your customer. Or how your data product makes your customer feel. After all, whether or not you get to invoice for your data product, you are “selling” it to your customers. Defects or friction points will need to be prioritized by you no differently than your car manufacturer takes feedback to produce a better car experience.
Speed is a competitive advantage. A product mindset will keep a team focused on what the customer wants and needs. Engineering or other tasks not directly related to increasing customer satisfaction will be lower on the backlog or kept in the “icebox”. One way for a team to go faster is to do less work. So, do work that keeps your customer happy and adopt your product more quickly. Ignore the other stuff as long as you can (tech-debt is a whole other article).
Bounded Context thinking
A “bounded context” is simply a way to describe the limits of how a particular domain is defined. “Bounding” a business domain means that the business relevance will not unnecessarily overlap with other domains. For example, a “customer” should exist, as a business definition, within a single area. In the “microservices” world, this would likely be a single service where a customer can be found. The “bounding” of the data should tightly correlate to how the business operates with “customers”.
Bounding is beneficial for a couple of key reasons. First, it drives simplicity because a data model for “customer” is, of course, simpler than a monolithic model that includes “customer”, “shipment”, and “order history”. Each domain can insulate itself from changes in other domains.
For the data space, we’ve chosen to refer to bounded contexts as “data domains”. Regardless of the semantics, we are creating a simpler world that closely matches up with our business. I tend to use both of these phrases interchangeably. My front-end friends prefer the bounded context terminology. I think I do as well because it more clearly defines exactly what it is.
In any event, bounding also creates pathways for the business rules and knowledge to push into the data. The business very likely has clearly defined ownership between “sales”, and “customer”, and “inventory” and they interact in very specific ways. If the data can organize and interact in the same ways, we can reduce friction and produce valuable outcomes much faster.
The space between bounded contexts is commonly referred to as a ‘seam’. It is a well defined area where business keys traverse and link up different domains. The domain relationships link across these seams in simple, understandable ways. A linkage between domains A and B does not need to use the same keys as the linkage between domains A and C. A valid set of keys could easily be customer number for A to B and customer unique id for A to C. Regardless, these keys are naturally defined by the business. If you look for them, you will find them. You’ll be surprised at how well the business keys just work. Resist the temptation to engineer something better.
Ready for it?
I see lots of over-thinking data mesh. Sometimes, that means companies or individuals will delay their implementation because it seems too hard, too risky, or they don’t quite understand it. A couple of the best mesh implementations I have been a part of, started by writing down a few words on a few drink coasters and really didn’t change. After all, if we’re modeling the business, how much is the business actually changing month over month or year over year? Shouldn’t your mesh be relatively slow to change if you got it right?
