The strangler-fig pattern promises incremental, reversible modernization — but the very first facade you build is doing double duty. It has to actually reduce risk, and it has to prove to a skeptical organization that the whole approach works before anyone commits budget to the next twenty slices. Choosing that first capability badly can sink a sound methodology on a bad first impression.
The intersection that matters
The right first facade sits at the intersection of high enough traffic to matter and low enough risk to fail safely. Too low-traffic and the win is invisible — nobody notices or cares that a rarely-used report now runs through a modern service. Too high-risk and a rollback during the inevitable first hiccup becomes a crisis instead of a Tuesday.
How to find it
- Map traffic volume against blast radius for every candidate capability — the sweet spot is upper-middle traffic, lower-middle risk.
- Prefer read-heavy capabilities for the very first slice — a lookup or query service is far easier to shadow-test and roll back than anything that writes.
- Pick something with a clear, measurable before-and-after — latency, error rate, or a manual step eliminated — so the win is demonstrable in a sentence, not a slide deck.
- Avoid anything tangled in undocumented downstream dependencies discovered during the mapping phase — save those for once the team has practice reps under its belt.
The first facade is a trust-building exercise disguised as an engineering task. Its real deliverable isn't the service itself — it's the organizational permission to do the next nineteen.
What this buys you
A well-chosen first slice creates a template — the facade pattern, the parallel-run process, the rollback rehearsal — that every subsequent slice reuses with decreasing ceremony. A poorly chosen one creates a war story that gets told in every future budget meeting about why modernization is risky. Choose accordingly.