Our Transformation Architecture uses three integrated frameworks: the Scalable Eisk Management Operating System (Δ ▢ ○⁴), the Enterprise Architecture Control Layer (Δ β α), and end-to-end product accountability (Total Product Ownership).
All three begin with the assertion that objective-aligned governance, managed accountability delegation with decision-making authority, and strategic talent management are the foundations for successful transformation..
Our Architecture Principles are here
#1 – Δ ▢ ○⁴ — The Scalable Risk Management Operating System
A structural control system for managing cost, risk, and change in regulated enterprises.
Δ — Contracts, Accountability & Talent
The three primary organizational levers for managing cost and risk:
- Contracts — the rules of the game
- Accountability — who is answerable, and for what
- Talent — the capability and judgement applied within those rules
This is a triangle, not a hierarchy. Weakness in any side destabilizes the system.
What Δ does: Sets governance intent, defines accountability boundaries, determines where judgement is required. Shapes the conditions under which work may safely occur.
What Δ is not: Delivery management, architecture design, or prioritization. Δ does not move work.
▢ — Office of the Product Owner (or Program/Project Manager)
A formal risk-bearing function holding four explicit, orthogonal accountabilities:
- Business Alignment Risk & Opportunity — what is delivered serves intended outcomes
- Architecture Risk & Opportunity — structural decisions support coherence, longevity, scale
- Delivery Risk & Opportunity — work can be delivered predictably, safely, within tolerance
- Change Risk & Opportunity (including Process, Culture, Technology & Engineering) — runtime behaviour, resilience, security, performance
The square exists to hold and balance competing risks and opportunities. It is where accountability becomes real, providing a single locus for change decisions and explicit trade-off management.
Decisions are made in collaboration and governed using the Middle Management Certification Regime (MMCR) for pace and transparent, appropriate accountability
The square can be seen like the TOGAF ADM cycle, except with Risk & Opportunity Management in the centre, as opposed to Requirement Management. The square provides the heart-beat of transformational change
In this system, the risk-based decision log becomes the delivery plan.
Why a square? Bounded, load-bearing, designed to hold tension.
○⁴ — Risk-Driven Change Cycles
The operational execution engines: Risk → Solution → Evidence → Residual Risk
- Risk — explicit, named, owned by ▢
- Solution — design/implementation to mitigate risk
- Evidence — objective proof of intended behaviour
- Residual Risk — remaining risk, consciously accepted, escalated, or reworked
Work does not progress without evidence. ○ does not accept risk—it manages it and return the residual.
Why a circle? Continuous, iterative, non-terminal. Risk is never eliminated, only re-balanced.
Why the 4? Each of the four risk domains operates its own continuous cycle:
– Business Alignment: Risk → Solution → Evidence → Residual Risk
– Architecture: Risk → Solution → Evidence → Residual Risk
– Delivery: Risk → Solution → Evidence → Residual Risk
– Change (Process/Culture/Technology/Engineering): Risk → Solution → Evidence → Residual Risk
The Office of Product Ownership (▢) receives residual risk from all four cycles and re-balances trade-offs across domains. This prevents risk from being “solved” in one domain by pushing it into another.
How Does This Scale?
Scaling happens in the Square – It defines four distinct roles, but does not dictate the number of people in each role. This system can be used with one person covering Business Alignment and Delivery, and another covering Architecture and Engineering Change, It can be used with multiple people in each corner as long as the division of accountabilities is clear and communication is continuous. Do not turn the Square into a governance board or weekly meeting.
#2 – Δ β α — Enterprise Architecture Control Layer
Corporate-level control and accountability flow, aligned to FCA/PRA expectations and SMCR logic.
Δ — Contracts, Accountability & Talent
Every enterprise is defined by it’s contracts – starting with its contracts with jurisdictional law & regulators and investors & shareholders, though these the enterprise has obligations and defined accountability for:
- Risk appetite
- Strategic direction
- Regulatory posture
- Cultural expectations
The Enterprise Architecture Control Layer uses these foundational contracts to generate operating principles, principle-led policies and explicit tolerances. The Enterprise Architecture Control Layer sits upstream of all technology.
Unlike the IT Operating System where we define the scope of the triangle for any given transformation or project, here we reflect the existing triad of governance of regulators, law and shareholder / contractual obligations, the accountability-delegation systems being used, and the business’s talent management and resource distribution approaches.
Answers: “What do we stand for, and what will we not tolerate?”
β — Behaviours (SMCR-Aligned + Capital Obligations)
Behavioural expectations defined and enforced through SMCR, regulatory governance domains and obligations to sources of capital. Not values-theatre—these behaviours are owned, evidenced, and enforceable.
Makes behaviour a designed system property rather than an aspiration. Regulators care about how people actually act, than the structures they act within.
Answers: “What are the necessary and expected behaviours of accountable individuals?”
α — Accountability Decomposition & Management
How accountability flows through the organization:
- Delegation with retained responsibility
- Control mechanisms and reporting
- Oversight and escalation
- Traceable accountability chains
Where governance becomes operational.
Answers: “Who is accountable, right now, for this risk; what resources do they need to manage it?”
#3 – ⬢ Total (Insurance) Product Ownership
Total (Insurance) Product Ownership is a way of managing insurance products that treats them as living systems, not projects, backlogs or static rule-sets.
An insurance product is more than pricing and wording.
It includes underwriting rules, data across the full life-cycle, technology, operations, regulatory obligations, customer outcomes and financial planning — all moving together.
Total Product Ownership assigns clear end-to-end accountability for the product.
It also accepts that this accountability is often too broad for a single individual.
Where appropriate, it is supported by an Office of Product Owners, which provides specialist capability, shared governance, and coordination across related products.
This structure promotes portfolio harmony, supports cross-cutting and shared functions, avoids local over-optimisation, and gives product owners the support they need without diluting responsibility.
This owner is not just accountable for delivery.
They are accountable for value, risk, cost, and financial sustainability over time.
Decisions are made by balancing seven things:
Customer outcomes, commercial value, available capital, regulatory compliance, architecture, process and data integrity, operational viability, and the product’s ability to evolve.
Risk is not pushed down into teams or hidden in technology.
It is held openly, prioritised consciously, and actively managed with evidence.
Change is not driven by urgency alone.
It is driven by understanding what could improve outcomes, what could go wrong, what matters most, and what can safely wait.
This creates products that are simpler to plan for, safer to operate, cheaper to change, and clearer to govern.
Total Product Ownership replaces short-term delivery focus with real, long term accountability — and gives insurers confidence that their products can grow without becoming fragile and be retired when no longer the best use of capital.
(The framework is currently being developed for Insurance Products, but other financial products could and should use appropriate variants)