Integration is not a technical problem

Every year, businesses spend enormous sums on software that underdelivers. Not because the software is bad — much of it is genuinely excellent — but because the underlying assumption about why the software will help turns out to be wrong.

The assumption is this: if we connect our tools, the data will flow, the team will follow, and the process will improve. This is an assumption about technology. The reality is that integration is not a technical problem. It is a workflow design problem, a change management problem, and sometimes a definition-of-success problem. Technology is only the final step.

Why rollouts fail

In our work with clients across sectors, we have observed three failure patterns that account for the majority of unsuccessful system rollouts. They have almost nothing to do with the technology selected.

Pattern 1: Automating a broken process

The fastest way to scale a problem is to automate it. When a flawed workflow is digitised and integrated, errors propagate faster, edge cases multiply, and the volume of affected transactions increases. Before any integration work begins, the process must be redesigned to the point where a manual version of it works consistently. Only then is it worth the investment of building it into a system.

Pattern 2: Building for today's team, not tomorrow's process

Many integrations are scoped around the current team's habits rather than the intended end-state process. This produces systems that are technically functional but organisationally rigid — they work the way the team worked six months ago, not the way the business needs to work in twelve months. Good integration design starts with the desired workflow and works backward to the technology required to support it.

Pattern 3: No ownership after go-live

A system that has no clear owner will drift. Fields go unused, automations break silently, and workarounds accumulate until the system becomes a second source of truth that everyone works around rather than within. Every integration needs a named owner — not a vendor, not a consultant, not "IT" — but a person inside the business who is accountable for the process the system supports.

Connecting two tools does not create a workflow. It creates the possibility of a workflow. The workflow itself has to be designed.

What good integration design looks like

The integration projects that succeed share a set of common characteristics that have more to do with preparation and clarity than technical execution.

• —The desired outcome is defined in plain language before any tools are evaluated
• —The current process is documented as it actually runs, not as it was designed to run — these are frequently very different things
• —Every data element that will move between systems has a single source of truth identified
• —Edge cases and exceptions are mapped before build, not after go-live
• —The go-live plan includes a parallel-run period where the old and new processes run simultaneously, so discrepancies can be caught and corrected
• —Post-launch ownership is assigned before the first line of configuration is written

The sequence matters

The sequence in which integration work is approached is as important as the approach itself. We recommend what we call a design-first, build-second sequence: spend more time on paper than on configuration, particularly in the early stages of a project.

This feels slower in the short term and almost always results in fewer changes, less rework, and more durable systems in the medium term. The instinct to move quickly to a live environment — to "just try it" — is understandable, but it consistently produces systems that need to be rebuilt within twelve to eighteen months.

The businesses that have invested in thinking clearly about their workflows before investing in technology are, in our observation, the ones that get the most out of their tools. Not because they chose better software, but because they understood what they needed the software to do before they bought it.

A practical starting point

If you are planning an integration project, start by answering these four questions on paper before speaking to any vendor or consultant:

• —What specific outcome will this integration produce, in measurable terms?
• —What does the current process look like, step by step, including all exceptions?
• —Who will own this process after go-live, and what does their accountability include?
• —What will you do when this integration breaks — because it will, at some point?

If you can answer all four clearly, you are ready to begin evaluating solutions. If you cannot, that is where the real work starts.

We help businesses design their workflows before selecting or configuring any technology. If you are approaching an integration project and want a clear-headed perspective before committing, we would be glad to talk. Reach out at hello@paradigmai.co.