Defining Data Product Ownership

The previous lesson ended with a map of decision rights. This lesson asks the next question: what exactly is the thing being owned? "Domain publishes data" is not a commitment. A data product is, and the difference is testable.

In this lesson, you will learn to:

• Judge whether an asset qualifies as a data product using DATSIS.
• Distinguish source-aligned, aggregate, and consumer-aligned data products.
• Mediate an ownership decision using domain knowledge, accountability, consumer value, and organizational capacity.

Two frameworks do most of the work here: the DATSIS characteristics, which tell you whether an asset qualifies as a product at all, and the ownership test, which tells you which domain should hold it.

DATSIS names six characteristics a genuine data product carries:

• Discoverable: consumers can find that it exists without asking a person.
• Addressable: it has a stable way to be referred to and reached.
• Trustworthy: it carries reliability commitments consumers can actually rely on.
• Self-describing: its meaning and structure are understandable without a translator.
• Interoperable: it can be combined with other products through shared conventions.
• Secure: access is controlled appropriately to the data's sensitivity.

The reason this list matters architecturally is that in practice, the two characteristics that most often fail are Trustworthy and Self-describing. Trustworthy fails because nobody has committed to anything, and Self-describing fails because the meaning lives in one analyst's head. Notice that both failures are about accountability and semantics rather than infrastructure, which is why a platform migration does not fix them. A well-catalogued, well-addressed table with no reliability commitment is a discoverable liability, not a product.

Not every data product serves the same need, and conflating the types is a reliable source of ownership disputes. A source-aligned data product exposes a domain's own operational reality close to where it happens: carrier scan events, payment attempts, meter readings. Its consumer need is faithful representation of what occurred. An aggregate data product combines or summarises across sources to answer a broader question, such as an enterprise on-time rate.

A consumer-aligned data product, by contrast, is shaped deliberately for one consumer's workflow, for example a per-order "promised versus actual" answer built for how a contact centre agent actually works a call. The practical value of holding these three apart is separation. When a domain resists ownership of a customer-facing view, it is often because the conversation has quietly collapsed the source-aligned feed it is happy to own with the consumer-aligned product it does not control. Naming them as two distinct products usually dissolves half the dispute.

The ownership test has four criteria, and all four must be weighed rather than the loudest one honoured. Domain knowledge asks who genuinely understands what the data means and the operational reality behind it. Accountability asks who can credibly stand behind the product's reliability to its named consumers.

The remaining two are the ones most often skipped. Consumer value asks whose need the product serves and who sits closest to it. Organizational capacity asks who has the people, incentives, and sustained attention to keep it working, not merely to claim it.

Use all four criteria to make an ownership assignment defensible for the specific product.

In a product-design review, Simone, a customer-support operations lead, tests an invoice-exception product with Dan, the enterprise data architect.

• Simone: Finance wants us to own the exception view because we already handle the escalations.
• Dan: That is a useful fact, but it is only one criterion. What does the product promise to its consumers?
• Simone: A clear explanation of why an invoice changed.
• Dan: Then test who knows the source events, who can stand behind that explanation, who serves those consumers, and who can sustain it.
• Simone: So an assignment made only because we are available would not be defensible.
• Dan: Exactly. Name the product first, then weigh the evidence rather than rewarding the loudest volunteer.

Watch how Dan refuses to let convenience substitute for the criteria without pre-solving any later ownership case.

The takeaway to carry: ownership is only defensible when the asset first qualifies as a product and the four criteria are applied to the specific product type in dispute. Two quick checks come next on product type and the DATSIS characteristics, and then you'll mediate a live ownership dispute where a domain lead pushes back in real time and the assignment has to hold.