Home | ← Back | Top | Next →

The Three Domains OP Model

flowchart LR
subgraph BPT["B-P-T Operational Model<br/>"]
    direction LR
    subgraph B["Business<br>Domain<br><br><br><br>"]
      direction TB
    end
    subgraph P["<br>Products<br>Domain<br><br><br>"]
      direction TB
    end
    subgraph T["Technology<br>Domain<br><br><br><br>"]
      direction TB
    end
end

    B <-->|Information| P
    P <-->|Information| T

Once CMM Level 5 is established, your organisation smoothly operates as three interconnected, collaborating domains — each with a distinct mandate.

Term “Domain” is chosen by the public. Term “Segment” was quietly rejected. “Domain”is very overloaded term.

	Business	Products	Technology
Mandate	Defines strategic intent. Owns the why and the what. Sets outcome goals, priorities, and success criteria. Commissions work and conducts final UAT.	Translates strategy into requirements. Owns the how it works. Acts as the bridge between Business intent and Technology execution — and again when returning for UAT.	Builds, integrates, and operates. Owns the how it’s built. Executes against Product-defined requirements, applying architecture standards and engineering rigour.
Responsibilities	Conceptual Architecture · Strategic goal-setting · Outcome definition · Stakeholder alignment · UAT acceptance · Investment decisions	Requirements design · Logical Architecture · Backlog ownership · Domain translation · UAT coordination · Iteration management	Physical architecture · Engineering & delivery · Application Architecture · Integration design · Technical governance · Platform & tooling

---

Key principle: Domains are not silos — they are organizational units: groups of roles.

In smaller organisations, people often wear multiple domain hats. The DBJ Method requires that domain thinking is always explicit, even when domain roles overlap. And because of that:

Every deliverable must be traceable back to a domain it originated from.

Thus, domain-to-domain information exchange must be consistent. Following the OP Model information exchange. In terms of best online collaboration practices: no emails flying around are advisable.

---

Domain Interfaces

Each domain has explicit handoff points — structured artifacts and gates that ensure the whole model continuity. BPT domains are visible organizational units. No domain begins work without a clear input from the prior domain, and no domain closes without producing a defined output, for the “next in line”. Thus the BPT becomes:

The B ↔ P ↔ T loop

flowchart LR
    subgraph B["Business Domain"]
        direction TB
        BI(&lt;&lt;Interface&gt;&gt;<br>Business<br>Operations) <-.-> BS(Storage)
    end
    subgraph P["Products Domain"]
        direction TB
        PR(&lt;&lt;Interface&gt;&gt;<br>Products<br>Operations) <-.-> PS(Storage)
    end
    subgraph T["Technology Domain"]
        direction TB
        TE(&lt;&lt;Interface&gt;&gt;<br>Technology<br>Operations) <-.-> TS(Storage)
    end

    B <-->|Information| P
    P <-->|Information| T

That is conceptual view of DBJ Method BPT Domains. Not to be confused with micro services.

Domain Accountability

Organization is following best practices of CMM. In addition to that each domain appoints a Domain Lead responsible for architecture decisions within their scope. Domain Leads co-own the cycle governance and escalate cross-domain conflicts to shared resolution.

Domain leads also regularly cooperate and steer the whole BPT loop.

Old fashioned equivalent might be “steering committee”