Systems Integration · Software Insight

The word that means six different things

Integration is asked about constantly and defined almost never, which is how the same word ends up covering six different arrangements: a scheduled file export on a server at midnight; a live lookup that reads the other system on demand; a one-way feed that pushes transactions across; a genuine two-way sync with conflict handling; a shared database; and a person who re-keys between two screens. All six are sold as integration. They differ in the only ways that matter — how fresh the data is, who wins when two systems disagree, and what happens when the connection fails at month end.

One system of record, pushed outward to the systems that need to know

What breaks when it is done badly

The failure mode is usually quiet divergence: two systems that agree in January and disagree by June, with no record of when they parted company. Reconciliation becomes a standing task for the one person who understands both systems. The second failure is an integration nobody documented, maintained by nobody named, found broken only when its figures were wrong for a quarter.

Decide where truth lives

The purpose of integration is to decide which system is authoritative for each record. Before designing one, answer three questions: which system is authoritative; how often the other system needs to know; and what happens when the link is down. The preference that follows is one authoritative record, pushed outward, with the receiving system holding a read-only copy. The ledger is the source for financial figures, and the reporting module reads rather than stores.

What to do about it, whatever you buy

Name the system of record for each type of data before you name the interface — most integration pain is unresolved ownership wearing a technical costume. Prefer fewer, duller mechanisms: a nightly feed that is monitored and logged beats a clever live sync nobody can debug. Insist on a visible failure: an integration that fails silently is worse than no integration, because it is believed. And document the arrangement in one page, including who is told when it breaks; the page will be read once, in a crisis, by somebody who has never seen it before.

One system, or integrated systems

Where a single system covers the work, it is better: no interfaces, no divergence, one vendor. Specialist systems exist for payroll, industry-specific software and customer-facing platforms. The choice is to replace when replacement is safer, or integrate when the specialist system earns its place, and in either case to write down which system owns which truth.

Questions this view raises

Should the interface be real-time?
Rarely. Real-time is worth its complexity only when a decision is made within minutes on the incoming figure — stock availability at a counter, for example. For financial and reporting data, an hourly or nightly feed is fresher than the business cycle that consumes it, and far easier to monitor and repair. Ask what decision the delay would break; if the honest answer is none, buy the scheduled feed and spend the difference on logging.
Who owns an integration once it is built?
Someone named, on both sides, with the failure notification routed to both — and this is written into the handover document, not left to convention. Integrations rarely break at the moment they are built; they break eighteen months later when one system is upgraded. A named owner and a monitored log turn that from an investigation into a Friday-morning fix.
Where this shows up in our software

InsightSuite names one system of record for each type of data, with other systems reading rather than storing. You can see these principles applied on the projects pages and throughout the InsightSuite module pages.

« All Insights Next Insight »