Skip to main content

DPCH07 - Reusable

“Designed for Reuse and Demonstrably Reused Across Use Cases or Domains”

What DPCH07 is really asserting​

DPCH07 is not asserting that:

“The product could be reused someday.”

It is asserting that:

The Data Product is intentionally designed for reuse beyond a single predefined consumer and, at maturity, is demonstrably consumed across multiple independent contexts without bespoke rework by the producing team.

Reuse must be structurally enabled. Adoption validates that enablement.

The Essence (HDIP + Data Mesh Interpretation)​

A Data Product is reusable when:

  1. It is structurally designed for consumption beyond one consumer
  2. It is not tightly coupled to a single downstream implementation
  3. Adoption can occur via self-service mechanisms
  4. At maturity, reuse is observable across multiple consumer contexts

Design enables reuse. Adoption confirms reuse.

If every “reuse” requires:

  • producer intervention
  • consumer-specific transformations
  • special versions per consumer

then DPCH07 is not met — that’s service delivery, not product reuse.

Positive Criteria — When DPCH07 is met​

DPCH07 is fully met when all of the following are true:

1. The product is structurally reusable​

The product:

  • Exposes generalized domain semantics
  • Avoids consumer-specific logic
  • Does not embed downstream formatting assumptions
  • Can support additional consumers without redesign

This condition is mandatory.

2. Reuse is evidenced by real consumption​

Evidence can include:

  • multiple distinct consumer teams
  • multiple consuming applications or pipelines
  • multiple use cases (analytics + reporting + operations)
  • usage telemetry from marketplace, APIs, or query logs

The key: real adoption beyond the initial creation context.

3. Consumers can onboard without bespoke producer work​

A new consumer can:

  • discover the product (DPCH04)
  • understand it (DPCH05)
  • trust it (DPCH06)
  • access it through standard ports (DPCH10)

…and begin using it without long workshops or custom builds.

4. The product’s interface is stable enough for repeat adoption​

Reuse implies:

  • contract stability
  • consistent semantics
  • backward compatibility behaviors
  • predictable change communication

If the product breaks consumers frequently, reuse will not scale.

Negative Criteria — When DPCH07 is not met​

DPCH07 is not met if any of the following are true:

❌ “Reuse” is achieved through custom delivery​

Examples:

  • producer team builds a one-off feed for each consumer
  • special views/tables created per downstream team
  • bespoke transformations repeated per use case

That’s data services, not reusable data products.

❌ Product is tightly bound to a single predefined consumer​

Examples:

  • semantics shaped around one dashboard
  • transformations embedded specifically for one application
  • naming conventions reflect one downstream system

Even if more consumers could exist, structural coupling blocks reuse.

❌ Reuse is blocked by friction​

Examples:

  • product is discoverable but incomprehensible
  • access takes weeks of manual approvals
  • ports are undocumented
  • trust signals absent

Availability without usability prevents reuse in practice.

Edge Cases (Important Guidance for Agents)​

Case 1: “Single consumer today, but structurally reusable”​

⚠️ Partial

Rationale:

  • design supports reuse
  • adoption has not yet expanded
  • indicates early-stage or niche context

Design maturity present; adoption maturity emerging.

Case 2: “Two consumers, but both inside the producer’s team”​

⚠️ Partial

Rationale:

  • indicates reuse potential
  • but not yet independent or cross-domain validation

Case 3: “Multiple consumers, but producer must coordinate every onboarding”​

⚠️ Partial

Rationale:

  • reuse exists
  • but not scalable
  • indicates weaknesses in DPCH04/05/06/10

Case 4: “Marketplace telemetry shows repeat independent adoption”​

✅ Met

Rationale:

  • reuse is measurable
  • self-service reuse becomes structural
  • productization claim validated

Evidence Signals an Agent Should Look For​

Authoritative evidence:

  • marketplace adoption counts
  • API gateway / query telemetry showing multiple consumers
  • access logs indicating multiple consuming roles/departments

Supporting evidence:

  • consumer references on product page
  • documented use-case patterns
  • reuse across multiple “Consumption Archetypes” (CSxx combinations)

Red flags:

  • repeated custom exports
  • per-consumer “special versions”
  • producer-controlled onboarding gatekeeping

Special Consideration: Ephemeral, Experimental, or Niche Data Products​

Certain Data Products may be intentionally scoped to:

  • A specific regulatory obligation
  • A controlled pilot or experimentation phase
  • A narrow domain specific capability
  • A time bound reporting requirement

These do not automatically fail DPCH07.

However, such products must still satisfy the design-for-reuse principle within their intended scope.

Clarification:​

A product may be:

  • Narrow in audience
  • Regulatory in purpose
  • Temporarily scoped

But it must not be:

  • Structurally coupled to a single predefined consumer
  • Hard-wired to one downstream implementation
  • Delivered as a bespoke artifact per request

If a regulatory product is:

  • Designed using canonical domain semantics
  • Exposed via standard ports
  • Consumable by any authorized regulatory workflow

Then DPCH07 may be considered satisfied — even if only one regulatory consumer exists.

If instead it is:

  • A one-off extraction
  • A spreadsheet produced for one regulator
  • A manually assembled dataset

❌ Then DPCH07 is not met.

How a Maturity Assessment Agent Should Decide​

Decision rule (refined):

If the product is structurally coupled to a single predefined consumer or requires bespoke producer work for additional adoption, DPCH07 is not met. If structurally reusable but not yet widely adopted, classify as partial maturity. Full maturity requires demonstrable independent reuse.

Why DPCH07 Is Non-Negotiable​

Without DPCH07:

  • productization remains theoretical
  • data mesh becomes distributed silos
  • platform ROI stays unproven
  • cost and governance burdens scale per consumer

Reuse is where the “product” claim becomes validated. Design-for-reuse makes democratization sustainable. Demonstrated reuse makes it credible.

Canonical Statement (for BPS)​

DPCH07 is satisfied only when a Data Product is intentionally designed for reuse beyond a single predefined consumer and demonstrates independent adoption across multiple consumer contexts without bespoke producer delivery.