Section 03 — The Three Method Domains

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

	Domain 01 — Business	Domain 02 — Products	Domain 03 — 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 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 people overlap. Every deliverable must be traceable to a domain mandate.

Domain Interfaces

Each domain has explicit handoff points — structured artefacts and gates that ensure continuity. No domain begins work without a clear input from the prior stage, and no domain closes without producing a defined output. The BPT: B→P→T loop.

Domain Accountability

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.


© dbj@dbj.org \| CC BY SA 4.0