How Does a Data Product REALLY work?
Another #Masterpiece by Eric Broda who breaks it all down for us. More in comments but highlights are:
Data Product = Data Domains + Product Thinking: This means you are ensuring that your product meets a specific business need, delivers tangible value, has a long-term time horizon, and has a clear and empowered #owner that acts not only in the enterprise’s but also customers’ interest.
A Data Product has 6 components: It has 1) clear boundaries 2) an empowered owner 3) it is part of an ecosystem of consumers and producers 4) It is enabled by a platform, that makes data discoverable, addressable, accessible, and interoperable. 5) It has published metadata, that enables discovery and self-serve while making data understandable AND it has federated governance.
In order to build Data Products repeatability, teams need A) templates that generate microservices & APIs with built-in discoverability and observability and B) extensions that make security, deployment and management straightforward.
There are 4 ways to identify if you’ve succeeded: A) Conway’s Law (your systems follow your organization structure i.e data ownership migrates to groups aligned closely to organizational units) B) CDO Data Domains Maps that identify the business entities that are of significant value to the enterprise. C) A business architecture that identifies important business capabilities and D) Commercial models, constructed upon particular #industry specific needs. For instance, in Financial Services, they include #FSLDM, Financial Services Logical Data Model).
Engage here!
More on Data Products this week: QuantumBlack, why you should treat data like a product.
More on Data Products this week: Difference between “Project vs Product” from Clayton Karges, Jeffrey Ung and Dheerendra Nath.
