Architecture Review

What your architecture actually does, in writing, by someone with no implementation work to sell.

You have technology that mostly works. You have a team that mostly knows what is going on inside it. What you do not have — and what you cannot easily get from inside the business — is an independent reading of your architecture, written for the people who have to decide what to do about it.

That is what this engagement is.

€15,000. Three to four weeks. Delivered in writing, with a presentation to whoever needs to hear it.

Fixed fee. No implementation work. No commissions. No product recommendations influenced by suppliers.

Why clients commission a review

A review is usually triggered by a specific moment. Most often, one of these:

• A newly-appointed CTO or IT Director needs to understand what they have inherited.
• The business is preparing for investment, acquisition, or due diligence.
• A major customer is asking questions about technology governance and resilience.
• Technology costs continue to increase without a clear understanding of why.
• The organisation has become dependent on one or two key individuals.
• Leadership suspects there is technical debt but cannot quantify it.
• Multiple systems have been added over time and nobody is confident how they fit together.
• The board wants an independent view before approving further investment in technology.

If one of these is the position you are in, the review is built for it.

Who this is for

Owners, MDs, and CEOs of established businesses — typically 50 to 300 staff, €5m+ revenue — who have a technology function and want an independent view of it.

Newly-appointed CTOs and IT Directors in their first ninety days who need a baseline of what they have inherited before they commit to a plan.

Boards and non-executives preparing for investment, acquisition, regulatory inspection, or a significant customer audit.

Who this is not for

Pre-revenue businesses or technology startups looking for an architect to build with them.

Owners who want validation of decisions already made. A review will tell you the truth, including the parts that are uncomfortable.

Organisations under fifty staff where the entire architecture sits in one person’s head. You do not need this yet.

What you receive

The review tells you three things in writing: what your architecture does well, where it is exposed, and what to fix first. Five artefacts, delivered together, in plain language.

A current-state assessment. What your architecture is. Major systems, how they fit together, what they do well, where they are exposed. Written so a non-technical board member can read it and a technical lead can verify it.

A risk register. Every material risk identified during the review, ranked. Operational risk, key-person risk, vendor risk, regulatory exposure where relevant. Each entry names the risk, the system it sits in, and what it would take to address.

A dependency map. The integrations, vendors, libraries, and external services your architecture relies on. Where the single points of failure are. What changes if one of them changes.

Written recommendations. What to do first, second, third. Each recommendation costed in rough effort and named against the risk it addresses. No vendor introductions. No implementation pitches.

An executive presentation. A one-hour session with whoever needs to hear the findings — you, your board, your technology committee, an incoming investor. Findings presented, challenged, and discussed in the room.

Typical outcomes

Most reviews result in one of four conclusions.

The architecture is fundamentally sound. The business can continue investing with confidence, focusing only on specific areas of risk.

The architecture is viable but carrying avoidable risk. The systems work, but key-person dependencies, undocumented integrations, technical debt, or supplier dependencies need addressing.

The architecture is constraining the business. Technology has become a barrier to growth, change, acquisition, compliance, or operational efficiency.

The architecture requires strategic intervention. The risks are significant enough that leadership should address them before committing further investment.

The review tells you which of these your business is in, and what follows from it.

How the review runs

Three to four weeks, in four parts.

Week one — interviews. Your technology lead. Your senior engineers, if you have them. Your operations team. Anyone the architecture passes through.

Week two — documentation review. Your existing diagrams. Any prior audits. Vendor contracts. Incident reports. Whatever your team can show that explains what is already known.

Week three — synthesis. The findings written up into the artefacts above.

Week four — presentation. The session, scheduled around your board cycle if needed. Revisions if anything in the report needs to be tightened.

Everything is written before it is said. Nothing is presented to your board that you have not read first.

What this is not

A remediation engagement. We identify and recommend; we do not implement.

A regulatory audit. The review can inform one, but it does not substitute for one.

A vendor selection exercise. The review does not end with a list of products to buy.

A penetration test or security assessment. Security architecture is in scope; offensive testing is not. For that, you want a specialist firm.

An architecture review is not a technology purchase. It is a decision-making tool.

The purpose of the engagement is not to tell you what technology to buy. It is to give leadership a clear understanding of what they already own, where it is exposed, and what matters next.

Proof

References available on request. Anonymised excerpts from prior reviews available on request.

What happens next

Start a Conversation

Thirty minutes. We confirm fit, scope, and timing. You decide whether to proceed. No proposal is sent unless you ask for one.

Start with the Technology Control Snapshot — €495

A short, scored review of your overall technology posture, delivered in writing within five working days. The Snapshot is the right place to start if you are not yet sure a full Architecture Review is the right engagement.

For ongoing executive oversight, see Fractional CTO.