System integration, also written systems integration, is the work of connecting separate software systems so that information entered in one is available in the others without anyone typing it again. An order placed on the website appears in the stock system. An invoice raised in the job system arrives in the accounts package. The systems stay separate and each carries on doing its own job. What changes is that data passes between them automatically.
The term has a second, broader use in the IT industry, where a systems integrator is a firm that assembles hardware, networks and software from several vendors into one working installation. This article is about the narrower meaning that matters to most businesses: getting the software you already run to share data.
How systems are connected
There are five common methods. Which one applies depends less on preference than on what each system allows.
| Method | How it works | Suits | Weakness |
|---|---|---|---|
| API | One system sends requests to another through an interface the vendor has published for the purpose | Current cloud and packaged products | Vendors change their APIs, and some charge for access |
| Webhook | A system sends a message to an address you choose the moment something happens | Reacting at once to an event, such as a new order | If the receiver is down, the message can be lost unless the sender retries |
| File transfer | One system writes a file, often in CSV format, and the other reads it on a schedule | Older products with an import and export facility and no API | Data arrives late, and a badly formed file can stop the run |
| Direct database access | One system reads or writes another’s database | In-house systems where you control both ends | Breaks when the other system is upgraded, and may breach its licence |
| Automation service | A hosted tool, such as Power Automate or Zapier, sits between products and passes records across | Simple links between well-known cloud products | Hard to manage once the rules become complicated |
An API, or application programming interface, is the method to prefer where it exists. It is the door the vendor intends other software to use, so it is documented and it checks the data coming in. Writing directly into another product’s database skips those checks, which is why it is the method most likely to cause damage.
A sixth case is becoming common. Where information arrives as an email or a PDF, there is no system at the other end to connect to. Here AI can read the document and enter the details, with a person checking anything it is unsure of.
Four decisions every integration needs
The method is the easier part. The harder part is four decisions about the data, and they are business decisions more than technical ones.
Which system owns each kind of data. If a customer’s address can be edited in the CRM, the accounts package and the delivery system, the three will disagree, and an integration will only spread the disagreement faster. Choose one system as the master for customers, one for prices and one for stock. The others receive copies and do not change them.
Which direction the data flows. Sending orders one way, from the web shop to the stock system, is simple. Keeping two systems in step in both directions is a much larger job, because both can change the same record at the same moment and something has to decide which change wins.
How quickly it must arrive. Some data is needed within seconds: a stock level shown to a customer who is about to buy. Much is not: invoices can reach the accounts overnight. Immediate transfer costs more to build and to run, so ask for it only where the business needs it.
How records are matched. The same customer may be “J Smith Ltd” in one system and “Smith, J. Limited” in another. An integration needs a dependable way to tell that they are the same, usually a shared reference number, and a rule for what to do when no match is found. Without one it creates duplicates.
A fifth question, what happens when a transfer fails, deserves a page to itself. We discuss it in your systems do not talk to each other.
A worked example
This is an illustration, not a client. A wholesaler runs a web shop, a stock and dispatch system, and an accounts package. Before integration, a member of staff prints each web order, types it into the stock system and, after dispatch, types an invoice into the accounts.
Integrated, the flow looks like this.
- The accounts package is the master for customers and credit terms. New accounts are created there and copied to the other two systems each night by file.
- The stock system is the master for products and stock levels. It publishes levels to the web shop through the shop’s API every few minutes.
- When a customer places an order, the web shop sends a webhook to the stock system, which creates the order ready for picking.
- When the order is dispatched, the stock system sends the invoice details to the accounts package through its API.
- Any record that is rejected is put in a list for the office to look at, with the reason, and the rest carry on.
Three methods are in use in one small company, each chosen for what the system at that end can do. Nobody types an order twice, and the office deals only with the handful that fail.
Direct links or a central hub
With two or three systems, connecting each pair directly is the sensible approach. It is the cheapest to build and the easiest to understand.
The arithmetic changes as systems are added. Five systems that all need to exchange data could require up to ten separate links, each with its own rules and its own ways of failing. At that point it can be better to route everything through a central piece of software, sometimes called middleware or an integration platform. Each system connects once, to the hub, and the hub handles the translation between them.
A hub is a system in its own right, with its own cost and its own need for upkeep. For a business with a few systems it is usually more than the problem calls for.
Integrate, or replace with one system
The alternative to connecting several systems is to replace them with one product that does everything. This is the idea behind ERP (enterprise resource planning) software: accounts, stock, orders and purchasing in a single package sharing one database, so that nothing between them needs integrating.
It is the right answer for some businesses, particularly smaller ones whose needs a single product covers well. The cost is that you take the product’s way of doing every job, including the jobs your current specialist systems do better. If each of your systems is good at its task and the trouble lies in the gaps between them, closing the gaps is the smaller and safer project.
Integration is also one of the foundations of automation. Once data moves by itself, the steps around it can follow, as we describe in understanding business process automation.
What to find out before you start
Most of what decides the cost of an integration can be established before anyone writes code. For each of the two systems, find out:
- whether it has an API, and whether your edition and licence include access to it;
- whether using the API carries an extra charge;
- if there is no API, what it can import and export, and in which format;
- whether the vendor offers a test account, so the integration can be tried away from live data;
- whether a ready-made connector between the two products already exists. If it does what you need, use it.
Then write down, for the hand-off you want to remove, how many records pass through each week and how long each takes to re-type. Those figures tell you what the integration is worth, and a supplier will need them to quote. Our fixed-price system integration package starts with the same checks on both systems.