If you’ve never engaged a technology architect before, it’s a fair question what one even does. The role gets talked about in vague terms, the deliverables can be hard to picture in advance, and the price tag rarely arrives with a clear “and here’s what you’ll have in your hands at the end.”
This page is here to answer the common questions, plainly.
What does a technology architect actually do?
An architect shapes the what and the how of a technology change before delivery starts, then stays close to delivery so the design holds up under real-world pressure.
In practice that means: understanding the business outcome, mapping the current technology landscape honestly, working out the sequence of decisions that gets you from here to there, writing those decisions down with the reasoning intact, and being available when the build team hits a question that needs an answer with context.
It’s a design-and-guidance role. The job is to decide how the thing should be built and to steer the people building it — not to run the build, and not to fix what’s already there.
How is this different from a project manager or a “consultant”?
A project manager owns the schedule, the budget, and the day-to-day delivery — who’s doing what, by when. An architect owns the design and the decisions — what we’re building, and why this way rather than another. The two roles work side by side on a healthy project.
“Consultant” covers a lot of ground. Many consultancies deliver advice and leave. An architect makes design decisions and stays close to them through the build, so the design survives the pressure of real-world delivery. The proof of the work isn’t the recommendation — it’s the system that ends up being built behind it.
Why hire one part-time rather than full-time?
Most medium-sized businesses don’t have enough architectural decisions in flight to justify a full-time hire. A senior architect on a permanent payroll spends a lot of their week looking for work to do, or quietly drifting into project-manager territory because that’s what’s in front of them.
A couple of days a week of senior architectural attention, focused on the decisions that actually matter, tends to deliver more value than five days a week of someone stretching to fill the role.
The other angle: an independent architect carries pattern recognition from many different organisations and industries. A full-time hire eventually only knows your environment. Both have value — the part-time arrangement keeps the cross-pollination flowing.
What actually happens in the first few weeks?
Three things, usually in parallel:
- Listening. Conversations with the people who depend on the technology — both the ones who run it and the ones who use it. The aim is to understand the business and where it’s heading before passing judgement on the tech.
- Reading. Existing documentation, vendor contracts, prior decisions, recent project post-mortems if any exist. The history matters more than people expect.
- Mapping. Building an honest current-state picture — platforms, integrations, capability levels, and where the real risks sit.
Decisions and recommendations come after this. Jumping straight to recommendations is how consultancies generate slide decks; it isn’t how an architect earns their fee.
Who in the business does the architect talk to?
Whoever knows the answer to the question being asked. In practice that’s a wide net: the executive sponsor, the people running each technology platform, the heads of the business functions that depend on those platforms, a sample of end users, and any incumbent vendors who hold material context.
A real part of the job is to connect those conversations. The gap between “what the business wants” and “what the tech is actually doing” is often where the most valuable findings sit.
What will I be asked to do as the sponsor?
Three things, mostly:
- Open doors. A short note from the sponsor saying “this person is doing X, please be candid with them” saves weeks of polite hedging.
- Make the calls that only you can make. When the work surfaces a decision that needs executive weight, the architect’s job is to lay it out clearly; yours is to choose.
- Push back. If something in a draft doesn’t match the reality you’re seeing, say so. The architect is working from a partial view at first — your corrections sharpen the output.
Day-to-day involvement is usually a short weekly check-in plus ad-hoc availability for the calls in point two.
What do I get at the end — and where does it live?
Documents your team can actually use. A current-state read, a roadmap, the decision records behind the choices, a governance framework if one was needed, the evidence trail behind any major platform decision. Specific to the engagement.
The output is not a slide deck. Slides are a summary medium, not a working medium. Where a presentation is needed for an executive audience, it’s grounded in the same underlying material — business requirements, current-state evidence, decision trails — not in standalone talking points that float free of the work.
Just as importantly, the artefacts live in your document store or repository — Confluence, SharePoint, GitHub, whatever your organisation already uses. They belong to you from the day they’re written. There is no parallel system to log into, no proprietary tool you need a licence for, no extraction project when the engagement ends.
Will you tell me to buy stuff I don’t need?
No, and based on experience the opposite is often the outcome with examples such as:
- “You’ve already got something that does this — let’s use it better before adding another tool.”
- “This decision can wait twelve months. Here’s what to monitor in the meantime.”
- “The right answer is to do nothing yet, and re-examine when X changes.”
When a new platform genuinely is the right answer, the recommendation comes with a decision trail — requirements, options considered, trade-offs, why this one — so it survives a CFO question or a board challenge years later.
How is this priced, and how do I know it’s working?
Engagements are scoped against deliverables wherever possible — a current-state document, a roadmap, a platform recommendation paper — with a day-rate inside a clear time envelope. You’re paying for an artefact and the thinking behind it, not for hours of presence.
The check-in cadence (usually weekly) is where you see the work taking shape. If at any point you can’t articulate what’s been produced since the last check-in, the engagement isn’t working — and that’s a fair conversation to have on the spot.
What happens after the engagement ends?
Three things tend to play out, in some mix:
- Your team owns the work immediately. Because the artefacts live in your systems and the decisions are recorded in your repository, your internal team picks up where I left off without an extraction project. There’s no “licence expiring” moment, no handover phase you’re paying for.
- The practice keeps running. If part of the engagement was setting up an architecture practice, the templates and governance rhythm are designed to run without me. The next decision record, the next platform call, the next checkpoint — your team has the patterns to handle them.
- Periodic check-ins, if useful. A common arrangement is a half-day review every quarter to see how reality has landed against the roadmap, and what to adjust. No retainer, no minimum commitment — booked when there’s a reason for it.
The other common reason to come back is a new major decision — a replatform, a vendor selection, a post-merger integration — where the business wants the architect who set up the patterns to apply them again. By choice, not by lock-in.
Why an independent architect rather than a Big-4 consultancy or vendor?
Three reasons, depending on what you value.
- Direct line, no overhead. With an independent, the person you brief is the person doing the work. No partner-and-team model, no junior consultants doing the reading and senior consultants doing the talking. The thinking and the writing come from one head.
- Skin in the game on the recommendation, not the implementation. Vendors and large consultancies often have a downstream commercial interest in what gets recommended — they sell the implementation that follows. An independent architect’s product is the recommendation; there’s nothing else to upsell.
- A cost structure that fits a medium-sized business. Big-4 engagement minimums are written for organisations with budgets to match. A part-time independent fits the cadence and the chequebook of a mid-sized business more naturally.
That said — Big-4 is the right tool for some jobs (very large transformations, very heavy compliance frameworks). The real question is which tool fits the job in front of you, not which is “better” in the abstract.
If a question came to mind while reading this that isn’t here, drop me an email — odds are it’s worth adding.