liveBook · Manning

Data product

As explained in Architecture Modernization: Socio-technical alignment of software, strategy, and structure

A data product is a deployable data asset that delivers value to customers or users and satisfies requirements such as discoverability, accessibility, trustworthiness, interoperability, security, and independent value.

A data product is a deployable, domain-scoped data asset that delivers independent value to customers or users. It shifts data work from finite project delivery toward customer-centric product ownership. section 14.2.2 section 14.3.1

A useful data product is:

  • Discoverable and addressable, with understandable definitions and metadata. section 14.2.2 section 14.2.3
  • Natively accessible, trustworthy, truthful, interoperable, composable, valuable on its own, and secure. section 14.2.2
  • Small enough to deploy and evolve within a domain rather than attempting an entire enterprise data lake at once. section 14.2.2

Treat the product as a socio-technical responsibility: domain requirements shape it, governance manages its lifecycle, and a self-serve platform helps people discover, access, manipulate, and provide feedback on data. section 14.2.5 section 14.2.3

Start with a minimal data product

A team delivered six small datasets, each consisting of one table with fewer than 200 columns. Deploying a useful first version enabled rapid feedback and later evolution from customer needs instead of waiting for a complete data lake. section 14.2.2 section 14.3.1

Implementation usually varies by infrastructure, but onboarding, the model, and the data contract are the principal product-specific elements. Reusable sidecar services can standardize cross-cutting behavior across deployments. section 14.3.4

Figure 14.4 The data quantum takes the shape of a hexagon, highlighting its multiple endpoints, allowing access to data, metadata, observability, and control.

Use the data quantum diagram to inspect how one deployable product exposes data, metadata, observability, and control through multiple endpoints. section 14.2.2

How Architecture Modernization: Socio-technical alignment of software, strategy, and structure covers it

How deep it goes
Defines product qualities, minimal scope, iterative delivery, architecture variables, and mesh integration; defers infrastructure-specific implementation choices.
Examples
Uses six small datasets, a minimal viable data product, data catalogs, feedback loops, and experience-plane scenarios.
What it assumes
Assumes familiarity with domain scope and Agile product thinking while explaining minimal viable delivery and data mesh relationships.
What you can do after
Build it from scratch as a minimal domain-scoped asset, expose it through a mesh, and evolve it through consumer feedback.
How it connects
Connects data mesh with domain ownership, self-serve data platforms, federated governance, data contracts, data quanta, and sidecar architecture.

Also explained in

Compare how 2 books explain data product →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Architecture Modernization: Socio-technical alignment of software, strategy, and structure. The section links point to the parts of the book it draws on.