Why Your Systems Do Not Talk to Each Other

Nobody sets out to build disconnected systems. It happens one sensible decision at a time. Sales needed a CRM, so they got one. Finance needed accounting software, so they got that. HR needed something for attendance. Each choice was correct in isolation.

The cost only appears later, and it appears as people: someone whose job is partly to move information between two screens, and a set of spreadsheets that exist purely to reconcile systems that should already agree.

What disconnection actually costs

The obvious cost is time spent re-entering data. The larger costs are quieter.

• Nobody knows which number is right. Two systems hold a version of the same figure and they disagree. Meetings get spent reconciling rather than deciding.
• Questions become projects. "How many customers who called support last month renewed?" should be a query. When calls live in one system and renewals in another, it becomes an afternoon of exports.
• Errors are invisible until they compound. A transcription mistake does not announce itself. It surfaces at an audit, or when a customer notices.
• Onboarding gets harder. New staff have to learn not just the systems but the undocumented conventions that hold them together.

The four reasons systems stay disconnected

1. Nobody owns the gap

Sales owns the CRM. Finance owns accounting. Nobody owns the space between them, so the person doing the manual bridging becomes the integration, and because they cope, the problem never gets escalated.

2. The tools do not agree on what things are

This is the real technical difficulty, and it is rarely about APIs. One system's "customer" is a billing account; another's is a person; a third's is a company domain. Same word, three meanings. Before anything can sync, someone has to decide which is authoritative and how the others map to it.

3. One of them was never designed to share

Older systems, and some newer ones with commercial reasons to keep you inside them, offer no usable API. The options narrow to file exchange, a scheduled export, or a vendor conversation. Worth knowing before you buy, not after.

4. The integration was scoped as a one-off

Someone writes a script that syncs two systems. It works. Then a field is renamed, or an API version is retired, and it silently stops. Integration is a system that needs monitoring and an owner, not a task that gets completed.

What integration actually involves

The engineering is usually the smallest part. The work looks like this:

• Agree the source of truth for every shared entity. If the CRM and the accounting system disagree about a customer's address, one of them wins. Decide which, in advance.
• Map the fields honestly, including the ones that do not map cleanly. The awkward ones are where the value and the bugs both live.
• Choose a direction. One-way sync is far simpler than two-way and is enough more often than people expect. Two-way sync means deciding what happens when both sides change between syncs.
• Decide on timing. Real-time is not always better. Nightly is easier to reason about, easier to re-run, and adequate for most reporting.
• Clean the data first. Syncing duplicates produces duplicates in two systems instead of one.
• Plan for failure. What happens when one side is down? Retry, queue, alert. Silent failure is the worst outcome, because the data keeps diverging while everyone assumes it is fine.

Three patterns, and when each fits

Point-to-point

A direct connection between two systems. Simplest to build, and the right answer when you have a small number of connections. The catch is that the number of possible connections grows much faster than the number of systems, so a point-to-point approach that is tidy at three systems becomes a tangle at seven. Fine for a handful, and worth revisiting once you are adding the fourth or fifth.

Hub and spoke

Every system connects to one central place that holds the authoritative record, and data flows through it rather than directly between tools. More work upfront, much less as you add systems, and it forces the source-of-truth question to be answered explicitly rather than implicitly. This is usually where a growing business should end up.

Scheduled file exchange

Unglamorous, and the correct answer more often than people expect. If one system has no API, or the data only needs to be current as of this morning, a nightly export and import is cheap, easy to re-run when something goes wrong, and trivial to reason about. Do not build a real-time pipeline for a report somebody reads on Mondays.

What it costs to run, not just to build

Integration budgets usually cover the build and stop there. The ongoing costs are real and predictable:

• API versions get retired. Vendors deprecate on their schedule, not yours. Someone has to notice the deprecation notice and act on it before the cutoff.
• Fields change. Somebody renames a field or adds a required one, and a sync that has worked for a year starts rejecting records.
• Volume grows. A sync that handles a hundred records a day may not handle five thousand, and rate limits arrive without warning.
• Monitoring is not optional. The thing that makes integrations expensive is not breaking, it is breaking quietly. A simple daily check that record counts match on both sides catches most of it.

A sensible rule is to treat an integration as owned software with a named owner, not as a completed task. The alternative is discovering in an audit that two systems diverged four months ago.

Telling a cheap gap from an expensive one

Not every disconnection is worth closing. A rough test:

Likely cheap: both systems have documented APIs, the shared entity means the same thing on both sides, one direction is enough, and the data is reasonably clean.

Likely expensive: one system has no API, the entity definitions genuinely conflict, both sides must be able to edit, the existing data is full of duplicates and free-text fields used as status flags, or the sync has to be immediate for an operational reason.

Expensive does not mean not worth doing. It means find out before you commit, not halfway through.

Where to start

Follow one piece of information end to end. Take a customer, or an order, or an employee, and trace every system it touches and every point where a person moves it by hand. That trace is your integration backlog, ordered by how much manual handling each step carries.

The step where someone is copying between screens daily is where to start, for the same reason it makes the best first automation: the rules are clear, the benefit is immediate, and it usually exposes the real source-of-truth question you were going to have to answer anyway.

Yoddha Lab does API development and integration as a software development service, and communication systems integration as part of business process reengineering. We run it internally too: Calilio integrates with LeadHeed CRM so call activity and customer records stay in one place. Related: what to automate first.