The Difference — “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
DBJ Method Flow contains Two Cycles chaining the B, P and T
These are not akin to tight and fast project loops. There are two way information exchanges between adjacent domains.
The core operating rhythm of the DBJ Method. BPT is composed of two sequential and decoupled cycles. Logically connecting the otherwise decoupled domains:
- 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. Inside the BPT, 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["<br>Business<br>Domain<br><br><br><br>"]
direction TB
end
subgraph P["<br>Products<br>Domain<br><br><br>"]
direction TB
end
subgraph T["<br>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 |