Skip to content

Transformation rarely fails inside a system. It fails between them.

Why we start every programme by mapping the handoffs, not the applications.

Integration, 5 min read

Reviewer note: Editorial draft written for launch. Review, edit and approve before publishing.

Ask an organisation to describe its systems and you will get a list of applications: the ERP, the CRM, the HR system, the portal. Ask the people who do the work to describe their day and you will hear about something else entirely — the spreadsheet that reconciles two of those systems, the email that carries an approval from one to another, the colleague who re-keys data because the interface between them was never built.

That second description is where transformation programmes succeed or fail. Replacing an application is a well-understood project. Changing how information moves between applications, teams and partners is not, and it is usually where the cost and the delay actually live.

Map the handoffs first

Before we recommend any technology, we trace a handful of real transactions end to end: a booking from enquiry to invoice, a worker from registration to ID card, an inspection from visit to closed finding. Every time information changes hands — between systems, people or organisations — we record who owns it, how it moves and what happens when it fails.

The result is rarely a list of applications to replace. More often it is a short list of handoffs that cause most of the friction, and a much smaller programme than the one originally scoped.

Treat integration as a product

Integrations are often built as one-off projects and then forgotten until they break. We treat the integration layer as a product with an owner: documented APIs and data contracts, monitored message flows, retries and dead-letter handling, and identity that is consistent across every system it touches.

That discipline is what lets an organisation add a new channel, partner or AI service later without starting over.

Sequence for value, not completeness

Once the handoffs are mapped, sequencing becomes a business decision rather than a technical one. Fix the handoff that costs the most first, prove it in production, then move to the next. Each step delivers something people notice, and each one makes the next easier because the integration layer is already in place.