Data Mesh: Domain-Driven Data Products
Howard Diesel
Chief Data Officer @ Modelware Systems | CDMP Master | Data Management Advisor
As with all technologies on the hype curve, we need to understand what obstacles it's tackling and what challenges we will face due to its current level of maturity.
Yolanda S. did an outstanding job of helping us understand, using a Data-to-Wine metaphor for clarification.
As Data Management programmes and professionals, we must find the value that can be delivered using this technology.
The value list that I derived is as follows:
Data Products by Business Value Chain Stage
I like this definition of a Value chain from Wikipedia:
"A value chain is a progression of activities performed .... to deliver a valuable product to the end customer."
It's a great confirmation to see the Data Value chain mapping to the Business Value Chain. It was a revelation to see that each stage of the Business Value Chain can deliver a Data Product.
Several comments in the chat box lamented that we have largely ignored the Business Value Chain as Data Programmes and Professionals.
Consumer Data Product Focus
Consumer describes both internal and external parties that require a data product.?
The Data Product feature list represents what consumers (people & programs) need from a Data Catalogue:
This list reads like a set of Data Quality dimensions for Data Products.
领英推荐
Consumer-Aligned Data Ownership
Data Ownership is undoubtedly a thorny topic within the Data Mesh environment. We had questions and comments on the approach to governing and defining Ownership.
The Data Mesh technology creates isolated platforms to deliver data products by federated domain.?
Isolated Domains certainly help with reducing bottlenecks but increase interoperability requirements.
Choosing the Domain isolation level for Ownership is tricky, and we face similar problems with Stewardship and Master Data Domains.
The three Ownership Archetypes are as follows:
The consumer-aligned approach benefits from a single view of fit-for-purpose (jobs-to-be-done) data products.
An appropriate level of governance
To avoid bottlenecks, we typically distribute services to improve throughput and reduce queuing. The downside of the federated approach is an increase in standardisation and governance to support interoperability. Examples of required standardisation are:
The suggested approach to reducing the need for standardisation is to allow economic forces to determine the survival of data products. If your data products do not adhere to the Consumer Data Product dimensions, the demand will drop, and it will not be economically viable.?
This approach works for Business products.
Head: Data Strategy & Engagement
2 年Hi Howard. Please share the recording. Thanks!
Thought Leader for Data Assets Management | Chief Information and Data Architect at Sasol
2 年Thanks to you Howard Diesel and Yolanda S. for sharing invaluable insights ???????????? Kindly please share the recording Howard Diesel
Senior Information Architect at Infosys Ltd
2 年Please share the recording. Thank you.
Leader of #reallyawesomedatapeople that exceeds client's expectations ?? MBA | CDMP Master | Data Strategy, Architecture, Way-of-working, Data Governance and Management
2 年Thanks for the support and compliments Howard Diesel. Looking forward to more discussions. Will you share the recording with me as well?
SAP MDG/MDQ/BODS consultant
2 年Howard Diesel would it be possible to share the recording?