The B ↔ P ↔ T Operating Model

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.

• 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

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.

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.

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 Four Activity Streams

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
• 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 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