Software engineering · Systems integration and APIs
Connecting the systems you already use
We design APIs around an agreed specification, set up event-based messaging and build connections to your existing business systems. When something fails, it is retried and reported automatically, rather than discovered at the end of the month.
Where this starts
The data exists, but it does not move
Most organisations do not have a data problem as much as a problem moving data between systems. A record is created correctly in one system, then typed into another by hand. Either the connection was never built, or it was built by someone who has since left and it now fails without telling anyone. The cost is rarely counted, because it is spread across many people who have simply absorbed it into their working day.
What we usually find
- The same record typed into two systems by two different teams
- A nightly file transfer that fails without warning and is only noticed at month end
- A connection that creates duplicate orders whenever it retries
- A change to a supplier’s API that broke something, first noticed by a customer
- No record of which systems are connected, or who is responsible for each connection
- Reports from different systems that disagree, with no way to tell which is right
Our position
A connection that can create duplicates when it retries, and that nobody monitors when it fails, will eventually cause a problem. The only question is when.
What the work covers
Agree the specification first, then build the connection
Integration projects rarely fail because of the technology used to move data. They fail because nobody agreed exactly what should be sent, or what should happen when the other system is unavailable.
API design
We agree and publish the API specification before building anything. Both sides then build against the same definition, and nobody has to work out the format by trial and error.
Event-based messaging
Where systems should not have to wait for each other, they exchange messages through a queue. We decide in advance how to handle message order, replaying messages and messages that cannot be processed, rather than discovering these problems when the system is busy.
Safe retries and failure handling
Retries cannot create duplicates. Messages that fail go to a separate queue that someone monitors. When a connected system is slow, we reduce the rate of retries so the problem does not spread to everything else.
Connections to business systems
We connect ERP, CRM, finance, payments, logistics and marketplace systems. The hardest part is usually not the technical connection. It is reconciling the different ways two systems describe the same thing, such as a customer or an order.
Versioning
We release changes without breaking existing users of the API. There is a clear process for retiring old versions, and you can see who still uses an old version before removing it.
Partner and public APIs
We provide documentation, a test environment, authentication and usage limits. A partner can then connect to you without needing a call with your engineers.
How failures are noticed
The difference shows when things go wrong
A reliable connection and an unreliable one look the same while everything is working. These are the things that set them apart when something fails.
- Contract tests
- Both sides are tested against the published specification in the pipeline. A change that would break the connection fails a build, not a customer’s order.
- Replay
- Messages are kept so they can be replayed. Recovering after an outage takes a single command, rather than rebuilding records by hand from log files and memory.
- Data checks
- Record counts and totals are compared between systems on a schedule, and any differences are reported. A silent failure is spotted on the same day.
- Alerts
- We monitor the number of failed messages and how long it has been since the last transfer. A connection that has completely stopped can otherwise look exactly like one that has nothing to do.
- Catalogue
- An up-to-date list of every connection, its owner and its specification is generated from the live systems, rather than kept by hand and left to go out of date.
What you are left with
- Published API specifications that both sides build against
- Connections that retry safely and report failures clearly
- Scheduled checks that the key systems agree with each other
- A catalogue of every connection and its owner
- A versioning and retirement policy your partners can rely on
Tell us which two systems your staff copy data between
That is usually where your biggest avoidable cost is, and it is rarely the one being discussed.