Insight: Systems Integration
“Why can’t this system talk to that system?”
It is one of the most common questions asked of any technology function, and the answer is usually too complicated to give in the moment. So it either frustrates the person asking or lands in the too-hard basket, and the manual work continues. It does not have to end there. The mindset is simple; the execution is where the complexity sits, and that is a problem to be quantified rather than avoided.
Illustrative rather than tied to a named client. Integration overlaps with data governance and automation, both of which are covered separately.
The Starting Point
The question behind the question
Most organisations run several systems that clearly relate to one another, such as a customer relationship platform, a warehouse system and an accounting package, and yet sit isolated, with people manually carrying information between them.
First
What is actually in use?
A complete picture of the systems the business runs on, including the ones adopted by a single department without anyone else being told. You cannot connect an estate you have not mapped.
Second
What needs to be easier?
Not what could theoretically be connected, but what would genuinely remove effort. Which manual step costs the most time, causes the most errors, or delays the information someone needs to make a decision.
Third
What already exists?
Which connections are available natively, and which would have to be built. Many organisations commission development for something the platform already offers, simply because nobody checked first.
Integration is not only an internal exercise
The same thinking applies outward. Connections between a business and its suppliers, customers and partners remove the same manual handling, and often carry more value: orders that arrive as data rather than as an email somebody re-types, stock positions that are visible rather than requested. The internal case is usually easier to make. The external one is frequently worth more.
The Options
Six ways to connect two systems
These run roughly from least to most expensive. The common error is starting at the costly end because it is the one people have heard of. Select any approach to see when it fits and where it does not.
The expensive answer is rarely the only answer
A quote of tens of thousands to develop a custom interface is a legitimate option, but it should be the considered choice rather than the reflex. A pipeline reading directly from a database may deliver the same reporting for a fraction of the cost. An agentic approach driving the interface the way a person would may bridge a system that offers no connection at all. The requirement determines the method, not the other way round.
There is always a solution. The question is what it should cost.
Integration problems are rarely impossible. They are usually priced wrongly, because only one method was considered.
The Decision
Build, bridge, or change the system
Once the requirement is clear and the options are understood, it becomes a commercial decision rather than a technical one, which is exactly where it should sit.
Quantify the requirement
How many hours a week does the manual step consume, how often does it introduce errors, and what decision is delayed because the information arrives late. Without those figures, integration is a preference rather than a case.
Quantify the investment
Build cost, ongoing maintenance, and what happens when either system is updated. A custom interface is not a purchase; it is a commitment with a maintenance obligation attached to it.
Consider changing the system
Sometimes a product exists that already does what is needed, and replacing beats bridging. That decision carries its own cost, including migration, retraining and disruption, and deserves examining rather than dismissing.
Decide the return
With the requirement and the investment both quantified, the return can be stated rather than assumed. That is the point at which an integration becomes something a board can approve with confidence.
The Point
Requirement first, method second
In an ideal world every system would speak to every other, with permissions as the only boundary. The world is not that tidy: there are thousands of products, each built to satisfy different requirements, and not all of them were designed to cooperate. Integration work is therefore a matter of understanding the systems genuinely, establishing what has to be achieved, and then selecting the method that achieves it at a defensible cost.
Some of it is straightforward. Some of it needs thinking that goes beyond the obvious approach. What does not change is the order of the questions: what needs to be achieved, and how will we achieve it. That determines the strategy, the cost, and the return.