Rewind to 2003, when Michael Jordan still played basketball, the third Lord of the Rings movie was in theaters, and you could buy a Ford Ranger for less than $9,000. A book broke onto the scene called “Domain-Driven Design” by Eric Evans that asked a great question – why aren’t data-driven software applications modeled more like our businesses? And why don’t technical folks and subject matter experts work more closely together?
Fast forward to today, and now data mesh, knowledge graphs, and agile data governance have breathed new life (and new hype) into this very smart but undervalued concept from the past.
Why? The last several years in the data realm, we’ve experienced the proliferation of centralized data architectures — data lakes and data lake houses — and despite all their benefits, they’ve presented big challenges around scalability, flexibility, and ability to reason about them. Companies find they’ve created data swamps and knowledge silos, and domain-driven design offers new insights on how to fix them.
Domain-driven vs data centralization
After Eric Evans' seminal book in the early 2000s, Mammad Zadeh’s teams at Intuit were among the first to adopt domain-driven design principles to data governance, placing “ownership” of specific data with the upstream engineering teams that understood it best.
This approach is particularly effective for large organizations with multiple complex data sets; instead of one person or team managing all an organizations’ data — which can quickly become overwhelming — domain-driven design facilitates a more scalable, more nimble data model.
Recently, particularly among smaller organizations with less data and less-complicated data systems, domain-driven design has been balanced with a return to data centralization, a model that requires less effort in terms of organizational governance and is consequently a better fit… as long as you’re working with a manageable amount of data.
For a hot second, larger organizations — perhaps tempted by the idea of one team being responsible for all their data — hopped onto the data centralization train. But after witnessing the consequences of centralizing mass quantities of disparate data, they’re moving back in the other direction. And that makes sense, because for enterprise-level organizations working with large amounts of disparate data, a domain-driven approach is really the only way to go.
The benefits of domain-driven design
The benefits of a domain-driven approach to data governance are numerous, particularly for enterprise-size organizations. By placing ownership of a domain — commonly defined as “a sphere of knowledge or activity” — in the hands of the people who work with it most and understand it best, your teams can expect improvements in:
Scalability - By distributing ownership of domains, you empower multiple teams to “own” specific functional areas and smaller data sets. When your organization reaches a certain scale, and is producing and working with a large amount of data, a single team — or *gulp* person — holding the keys to all of it can become overwhelmed by your data’s volume or complexity. Multiple teams working within a specific domain are more nimble and much more likely to have a complete understanding of the data within their purview.
Resilience - A domain-driven approach naturally means your data is dispersed throughout your organization, improving its resilience in the face of data loss or corruption. By distributing your data across multiple domains, a disruption to a single domain is much less likely to result in a system-wide failure.
Accountability - When specific teams and people “own” specific data, that data is much more likely to receive the attention it needs to stay clean and organized. Having a single team responsible for a set of data also means others within your organization know where they can find the data they need, and who can help them understand it.
Reliability - Similar to the above, when a team or person is accountable for the quality of a data set — particularly when it’s data in which they’re expert — that data is much more likely to be organized, accurate, and error free.
Usability - And when your data is organized, accurate, error-free, and “owned” by people who understand it completely, it’s vastly more likely that it’s easy to use. (And if you do have questions, you know exactly which domain owners have the answers.)
Even if you are smaller or have a more centralized data platform team, domain driven design approaches can also positively impact how you model your data and design your data products in that context as well to reap many of these benefits.
In the follow-up to this post, I’ll explain how an enterprise data catalog puts you on the fast track to establishing a domain-driven data governance methodology.
For more information on how a data catalog can enable domain-driven design, schedule a demo with our team.
