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.

NOTE
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, into accountable and responsible to the conceptual architecture
    • This is done by onboarding them onto the 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

TIP
Continuous Product-Centric Cycle

The BPT Loop

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 domain (segments) are decoupled. That makes roles servicing them clearly separated along the lines of clear cut responsibilities.

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

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

IMPORTANT
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 StreamIntentKey Roles
RequireBusiness declares product needs; EA ensures alignment with strategyBusiness, EA
DevelopTechnology builds to product specifications; EA governs coherenceTechnology, Product, EA
DeployProduct is released into operations; EA validates architecture complianceTechnology, Product, EA
EvaluateMeasure outcomes against business objectives; feed back into next cycleBusiness, 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
  • BPT Runtime — the domains at runtime: what contains what, and how many of each
  • Business, Product, Technology — the three segments in depth: boundaries, repositories, and the four Activity Streams (postponed)
  • 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

IMPORTANT
BPT OP model: Product unifies; Loop validates.

BPT Domains are gravitational regions of gravitational pull for organization roles, circling around them.

  • Business roles to the Business Domain
  • BA roles around the Products Domain
  • Engineers and DevOps around the Technology Domain