Why Integration Is Hard

Point-to-point integration grows quadratically, hides in scripts, drifts in quality and concentrates risk in a few people. Here is why.

The problem nobody plans for

No organisation sets out to build an integration problem. It accumulates. The billing platform arrives first, then a CRM, then a support desk, an inventory tool, an accounting package and an online store. Each is excellent at its own job. Each holds its own copy of the customers, and none of the copies quite agree.

Consider a typical internet service provider. Billing lives in Splynx, the network inventory in NetBox, the sales pipeline in HubSpot and support tickets in Zendesk. A customer phones about an outage. The agent needs the account status from billing, the equipment from inventory and the ticket history from support, and those three screens each spell the customer's name differently.

The quadratic trap

The obvious fix is to wire systems together directly. Billing pushes new customers to the CRM. The CRM notifies the support desk. Each link seems small, and each one works, at first.

The mathematics is unkind. With four systems there are six possible links. With six systems there are fifteen. With ten there are forty-five. Every new system does not add one integration, it multiplies the surface that can break. Teams rarely build every link, but even a partial mesh becomes the most fragile part of the estate, because each link was built at a different time, by a different person, in a different way.

Where the knowledge goes to die

Point-to-point links tend to live in scripts, scheduled tasks and one-off jobs. They are rarely documented, because they were meant to be temporary. Nobody dares to touch the overnight sync that has run since 2019, because nobody remembers exactly what it does, and the person who wrote it left.

This is key-person risk in its purest form. The organisation's understanding of how its own data moves exists mainly in a few heads. When those people are on leave, changes wait. When they resign, changes stop.

Drift, silently

Brittle links fail in two ways. The loud way is an error that pages someone. The quiet way is worse. A sync falls behind, or a field stops being copied, and the two systems slowly diverge. Finance reports one number of active customers, operations another, and the board meeting is spent reconciling spreadsheets rather than deciding anything.

Data quality problems of this kind are rarely caused by careless users. They are caused by copies of the same fact living in several places with no single point of truth and no mechanism keeping the copies honest.

The compounding cost

Each of these problems feeds the others. More links mean more undocumented scripts. More scripts mean more key-person risk. More silent drift means less trust in the data, so people export to spreadsheets, creating still more copies. The cost of adding the next system keeps rising, which is exactly backwards. Adding a system should get cheaper as the estate matures, not dearer.

A different shape

The way out is structural rather than heroic. Instead of a mesh of direct links, each system connects once to a central hub that holds the authoritative copy of the shared data. Integration effort then grows linearly with the number of systems, every movement of data is visible and monitored in one place, and the knowledge lives in the platform rather than in someone's head.

That is the shape STRAX is built around. What is STRAX? explains the platform, and How STRAX works walks through the lifecycle from first connection to a live portal.