← Back | Next →

The core of the Operating model

The whole of the organization is divided into three “domains”. Domain name reflects its role.

  1. Business
  2. Products
  3. Technology

Decoupled but acting together, in what we call “BPT Loop” constellation.

flowchart 
subgraph BPT["Organization under B-P-T Operational Model<br/><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 <-->|Domain<br/>Iterations| P
    P <-->|Domain<br/>Iterations| T

It is as simple as that. The “core of the trick” is to follow this simple concept when adding details to it.

Domain iterations are repeated two-way information exchange between domains. It is controlled and structured.

Once required CMM Level (required 3, ideally 5) is established, your organization is ready to start to smoothly operate as three interconnected, collaborating domains; each with a distinct mandate.

TIP
“Domain” is the term chosen by the public. Term “Segment” was suggested and quietly rejected. “Domain"is very overloaded term.
BusinessProductsTechnology
MandateDefines 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.
ResponsibilitiesConceptual Architecture · Strategic goal-setting · Outcome definition · Stakeholder alignment · UAT acceptance · Investment decisionsRequirements design · Logical Architecture · Backlog ownership · Domain translation · UAT coordination · Iteration managementPhysical architecture · Engineering & delivery · Application Architecture · Integration design · Technical governance · Platform & tooling
IMPORTANT
Key principle: Domains are not silos — they are runtime 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:

IMPORTANT
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.

Have organized repositories of ADM Deliverables. Each using simple but sufficient template for backtracing to the “origin”.

Domains contains projects

Smaller organizations might have single product to “wory about” deliver; and that will be initiated by a single project in a Business domain, passing the information to a single project in the Products domain. When initial Business ↔ Products iterations are settled, Products project is ready to require Technology domain to organize and execute product development and delivery.

flowchart LR
    subgraph B["Business Domain"]
        direction TB
        BI1["Initiative 1"]
    end
    subgraph P["Products Domain"]
        direction TB
        P1["Product 1"]
    end
    subgraph T["Technology Domain"]
        direction TB
        T1["Team 1"]
    end

    B <-->|Iterations| P
    P <-->|Iterations| T

Larger organizations will naturally contain several projects per domain. Starting from the Business. In most organizations Business projects are called initiatives. One initiative can spawn one or more Products domain projects.

flowchart LR
    subgraph B["Business Domain"]
        direction TB
        BI1["Initiative 1"]
    end
    subgraph P["Products Domain"]
        direction LR
        P1["Product 1"]
        P2["Product 2"]
    end
    subgraph T["Technology Domain"]
        direction LR
        T1["Team 1"]
        T2["Team 2"]
    end

    B <-->|Iterations| P
    P <-->|Iterations| T

Notice that Domain Information exchange is two ways. Technology and Products will iterate and exchange information. During the development and importantly after the deployment, during the never-ending maintenance stage of the product

Domain handoff points

Each domain has explicit handoff points — emitting and receiving structured artifacts that ensure the whole model continuity. BPT domains are visible, run time organizational units. Unless it is business, no domain begins work without a clear input from the prior domain, and no domain closes without producing a required output. Thus the BPT layout becomes:

flowchart LR
    subgraph B["Business Domain"]
        direction TB
        BI(&lt;&lt;Interface&gt;&gt;<br>Business<br>Operations)
          direction LR
        BP1["Initiative 1"]
    end
    subgraph P["Products Domain"]
        direction TB
        PR(&lt;&lt;Interface&gt;&gt;<br>Products<br>Operations)
          direction LR
        PP1["Initiative 1"]
        PP2["Initiative 1"]
    end
    subgraph T["Technology Domain"]
        direction TB
        TE(&lt;&lt;Interface&gt;&gt;<br>Technology<br>Operations)
          direction LR
        TP1["Initiative 1"]
        TP2["Initiative 1"]
    end

    B <-->|Domain<br/>Iterations| P
    P <-->|Domain<br/>Iterations| T

Domain interfaces are a simple public connection points int the domains.

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

Domain Roles Accountability

Before starting the BPT journey, organization team is trained in following best practices of CMM. In addition to that each domain should appoint a Domain Lead roles, responsible for architecture decisions within their domain scope. Domain Leads co-own the BPT cycle governance and escalate cross-domain conflicts to shared resolution.

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

TIP
Old fashioned equivalent might be “steering committee”