Concept

The whole operating model is divided into three decoupled “domains”.

1. Business
2. Products
3. Technology

Domain name reflects its role. Domains are decoupled but acting together, in what we call “BPT Loop” constellation.

• Each domain is running decoupled from any other domain
  • Being decoupled, the three domains obviously run in parallel.
    • That follows from the domain decoupling itself. It is an attribute of the operating model’s conceptual architecture. Domains exchange information in asynchronous mode; none of them waits for another.
• Communication between domains is asynchronous two way communication.
  • Somewhat like “email based chat”
    • (which we do not recommend for online collaboration)

The “core of the trick” is to consistently follow this simple concept when implementing it.

Once the required Organisation Maturity, DBJ CMM L5, is established, the organization is ready to start to smoothly operate over three interconnected, collaborating domains; each with a distinct mandate.

Product

The “item” the BPT domains delivers is a Product. A Product is whatever the Business declares and Technology implements: a software product, a service, documentation, a process description, a physical book, and so on. A Product development exists in the documents and deliverables that are the outcome of a DBJ ADM wheel.

Not every kind of Product involves coding or engineering deliverables.

A Product is fully described by 3 × 5 (15) deliverables: each of the three BPT domains runs one DBJ ADM wheel, and each wheel produces five deliverables. The deliverables are all supporting the development of the same Product. Each is written in the context of the domain it resides in. Business works on an Initiative, Products and Technology work on Projects. The deliverables are presumably small. Their existence and their classification is what matters.

In smaller BPT adopters organisations, people in one role often wear multiple domain hats. Beside CMM proven maturity. Example: Product Owner (PO) single person, can be involved in the Business domain and in the Products. DBJ Method requires that person domain association is always explicit. Thanks to that:

The domain-to-domain information exchange must be consistent. Following the OP Model decoupled information exchange.

Adopting Organizations usually have organized repositories of ADM Deliverables. Each using simple but sufficient template for backtracing to the “origin”.

Domain handoff points

Each domain has explicit handoff points — emitting and receiving structured artifacts that ensure the whole model continuity. Unless it is Business, no domain project finished work without a prior clear input from the prior domain, and no domain publishes without producing an output defined by DBJ ADM. 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["Product 1"]
        PP2["Product 2"]
    end
    subgraph T["Technology Domain"]
        direction TB
        TE(&lt;&lt;Interface&gt;&gt;<br>Technology<br>Operations)
          direction LR
        TP1["Product 1"]
        TP2["Product 2"]
    end

    B <-->|Domain<br/>Iterations<br/>Cycle 1| P
    P <-->|Domain<br/>Iterations<br/>Cycle 2| T

Domain interfaces are simple conceptual public connection points on the domains. How many projects each domain holds, and what a domain looks like inside is arbitrary. Explained in BPT Runtime.

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 role, responsible for architecture decisions within their domain scope. Domain Leads co-own the BPT cycle governance and escalate cross-domain conflicts to shared resolution.

As noted above, one person may hold roles in more than one domain: a Product Owner, for example, working on Business initiatives and on Products projects. The domain association stays explicit even where the roles overlap.

Domain leads also regularly cooperate with the Architecture authority.