Teams plan the build and then discover that system development integration is the project. The features were understood, the joins between systems were not, and the schedule was written as though connecting two things is a task rather than a phase.
Here are six system development integration rules we hold to, each one learned the expensive way.
1. Start system development integration earliest, not last
The instinct is to build each piece properly and connect them at the end. However, that saves nothing, because every assumption you made about the other system stays unchallenged until the worst possible moment. Make a thin end-to-end path work in week one, even if it carries one field and does nothing useful.
After that, every later change is tested against something real rather than against a document.
2. The other system’s documentation is a hypothesis
It will be out of date somewhere, and the gap is rarely flagged. So call the real endpoint early, record what comes back, and keep those recordings as fixtures. When the behaviour changes six months later, you will have evidence of what it used to do.
3. Decide what system development integration does when the other side is down
Not if. Every integration has an outage, a timeout and a slow day. Decide per call whether the right behaviour is to queue, to retry, to fail visibly or to carry on without it, and write that decision next to the code.
Retries need care too, since a retried payment or a retried email is worse than a failure. Make the operation safe to repeat, or make it impossible to repeat.
4. Agree who owns the truth for each field
When two systems both hold a customer’s address, one of them is right and the other is a copy. If nobody has decided which, you will get a loop where each system updates the other and support cannot explain why the address keeps changing. Write the ownership down per field, not per system.
5. Log the conversation, not just the result
When something goes wrong between two systems, the question is always what was actually sent and what actually came back. Store both, with a correlation identifier that appears in every log line, and redact what should not be kept. This costs very little and saves days.
6. System development integration needs a named owner on both sides
The hardest system development integration problems are organisational. A question about a third-party system takes a day to answer if you know who to ask and a fortnight if you do not. Get a name and a channel before the work starts, and escalate early when answers stop arriving, because waiting politely is the most common cause of a slipped date.
For the architectural side, Martin Fowler’s article on microservices remains a clear explanation of the trade-offs you are accepting when you split systems up in the first place.
System development integration questions we get asked
How much of a project is system development integration?
More than the plan says, routinely a third to a half once you count the failure handling, the field ownership arguments and waiting on answers from other teams. Scheduling it as a phase rather than a task is most of the fix.
Who should own system development integration?
One named engineer on your side and one named contact on each external system. Shared ownership here reliably produces the slowest version of every answer.
Does system development integration need its own test environment?
Yes, and the recorded-response fixtures described above matter more. A sandbox tells you what the other system claims to do; recordings tell you what it actually did.
What good looks like six months in
System development integration stops being the risk. Nobody is surprised by an outage, because the behaviour was decided in advance and is visible in the logs. A new field takes an hour rather than a meeting, since ownership is already written down. And when the third party changes something, you find out from a failing fixture rather than from a customer.
What to put in the plan
A system development integration plan needs four things: a thin end-to-end path in the first week, a named contact for every external system, a written decision on failure behaviour per call, and field-level ownership. Those four take an afternoon to agree and they remove most of the surprises.
Our API integration page sets out how we run this, and the custom software development page covers how it fits into a wider build.
Leave a Reply