All services Every engagement has a fixed, published price. Book a strategy call
The six deliverables a good enterprise architecture engagement produces, how to test each one, the artefacts that go unused, what to ask before signing and how to judge it ninety days later.
Most enterprise architecture engagements are bought on trust and judged on paperwork. A firm arrives, runs interviews, produces a substantial document, presents it well and leaves. Six months later the estate looks the same, the decisions that prompted the engagement are still open, and nobody can point to what changed.
That outcome is avoidable, and the way to avoid it is to be specific about the deliverables before the work starts. Enterprise architecture has a well documented body of method behind it, so the argument is rarely about approach. It is about whether what you receive can be used by the people who have to decide things.
This guide sets out what a good engagement produces, how to test each deliverable rather than admire it, the artefacts that reliably go unused, what the working weeks should look like from the inside, the questions to ask before signing and while the work runs, and how to judge ninety days later whether the money did anything. Every fee named here is published on our own service pages.
The short answer. A good enterprise architecture engagement delivers six things: a decision record, a baseline scoped only to the decisions in hand, a target architecture with its constraints written down, a sequenced roadmap with decision points, principles that reject options, and a governance route a delivery lead can follow on day one. Test each one rather than accept it. Ask which decisions the engagement will make and which it will only inform, who works on it by name, what you own at the end and in what format, and what the firm sells besides advice. Insist on a written read back every second week rather than one reveal at the end. Our published floors run from £18,000 + VAT for a ten day baseline, from £45,000 + VAT for architects inside a live programme and from £6,500 + VAT per month for a fractional department.
The expensive failure is not a bad recommendation. It is an engagement that produces description instead of decisions. Description is comfortable for both sides. The firm can evidence effort by volume, and the client can point to a deliverable. Nothing in it obliges anyone to choose.
You can spot the pattern in the language. Documents that say a capability is fragmented, that integration is point to point, or that data ownership is unclear are describing the weather. Documents that say you should retire these four systems in this order, accept this constraint, and decide the identity platform before the ERP contract is signed are doing architecture.
This is not only a private sector problem. The National Audit Office has examined the barriers to digital change in government more than once, and the recurring themes are familiar to anyone who has watched a transformation stall. Unclear ownership, decisions taken late, and dependencies discovered after commitments were made. Architecture work earns its fee by moving those three things earlier.
Ask for these by name in the statement of work. The third column matters more than the second, because a test you can apply is worth more than a description you can be talked past.
| Deliverable | What it has to contain | The test to apply |
|---|---|---|
| A decision record | Every decision taken during the engagement, the options rejected, the reason, the date and the person accountable | Hand it to somebody who joined last week. They should be able to explain why you chose what you chose without asking anyone |
| A baseline scoped to the decisions | Only the systems, flows, contracts and dependencies that bear on the decisions in hand, at the depth needed to decide | Every diagram should be referenced by at least one decision or risk. A page that supports no decision should not be there |
| A target architecture with its constraints | The shape you are moving to, what it assumes, what it deliberately rules out, and the conditions under which it would change | Take a real solution proposal to it. You should be able to tell from the document alone whether the proposal conforms |
| A sequenced roadmap | The order things must happen in, the dependencies between them, and the decision that must be closed before each step starts | Point to the next three decisions and their dates. If the roadmap is a set of project bars with no decisions on it, it is a plan of activity |
| Principles that reject options | Six to ten statements written tightly enough to stop something specific | For each principle, name a real thing it prevents. A principle that would never block anything can be deleted with no loss |
| The governance route | Who decides what, at which threshold, in which forum, on what evidence, and how long an answer takes | Ask a delivery lead where they would take a design and how long they would wait. If they cannot answer from the document, it is not a route |
Two notes on standards. If the engagement uses TOGAF or notation such as ArchiMate, that is a reasonable choice and it should make the deliverables clearer to read. It is not a deliverable in itself. If you are a UK public body, the Technology Code of Practice already sets expectations your architecture work should answer directly, and a firm that has not read it will produce material your own assurance process rejects.
These are produced in good faith and almost never opened again. Each one has a cheaper substitute that gets used, so ask for the substitute instead.
Buyers are usually shown a methodology diagram and then nothing until the final presentation. That gap is where engagements go wrong quietly. Here is the shape of a ten working day baseline, which is the length we run, with the point at which you should intervene if it is not happening.
| When | What should be happening | Say something if |
|---|---|---|
| Days one and two | The decisions in scope are written down and agreed with you in one page | Nobody has written the list of decisions. Everything downstream inherits this gap |
| Days three to five | Evidence gathering across systems, contracts, interfaces, data flows and the people who run them | You are only being interviewed. Architecture that never looks at a contract or a schema is opinion |
| Days six and seven | A first honest read back, including the findings you will not enjoy, while there is still time to act | All bad news is being held for the final report. A firm doing that is managing you rather than advising you |
| Days eight and nine | Options with costs, consequences and the rejected alternatives shown alongside | One option arrives with no alternatives. A single option is a preference presented as analysis |
| Day ten | Handover of the six deliverables in editable form, in your own tooling | Anything is delivered as a locked file or held in the firm’s own platform |
Longer engagements follow the same rhythm on a fortnightly cycle. The part worth writing into the contract is the read back. A short written update every second week, including what has changed in the firm’s view, prevents the single most common commercial argument in advisory work, which is a disagreement at the end about what was agreed in the middle.
These are the ones almost nobody asks, and they are the cheapest quality control available.
Two commercial models dominate. Day rates transfer scope risk to you, because the total depends on a day count that grows with every extra workshop. Fixed fees transfer that risk to the firm, which is why a firm quoting one will insist on scoping first. For architecture work with named deliverables, fixed fee is almost always the better purchase, and it forces both sides to agree what good looks like before the money starts.
| What you are buying | Shape of the engagement | Our published floor |
|---|---|---|
| A baseline and the decisions it unlocks | Ten working days, senior led, ending in the six deliverables | EA QuickScan from £18,000 + VAT |
| Architecture inside a live programme | Architects embedded through delivery, making decisions as they arise | ProjectEA from £45,000 + VAT, with ERP scale programmes from £120,000 |
| A standing capability without a permanent hire | A named senior lead and bench, eight senior days a month upwards, rolling monthly | Virtual EA Department from £6,500 + VAT per month |
| The operating model and governance route | Diagnostic in three to four weeks, then a build scoped from what it finds | Operating model diagnostic from £18,000 + VAT, full build from £95,000 + VAT |
| Tooling and a repository people use | Selection against written requirements, then design and implementation with owners trained | Tool selection from £12,500 + VAT, repository build from £28,000 + VAT |
| Architecture for a cloud or ERP move | A baseline before the business case, then architects through the programme | EA for cloud and ERP from £18,000 + VAT |
| Architecture for a data or AI platform | Twin baselines covering the systems and the data reality behind them | EA for data and AI platforms from £14,500 + VAT |
| An independent opinion on architecture already done | A review of somebody else’s work, addressed to the board or the sponsor | Independent technology audit from £8,500 + VAT |
Our guide to enterprise architecture consulting cost in the UK explains what moves each figure above its floor. If the prior question is whether you need this capability at all, the sizing guide answers it honestly, including the cases where the answer is no.
Agree these tests before the engagement starts and put the date in the diary. Judging the work by whether the final presentation was impressive is how organisations buy the same engagement twice.
Where governance is the weak point rather than the architecture itself, the operating models guide covers centralised, federated and hybrid designs and what each one costs to run. Frameworks such as COBIT can help set the decision rights, and if you report into a formal assurance regime the published delivery confidence assessments for UK major projects show the level of scrutiny large programmes attract.
We are a specialist advisory and assurance firm. Enterprise architecture sits alongside cyber assurance, ISO certification support, data governance and AI governance, which matters because architecture decisions usually fail at the joins with those disciplines rather than in the modelling.
What we do. We produce a baseline and the six deliverables in ten working days, embed senior architects inside live programmes, run a fractional department where a permanent hire is not the right answer, design operating models and governance routes, select tooling, and independently review architecture produced by other firms. Fees are published as floors and fixed in writing before work starts. The people who sell the work deliver it.
What we do not do. We sell no software licences and take no vendor commissions, which is why a tool selection can honestly end in a recommendation to buy nothing. We do not review architecture we produced ourselves, so where we did the work the review goes to another firm. We are not a systems integrator, so we will not build what we specified. If you need hands on build capacity or a delivery squad, we are the wrong firm and will say so on the first call.
A first engagement usually starts with the baseline, because it is short, fixed and it prices everything that follows. If you would rather talk it through first, the enterprise architecture practice page lists every service with its fee, and you can speak to a senior architect directly. For background, our practical guide for CIOs and the plain explanation of what enterprise architecture is cover the ground beneath this article, and the ERP selection questions show what these deliverables look like applied to one decision.
Six things: a decision record showing what was decided and what was rejected, a baseline scoped only to the decisions in hand, a target architecture with its constraints and assumptions written down, a sequenced roadmap with the decision points marked, six to ten principles tight enough to reject real options, and a governance route a delivery lead can follow on day one. Everything else is supporting material. If a deliverable does not support a decision, it will not be opened again.
With Intelance a ten working day baseline runs from £18,000 + VAT, architects inside a live programme from £45,000 + VAT with ERP scale programmes from £120,000, a fractional department from £6,500 + VAT per month, an operating model diagnostic from £18,000 + VAT with a full build from £95,000 + VAT, tool selection from £12,500 + VAT and an independent review from £8,500 + VAT. All are floors, fixed in writing after scoping. Day rate engagements are common in this market and typically run from £1,200 to £2,500 per day, which makes the final total hard to predict.
Short. Ten working days is enough to establish the estate position, the decisions in scope and a defensible sequence, and it prices any larger programme accurately. Long first engagements tend to produce description because the scope was never forced to narrow. If a firm proposes three months before any decision is made, ask what decision the first two weeks will close.
An architecture consultancy decides what should be built and in what order. An integrator builds it. The two can work well together and the roles should sit with different organisations, because a firm that specifies work it will later win has an interest in the specification. Ask any prospective partner whether it also bids for the build, and treat the answer as a scope question rather than a criticism.
Ask for a written read back every second week, including what has changed in the firm’s view. Ask which decision each deliverable supports as it arrives. At the halfway point, expect the firm’s position to have moved in at least one respect, because evidence should change a view. A firm that holds every finding until the final presentation is managing the relationship rather than advising you.
You need decisions, ownership and a sequence. TOGAF is a well established method for producing those and a competent firm will know it, but the framework is a means. Ask which parts of it the engagement will use and which it will skip, and expect a straight answer. A firm that populates every artefact the method allows in order to prove thoroughness is producing volume, and volume is what goes unread.
A named person inside your organisation, with hours in the diary and the authority to say no. That can be a permanent head of architecture, a senior technologist holding the role part time, or a fractional arrangement where the market is tight. What does not work is assigning ownership to a committee or to whoever seemed most willing at the end of the engagement.
No, and it is reasonable to ask the question at the start rather than a year later. Producing and independently reviewing the same work require different positions. Intelance does both kinds of work and where we produced the architecture the review goes to another firm. Boards and audit committees apply this test routinely to financial work and increasingly to technology decisions of the same value.
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
