What goes wrong when two business systems are connected

When two of your systems are connected, say your online store and your accounting software, the fact that it works on the first day tells you very little. A connection like that (developers call it an integration) needs looking after for as long as you use it, and when it goes wrong, it tends to go wrong in ways that are hard to spot.

Here's what we see go wrong, roughly in order of how often we've had to fix it.

The other company changes something

The software on the other end belongs to another company, and they update it when they like. They retire a feature your connection relied on. A field that always had something in it starts coming through empty now and then. None of these causes an obvious outage. What you get instead is a small share of orders or records that never make it across, and by the time someone notices, three weeks have gone by.

The protection is unexciting and it works. The connection should check every piece of information that comes in against what it expects, and when something doesn't look right, it should tell a person instead of skipping that record and carrying on.

A sign-in or permission runs out

Connected systems sign in to each other much like people do, and those sign-ins expire. Security certificates expire too. Sometimes the account a connection uses gets switched off when an employee leaves, because nobody knew what it was for. This one is easy to recognize. Everything works perfectly for months, then stops completely, usually on a weekend.

Set up anything that can renew itself to do so automatically, and for anything that can't, put the expiry date on a calendar that a real person checks.

Work piles up faster than it gets done

Fifty records an hour is no trouble. Things fall behind when a customer uploads a spreadsheet with nine thousand rows, or when the other system runs slowly for an afternoon. If nothing slows the flow to a pace both sides can handle, this is where you end up with duplicate records, updates that only half went through, and a very bad Monday.

When an attempt fails, the connection should wait a little longer before each retry instead of hammering away. Anything that keeps failing should be set aside in a holding area where a person can look at it later. An order that disappears without anyone knowing is far worse than an error message someone sees.

The same thing happens twice

Sometimes the line drops after the other system has done the work but before it confirms it. The sending side doesn't know it succeeded, so it tries again, and now you have two orders. Any step can end up being retried this way, so every step needs to be safe to run twice. In practice, each record carries a fixed reference number from the system it came from, so a second attempt is recognized as a repeat.

This is the failure that costs real money, because instead of an obvious gap it gives you wrong information that looks believable, like a customer billed twice for one order.

Watch for silence as well as errors

Almost everyone sets up alerts for errors. Far fewer set one up for when nothing happens, and nothing happening is what most of the problems above look like from the outside.

If orders normally come through every few minutes during business hours, two hours with none on a Tuesday afternoon is a problem, even if no error appeared anywhere. An alert that goes off when the usual activity hasn't happened will catch the expired sign-in, the retired feature and the backed-up work, all three, and it's perhaps two hours of work to build.

When the other system has no proper way to connect

Where the other company offers an official, documented way for systems to connect, use it. The alternative is software that reads their screens and clicks their buttons the way a person would, and that works right up until they move a button. They'll move buttons without telling anyone, because from their side nothing important changed.

Sometimes there's no official option at all. Plenty of the systems small businesses depend on can only send or receive files on a schedule. That's workable, and we build connections like that regularly, but treat the file layout as an agreement you've worked out for yourself rather than one the other company has promised to keep. Check every file, get an alert when one doesn't arrive, and never assume the columns will stay in the same order.

What a dependable connection looks like

None of this shows up in a demo. A connection you can rely on checks what comes in instead of assuming it's right, can safely run the same step twice, puts failures somewhere a person will find them, and alerts you when nothing has happened as well as when something has gone wrong.

We build these as part of connecting the systems you already run, and the monitoring described above is included rather than sold as an upgrade. We're the ones who get the call when it breaks, so we'd like to know first.