I’ve worked inside four banks, a telco, an energy retailer and two federal departments in the last decade. Every one of them was running four parallel programmes:
- An enterprise architecture programme, usually owned by the office of the CTO or Chief Architect.
- A platform engineering & DevSecOps programme, usually owned by the VP of Engineering or CISO.
- A data modernisation programme, usually owned by the Chief Data Officer.
- An AI / GenAI programme, usually a new Chief AI Officer or AI Centre of Excellence.
Four sponsors. Four budgets. Four roadmaps. Four sets of OKRs. Four reports to the board. Each one staffed by good people doing the right work for their function. And in most cases, almost no compound between them.
After watching this pattern play out four or five times, I started writing it down as The 4-Discipline Stack. The framework page describes the shape. This essay explains why the compound fails and what to do about it.
Where the leakage actually happens.
Consider a typical 18-month cycle. The EA function writes a target-state architecture that names workload identity, encoded policy and observability defaults as principles. Six months later the platform team rolls out workload identity for new services. Three months after that the data team starts a programme on data lineage. Three months after that the AI team launches a GenAI feature.
Four functions, each doing the right work in the right order, on paper. In practice:
- The platform team’s workload-identity rollout doesn’t cover the data team’s pipelines, because nobody wrote it down as a cross-cutting requirement.
- The data team builds lineage in a tool the AI team doesn’t consume from, because the AI team is using a different vector store than was specified.
- The AI feature ships with its own bespoke observability, because OpenTelemetry GenAI semconv wasn’t in any of the four roadmaps.
- The EA principle is “done” (the platform implemented workload identity!) even though the principle in practice covers 20% of the surface area.
Four projects, all delivered. Zero compound. Each function’s board report shows green. The substrate is a patchwork. The first time someone tries to ship an audit-grade GenAI feature, all four gaps surface simultaneously.
What “substrate” means.
A substrate is the small set of capabilities that every discipline consumes and that compounds across all of them. In 2026 the substrate is roughly:
- Identity. Workload identity (OIDC/SPIFFE) as the universal authn primitive across services, data pipelines, AI gateways. Static credentials become exceptions.
- Observability. OpenTelemetry as the universal instrumentation. Traces span from the Terraform module to the LLM inference call.
- Policy. Policy-as-code (OPA/Kyverno) enforced at deploy. Architecture principles are written as policies, not as PDFs.
- Audit evidence. Per-decision evidence packs generated at decision time, signed, retention-policy-controlled.
- Data lineage. Catalogued data with owners, freshness, residency. Consumable by AI, BI, ops alike.
With these five in place, each of the four disciplines accelerates the next. Without them, each one rolls its own bespoke version and the patchwork accumulates.
The single org-design problem.
Look at the list. Identity, observability, policy, audit, lineage. None of these are a single function’s clear deliverable. Each of them lives at the seam between two disciplines.
Identity is shared between platform and security. Observability is shared between platform and SRE. Policy is shared between architecture and platform. Audit evidence is shared between compliance, AI and platform. Lineage is shared between data and AI.
When no single function owns the seam, the seam doesn’t get built. Each function builds its half; the halves never meet. That is the compound problem.
The shape that fixes it.
Three structural moves change the dynamic:
1. Name a substrate-owning role.
Usually this is the head of platform engineering, with the explicit mandate to own the substrate as a product. Not “the Kubernetes platform.” Not “the developer portal.” The substrate — identity, observability, policy, audit, lineage — as a coherent thing.
This person reports to whoever has cross-functional authority — often the CTO. Their roadmap is published. Their KPIs are the substrate coverage metrics, not feature delivery.
2. Federate architects into the streams.
Central EA owns the substrate principles and the capability model. Federated architects sit in the highest-coupled streams (data, identity, payments, AI), reporting dotted-line to central EA. They are the people who make sure each stream’s decisions encode the substrate principles rather than route around them.
Without federation, central EA writes principles that the streams don’t implement. With federation, the principles get encoded into the streams’ templates and choices.
3. Report compound metrics, not discipline metrics.
The KPIs that change behaviour are the ones that span disciplines:
- Percentage of services with inherited identity + observability + policy + audit (substrate coverage).
- Time from architecture decision to platform default.
- Time from new AI use-case sponsorship to production with all nine controls in place.
- Number of distinct teams that consume the same substrate primitive (eg. shared observability vs. bespoke).
These metrics force investment in the seams. Once the board sees compound metrics, the four functions stop optimising in isolation.
What this looks like in practice.
I’ve seen the pattern land at two orgs. In both cases the trigger was the first regulator-grade question: “Show me how this decision was made.” In both cases the org realised it could answer the question for the AI feature only by building bespoke infrastructure — or it could build the audit-evidence substrate once and reuse it for every future feature.
Both chose the substrate. Both took two quarters to land it. Both compounded for the next two years — not just on AI but on compliance reporting, incident response, change management, capability investment.
The board conversation after substrate investment is qualitatively different. You stop reporting on individual function delivery and start reporting on the rate at which the four disciplines ship together.
The diagnostic test.
Two questions surface whether your four functions are compounding:
- Can a single platform-engineering investment be defended to the board on three or more strategic outcomes (eg. AI rollout + operational risk + audit-readiness)? If yes, you have a substrate. If no, you have four projects competing for the same engineers.
- If you run all four of the corresponding diagnostics — EA, platform, data (coming soon), AI — do the capability breakdowns identify the same one or two weaknesses recurring across all four? The recurring weakness is the substrate gap. The discipline-specific weaknesses are downstream symptoms.
In every case I’ve seen, the recurring weakness across all four is one of: identity, observability, policy enforcement, or audit evidence. The substrate gap is the same gap.
The mandate is the practitioner’s.
Boards don’t see the seam. CFOs don’t fund the seam. CIOs don’t organise around the seam. The person who sees the seam — and whose job depends on it being closed — is the practitioner operating across two or more of the four disciplines.
That’s the architecture function (when it’s embedded), the platform engineering function (when it’s product-oriented), or the increasingly common “chief of staff to the CTO” role. If you’re in one of those roles, naming the substrate — and getting funded for it — is the highest-leverage thing you can do this year.
It’s also the thing that makes the four functions, each doing their job, finally compound.