Category: Consulting

There’s a version of every troubled project where the problems were visible from the start, to anyone who looked carefully. The database schema that can’t represent the core business entity without a join across five tables. The event model that can’t support the audit log that compliance will definitely require. The authentication approach that can’t extend to the multi-tenant model on the roadmap.

What we review and why

A pre-engagement architecture review covers six areas: data model, API surface, authentication and authorisation model, infrastructure and deployment topology, observability, and test coverage. We’re not auditing for code quality — we’re looking for structural constraints that will become expensive problems later.

The most valuable output isn’t a list of issues — it’s a risk-ranked prioritisation. Not every architectural problem needs fixing before work starts. The review gives the team a shared, honest picture to make that call.

The conversation with clients

Some clients push back on a review. They want to ship, not audit. Our framing: the review takes a week and might save three months of rework. We’ve had that trade pay off on more projects than we can count.

We share the findings in a written report with a risk rating (high/medium/low) and a recommended action for each finding. High-risk items go into the project plan explicitly.

What we consistently find

The most common high-risk finding is a schema that can’t represent the business entity accurately. The second most common is an auth model that assumes a single-tenant deployment when the product roadmap clearly leads to multi-tenant. Both are cheap to fix at the start and expensive to fix at month six.

Every legacy modernisation project starts with someone proposing a full rewrite. It’s the instinct of engineers who’ve spent months fighting an old codebase: burn it down, start fresh. We’ve seen this end badly enough times that we now treat the full-rewrite proposal as a red flag rather than a solution.

Why rewrites fail

The new system has to reach feature parity with the old one before it can ship. The old system keeps being used (and sometimes extended) while the new one is being built. By the time the new system is ready, the old one has moved on, and the team has been running in parallel for months or years.

The strangler fig approach

We use the strangler fig pattern: route traffic through a thin proxy layer, and migrate functionality piece by piece from the old system to the new one. Each migrated module is deployed and tested independently. The old system shrinks over time; the new one grows. There is no “big bang” cutover.

The key to making this work is identifying the seams. Not every legacy system has clean module boundaries — some are a single large process where everything touches everything else. The first phase of a strangler fig engagement is often introducing those seams.

What to migrate first

Start with the highest-value, lowest-risk modules: things that are well-understood, frequently changed, and have clear inputs and outputs. Not the authentication module (high risk), not the reporting engine (complex) — something in the middle that gives the team a working example of the new architecture in production.

The organisational piece

Modernisation only works if feature development continues on the old system during the migration. This requires explicit rules: new features go on the new system if the relevant module has been migrated; otherwise they go on the old system with a migration ticket created. Without this rule, the migration stalls.

The graveyard of enterprise technology strategy is full of documents. Beautifully formatted, thoroughly researched, delivered with a presentation and a Q&A — and then never looked at again. The teams we work with are smart; the documents weren’t bad. The problem was structural.

The problem with deliverable-centric engagements

Most strategy engagements end with a deliverable: a report, a roadmap slide deck, a set of recommendations. The consulting team presents it, the client applauds, and then the client goes back to the day job. The document has no forcing function. It doesn’t connect to the next sprint, the next hire, or the next budget conversation.

What we do instead

We structure engagements around decisions, not documents. At kickoff, we ask: what are the three most important technology decisions you need to make in the next six months? Everything we do during the engagement is in service of those specific decisions. The output is a decision memo, not a strategy paper — shorter, more direct, with a clear recommendation and the evidence behind it.

The 30-day follow-through

We include a 30-day follow-through session in every engagement. Thirty days after delivery, we meet with the client to review which recommendations have been acted on, which have been deprioritised (and why), and what obstacles have appeared. This creates accountability and surfaces implementation problems early when they’re still cheap to address.

The metric we use internally

We track the “recommendation adoption rate” — the percentage of our recommendations acted on at the 90-day mark. A low adoption rate is a signal that the engagement was too abstract, too expensive to implement, or solving the wrong problems.