BPT Runtime

← BPT Operating Model

UAT is probably the most important kind of testing. User Acceptance Testing. Not equal to myriad of technology tests executing and repeating inside technology domain projects.

Domains contain projects

A small organization may have a single product to deliver: one project in the Business domain, passing information to one project in the Products domain. Once the Business ↔ Products iterations have settled, the Products project requires the Technology domain to organize and execute development and delivery.

Larger organizations naturally run several projects per domain, starting from Business, where projects are usually called initiatives.

Business runs 1..N Initiatives. Each Initiative produces 1..N Products. Each Product maps to one Technology project.

flowchart TD
    subgraph BPT["BPT Loop"]
        subgraph B["Business Domain"]
            I1(Initiative 1)
            I2(Initiative N)
        end
        subgraph P["Products Domain"]
            P1(Product 1)
            P2(Product 2)
            PN(Product N)
        end
        subgraph T["Technology Domain"]
            T1(Project 1)
            T2(Project 2)
            TN(Project N)
        end
        I1 <--> P1
        I1 <--> P2
        I2 <--> PN
        P1 <--> T1
        P2 <--> T2
        PN <--> TN
    end

One BPT Loop guides one Product from inception to deployment. Complexity multiplies inside the domains, never in the loop: the loop is always the same structure. Architecture oversees all initiatives and keeps them aligned.

Domain information exchange is two-way throughout — during development, and after deployment, through the never-ending maintenance stage of the product.

Projects contain instances of DBJ ADM

Each Business and Product domain project turns its own DBJ ADM wheel.

Technology is an exception

(hint: Engineering is rarely a problem)

Each is iteration, regardless of the team owning it. As an example technology domain teams run on Engineering’s established agile models instead.

Domain anatomy

• A DBJ Method Domain is conceptually a service.
• Each Domain maintains its private persistent storage of deliverables.
• Domain Operations communicate with the adjacent domains. Products communicates with two.

flowchart LR
    subgraph B["Business Domain"]
        direction TB
        BI(&lt;&lt;Interface&gt;&gt;<br>Business<br>Operations) <-.-> BS(Storage)
    end
    subgraph P["Products Domain"]
        direction TB
        PR(&lt;&lt;Interface&gt;&gt;<br>Products<br>Operations) <-.-> PS(Storage)
    end
    subgraph T["Technology Domain"]
        direction TB
        TE(&lt;&lt;Interface&gt;&gt;<br>Technology<br>Operations) <-.-> TS(Storage)
    end

    B <-->|Information| P
    P <-->|Information| T

Domain interfaces are simple public connection points into the domains. This is a conceptual view of the DBJ Method BPT Domains. Not to be confused with micro services.

Domains are operationally decoupled. They live and operate independently of each other, and can be STARTed and STOPped as a result of information arriving from an adjacent domain.

Keep the domains decoupled. Exchange information with other domains, but keep the domain storage private.