Enterprise Architecture
also called EA Practice, Architecture Function
The practice of owning the architectural decisions whose costs and benefits land on different teams or outside any team's planning horizon - the decisions competent delivery teams have no incentive or information to make.
A feature request arrives and touches five teams, four message formats and two identity systems. Nobody decided that. Each system was built well by a team optimising for its own delivery, which was right for each team, and the shape of the estate is the residue of decisions nobody was present for.
Enterprise architecture is the function that is present for them. Not the drawing of diagrams and not the maintenance of a model repository: the ownership of one class of decision — where the benefit accrues to a team and the cost to the estate, or where the payback outlasts any team's horizon. If a decision's consequences land entirely inside one team, it is not an enterprise architecture decision and taking it is interference.
Why it matters
The absence of the practice is invisible for years. Delivery is fast, every system is defensible, and the cost surfaces as coordination: a feature needing three teams to change in sequence, an integration estate whose run cost is spread across budgets so no line item shows it, a portfolio nobody can retire from because nobody knows what reads what. In estates that have gone this way, coordination commonly accounts for 40 to 60% of elapsed time on ordinary work.
By then the expensive part is not the missed decision but the systems built on top of it. An identifier scheme chosen for one team's convenience in year one is embedded in a dozen systems and a partner contract by year four.
Implementation patterns
- Federated rather than central. Architects embedded in delivery groups with a small coordinating core; a central team reviewing everything is a queue, not a practice.
- A small artefact set, each serving a named decision. An application inventory with owners, a level-2 capability map, a standards set with a waiver path, a target state with a review date, and decision records. The rest is rarely worth its refresh cost.
- Standards expressed as machine checks where possible. A rule a pipeline evaluates scales with the rate of change; a rule on a wiki scales with the number of people who read it, which after month three is close to nobody.
- Influence instruments over mandates — a paved road, a reference implementation that generates a compliant service, a conversation at the point money is committed. These arrive before the decision; a review arrives after commitment and can only bless or block.
Industry example
The Open Group's TOGAF is the most widely adopted formalisation: a Preliminary phase, Phases A to H, and Requirements Management at the centre of the cycle. It supplies a vocabulary and a checklist of concerns and it supplies no decisions, which is why organisations adopt it and still have an estate nobody can change.
Thoughtworks' Technology Radar is the other end: published since 2010 and now twice a year, blips submitted by delivery teams and curated internally. That is governance by aggregated experience rather than approval, and a working practice holds both instruments.
Failure scenarios
- The documentation practice. Three years of models and no decision that went differently. The test is a list of decisions the function changed, with dates.
- The approval gate. The function becomes a review board with a six-week queue, so designs arrive late and pre-built and get rubber-stamped.
- Standards nobody breaks and nobody follows. With no waiver path, deviations happen silently and the standards set stops describing the estate within a year.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Central authority | Consistency and the ability to change the estate on a deadline | A queue in front of delivery and steady erosion of trust |
| Federated influence | Decisions made near the work and adopted willingly | Slow convergence and standards that vary by group |
| No practice at all | Maximum team velocity in year one | Coordination becoming the dominant cost by year three |
When not to use it
Below roughly five to eight teams the cross-team view exists informally and a formal function adds a hop while telling people what they already know. The trigger is not headcount, it is repetition: the third time two teams independently build the same capability, information has stopped flowing on its own.
Interview question
Q: You join a 900-engineer company with no enterprise architecture function. Every team designs competently and delivery is fast. What do you set up in the first six months, and how would you know a year later whether it was worth it?
What a strong answer covers: naming the decision classes genuinely absent rather than inventorying documents; starting with the artefacts that serve decisions already on the table; choosing influence over gates; and committing up front to the measures — cross-team change lead time, estate run cost, decisions the function changed — including the result that would mean stopping.
Quick check
Quiz: Which decisions belong to an enterprise architecture function rather than a delivery team? Those whose costs and benefits land on different teams, or whose payback outlasts a team's horizon. If the consequence lands inside one team, taking the decision from them is interference.
Flashcard: What proves an EA practice is working? — Decisions that went differently because of it, plus movement in cross-team lead time, estate run cost or unowned risk. Model counts prove nothing.