Enterprise Architecture — Frequently Asked Questions
Candid answers on enterprise architecture — what it is for, whether frameworks like TOGAF help, how to run a portfolio review, why roadmaps stall, and how to have influence without becoming a gate everyone routes around.
The function#
What is enterprise architecture actually for?#
Making decisions about the estate as a whole that individual projects cannot make for themselves: which capabilities we invest in, which applications we retire, where duplication is tolerated and where it is not, and what the technology position needs to be in three years.
Projects optimise locally and correctly. The estate is where local optimisation produces four systems doing the same thing, none of which anyone owns.
How is it different from solution architecture?#
Scope and time horizon. Solution architecture decides how one system is built, now. Enterprise architecture decides what should exist at all, and over years.
Both are needed, and the failure mode is when the enterprise function drifts so far from delivery that it produces target states nobody can act on. If your architects have not been near a delivery team in a year, the models will be beautiful and wrong.
Do we need a framework like TOGAF?#
Use it as a vocabulary and a checklist of things worth considering, not as a programme plan. The frameworks are comprehensive by design, and running them completely consumes more time than most organisations have before their situation changes.
Take the parts with clear value — a capability model, an application portfolio, decision records, a defined governance path — and skip the rest until you feel its absence. Adopting a framework wholesale is how architecture becomes a documentation department.
Doing the work#
Where should a new EA function start?#
With an inventory. What applications exist, who owns each, what each costs, and what data each holds. Not a target state, not a strategy deck.
The inventory is unglamorous and immediately valuable: it usually reveals redundant systems, unsupported platforms holding regulated data, and applications nobody can name an owner for. Those findings buy you the credibility to do anything else.
How do we run a portfolio review without it taking a year?#
Score two dimensions only — business fitness and technical fitness — and force a disposition from four options: invest, tolerate, migrate, eliminate. Use measurements for cost and usage; use the owner's judgement for the rest, recorded with a one-line justification.
Timebox it. A rough assessment of the whole estate is more useful than a rigorous assessment of a third of it, because the value comes from comparison.
What does "tolerate" mean in practice?#
Keep it running, contain the risk, do not extend it, review on a date. It is the most avoided decision in portfolio work because it feels like failure, and it is usually the correct answer for a system that works well enough and is not worth the modernisation budget.
A roadmap that claims everything will be modernised is not a plan. Naming the tolerated systems, with containment actions, is.
Why do our roadmaps never get delivered?#
Common causes, roughly in order: they were never funded, only endorsed; they were built on a target state rather than on the next two or three defensible steps; the business changed and the roadmap did not; or delivery teams were never involved and reasonably treated it as someone else's document.
A roadmap with named owners, funded first steps and a review cadence survives. One with a three-year end state and no first quarter does not.
Influence and governance#
How do we avoid becoming a rubber stamp — or a bottleneck?#
Be a gate on very few things and a resource on many. Reserve mandatory review for decisions that are genuinely expensive to reverse: data ownership, integration boundaries, new platforms, new vendors holding regulated data.
Everything else gets a pattern, a template and an offer to help. Architecture functions that review everything are routed around within a year, and then discover changes after they have shipped.
How do we get teams to follow standards?#
Make the standard the easiest path. A documented pattern with a working starting point gets adopted; a policy document does not.
Then be willing to hear that the standard is wrong. Repeated deviation is usually information about the standard rather than about the teams. Standards that cannot be questioned get complied with in form and evaded in practice.
What should we document, and how much?#
Decisions, boundaries and ownership — the things that are expensive to rediscover. A capability model, an application portfolio with owners, integration boundaries, and decision records with reasoning.
Not: detailed current-state diagrams of everything. They are stale before they are approved, and maintaining them consumes the capacity that should go into decisions.
How do we show the value of the function?#
In the language of the estate: applications retired, duplicate systems consolidated, unsupported platforms removed, licence cost avoided, systems brought into a recoverable state, time saved by teams reusing a pattern.
Those are countable. "Improved alignment" is not, and it is why architecture functions are vulnerable when budgets tighten.
Common questions from the business#
Can we just buy a tool for this?#
A repository tool helps once you have the discipline and hurts before it. The tool does not produce ownership, decisions or accurate data; it produces a place to put them, and an expectation that someone maintains it.
Most organisations get further with a maintained spreadsheet and a decision log than with an unmaintained repository, and the second is more expensive.
How often should the portfolio be reviewed?#
Lightly every quarter, thoroughly once a year, and immediately when something changes materially — an acquisition, a major vendor announcement, a platform going out of support. The annual version is what informs the budget cycle, which is the moment architecture influence is actually exercised.