Enterprise architecture
The structure decisions get made inside — kept current enough to use.
Enterprise architecture defines how an organization's strategy, business capabilities, applications, technology, data and integrations fit together, and sets the standards and roadmaps that govern how that structure changes.
Your enterprise architecture should describe the enterprise that exists now, not the enterprise that existed when the diagram was created. The test is not the quality of the models — it is whether the architecture changes decisions at the moment they are taken. Consulted afterwards, or only during annual planning, it is a description of the estate rather than a control on it.
Architecture as an operational discipline
Most architecture practices fail the same way. They produce extensive current-state documentation, a target state nobody disputes because nobody is bound by it, and a governance forum that reviews decisions after they have effectively been made. The work becomes descriptive, and the organization learns to route around it.
The root cause is currency. A target state agreed three years ago and a current state surveyed last quarter will disagree; once teams notice the disagreement they stop consulting either. An architecture that is not current is not authoritative, and one that is not authoritative is documentation.
One concrete test of whether architecture is operational: does it know when a contract renews? A renewal is a real decision point — the moment when replacing, consolidating or renegotiating is actually possible. An architecture practice disconnected from that cycle is not participating in the decisions that shape the estate; it is commenting on them afterwards.
What architecture has to connect
Who needs it
- Organizations facing a platform decision — EMR, ERP, core system — that will constrain the next decade.
- Health systems integrating clinical and administrative estates across merged entities.
- Universities where three estates are governed separately and nobody owns the whole.
- Any organization where every initiative touches more systems than expected, so estimates are unreliable.
How EXOS runs it
What EXOS actually does
From the practice as it runs today: EMR and ERP integration and process flow design; discharge and patient flow optimization; operating-room scheduling and service line design; clinical and business data reporting and governance; and implementation services to take the design into production. The healthcare weighting reflects where the practice has been most active, not a limit on where it applies.
Where AI and Tacit OS fit
Architecture is constrained by how much of the estate a team can hold in view at once. EXOS uses AI and Tacit OS to widen that: reconciling system and data documentation, surfacing dependencies manual review misses, and carrying prior architectural decisions into the current engagement. Decisions are recorded with their reasoning intact, which matters most years later, when the person who made the call has gone and the organization needs to know whether the constraint still applies.
What you keep
The decision record. Architectural choices stored with the trade-offs behind them, so a successor can ask whether a constraint still holds rather than inheriting it as folklore.
Delivered through fdX
EXOS delivers this through fdX — Forward-Deployed Expertise. Here the expertise is architects who have delivered rather than only modelled, which is the difference between a target state and a target state anyone reaches. Engineering takes the design into production, and AI widens how much of the estate the team can hold in view at once.
Common questions
Does EXOS use TOGAF or a named framework?
EXOS works from first principles — starting from the actual problem rather than the available framework. Established frameworks are useful vocabulary and EXOS practitioners are fluent in them, but an architecture practice whose main output is framework conformance has usually stopped serving the organization.
How does enterprise architecture support enterprise AI?
AI is bounded by data, and data is bounded by architecture. Many stalled AI initiatives are architecture problems wearing an AI costume: the model cannot be trusted because the underlying records contradict each other across systems. See enterprise AI.