Someone has told you that you need an enterprise architect. Maybe a consultancy said it in a proposal, maybe a board member repeated it after a conference. Before you open a requisition or sign a statement of work, it is worth asking a blunter question: does your estate actually need dedicated architecture capacity, or does it need a senior engineer with time protected to think? Those are different problems with very different price tags. I have spent 22 years on both sides of that line, and most of the time the honest answer is not the one that generates an invoice.
When architecture is a part-time responsibility
Enterprise architecture is not a job title, it is a set of decisions: how systems fit together, which one owns which piece of data, what you standardise on, and what you deliberately do not. Every organisation makes those decisions whether or not anyone is paid to. The question is only whether the volume and consequence of the decisions justify a person whose entire week is spent on them.
Below a certain scale, they do not. If you run roughly a dozen or fewer significant systems, your integration count is in single digits, and your rate of change is one or two meaningful projects a year, architecture is a part-time responsibility of a senior IT lead or a hands-on solutions engineer. What that person needs is not a new colleague, it is protected time, a decision log, and the authority to say no. Hiring a dedicated architect into an estate that small tends to produce documentation nobody reads and a governance forum that slows delivery without improving it.
The insight most vendors skip
The demand for architecture is driven by change rate and coupling, not by company size or revenue. A 400-person firm mid-merger with fifteen integrations needs architecture badly. A 4,000-person firm running six stable systems it has owned for a decade may not need a dedicated architect at all. Size the role to the decisions, not to the org chart.
So the first test is subtraction, not addition. Look at your last two years of project pain. If the failures trace to weak project management, unclear requirements, or under-resourced delivery teams, an architect will not fix them and may distract from the real gap. If the failures trace to design (systems that could not talk to each other, data that meant different things in different places, a platform choice that boxed you in) then you have an architecture problem, and the rest of this article is for you.
The six triggers that justify a dedicated role
Rather than a fuzzy "you are getting bigger", here are six concrete conditions. If none of these is true, hold off. If one is true, consider fractional capacity. If two or more are true at once, a dedicated architect is likely to pay for itself.
| Trigger | What it looks like | Why it needs architecture |
|---|---|---|
| Multi-system programme | Three or more systems being replaced or introduced in one coordinated programme. | Someone has to own the target state and the sequencing, or each workstream optimises locally and the seams fail. |
| Merger or acquisition | Two estates to rationalise: duplicate ERPs, overlapping CRMs, two ways of doing everything. | Rationalisation is an architecture decision at every step. Get it wrong and you carry double cost for years. |
| Integration count over ten | More than ten live point-to-point integrations, growing without a pattern. | Past roughly ten, ad hoc connections become a maintenance tax. You need integration patterns and ownership. |
| Cloud migration | Moving core workloads off on-premise, or re-platforming a monolith. | Landing zones, identity, data residency and cost models are design choices that are painful to reverse. |
| Regulatory data obligation | A new duty on data residency, retention, lineage, privacy or auditability. | Compliance is structural. It has to be designed into where data lives and flows, not bolted on afterwards. |
| Repeated design failures | Two or more recent projects that failed or overran, traced back to design, not delivery. | A pattern of design-caused failure is the clearest signal that decisions are being made with nobody accountable for the whole. |
Notice what is not on this list: "we are doing digital transformation" and "the board wants innovation". Those are ambitions, not triggers. If you want the fuller version of what a transformation effort should actually deliver, I wrote it up separately in what a digital transformation consultancy should do.
Three ways to source the role
Say you have crossed the line and you need architecture capacity. You have three realistic options, and they trade off against each other on cost, continuity, independence and speed to value. Treat the numbers below as indicative and dated (mid-2020s, Gulf and UK blended rates). They move with market and geography, so use them to compare options, not to budget.
| Dimension | Permanent hire | Fractional external architect | A firm's practice |
|---|---|---|---|
| Indicative day rate | n/a (salaried) | Approx. 900 to 1,800 USD/day | Approx. 1,800 to 3,500+ USD/day |
| Indicative annual cost | Approx. 120k to 220k USD fully loaded | Approx. 60k to 150k USD (1 to 2 days/week) | Approx. 250k to 600k+ USD for a sustained engagement |
| Continuity | Highest. Retains context, lives with decisions. | Good, if you retain the same person on a rolling basis. | Weakest. Teams rotate, knowledge leaves with them. |
| Independence | High on vendors, but can go native over time. | Highest, if they sell no software and no downstream build. | Lowest where the firm also resells platforms or staffs the delivery. |
| Speed to value | Slowest. Recruit, notice period, ramp: three to six months. | Fastest. Experienced hands, productive in weeks. | Fast to mobilise, slower to deliver value through process overhead. |
| Best when | The change is permanent and the estate keeps growing. | You need senior judgement now, on one or two triggers, not forever. | You need scale and a brand name on the programme for board comfort. |
My honest read: most mid-sized operators are best served by a fractional architect for the first year, then a permanent hire once the shape of the estate and the workload is clear. You get senior judgement fast, you avoid a mis-hire into a role you have not yet scoped, and you learn what the permanent job actually is before you write the job description. A firm's practice earns its premium on genuinely large, multi-year programmes where you need bench depth and are willing to pay for the coordination overhead. Watch the independence column closely: an architect who is paid by the same firm that will later sell you the platform is being asked to mark their own homework. The detail on why that coupling matters is in my enterprise system integrations guide.
Warning signs of the wrong hire
Once you are interviewing, the failure mode is subtle. A weak architect can sound extremely impressive, because the vocabulary of the discipline is easy to perform and hard to check. Here is what I listen for.
The caution: frameworks are not decisions
- Talks in frameworks, not decisions. If every answer routes through TOGAF phases, capability maps and reference models but never lands on "here is what I would decide and why", you are hiring a narrator, not an architect. Frameworks are scaffolding. The job is the call you make.
- No delivery scars. Ask what they shipped, what broke, and what they would do differently. An architect who has never been on call at 2am for a design they signed off has never had their diagrams tested by reality.
- No opinion on your contentious choices. Every estate has two or three genuinely arguable decisions: build versus buy on a key capability, one platform versus best-of-breed, a data hub versus point-to-point. A good architect will have a view within the first hour and will defend it. "It depends" with no follow-through is a tell.
- Cannot say no to a stakeholder. Architecture is mostly saying no to good-sounding ideas that do not fit. If they cannot describe a time they blocked something senior leadership wanted, they will not do it for you either.
The single best interview question I know is: "Tell me about a design decision you got wrong." A strong candidate answers immediately, specifically, and without defensiveness. A weak one cannot think of one, which means they either have not made enough real decisions or cannot see their own failures. Both are disqualifying.
The first ninety days
Whether you hire permanently or bring someone in fractionally, hold them to output, not activity. A good architect produces artefacts you can act on quickly, not a strategy deck at month six. Here is the checklist I would hand a new architect on day one and hold them to at day ninety.
- A current-state map. Every significant system, who owns it, what data it masters, and how it connects to the others. On one page. If it takes twenty, it is not a map, it is inventory.
- A ranked list of the top risks in the estate. The three to five design problems most likely to cause the next failure, with a plain-language explanation of the impact.
- A target-state direction, not a finished blueprint. Where the estate should head over 18 to 24 months, expressed as principles and a few firm decisions, deliberately not a fully detailed end-state nobody can commit to yet.
- A decision log, started and populated. The contentious calls, the option chosen, the reasoning, and who signed off. This is the single most valuable thing an architect leaves behind.
- A view on one live project. Concrete, specific input into something already in flight, so the role earns credibility with delivery teams instead of sitting apart from them.
- A lightweight governance model. How architecture decisions will get made from now on, sized to your pace, that speeds good decisions rather than adding a committee.
If ninety days pass and what you have is a maturity assessment and a roadmap slide, you hired the wrong person or scoped the role wrong. If you have a one-page map, a risk list, a decision log and a delivery team that is already asking their opinion, you hired well. The same short-horizon discipline matters when the estate is asset-heavy and the core system is the ERP, which I cover in ERP selection for asset-heavy operators.
A note on independence
Disclaimer: I provide independent architecture and integration advisory and I do not resell software licences or take vendor commissions. That shapes the guidance above, including the honest admission that many organisations do not yet need a dedicated architect. Read any sizing advice, mine included, against what the adviser sells. If the recommendation always lands on "you need more of the thing I provide", weigh it accordingly.
If you want to go deeper on the discipline itself, the two canonical references are worth a look: The Open Group TOGAF standard for the framework, and the Gartner IT glossary for how the terms are defined in the market. Use them as vocabulary, not as a substitute for judgement.
Conclusion
Hire an enterprise architect when the decisions in your estate outgrow the time a senior lead can give them, and not before. Test for it with the six triggers, size the sourcing to the workload rather than defaulting to a permanent hire or a big firm, screen hard for decisions over frameworks and scars over vocabulary, and hold whoever you bring in to a ninety-day checklist of things you can actually use. Do that and the role pays for itself. Skip it and you will pay either way: in a mis-hire you did not need, or in the design failures you keep having because nobody owns the whole.
Written by Muhammad Abbas
CMMS / CAFM Manager & Enterprise Integration Specialist · 22+ years across ERP, EAM, CAFM and enterprise integration.
Work with me