Services

The six services below cover the typical shape of an architecture engagement — from an initial read of where you are, through to staying with the delivery team until the thing is built. Most engagements pick two or three; some run all six end-to-end.

Current-state analysis

An honest read on where your technology and capabilities stand today — what’s working, what’s creaking, and where the real gaps are.

When it helps. You’ve inherited a landscape you didn’t build, or enough time has passed that nobody has the full picture anymore. Decisions are being made on out-of-date assumptions, and you need a baseline before anything else moves.

What you get. A current-state document covering platforms, integrations, capability levels and key risks, plus a shortlist of the gaps most worth addressing. Written for the CIO, readable by the executive team.

Typical shape. Two to four weeks, depending on environment size. Mostly stakeholder interviews, artefact review, and a workshop or two to validate findings.

Technology roadmaps

A sequenced plan of technology decisions and investments that moves your organisation from where it is to where it needs to be — with enough detail that the next 6–12 months is clear, and the following 12–18 months is directionally honest.

When it helps. You’ve got a rough sense of where the business is heading, but the path to get there in technology terms is a fog. New platforms, replatforms, capability uplifts, integration work — it’s hard to know what comes first, what depends on what, and where the budget should land.

What you get. A roadmap document pitched at both executive and technical audiences. Sequenced initiatives, dependencies surfaced, rough sizing and cost indicators, and a one-page summary for the board pack.

Typical shape. Four to six weeks, running in parallel with your day-to-day. Starts with stakeholder conversations and a current-state read, finishes with a working session to walk the executive team through the recommended path.

Platform selection

Guided vendor evaluation for a significant platform decision — CRM, CMS, data platform, integration layer, identity, and so on. Covers technical fit, commercial viability, implementation risk, and the decision trail to back up the recommendation.

When it helps. You’ve narrowed the problem to “we need a platform for X,” the vendor shortlist is forming, and you need an experienced pair of eyes to challenge assumptions, run the technical evaluation, and land a defensible recommendation. Particularly useful when the outcome needs to survive CFO, board, or audit scrutiny.

What you get. Requirements framing, vendor shortlist with scored evaluation, technical deep-dives and POC oversight where warranted, and a recommendation paper with the decision trail intact.

Typical shape. Six to twelve weeks, depending on vendor count and complexity. Usually overlaps with an internal selection committee.

Governance and decision evidence

The checkpoints, artefacts, and decision records that let the executive team approve technology investments with confidence — and that survive audit, leadership turnover, and the inevitable “why did we do it this way?” question years later.

When it helps. Projects are progressing, but the paper trail behind key decisions is thin. Approvals are happening in conversation rather than in documents, and the organisation doesn’t yet have a consistent way to capture the why behind technical direction.

What you get. A governance framework sized to the business, architecture decision record (ADR) templates, checkpoint patterns for significant changes, and coaching on how to run the practice once it’s in place.

Typical shape. Three to six weeks to set up, then ongoing as a retainer if the practice needs coaching to bed in.

Implementation oversight

Staying with the delivery teams through the build, so the design survives contact with reality. Not project management — architectural guardianship. When the team hits a design question mid-sprint, someone with context is there to answer it.

When it helps. A significant platform or integration build is underway, and the risk is that design intent gets diluted by expedient choices made under delivery pressure. You want a steady architectural hand through the build phase without carrying the overhead of a full-time architect on the project.

What you get. Regular design reviews, architecture guardrails for the delivery team, documented design decisions as they’re made, and honest escalation when a proposed shortcut will cost more later than it saves now.

Typical shape. Part-time involvement for the duration of the build — often a day or two a week, tapering as the team gains autonomy.

Architecture practice setup

Establishing the architecture function in an organisation that doesn’t yet have one, or reshaping a practice that isn’t working. Includes the structure, the artefacts, the governance, and the working rhythm.

When it helps. The business has grown to a size where ad-hoc technical decisions are starting to cost real money, but a full-time head of architecture isn’t yet the right hire. Or there’s an existing practice that’s become overhead-heavy without delivering the judgement it should.

What you get. A practice design — roles, responsibilities, cadences, artefact standards — alongside a governance guide and a roadmap to make the practice sustainable after I step back. Includes knowledge transfer to the internal team who’ll own it going forward.

Typical shape. Usually a three-to-six-month engagement, tapering from hands-on setup to ongoing coaching as the internal team takes ownership.


If any of these look like the help you need, drop me an email .