Why your two systems don't talk, and what it takes to fix

The complaint is nearly always the same. We have a system for orders, a system for accounts and a system for stock, and a person in the middle carrying information between them.

The assumption is that this is a technical gap. Usually it is not.

The real difficulty is agreement, not APIs

Before anything can move automatically, somebody has to decide which system is allowed to be right.

If the storefront says there are four in stock and the warehouse says there are two, an integration cannot resolve that. It can only make the disagreement faster. So the first part of the work is a conversation, not code. Which system owns the customer record. Which owns the price. Which owns the stock figure. What happens when a value changes in the system that does not own it.

Once those decisions exist, the technical part is comparatively ordinary.

What good looks like

It is boring. Information moves and nobody thinks about it.

It survives outages. A system being unavailable for twenty minutes should delay a message, not lose it. Work queues and retries are not luxuries.

It is visible. There is a record of what moved and an alert when something does not. Silent failure is what destroys trust in an integration, far more than downtime.

It is documented. Somebody other than us can read how it works.

Older systems are usually still connectable

Modern products have APIs. Older ones often do not, and that is not the end of it. Database level access, scheduled file exchange or a small purpose built layer in front of the old system all work. What matters is being honest about which approach is being used and what its limits are.

An example

A major retailer's Shopify storefront, a distributor's Akeneo product information system and Sage accounting all held part of the truth, joined together by manual work. We connected them so orders route automatically, product data has one home and reconciliation stopped being a monthly exercise.

If your people are the join between two systems, start by writing down exactly what they carry across and how often. That list is usually the business case.