Enterprise architecture
Everything so far has been about one system. Enterprise architecture zooms out to all of an organisation's systems: hundreds of applications, owned by dozens of teams, bought and built over decades. Its questions are different: which systems overlap, which technologies should be standard, how to make acquisitions fit, and how business strategy turns into changes across the portfolio. Done badly, it produces binders of diagrams nobody uses. Done well, it helps an organisation change direction without starting over.
1. The idea
Two approaches
Model-driven
First model the whole enterprise as it is (every system, process and data flow), then design the target state, then plan the transition. Thorough, and slow: in a large organisation the model can take years and is out of date when finished.
Initiative-driven
Start from the business initiatives that matter now (an acquisition, a new market, a cost target) and do just enough enterprise architecture to deliver them well. Faster and tied to value, at the risk of losing the overall picture.
Strategies for how much to standardise
| Strategy | How it works | Good for | Cost |
|---|---|---|---|
| Prescriptive | The EA team chooses standard technologies and platforms; teams must use them | Regulated, cost-focused organisations | Slow to adopt new technology; teams feel constrained |
| Classic alternatives | A short approved list per category (two databases, two languages); teams choose within it | Balance of consistency and choice | The list needs regular review |
| Distributed (lightweight) | Teams choose their own technology; EA sets principles and shares guidance | Fast-moving product organisations | Duplication; harder to move people and share tools |
| Durable interface | Teams choose freely inside their systems, but interfaces between systems follow enterprise standards | Large, varied organisations that must integrate | Interface standards must be good and stable |
Frameworks in brief
| Framework | What it is |
|---|---|
| TOGAF | A process framework (the Architecture Development Method): a cycle of phases from vision through business, data, application and technology architecture to migration planning and governance. Comprehensive; use the parts you need. |
| Zachman | A classification grid, not a process: rows are perspectives (planner, owner, designer, builder…), columns are the questions what, how, where, who, when, why. Useful as a checklist of what to document. |
2. How it works
An acquisition, initiative-driven
A retailer buys a smaller competitor. Watch enterprise architecture work from the initiative, not from a complete model.
Durable interfaces in practice
Three divisions, three technology stacks, one customer. Watch what the interface standard allows.
3. Try it yourself
Which EA strategy fits?
Describe the organisation, and see the four strategies ranked.
4. Trade-offs
Standardise vs autonomy
Standards cut costs, ease hiring and moving people between teams, and simplify operations. Autonomy lets teams choose the best tool for their problem and move faster. Standardise where systems meet; free them inside.
Model vs initiative
A complete model is thorough and slow; initiative-driven work is fast and partial. Most successful EA teams model only as much as the current initiatives need.
Central team vs embedded architects
A central EA team keeps the overall picture; architects embedded in product teams know the details. The two need regular contact, or EA becomes an ivory tower (Module 02).
Framework vs pragmatism
Frameworks provide vocabulary and completeness. Applied in full they can become the work itself. Take what serves the organisation's decisions.
5. In real projects
Why enterprise architecture efforts fail: they produce documents instead of decisions; they're disconnected from business initiatives and budgets; they try to model everything before acting; they impose standards without explaining them; and they have no way to check standards are followed (fitness functions apply at enterprise scale too).
What tends to work: tie every EA activity to a business initiative; publish a short list of principles and a technology radar rather than a binder; standardise interfaces and identity; measure the portfolio (duplicate systems, end-of-life technology, integration costs) and report it in business terms.
From track to enterprise. Every idea in this track scales up: characteristics, trade-offs, quanta, decision records, risk assessments and roadmaps all apply to a portfolio of systems as they do to one.
Say it in the interview
- "What is enterprise architecture?" Architecture across all of an organisation's systems: which overlap, what's standard, how they integrate, and how business strategy turns into changes across the portfolio.
- "How much should an enterprise standardise?" It depends on the organisation; a common answer is durable interfaces: teams choose freely inside their systems, while the interfaces between systems follow enterprise standards.
- "Why do EA efforts fail?" They produce documents instead of decisions, model everything before acting, and lose touch with business initiatives. Initiative-driven EA ties each activity to something the business is doing now.
- Describing EA as producing a complete model of the enterprise first.
- Standards with no reason or no review date.
- No connection between EA work and business outcomes.
6. Remember it
How this hook works: what "plan the roads, not the houses" means
What the slogan means, phrase by phrase
- "Plan the roads"
- Interfaces, integration standards, identity, shared data: what every system depends on.
- "not the houses"
- Inside each system, the owning team decides.
Why this picture fits: it captures the durable-interface strategy and the boundary between enterprise and solution architecture in one line.
The story → the concept
| City planning | Enterprise architecture |
|---|---|
| Roads, water and power | Integration, identity, shared data |
| Building codes | Standards and principles |
| Zoning | Which system owns which capability |
| A new district | A business initiative |
The trap it saves you from
An EA team designing every system's internals, and becoming every team's bottleneck.
7. Common mistakes
8. Design exercise (30 minutes)
- Map duplication (10 min). List the systems in your organisation that do roughly the same job. What does the duplication cost?
- Pick a strategy (10 min). Use the lab with your organisation's traits. Does the result match what you have today?
- Write three principles (10 min). Three short enterprise principles, each with its reason, that would most improve your portfolio.
9. Self-check quiz
An EA team works only on what's needed for this year's acquisition and new-market launch. Which approach?
Teams pick any technology inside their systems, but all APIs and events follow enterprise standards. Which strategy?
What is the Zachman framework?
What's a common reason EA efforts fail?
Which framework centres on a cyclical development method from vision to migration planning?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| TOGAF (The Open Group) | browse | The framework's official overview. |
| Zachman Framework | 15 min | The grid and its origins. |
| The Software Architect Elevator (Gregor Hohpe) | book | Architecture at enterprise scale, from strategy to engine room. |