All services Every engagement has a fixed, published price. Book a strategy call
A practical enterprise architecture guide for CIOs: the decisions EA must own, realistic UK costs for internal teams versus EA as a service, team sizing, governance, metrics a board will accept, and a one page EA charter you can copy.
This is an enterprise architecture guide for CIOs written by people who run architecture functions for a living rather than by a research firm selling subscriptions. It covers the decisions enterprise architecture must own, what it should cost, how many architects you need, how to govern and measure it, and how to start. It ends with a one page EA charter you can copy and sign. Every recommendation in it is something we have done inside real organisations, and every price we quote for our own services is published on this website.
The short version. Enterprise architecture is a decision discipline rather than a documentation exercise. Give it a small number of decisions to own, write those decisions down in a one page charter, staff it with a handful of senior people or buy it as a service, and measure it in money: applications retired, duplicated spend removed, and change delivered without rework. Everything else in this enterprise architecture guide is detail in service of that.
Enterprise architecture is the discipline of making technology decisions deliberately across a whole organisation, instead of one project at a time. It answers a small set of expensive questions: which applications we keep, how systems connect, where our data lives, what we build on, and what we retire. Done well, it is the difference between a technology estate that was designed and one that merely accumulated.
It helps to be clear about what modern enterprise architecture is not. It is not a library of diagrams nobody reads. It is not a committee that slows delivery down. It is not a framework certification programme, and it is not a tool purchase. Frameworks such as TOGAF are useful vocabulary, and tools are useful memory, but neither of them is the job. The job is decisions.
For a CIO, the practical definition is this: enterprise architecture is the mechanism by which your technology strategy survives contact with individual projects. Without it, every programme optimises for itself, and the estate you are accountable for becomes the sum of a hundred local decisions nobody made deliberately.
Four forces have moved enterprise architecture from a nice-to-have to a board conversation, and a CIO guide to enterprise architecture written in 2026 has to start with them.
Cost pressure meets technology sprawl. Most organisations above a few hundred staff run far more applications than they think, and pay for licences, integrations and support on all of them. Duplicated capability is the quiet budget leak: three tools doing one job, each with an owner who likes it. Technical debt management belongs in the same conversation, because unmanaged debt is what turns every future change into a renegotiation with the past.
AI is being adopted faster than it is being governed. Teams are buying AI features inside existing products and standing up new tools with company data. Without an architecture view of where data flows and which platforms are approved, AI adoption happens anyway, just invisibly, and the risk lands on the CIO’s desk after the fact.
Cyber and regulation now price architecture decisions. Insurers, certifiers and regulators increasingly ask questions only an architecture view can answer: where regulated data lives, which systems can reach it, and what happens when one of them fails. A poor architecture answer is now a premium, a finding, or a lost contract.
Product and platform operating models moved the decisions. When delivery is organised into product teams, decisions that used to be made once centrally are now made weekly in dozens of places. That is precisely when decision guardrails matter most, and precisely when heavyweight central approval fails.
Honestly: not always, and it is worth saying so before this enterprise architecture guide asks you to build anything. If your organisation runs a dozen systems, one core platform and a small change portfolio, you do not need an enterprise architecture function. You need a competent IT leader, a tidy roadmap and the discipline to say no to duplicate tools. Hiring an architect into that situation creates documentation rather than value.
The signals that you do need one are consistent across the organisations we work with. You are running more than forty or fifty applications and nobody can list them. You operate more than one ERP, or you are about to change the one you have. You are acquiring businesses, or being acquired. You hold regulated data across multiple systems. AI tools are arriving faster than anyone is approving them. Your change portfolio runs to millions of pounds a year and programmes keep colliding with each other. Two or more of those, and the absence of enterprise architecture is already costing more than the function would.
EA fails when it is accountable for everything in general and nothing in particular. It works when it owns a short, explicit list of decisions, agreed with the executive and written into a charter. Seven cover almost every organisation we have worked with.
| Decision | The question it answers | The cost of getting it wrong |
|---|---|---|
| 1. Application portfolio | Which applications we invest in, tolerate, and retire | Duplicated licences, integrations and support, and an estate that only ever grows |
| 2. Integration and APIs | How systems talk to each other, and through what | Point to point spaghetti that makes every future change slower and riskier |
| 3. Cloud and infrastructure | What we build on, and what we are leaving | Workloads scattered across platforms, paying twice and securing everything three ways |
| 4. Data and AI platforms | Where data lives, who may use it, and on which approved platforms AI runs | Ungoverned AI adoption, unanswerable regulatory questions, stalled analytics |
| 5. Security by design | The patterns every solution must follow, agreed with the security team | Security bolted on after build, at ten times the cost and half the effect |
| 6. Vendor and procurement architecture | What we check before we sign, and which duplicates we refuse | Contracts that quietly commit the estate to another decade of sprawl |
| 7. Delivery governance | How designs get reviewed and decisions get recorded, at delivery speed | Architecture that exists on paper while projects build something else |
This is the decision with the fastest money attached. Build one inventory of applications with cost, owner, business value and technical health, then force each application into a quadrant: invest, tolerate, migrate or retire. The retire column is where enterprise architecture pays for itself, and technical debt management stops being an abstraction the moment each debt item has an owner, a cost and a date. Most estates we assess can name retirement candidates within weeks. What they lacked was not analysis but a forum with the authority to decide.
Decisions two to four share one property: they are cheap to make early and brutally expensive to unmake. Pick the integration patterns and name the platforms through which systems connect. Decide what you build on and write down the exit route from what you are leaving. For data and AI, the decision is an operating model: where data of each class may live, which platforms are approved for AI workloads, and who signs off new use. None of this needs a hundred pages. Each needs one page, a named owner and a review date.
Security by design is a joint decision with your security leadership: a small set of patterns every solution follows, so security review confirms rather than discovers. Vendor and procurement architecture puts EA in the room before contracts are signed, with the right to refuse a duplicate. And delivery governance is the decision most guides skip: how architecture lands in projects, which is the subject of the EA governance section below.
The enterprise architecture operating model is the decision CIOs most often get wrong first time, usually by copying whatever their last organisation did. There are four workable shapes, and the right one depends on your size, your delivery model and how much change you are running.
| Operating model | How it works | Fits best | Watch out for |
|---|---|---|---|
| Central team | One team owns all architecture decisions and reviews | Organisations up to mid size with a concentrated change portfolio | Becomes a bottleneck as delivery scales. Risks ivory tower behaviour |
| Federated with a small core | A small central team sets standards. Architects sit inside product or domain teams | Larger organisations with product operating models | Standards drift unless the core runs a real decision forum |
| Centre of excellence | A central capability that coaches, sets method and lends architects to programmes | Organisations building architecture maturity from a low base | Can become advisory only, with no decisions owned |
| EA as a service | An external senior team runs the function to an agreed charter and cadence | Organisations that need the capability now and cannot justify or find permanent hires | Must be anchored to a charter and named internal sponsor, or it floats |
Whichever shape you choose, one artefact anchors it: a business capability map. It is a one page picture of what the organisation does, against which every application and every investment can be placed. It is how you spot three systems serving one capability, and how you explain the estate to a board in language they already speak.
Most guides go vague here, because the firms writing them bill by the day and would rather you did not do the arithmetic. Here is the arithmetic. The figures for our own services are published prices. The market figures are typical UK ranges and worth checking against current advertisements in your sector.
| Option | Typical annual cost | What you get | Fits best when |
|---|---|---|---|
| One senior hire | Senior enterprise architects in the UK are commonly advertised between £90,000 and £130,000. With employer costs and tooling, £110,000 to £160,000 a year. A head of architecture commonly £130,000 to £180,000 | One person, one set of strengths, a three to six month search, and a single point of failure who may leave | You have sustained change demand and a bench of engineers for them to work with |
| Internal team of three | £350,000 or more a year, fully loaded | Coverage across domains, resilience, and a capability that compounds, if you can hire and keep them | Revenue above roughly £500M or a change portfolio that never sleeps |
| Big firm consultancy | Commonly £1,200 to £2,000 or more per consultant per day. An operating model engagement commonly £95,000 to £220,000 | Credible method and manpower, for as long as you keep paying. Knowledge tends to leave with the team | A defined, deadline driven programme where speed matters more than retention |
| EA as a service (Intelance) | From £6,500 + VAT per month, published | A senior architecture function on an agreed charter and cadence, without recruitment risk, with everything documented in your estate | Revenue roughly £50M to £500M without a head of architecture, or while you build the internal team |
Two caveats. First, EA as a service is our own offer, so weigh our view accordingly. The reason we publish the price is so you can do this comparison without talking to us. Second, these options combine well: many organisations run a small internal core and buy specialist depth for cloud, ERP or data programmes when they need it.
If you want a grounded starting point rather than a structural decision, an assessment is the cheaper first move: our EA QuickScan is from £18,000 + VAT, fixed, and produces the portfolio view and decision list this guide keeps referring to.
Fewer than the market wants to sell you. Architecture headcount should follow the change portfolio rather than the org chart, and these rules of thumb hold up well in practice.
| Organisation | Typical need | Shape |
|---|---|---|
| Under £50M revenue | A fractional or part time architect | One senior person, days per week, plus clear standards |
| £50M to £250M | One to two architects, or EA as a service | A generalist enterprise architect plus solution depth bought when needed |
| £250M to £1B | Three to six | Small central core, architects aligned to major domains or programmes |
| Above £1B | Six to fifteen or more | Federated model with a strong core and domain architects in the business |
Adjust for intensity rather than vanity: an organisation mid way through an ERP replacement needs more architecture than a stable one twice its size. And a small number of senior people beats a large number of junior ones every time, because the job is judgement.
EA governance has a bad name because most of it is designed to be routed around: monthly boards, forty page templates, and approval steps that arrive after the decision was really made. Governance that works has three properties: it is fast, it writes decisions down, and it has a legal exit.
Fast. One design forum, weekly, forty five minutes, with the authority to decide. If a decision can be made asynchronously in a day, it should be. The moment governance is slower than delivery, delivery will go around it, and it should.
Written down. Every significant decision becomes a one page architecture decision record: what we decided, why, what we rejected, who decided, when it expires. A year of ADRs is worth more than any framework repository, because it is the organisation’s actual memory.
A legal exit. There must be an exception route: time boxed, costed, signed by someone accountable, with an expiry date. Exceptions without expiry dates are just permanent decisions made quietly. When people can get a fast yes-with-conditions, they stop lying to the process.
The rule for enterprise architecture metrics: measure decisions and money, never artefacts. Diagrams produced, models completed and maturity scores are activity dressed up as progress, and boards can smell it. Report a small set of numbers with evidence behind each one.
| What to report | The evidence behind it | How often |
|---|---|---|
| Applications retired against applications added | The portfolio inventory, with decommission dates and saved run cost | Quarterly |
| Spend on duplicated capability | Capability map with overlapping systems costed | Quarterly |
| Change spend reviewed before build | Design forum log against the change portfolio | Monthly |
| Time from request to architecture decision | Timestamps in the decision log | Monthly |
| Technical debt: items closed, added, and total carrying cost | The debt register, each item owned and costed | Quarterly |
| Incidents and audit findings tied to known architecture risks | Incident records mapped to the risk and debt registers | Quarterly |
Notice what that list does: it converts enterprise architecture from a cost centre explaining itself into a function reporting money found, risk retired and delivery unblocked. That is a conversation a board will fund.
The ivory tower. The team produces target states and reference models while delivery teams build what they were going to build anyway. The tell is beautiful documents and zero decisions anyone can point to. The fix is the charter: give the function decisions to own, then hold it to them.
Buying a tool before the operating model. An EA repository is bought, populated for three months, then quietly abandoned, because a tool cannot answer the question nobody has settled: who decides what. Choose the operating model and the decisions first. Buy the tool when there are decisions worth recording. When you get there, choose it deliberately: our EA tool selection service is priced and scoped for exactly that moment.
Governance theatre. Boards that meet monthly to note decisions made weeks earlier, templates measured by weight, and review steps that exist so a process document can say they do. Theatre is worse than nothing, because it teaches the organisation that architecture is a formality. Governance earns its place only by being faster than the alternative and by changing outcomes.
Perfection before usefulness. Six months spent perfecting a current state model is six months in which every real decision was made without you. Ship the eighty percent view in weeks and improve it while it is being used. The estate does not hold still, and neither should the model.
Architecture without a business question. If the work cannot name the business decision it serves, it is a hobby. Every piece of architecture work should trace to a live question: this acquisition, this ERP choice, this cost line, this risk. That traceability is also, by no coincidence, exactly what makes EA measurable.
Policing instead of enabling. A function known mainly for saying no will be excluded from the conversations that matter, and the estate will be shaped by whoever stopped inviting you. The posture that works is a fast yes-with-conditions, a clear exception route, and architects who make delivery teams faster rather than slower.
Asked how to start EA, most frameworks answer with a method adoption programme. Do not start there. Start with the estate you have and the decisions already in flight.
Days 1 to 30: see. Build the first application inventory, top fifty applications with cost, owner and health, version one of the capability map, and a list of every significant technology decision currently being made anywhere in the organisation. That last list is usually the most alarming artefact a new architecture function produces.
Days 31 to 60: decide how you decide. Get the one page charter signed by the executive rather than just the CIO. Stand up the weekly design forum and record the first architecture decision records. Take the two or three in flight decisions from the first month through the forum, visibly and quickly, so the organisation sees what the function is for.
Days 61 to 90: prove it in money. Take the first retirement decisions to the portfolio forum. Present the capability map and the duplicated spend it exposes to the executive. Baseline the metrics from the table above so that every future quarter has something solid to report against.
After ninety days you will not have a mature function. You will have something better: an organisation that has watched architecture make three real decisions, retire real cost and unblock real delivery. Maturity is what happens if you keep doing that.
This is the most requested artefact we produce, so here it is in full. Replace the bracketed text, argue about section two properly, and have it signed by the executive team. If a decision is not on this page, architecture does not own it, and that constraint is what makes the page powerful.
1. Purpose. The architecture function exists to make [organisation]’s technology estate cheaper to run, safer to operate and faster to change, by owning a defined set of decisions and being measured on their outcomes.
2. Decisions architecture owns. Application portfolio (invest, tolerate, migrate, retire). Integration patterns and platforms. Cloud and infrastructure standards. Data and AI platform approval. Security by design patterns, jointly with [security leadership]. Technology selection in procurement above [£threshold]. Design approval for change above [£threshold or risk class].
3. Decisions architecture informs but does not own. Business strategy and priorities. Programme funding and sequencing. Vendor commercial terms. Team structures and hiring.
4. When architecture must be in the room. Any procurement above [threshold]. Any new system of record. Any acquisition or divestment. Any new AI use of [data classes]. Any exception to section 2 decisions.
5. The forum. A weekly design authority of [named members], forty five minutes, quorum [n], with authority to decide. Decisions recorded as one page architecture decision records within [48 hours], in [location].
6. Exceptions. Any team may request an exception. Exceptions are time boxed, costed, owned by a named accountable person, and expire on a stated date. Expired exceptions return to the forum.
7. Proof of value. Architecture reports quarterly, in money: applications retired against added, duplicated spend removed, change spend reviewed before build, decision turnaround time, and technical debt movement.
8. Sponsorship and review. Sponsored by [executive]. This charter is reviewed every [12 months] and survives changes of personnel, including the CIO who signed it.
We run architecture functions and fix broken ones, at published fixed prices. The EA QuickScan produces the portfolio view, risk list and decision list in ten days. The EA operating model and governance service designs and installs the charter, forum and cadence described in this guide. The Virtual EA Department runs the function for you as a service. For programmes, ProjectEA puts senior architects inside your transformation, and dedicated services cover cloud and ERP and data and AI platforms. Every price is on the page, which is also how you know this guide was not written to start a discovery call.
Enterprise architecture is the discipline of making technology decisions deliberately across a whole organisation instead of one project at a time: which applications to keep, how systems connect, where data lives, what to build on and what to retire.
Seven cover most organisations: application portfolio, integration and APIs, cloud and infrastructure, data and AI platforms, security by design patterns, technology selection in procurement, and design governance for significant change. Write them into a one page charter signed by the executive.
Usually not as a function. Below roughly forty applications and a modest change portfolio, a competent IT leader with a tidy roadmap does the job. The need starts when applications multiply, ERPs change, acquisitions happen or AI adoption outruns approval.
Above roughly £500M revenue with continuous change, build a small internal team and buy specialist depth. Between roughly £50M and £500M, EA as a service or a hybrid usually delivers a senior function faster and at lower cost than a single hire, without recruitment risk.
A senior enterprise architect is commonly advertised between £90,000 and £130,000 a year, a three person team £350,000 or more fully loaded, and big firm engagements commonly run £95,000 to £220,000. Intelance publishes its prices: EA as a service from £6,500 + VAT per month, and a fixed price EA QuickScan from £18,000 + VAT.
Follow the change portfolio rather than the org chart: a fractional architect below £50M revenue, one to two architects or a service between £50M and £250M, three to six up to £1B, and a federated model above that. Senior judgement beats headcount.
In money and decisions, never artefacts: applications retired against added, duplicated spend removed, change spend reviewed before build, decision turnaround time, technical debt movement, and incidents tied to known architecture risks.
Eight sections on one page: purpose, decisions owned, decisions informed, when architecture must be in the room, the decision forum, the exception route, how value is proved, and executive sponsorship with a review date.
Days 1 to 30: inventory the top fifty applications, draft the capability map, and list every technology decision in flight. Days 31 to 60: sign the charter, stand up a weekly design forum, record the first decisions. Days 61 to 90: take the first retirement decisions and baseline the metrics.
Written by Emmanuel Olatunji, Chief Enterprise Architecture Partner at Intelance. TOGAF 9 and 10 certified. Last reviewed 8 July 2026.
Emmanuel Olatunji
Chief Enterprise Architecture Partner
Emmanuel founded Intelance in 2017 and has led architecture, AI governance, cyber and deal engagements across the UK, Europe, the Middle East and Africa. Every Intelance engagement runs under his direction, and every guide he publishes comes from that work.
See his record on LinkedIn About IntelanceThirty minutes with the architect who wrote this guide. A clear recommendation and a fixed fee in writing, within one UK business day.
Talk to a senior adviser
Enterprise Architecture
