Making Your Software Talk to Itself: What Integrations Really Are
Every piece of data someone retypes from one system into another is time spent twice and a mistake waiting its turn. What integrating two systems actually means, when it pays off, and when you are better off leaving it alone.
In almost every company I visit there is one person who spends part of their day retyping data from one screen into another. Orders from the e-commerce site into the management system. New customers from the management system into the invoicing software. Stock levels from a spreadsheet onto the website.
When I ask how long it takes, the answer is always “not long, ten minutes”. Ten minutes a day is forty hours a year — and that isn't even the main cost. The real cost is the mistakes, which make no noise and get discovered by an angry customer.
Integrating two systems means taking that person out of the loop. Here is what that involves in practice.
What it means, without the jargon
Two pieces of software talk to each other when one can ask the other something and get back an answer it understands. The channel this happens through is called an API: a service door a program opens so other programs can query it.
There is nothing magic about it. When your e-commerce site “sends the order to the management system”, it is doing exactly what you would do by copying the data across, except it does it in half a second, always the same way, and it doesn't get distracted on a Friday afternoon.
The three questions that decide whether it can be done
Does the software have a door? Most modern systems have documented APIs: if yours does, the integration is ordinary work. If it doesn't, it can still be done through exchange files (the old CSVs), but it becomes more fragile.
Who is in charge? This is the question companies skip and then pay for. If a customer changes their address on the website and in the management system, which one wins? For every piece of data, someone has to decide which system is the source of truth. Without that decision, two connected systems overwrite each other.
What happens when something goes wrong? Connections drop, suppliers push updates, an order arrives malformed. A well-built integration notices, retries, and if it really can't proceed, it tells a human. A badly built one fails silently — and silence is the worst way to discover that nothing has come through for three days.
What copy-paste really costs
| What gets copied by hand | The visible cost | The cost you don't see |
|---|---|---|
| Orders from the webshop | 10 minutes a day | Orders lost on peak days |
| Customer records | 5 minutes per customer | Two systems, two addresses |
| Stock levels | half an hour a week | Selling what you don't have |
| Invoicing data | a full day at month end | Wrong amounts, found by the customer |
When it isn't worth it
An integration is code that lives over time: when either system changes, it needs updating. It makes sense when the volume justifies it.
If you retype three orders a week, the integration costs more than the problem it solves, and the honest answer is to carry on by hand. If you are about to replace one of the two systems within six months, wait: you would do the same work twice. And if the process isn't stable — if every month you decide to handle it differently — stabilise the process first, connect it second.
Where to start
You don't integrate everything at once. You start with the most frequent, most tedious transfer — the one everyone in the office names without thinking. You connect that, leave it running for a few weeks, and meanwhile it becomes obvious what the second one should be.
Almost always that first connection pays for itself within months, and more importantly it shows the company that this kind of work isn't fate: it is a choice.
Tell me which data you retype today, from where to where and how many times a day: I'll tell you whether the two systems can be connected, and whether the volumes make it worth doing or you are better off leaving things as they are.
