Modern websites rarely operate independently.
A CMS may need to exchange information with a CRM, ERP, product information system, fulfilment provider, identity platform, search service, payment provider or several other systems.
Connecting those systems is often straightforward.
Building integrations that remain understandable and reliable over several years is harder.
The difference usually comes down to architecture.
Point-to-point works — until it doesn't
A direct connection between two systems can be perfectly reasonable.
The problem appears when direct connections become the default solution for everything.
The CMS sends customer information to the CRM. The CRM sends something to the ERP. The ecommerce platform updates the fulfilment system. Another process synchronises product information back to the website.
Over time, business rules become distributed across multiple connections.
Eventually, answering a simple question such as “Where does this value come from?” can require investigating several systems.
The technical problem is not necessarily the number of integrations. It is the absence of clear boundaries and ownership.
Start with the source of truth
For every important piece of data, establish which system owns it.
Where is a product created?
Which system owns its price?
Where is customer information mastered?
Which platform determines stock availability?
Can information be edited in more than one place?
Without clear answers, integrations can create circular synchronisation and conflicting updates.
Defining a source of truth makes the direction of data movement explicit and dramatically simplifies troubleshooting.
Define the contract
An integration should have an understandable contract.
What information is exchanged? When does it move? What format does it use? What happens when fields are missing? Which changes are backwards compatible?
These questions become particularly important when different teams or suppliers own different systems.
Without a defined contract, seemingly harmless changes can have unexpected consequences elsewhere.
Design failure before success
Most integration diagrams describe what happens when everything works.
Production systems need to describe what happens when it doesn't.
What if an API is unavailable?
What happens if the request times out?
Should it retry?
Could retrying create a duplicate order?
What happens to the original data?
Can someone replay the operation?
Does anyone know that it failed?
These are architectural questions, not edge cases.
External systems will eventually become unavailable, return unexpected information or change behaviour. A robust integration assumes this will happen and provides a controlled response.
Logging needs to answer useful questions
Logging should make it possible to understand what happened without recreating the problem.
That usually means being able to identify the transaction, the systems involved, when it occurred, whether it succeeded and why it failed.
Logs should also be usable by the people responsible for supporting the platform.
A technically detailed log that nobody knows exists is not an operational solution.
Decide who owns the integration
Ownership is frequently overlooked.
If the website successfully sends information but the receiving system rejects it, whose responsibility is it to investigate?
If a third-party API changes, who coordinates the response?
If an integration fails outside office hours, does anything need to happen?
The answers will vary between organisations. What matters is making them explicit.
Keep the architecture understandable
Sophisticated architecture is not automatically good architecture.
Queues, middleware, event buses and integration platforms can solve genuine problems, but they also introduce infrastructure and operational overhead.
Sometimes a direct API connection is exactly the right solution.
The objective should be the simplest architecture that provides the reliability, visibility and flexibility the organisation actually needs.
A good integration architecture is not defined by how many technologies appear on its diagram.
It is defined by how easily the team can answer four questions:
Where did the data come from?
Where is it going?
What happens when it fails?
And who is responsible for fixing it?