Most organisations that experience repeated enterprise architecture failures conduct post-mortems that identify technical causes: the wrong technology choice, insufficient capacity planning, inadequate testing coverage, poor integration design. Those causes are real. They are secondary.
The primary cause, the one that generates the technical failures as a downstream consequence, is almost always an incomplete understanding of what the business actually requires from the system.
What Business Context Means in Practice
Business context, in the architectural sense, is not the requirements document. Requirements documents capture what stakeholders have been able to articulate and agree on. They do not capture the operational dependencies that stakeholders do not know they need to describe, the constraints imposed by adjacent systems that the project team discovers mid-build, or the performance envelope the business will actually need once the system is in production.
The architect’s job is to read the genuine technical requirement behind each commercial ask. That requires domain knowledge of how the business actually operates, structured stakeholder analysis, and the discipline to keep asking what the system needs to do under failure conditions as well as normal operation.
A payment platform that meets every stated requirement but fails under peak load during a promotional event has failed its architectural requirement. The peak load profile during a promotional event was a knowable fact before design began. It was not in the requirements document because the stakeholders did not connect that operational reality to the architecture discussion.
Why Technical Skill Cannot Substitute for Business Understanding
An architect with deep technical skill can design a system that meets the stated specification with precision. The system will fail if the specification is incomplete, because technical precision applied to an incomplete specification produces a system that exactly satisfies a wrong problem.
The failure mode is characteristic. The system works in testing because testing is designed against the specification. It fails in production because production contains the conditions the specification did not describe. The post-mortem identifies technical root causes because those are visible in the failure: the cache configuration that could not handle the load, the database schema that could not accommodate the data shape. The upstream cause, the specification that did not capture the production requirements, is less visible and rarely documented.
The Design Authority Role
The Design Authority function exists precisely to hold this gap. A DA does not review technical designs for technical correctness: that is what the engineering review process handles. A DA reviews technical designs against the business requirements, including the requirements that were not formally specified, and holds architectural boundaries where scope additions would compromise system stability.
That function requires business understanding. An architect who can read a technical specification but cannot read a commercial roadmap, understand a customer journey map, or track the revenue implications of a system design decision is working with half the information they need.
The organisations that consistently deliver architectures that work in production have created a formal mechanism for technical decision makers to interact with business context, not just business requirements. That mechanism can take many forms: embedded architecture roles within business domains, structured design review processes that include commercial stakeholders, or explicit documentation requirements that force the connection between technical choices and business outcomes. An assumption that the requirements document contains everything the architecture needs to know is not a substitute for any of them.
