Strangler fig, APIs first and event-driven integration

The strangler-fig pattern replaces an old system gradually: a routing layer sends some requests to new services and the rest to the old code until nothing is left. Exposing existing functions as APIs and publishing business events usually comes first, because it creates the seams you need.

The pattern and its name

A strangler fig is a plant that grows around a host tree until it can stand on its own. Software architects borrowed the image for a way of replacing systems: build the new around the edges of the old, move one function at a time, and let the old system shrink until it can be switched off. The key idea is that the old and new run side by side throughout.

Strangler fig: a routing layer decides where each request goes

Channelsmobile, web, partners

Routing layerAPI gateway or facade

New servicefunctions already moved

Existing COBOLeverything else

How it works step by step

Put a routing layer (often an API gateway) in front of the function, so callers no longer call the old system directly.
Pick one well-bounded function, such as an address change or a balance enquiry.
Build the new implementation and run it in parallel, comparing results with the old code.
Switch a small share of traffic, then all of it, at the routing layer. Switching back is a configuration change, not a redeployment.
Remove the old code path and repeat with the next function.

Why API enablement comes first

You cannot route around something that has no seam. Exposing existing CICS, IMS or batch functions as REST APIs (for example through z/OS Connect or CICS web support) gives every caller one stable contract. Once callers use the API, what sits behind it can change without them noticing. API enablement also delivers value on its own: new channels can use mainframe functions within weeks, which is why many programmes start here even if they never rewrite anything.

Event-driven integration

APIs suit request-and-reply. Many systems also need to know when something happened: a payment posted, an address changed. In event-driven integration the system of record publishes an event and any interested system consumes it, without the publisher knowing who listens.

Source of events	How it works	Typical tools
Application publishes	The COBOL program puts a message as part of its unit of work	IBM MQ, often bridged to Apache Kafka
Change data capture	Changes are read from the database log and turned into events	Replication and CDC products, Kafka connectors
Batch extract	A job writes changed records to a file that is sent on	File transfer, schedulers

Publishing inside the same unit of work as the database update matters: if the update is backed out, the event must be too, otherwise other systems act on something that never happened.

The hard part: data

Moving logic is usually easier than moving data. While a function is split between old and new, both may need the same records. Common approaches are: the new service calls the old system for data through an API; data is replicated to the new service's store, read-only; or ownership of a data set moves to the new service and the old code calls it. Whatever you choose, there must be one system of record for each piece of data at any time.

Where it goes wrong

The routing layer is added but nothing is ever moved, so it becomes one more hop.
Functions chosen are too large, so each slice takes a year.
Parallel running is skipped and differences are found by customers.
Old code paths are never removed, so both systems must be maintained.