DBJ.METHOD
Why 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.
Reminder: The underlying idea of DBJ Method is to encapsulate complex TOGAF artifacts behind an Operating Model for feasible business usage. TOGAF stays underneath; business op roles never see its complexity directly.
- Importantly DBJ Method, transforms Business Roles central, into accountable and responsible to the conceptual architecture
- This is done by onboarding them on simplified Maturity Model
- Abbreviated name “DBJ CMM”
- Business domain projects are modeled after the TOGAF ADM. Good analogy: the steering wheel of the business ship.
- To make the TOGAF ADM usable by the business, DBJ Method has encapsulated it behind a version in which the business truly drives the outcome.
- TOGAF ADM is central structure for Enterprise Architecture projects, used by (many) Enterprise Architects producing only EA Artifacts
- We have encapsulated the (TOGAF) ADM wheel into the Project Management Concept where Business is in the driving seat.
- Name is abbreviated to DBJ ADM
- At the helm of DBJ ADM “wheel” is the business. Enterprise Architecture is “just” the navigator.
- That is unlike TOGAF ADM, that is a domain of Enterprise Architects, producing EA Artifacts only. By default for large corporations.
- The core necessity of the BPT Operating Model is to encapsulate the DBJ ADM deliverables behind an interface usable by the three key segments of any DBJ Method organisation:
- Business
- Product
- Technology
The B ↔ P ↔ T Loop
Continuous Product-Centric Cycle
Loop is at the heart of the BPT Operating Model.
- Business — market strategy, stakeholders, and business owners — declares intent.
- Product — the specification and delivery management layer — is the alignment point between them, decoupling each so both can evolve independently, while coupling them so delivery is coherent and traceable.
- Technology — engineering and development teams — implements to product specifications.
The three segments are decoupled. That makes roles servicing them clearly separated along the lines of clear cut responsibilities.
Example: Business Analyst (EA) works inside the “Product” segment. It is informed by “Business” segment deliverables on WHAT (Product) is required. BA creates workflow diagrams to translate what into how , but only until the implementation takes over. How is the responsibility of the “Technology” roles, operating in the “Technology” segment. Each of the roles mentioned can have other duties and “jurisdictions” completely encapsulated in their fields of expertise. As business sees fit.
Each segment has a logical repository — a logical persistent store for the deliverables that belong to it. The DBJ ADM wheel does not “somehow” hand deliverables to roles directly; it places them in the correct logical domain repository. Roles “watch”/”observe” the domain repository; they never watch the wheel directly. This is what keeps the wheel and the domains decoupled.
ADM deliverables by segment: Business produces Conceptual outputs. Product produces Logical and Physical outputs. Technology receives Physical and Implementation outputs. Outputs the testing material
Enterprise Architecture (EA) (if present) governs the BPT loop from above. It does not participate in delivery — it defines the principles, governs the transitions, and measures alignment health through the feedback.
The entry ticket to the BPT Loop is ACMM Level 5. That is the precondition for smooth cycling and delivery.
The Four Activity Streams
| Activity Stream | Intent | Key Roles |
|---|---|---|
| Require | Business declares product needs; EA ensures alignment with strategy | Business, EA |
| Develop | Technology builds to product specifications; EA governs coherence | Technology, Product, EA |
| Deploy | Product is released into operations; EA validates architecture compliance | Technology, Product, EA |
| Evaluate | Measure outcomes against business objectives; feed back into next cycle | Business, Product, EA |
Evaluate Stream feeds back to Business so the next Requirement event can initiate the commencement — the loop never stops.
BPT Operating Model from the EA Point of View (POV)
The BPT Operating Model is Architecture Governance as a productized execution model. It does not replace the ADM “Wheel” — the DBJ ADM wheel runs as the governance layer above it, producing the deliverables that the three domain consume.
- Conceptual Foundations
- Business, Product, Technology — the three segments in depth: boundaries, repositories, and the four Activity Streams
- Roles, Actors and Jurisdictions — who works where in the BPT Operating Model and why
- DBJ ADM — the governance ADM (aka “steering wheel”) that operates above the BPT Operating Model
- CMM — the maturity prerequisite for the business ship crew. Before the ship sails.
Summary
BPT OP model: Product unifies; Loop validates.