Skip to main content

DPCH02 — Deployable

“Independently Deployable Unit”

What DPCH02 is really asserting​

DPCH02 is not asserting that:

“Someone can deploy this data product.”

It is asserting that:

The Data Product Owner (or their domain team) can ideate, design, develop, test, publish, and manage the data product end-to-end using self-service automation—without relying on engineering competence or engineering teams.

This is about who holds agency, not whether pipelines exist.

The Essence (HDIP + Data Mesh Interpretation)​

A Data Product is deployable if and only if:

  1. The business/domain actor can move the product through its lifecycle
  2. The interaction is expressed in business intent and assertions
  3. Technology constructs are compiled away, not exposed

If deploying the product requires:

  • writing SQL
  • designing pipelines
  • selecting infrastructure
  • understanding tools

…then DPCH02 is not met, even if deployment is technically automated.

Positive Criteria — When DPCH02 is met​

DPCH02 is met when all of the following are true:

1. Lifecycle is self-service from the domain perspective​

The DPRO (or delegate) can:

  • declare product intent
  • describe business meaning
  • define assertions/expectations
  • trigger publish/update
  • observe status and outcomes

All without:

  • editing code
  • authoring pipelines
  • choosing tools or runtimes

This aligns with IDDD:

Ideate → Design → Develop → Deploy → Distribute → Manage

2. Inputs are business-native, not technical​

Valid inputs are conceptual, semantic, and business-aligned constructs, including:

  • Business entities, events, and measures
  • Canonical business definitions and meanings
  • Conceptual enterprise ontology elements (entities, relationships, semantic boundaries — at the conceptual layer only)
  • References to existing Data Products as semantic dependencies
  • Quality assertions (e.g., “must be complete by T+1”)
  • Usage intent (e.g., “used for regulatory reporting”)
  • Policy selections and compliance expectations
  • Business assertions describing expected facts or behaviors

Invalid inputs include:

  • SQL joins
  • dbt models
  • Spark configs
  • DAG definitions
  • infrastructure parameters

Those belong to the platform, not the product owner.

3. Engineering complexity is hidden behind the platform​

The platform:

  • selects tools
  • wires pipelines
  • provisions infra
  • deploys policies
  • configures observability

The domain never needs to know how this is done.

This is true self-service, not “self-service-ish”.

Negative Criteria — When DPCH02 is not met​

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

❌ Deployment requires engineering involvement​

Examples:

  • “Raise a ticket for deployment”
  • “Ask data engineering to update the pipeline”
  • “Platform team must review SQL”

Even if fast, this breaks DPCH02.

❌ Self-service UI exposes technical constructs​

Examples:

  • UI asks users to:

    • write SQL
    • select compute engines
    • configure DAGs
    • tune partitions

  • Templates that require technical understanding

This is engineering disguised as UI, not domain empowerment.

❌ Product is deployable only by engineers​

Examples:

  • Engineers create pipelines “for” the domain
  • Domain reviews outputs but cannot redeploy independently
  • Changes require code merges by engineers

This is centralized delivery, not Data Mesh.

Edge Cases (Important Guidance for Agents)​

Case 1: “Low-code UI over technical templates”​

❌ Not met

Rationale:

  • Low-code ≠ intent-driven
  • If the user must reason about joins, schemas, or infra, DPCH02 fails

Case 2: “Domain writes SQL but deploys themselves”​

❌ Not met

Rationale:

  • SQL is a technical construct
  • This still requires engineering competence
  • Domain autonomy ≠ domain-as-engineer

Case 3: “Domain declares intent; platform generates everything”​

✅ Met

Rationale:

  • Platform acts as an automated technology organization
  • Domain expresses what, not how

This is the target state.

Case 4: “Partial self-service (some steps manual)”​

⚠️ Partial

Rationale:

  • Transitional state

  • Acceptable only if:

    • roadmap exists to remove manual/engineering steps
    • intent model is already in place

Evidence Signals an Agent Should Look For​

Authoritative evidence:

  • Intent-based onboarding portal
  • Declarative product intent model
  • One-click publish/update from business UI

Supporting evidence:

  • DPDS generated automatically (not authored by domain)
  • Platform selects tools/runtimes dynamically
  • No domain-authored code repositories

Red flags:

  • Git repos owned by domain with SQL/ETL
  • UI fields labeled “join”, “partition”, “engine”
  • Deployment instructions referencing engineers

How an AI Agent Should Decide​

Decision rule (simplified):

If deploying or changing the product requires the domain to think like an engineer, DPCH02 is not met.

Why DPCH02 Is Non-Negotiable​

DPCH02 ensures that:

  • scale comes from platform leverage, not hiring more engineers
  • domains own outcomes without owning complexity
  • Data Mesh does not collapse into “distributed ETL teams”

Without DPCH02:

  • DPCH01 becomes symbolic
  • self-service becomes marketing
  • productization stalls at pilot scale

Canonical Statement (for BPS)​

DPCH02 is satisfied only when a Data Product can be ideated, designed, deployed, and managed end-to-end by the domain using intent-driven self-service automation, with all technical and infrastructural complexity fully abstracted by the platform.