The B ↔ P ↔ T
DISAMBIGUATION — “BPT Loop” and “Operating Model” are not synonyms; they are different altitudes of the same thing.
BPT Loop describes the mechanism — the endless Business · Product · Technology cycle.
Operating Model describes its role in the architecture — what BPT is to the organization.
One Flow Two Cycles
DBJ Method Flow is made of Two Cycles chaining the B, P and T
The core operating rhythm of the DBJ Method. BPT is composed of two sequential and decoupled cycles:
- Cycle 1: B ↔ P — Business commissions; Products translates and returns for acceptance.
- Cycle 2: P ↔ T — Products specifies; Technology builds and returns for verification.
Every business initiative completes both cycles in order before it can be closed. There are as many cycle-pairs running concurrently as there are active Products — one per Product, all identical in structure.
flowchart LR
subgraph BPT["BPT<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 <-->|Cycle 1<br>B ↔ P| P
P <-->|Cycle 2<br>P ↔ T| T
Notes on two Cycles: B--P and P--T
- Business works in “Initiatives”
- One Initiative can produce one or more products
- Business can change some initiative “mid-flight”. That questions the current Product existence, after the second cycle has started for the current Product.
- In that scenario Product executes the second cycle STOP until the first cycle is finished and Technology can restart the Product with new set of requirements
- The Business and Product will decided on the cost of that operation.
- If the change is ADD the Product flows into next version
- If the change is REPLace then Product fork is required. Current product goes into the deprecated state
Cycle B ↔ P
| Method Domain | Phase | Description | Output |
|---|---|---|---|
| Business | Strategy & Commission | Business defines the strategic outcome: what problem to solve, what value to create, what constraints apply. Sets acceptance criteria — the conditions under which UAT will pass. | Initiative brief · Outcome criteria · Domain mandate |
| Products | Translation & Design | Products receives the Business mandate and translates it into architecture-ready requirements. Designs the solution logic and shape, owns the backlog, defines what Technology must build. Returns to Business for mandate confirmation. | Requirements spec · Solution design · Delivery backlog |
Cycle P ↔ T
| Method Domain | Phase | Description | Output |
|---|---|---|---|
| Technology | Build & Integrate | Technology executes against the Products specification. Engineering, integration, and technical governance happen here. Delivers a testable increment back to Products for verification. | Working increment · Integration artefacts · Technical sign-off |
| Products | Verify & Stage for UAT | Products verifies the built increment against requirements and prepares it for Business acceptance. Coordinates UAT logistics so Business can evaluate meaningfully. | UAT package · Verification report · UAT schedule |