The previous series ended with an obligation.
Not a framework to implement. Not a methodology to follow. A structural argument — that architecture influences outcomes only when it is part of the decision system of the enterprise — and the explicit acknowledgement that building that system requires something no series of articles can substitute for. Political work. Organisational work. The kind of work that begins on a specific Monday morning in a specific organisation with a specific inheritance.
This series begins on that Monday morning.
Not in a clean environment. Not with executive mandate already in place and a delivery team waiting for architectural direction. Inside an organisation that has been doing something called architecture for some time, that has produced the artefacts that architecture is supposed to produce, and that cannot answer the four questions a Solution Architect needs answered by Thursday afternoon.
The first obligation is not to build. It is to read.
What Configuration Inheritance Actually Is
Every organisation a practitioner enters has already made decisions. Most were never recorded as decisions. They accumulated as structural conditions — the way authority actually flows, the way delivery actually routes around constraints, the way the record and the reality have drifted from each other over time.
Configuration Inheritance is the sum of those conditions. Not the org chart. Not the documented architecture. What the practitioner actually finds when they look at what the organisation does rather than what it says it does.
Two organisations can have identical documentation and completely different Configuration Inheritances. One has a repository that delivery teams trust and use. The other has the same repository, updated on the same cycle, populated with the same artefact types — and delivery teams have learned to route around it because it has never answered a question they needed answered under pressure. The documentation is identical. The inheritance is not.
Reading Configuration Inheritance requires a different instrument than reading documentation. It requires observation of what the organisation actually does when a decision arrives under pressure. Who gets called. Whether the call produces a binding answer or a workshop. Whether the answer is recorded or verbal. Whether the record, if it exists, reflects what was actually decided or what was comfortable to document.
That observation takes forty-eight hours to begin in most organisations. Not because the signals are subtle. Because most practitioners are not looking for them.
The Diagnostic — Five Signals in the First Two Weeks
Signal One — Decision Latency
Pick three decisions raised in the last month. Not significant ones — ordinary ones. A new integration pattern. A domain boundary question. A constraint conflict between two delivery teams. How long from the question being raised to a binding answer being produced?
In a functioning decision system, ordinary decisions at domain level close in forty-eight hours. Cross-domain decisions close in five working days. These are practical heuristics, not universal standards. An organisation handling genuinely high-consequence decisions may legitimately take longer. The signal is not the number. It is the pattern. If the answer to any of the three is "it went to a working group and is still open," the latency is structural, not situational. If the answer is "we are not sure who owns it," the ownership signal underneath is more severe still.
In the non-profit, the most recent cross-domain question had been open for eleven days and was sitting in a shared inbox with no named owner. That is not a busy week. That is a Vacuum Inheritance signal underneath a Theatre Inheritance surface.
Signal Two — Baseline Integrity
Ask to see the current estate documentation. Not the target architecture. Not the roadmap. The current state. Then ask three people who work inside the estate — a platform engineer, a delivery lead, a domain architect — whether the documentation reflects what is actually running.
The platform engineer answers first. She says the documentation is accurate for the core systems but the integration layer changed significantly during the last migration and nobody updated the diagrams. The delivery lead says he stopped consulting the repository eighteen months ago because it kept describing systems that had been decommissioned. The domain architect says the documentation is mostly right but the ownership fields have not been updated since the last reorganisation, so the named owners for three of the five domains no longer hold those responsibilities.
Three people. Three different answers. The same documentation.
That conversation takes twenty minutes. It surfaces what no artefact review would have found — not a documentation gap but a trust gap. The practitioners inside the estate have quietly and individually concluded that the record cannot be relied upon. They have not reported this formally because there is no mechanism to report it to, and because the measurement model has never asked whether the documentation is trusted, only whether it exists.
The gap between what they say and what the document says is the Baseline Integrity reading. An organisation with high Baseline Integrity has documentation that practitioners trust enough to make decisions from. Most organisations with a year of capability mapping have low Baseline Integrity on current state and high completeness on future-state aspiration. The map shows where they want to be. It does not show where they are.
Signal Three — Authority Clarity
Surface one constraint conflict. It does not need to be significant. Find a place where two delivery requirements are pulling against each other and there is an architectural constraint that should resolve it. Then watch what happens when the conflict is named.
In a functioning decision system, the conflict routes to a named individual at the right Decision Altitude. That individual produces a binding answer within the time bound for that level. The answer is recorded. The constraint owner is notified if the decision represents an override.
In most organisations the conflict is acknowledged, a meeting is scheduled, the meeting produces a recommendation, the recommendation goes to a steering group, and three weeks later the delivery team makes the pragmatic call that the process was too slow to inform. The constraint exists. The authority to enforce it does not.
Signal Four — Deviation Pattern
Ask whether exceptions to architectural constraints are tracked. Not whether they are approved — whether the pattern of approvals is visible to anyone. Whether anyone can say, today, how many times a specific constraint has been overridden in the last six months, by which domains, and for what stated reasons.
In a functioning decision system, this information is available and reviewed on a defined cadence. In most organisations, exceptions are approved case by case and the pattern is invisible. Each exception is evaluated in isolation. The accumulation is not a signal anyone is reading. The constraint may be miscalibrated. Nobody would know.
Signal Five — The Measurement Model
Ask what the architecture function is measured on. The answer tells you more about the Configuration Inheritance than any artefact review.
If the answer involves artefact production — frameworks published, reviews completed, workshops held, documents approved — the measurement model is rewarding activity. Then look at what behaviour has actually been visibly rewarded or sanctioned in the last quarter. Not what people say they are measured on. What gets praised in governance reports. What gets defended when challenged. What gets quietly dropped when delivery pressure arrives.
The gap between the stated measurement model and the revealed measurement model is the real signal. An architecture function that says it is measured on strategic alignment but whose practitioners are praised for producing documents and sanctioned for slowing delivery has a Theatre Inheritance regardless of what the framework documentation says.
What the Signals Produce
Not a score. Not a report.
The five signals rarely point in the same direction cleanly. Low Decision Latency in one domain alongside a complete absence of Deviation Pattern tracking is not a contradiction — it is a compound reading. One domain has functional authority. The organisation has no learning mechanism. Both are true simultaneously. The diagnostic does not resolve that tension into a single verdict. It maps it. The map is what the first intervention is designed against.
Three inheritance types recur across most organisations. They are not mutually exclusive. In practice they compound — a Theatre Inheritance in the governance layer sitting above a Vacuum Inheritance in the delivery layer is more common than either condition appearing alone, and more resistant to the interventions that work on each type separately.
The Theatre Inheritance. Active, visible, productive — and disconnected from every decision that matters. The architecture function produces what it is measured on. The measurement model never asked whether production was connected to a decision. The delivery organisation has learned, quietly and without announcement, that architecture is consulted after decisions are made, not before them. Nobody is behaving badly. The governance forums are real. The artefacts are real. The failure is the gap between the architecture function's self-description and its actual relationship to the decisions that govern delivery.
The Vacuum Inheritance. No authority designed. Decisions are made by whoever is most senior in the room, most comfortable with conflict, or most willing to absorb the consequence. Operationally chaotic. Structurally honest. Nobody is pretending the decision system functions. The absence is visible. That visibility is the starting condition for building something real.
The Decay Inheritance. Correctly designed once. A constraint infrastructure accurate two years ago now enforcing boundaries the business has moved beyond. An authority structure that worked across three domains now producing Governance Drag across twelve. Structure looks intact. Substance has not kept pace. The most insidious inheritance because the structural conditions look correct — the repository exists, the authority levels are documented, the forums run — but the calibration has drifted so gradually that nobody can identify the precise point at which the decision system stopped being connected to delivery reality.
The Non-Profit in the Room
Twenty thousand users. Five hundred sites. A VMware licensing model that changed in 2024 and has not been addressed. A major SAP upgrade running without architectural routing. No cloud strategy. No enterprise-grade EA tooling.
And a capability map. Complete. Accurate, as of the date it was saved.
This organisation has a Theatre Inheritance with elements of Decay underneath it. The architecture function produced what it was measured on. The measurement model never asked whether production was connected to a decision. The VMware drift was not invisible to the estate — it was invisible to the measurement model. The SAP upgrade's architectural conflicts are not invisible to the delivery team — they are invisible to the governance model that was never designed to surface them.
The practitioner walking in is not walking into a failure. They are walking into a sincere investment in the wrong instrument. The capability map is not wrong because capability maps are wrong. It is wrong because this organisation needed a decision system and received a taxonomy instead.
Reading that distinction in the first two weeks — without accusation, without the theatre of a dramatic diagnosis, without the consulting instinct to produce a new artefact that describes the failure of the old artefact — is the first act of the implementation.
The Baseline Integrity reading alone surfaces the VMware situation. Not because the practitioner is clever. Because the practitioner asked what was running and compared it to what was documented. That comparison took an afternoon. It had not been done in two years because the measurement model did not require it.
What the Reading Produces — and What It Does Not
One output. Not a report. Not a new framework. Not a recommendation deck.
A starting position. Which failure mode is most active. Which structural condition is most constraining. Which domain has the highest decision pressure this week — not in the target architecture, not in the capability map, but in the actual delivery environment right now.
That starting position determines the implementation sequence. The Theatre Inheritance and the Vacuum Inheritance do not begin in the same place. The Decay Inheritance requires a different first intervention than either. The First Domain addresses that choice directly — how to read the inheritance type and select the first domain accordingly.
The reading also produces a credibility position. The practitioner who spends two weeks observing before recommending has demonstrated something no credential, framework recitation, or title can substitute for. They are inside the organisation's actual problem rather than adjacent to it. The delivery lead who has been routing around the architecture function for eighteen months will talk to a practitioner who asks what is actually running before proposing what should run instead.
That conversation — the one earned by reading before recommending — is where the implementation begins. Not in a governance forum. In the room where the real decisions are being made and the architecture function has not yet been invited.
One more thing the reading produces. An honest account of what will resist. Not who. What structural conditions will make the first constraint harder to land, the first authority design harder to defend, the first Pulse cycle harder to sustain.
Reading the inheritance precisely is not pessimism. It is the precondition for building something that holds when the pressure arrives.
Which it will. It always does.