Enterprises do not have a tooling problem. They have an operating contract problem.
Enterprise Architecture owns the repository. Solution Architecture owns delivery. On paper, that division works. In practice, the boundary is rarely explicit.
EA writes principles and patterns. SA designs systems, manages trade-offs, and performs impact analysis under delivery pressure. Both functions exist. Only one consistently carries consequence.
Archive or Operating System
An archive stores artefacts. An operating system shapes decisions.
If your repository mainly holds diagrams, documents, and audit extracts, it is recording architecture, not governing it.
When a Solution Architect asks, "What are my guardrails?" and receives a principle document, governance has dissolved into interpretation.
Advisory language scales interpretation. Guardrails scale decisions.
This is the difference between architecture as literature and architecture as leverage.
Ownership of Consequence
The friction between EA and SA is not about effort. It is about leverage.
If the repository cannot answer impact questions quickly, the Solution Architect becomes a manual crawler — reconstructing enterprise context through meetings and memory.
That is enterprise work without enterprise leverage. The repository exists. The leverage does not.
Making the Contract Explicit
For governance to scale, ownership must be clear.
Enterprise Architecture owns binding constraints and visibility into deviations. Solution Architecture owns design within those constraints and explicit trade-off documentation.
Without this clarity, EA becomes advisory, SA becomes overloaded, and the repository becomes passive.
From Documentation to Decision Data
The 100-page Solution Architecture Document is not the root problem. It is a compensation mechanism.
When decisions are not captured structurally, architects write prose to protect themselves.
The answer is decision data that can be queried — structured context, applied constraints, explicit trade-offs, mapped domains, and classified risk. If constraints live only in PDFs, they cannot surface at the moment of decision. Velocity outruns governance. AI did not create this gap. It exposed it.
The Tuesday Test
It is Tuesday afternoon. A Solution Architect evaluates a new capability. The system should respond with clarity: impacted domains, applicable guardrails, required escalation, or none.
If the answer is "refer to the position paper," governance is literature, not structure.
Enterprise Architecture does not need louder voices. It needs sharper instruments.
From archive to operating system. From semantics to structure. From review boards to decision telemetry.