Connecting systems into one whole

An API is an application programming interface: an agreed way for one system to make data available to another without a person involved. An API layer is one place through which the company's systems talk to each other. Each system connects once, to the layer, and the layer knows where to get customer data, where to send an order and what to do when a system does not respond.

We connect systems that are already running. ERP, CRM, industry system, online shop, warehouse program: each has some route for exchanging data, whether a ready-made vendor interface, file export or access to the database. We check which route the system offers and on what terms, and connect that route to the layer. We do not replace the system unless the analysis shows that it is what holds the process back. We treat spreadsheets as a system: if a department works in a spreadsheet, the layer feeds it data and collects the results until the company decides to replace it.

In some sectors the way data is exchanged is set in advance. In telecommunications it is TM Forum, the industry standard for cooperation between operators. If your industry has such a standard, the API layer speaks its language, and your internal systems do not have to know it.

Three things are produced. Interfaces: agreed inputs and outputs for each system, tested on your company's data. Documentation: a description of each exchange, what data, from where, to where, how often and who is responsible for it, in a form the next contractor can read. Exchange monitoring: a view of which exchanges went through, which stopped and why, with a notification to a designated person.

1. We map the data flows. We talk to the people who retype data today and look at the systems from the inside. Outcome: a data flow map and a list of exchanges to build, in order of the manual work each one replaces.
2. We design the API layer. We establish which system is the source of each piece of data, what each interface looks like and what happens when a system does not respond. Outcome: a layer design and interface documentation for your approval before the build.
3. We connect the systems one by one. We launch each connection separately, first on a copy of the data, then in the daily work of one department. Outcome: one exchange after another running on its own, with manual retyping switched off department by department.
4. We hand over oversight. We switch on monitoring, teach a designated person to read the exchange log and hand over the instructions for connecting further systems. Outcome: the exchanges in the care of your team or ours, as the contract sets out.

1. Who holds the interface documentation after the project ends, and is it written so that another contractor can read it?
2. What happens to the data when one of the systems is unavailable for an hour: does it wait, get lost or arrive twice?
3. Who will find out that an exchange has stopped, and how?
4. How much work does it take to connect another system or to change the supplier of one of the current ones?
5. Which personal data passes through the layer, where is it stored and who has access to it?
6. Does connecting to our ERP or CRM require the vendor's consent or licence, and who obtains it?
7. On what data will the connections be tested before launch, and who on our side will confirm the result?

The answers depend on which systems and what data are involved, so we start with an analysis of the process and systems that ends with a scope recommendation.