Ask an architecture team to name their most critical dependency and they'll usually point to a diagram. Ask them what happens if that dependency changes, and the room gets quiet. The gap between the two answers is the subject of this piece.
Over eighteen months, the Institute reviewed sixty-two enterprise architecture reviews across financial services, healthcare and manufacturing. In fifty-one of them, we found at least one system, contract or integration that every downstream team depended on, that no single owner was accountable for, and that had never been load-tested against a change.
The wall is a decision, not a system
The instinct is to treat this as a technical problem — find the fragile system, replace it, move on. That instinct is usually wrong. The wall is rarely the system itself; it's the decision that made the system load-bearing in the first place, made years earlier, by people who no longer work there, for reasons no longer written down.
Technical debt is what you get when nobody owns a decision. Architectural risk is what you get when nobody remembers it was made.
That reframing changes who should be in the room. It's not primarily an engineering conversation about refactoring; it's a governance conversation about who currently holds — and who should hold — the authority to change a decision nobody remembers making.
The organizations that found their load-bearing walls before something forced the issue shared one habit: they mapped decision rights alongside system dependencies, not after them. That map is the deliverable this research produced, and it's the subject of the governance maturity model elsewhere in this issue.