How a Strategic Consulting Approach Helps Enterprises Accelerate Innovation
A diagnose-first engagement replaces assumptions with an actual map of the system, its decisions, and its risks before anyone writes a recommendation. Skip the map and a "strategic consulting approach" is just guessing with better slides.
What diagnose-first replaces
The common failure mode in enterprise consulting is a strategy deck built from stakeholder interviews and a competitor scan, with no one having opened the codebase, the data warehouse, or the actual architecture running in production. The recommendations sound reasonable and miss the constraint that made the last three initiatives fail.
Diagnose-first means the technical map comes before the plan, not after it. It's slower in week one and faster in every week after, because the plan is sequenced against what's actually true instead of what the org chart believes is true.
Mapping the system as it exists
The first artifact isn't a slide, it's a diagram of the system that's actually running, at a level of detail someone can argue with. The C4 model gives that a structure: context (how the system fits with the people and systems around it), containers (the deployable pieces), components (what's inside each container), and code, used only when a specific piece needs that resolution (C4 model — Introduction).
Most engagements only need the top two levels. A context diagram plus a container diagram is usually enough to have an honest architecture conversation with both engineers and the executives sponsoring the work (C4 model — Diagrams).
Interviews alone don't produce a map
Stakeholder interviews describe what people believe the system does. They don't reliably describe what the system actually does, because the person who remembers why a service was built that way often left, and the documentation, if it exists, describes an earlier version.
An instrumented discovery pass, reading the actual repositories, tracing a real request through the deployed services, checking what's actually running against what the architecture diagram claims, catches the gap interviews miss. The C4 model's container level is usually where that gap first becomes visible: a "service" on the org chart that's actually three deployables, or two "separate systems" that share a database nobody flagged.
| Discovery method | What it reliably tells you | What it misses |
|---|---|---|
| Stakeholder interviews | What people believe the process is, organizational priorities, political constraints | Whether the system still works that way; assumes institutional memory is accurate |
| Instrumented discovery (repo, deploy config, live traces) | What's actually deployed, what actually talks to what, real request paths | Why a decision was made, business context behind a workaround |
Neither method alone is sufficient. The plan gets built on both together: the instrumented view for what's true, the interviews for why it got that way and what constraints a fix has to respect.
Mapping the domain, not just the system
Architecture diagrams show how the system is built. They don't show what the business actually thinks is happening inside it, and those two views diverge more often than anyone expects. EventStorming, a workshop format built around sticky notes and domain events, closes that gap by getting the people who run the process in a room to lay out what actually happens, step by step, without a system diagram anchoring the conversation (EventStorming — official site).
The value isn't the sticky notes. It's the moment a warehouse manager and a backend engineer discover they've been describing two different processes as if they were the same one.
An architecture diagram shows what the system does. A domain workshop shows what the business thinks the system does. The gap between those two is usually where the actual risk lives.
Recording decisions as you go
Findings that live only in a final deck get argued with again six months later, because nobody can reconstruct why a decision was made. Michael Nygard's architecture decision record format fixes that with a small, dated document per significant decision: title, status, context, decision, and consequences (Cognitect — Documenting Architecture Decisions).
The discipline that matters isn't the template, it's writing the record at the moment the decision is made, not reconstructed afterward from memory. A decision log built during discovery becomes the reference the delivery team argues from later, instead of re-litigating settled questions.
# ADR-014: Keep the legacy pricing engine during phase 1
## Status
Accepted
## Context
The pricing engine has 40+ undocumented business rules encoded
in stored procedures. No current owner can enumerate them all.
## Decision
Wrap the pricing engine behind a service interface (strangler
fig) rather than rewriting it in phase 1.
## Consequences
Phase 1 ships faster. Rules get documented incrementally as
each one is extracted, not all at once up front.Turning findings into a sequenced plan
The instinct after a discovery phase is to recommend a rewrite. The instinct is usually wrong, because a rewrite freezes feature delivery for the length of the project and re-implements bugs nobody remembers are load-bearing.
Strangler fig over rewrite, most of the time
The strangler fig pattern puts a facade in front of the legacy system and the new system together, routing each request to whichever one currently owns it, and migrates functionality piece by piece until the legacy system is decommissioned (Microsoft Learn — Strangler Fig pattern). The legacy system keeps running the whole time, which is what makes this the lower-risk default over a rewrite.
The facade is also where the diagnosis phase pays off directly. Deciding which requests route to the legacy system versus the new one requires knowing the boundaries mapped during the C4 and EventStorming work; guess at those boundaries and the facade routes traffic incorrectly on day one.
Shared data is where a strangler fig migration actually gets hard
Both the legacy and new systems typically need access to the same underlying data during the transition, and Microsoft's own guidance on the pattern flags this directly: plan for how services and data stores get used by both systems concurrently before starting the migration, not after the first data conflict (Microsoft Learn — Strangler Fig pattern). A discovery phase that produced an accurate data-ownership map, not just a service map, is what makes this planning possible instead of reactive.
| Approach | Delivery risk | Feature freeze | When it's the right call |
|---|---|---|---|
| Full rewrite | High — all value delivered at the end | Full freeze for the project duration | The legacy system is small, well-understood, and genuinely disposable |
| Strangler fig, phased | Lower — value ships incrementally | None; legacy keeps running alongside | The legacy system is large, partially undocumented, or business-critical |
Deciding what's worth adopting
Every engagement surfaces a list of candidate tools, patterns, and platform changes. Thoughtworks' own public radar sorts these into four rings, adopt, trial, assess, and hold, and its own stated litmus test for moving something from assess to trial is that the team has actually used it on real project work, not just evaluated it on paper (Thoughtworks Technology Radar — FAQ). Building the same four-ring view internally, specific to the client's stack, keeps the plan from turning into a wish list of every tool that came up in a workshop.
- Adopt: proven for this specific stack and team, ready to standardize on now.
- Trial: promising, but only after a real project uses it, not a proof of concept.
- Assess: worth watching, not worth committing engineering time to yet.
- Hold: don't start anything new with it; existing usage isn't an emergency to rip out.
What actually gets delivered at the end
A diagnose-first engagement's output isn't a strategy narrative. It's a set of artifacts the delivery team can pick up and execute against without the consultants in the room.
That's the actual test of whether the diagnosis phase succeeded: hand the artifacts to an engineer who wasn't in any of the discovery sessions, and see whether they can start executing the first phase of the plan without scheduling a meeting to ask what a decision meant.
- An architecture map at the context and container level, current as of the engagement, not aspirational.
- A domain model from the EventStorming sessions, showing what the business actually does, agreed by the people who do it.
- An ADR log covering every significant decision made during discovery, with context and consequences attached.
- A phased execution plan sequenced by risk and dependency, using strangler fig boundaries where legacy systems are involved.
- An adopt/trial/assess/hold list for tools and patterns, scoped to what this specific team and stack can actually absorb.
If the delivery team can't execute the plan without the person who wrote it in the room, the diagnosis wasn't finished. It was summarized.
FAQ
How long should a diagnose-first phase take?
Long enough to produce a real architecture map, a domain model people agree with, and a decision log, not a fixed number of weeks. Rushing this phase to hit a calendar date is how the plan inherits the wrong assumptions.
Isn't mapping the existing system just delaying the real work?
The mapping is the real work. A plan built without it gets rewritten mid-execution once the team discovers the constraint that was sitting in the architecture the whole time.
Who needs to be in an EventStorming session?
The people who actually run the process being modeled, not just their managers. The value comes from surfacing disagreements between people who each thought they understood the process the same way.
Why not just rewrite the legacy system and skip the complexity of a strangler fig migration?
Because a rewrite defers all value delivery to the end of the project and re-implements whatever undocumented business rules the legacy system encodes, often incorrectly, since nobody who wrote the rules is still around to check the rewrite against (Microsoft Learn — Strangler Fig pattern).
Do ADRs need to be approved by a committee?
No. The original format is intentionally lightweight, a short document per decision, written at the time the decision is made, not routed through an approval process that defeats the purpose of keeping it current (Cognitect — Documenting Architecture Decisions).
What's the biggest risk in a strangler fig migration specifically?
Shared data stores that both the legacy and new systems write to during the transition. Microsoft's own guidance calls this out directly as something to plan for up front, since an unplanned write conflict between the two systems is where these migrations actually stall (Microsoft Learn — Strangler Fig pattern).
Should interviews happen before or after the instrumented discovery pass?
In parallel, ideally. Interviews without the instrumented view produce a plan built on assumptions; an instrumented view without interviews produces an accurate map with no context for why the system ended up that way.