System Integration Services: Buy Interfaces, Not Connections

Every enterprise has a number it does not track and cannot easily find: how many point-to-point connections exist between its systems. Nobody knows, because each one was reasonable when it was built. A team needed data, another team had it, somebody wrote a connection, and it worked.

Last updated: August 20, 2026

Then it happened four hundred more times. That is integration debt, and it is the most expensive kind because it never appears as a line item. It appears as every project taking longer than the last one.

What are system integration services?

System integration services are outside help connecting applications, data, and processes so they work as one system, whether that means building interfaces, replacing point-to-point connections, or standing up the platform that carries them.

The work falls into three shapes, and the difference matters more than the tooling.

• Connect. Make two systems talk. Fast, and it adds to the count.
• Interface. Publish a stable, versioned contract that many consumers use. Slower, and it reduces the count.
• Consolidate. Remove a system so the connections to it stop existing.

Most integration budgets are spent on the first, most integration value comes from the second, and the third is the only one that reduces long-term cost. If a proposal is entirely made of connections, it is buying you speed today at a rate you will pay for years.

Why the connection count is the number to manage

The arithmetic is unforgiving. Connect systems directly and the number of possible connections grows with the square of the number of systems. Ten systems can hold forty-five direct connections. Twenty systems can hold a hundred and ninety.

Nobody builds all of them, which is why this feels theoretical until it does not. What actually happens is subtler:

• Change becomes negotiation. Nobody can alter a field without finding out who reads it.
• Nobody owns the middle. Each connection has an author, and the estate has no owner.
• Testing gets impossible. The blast radius of a change cannot be established, so teams stop making changes.
• The same data exists five times. With five definitions, and the reconciliation meeting becomes a permanent institution.

The fix is not a better connection. It is fewer of them, with contracts on the ones that remain.

Buy interfaces, not connections

The practical rule we apply: any data or capability that more than two consumers need should be an interface, not a set of connections.

An interface has properties a connection does not.

The caveat, because this reads as absolutist: connections are fine, and sometimes correct. A one-off feed to a system being retired next year should not be an interface. The judgment is about durability. Build a connection when you know it is temporary and you are willing to write down when it goes away.

Integration is becoming a regulatory requirement, not just an architecture choice

It is worth noting where this is heading, because it changes the business case.

CMS released the Interoperability and Prior Authorization final rule (CMS-0057-F) on January 17, 2024, with a January 1, 2027 compliance date for patient access, provider access, payer to payer, and prior authorization application programming interfaces. That is a regulator specifying that certain capabilities must be reachable by other organizations through documented interfaces, on a date.

Read past healthcare for a moment. The direction of travel across regulated industries is that data has to be retrievable by parties outside your organization on demand. An estate held together by internal point-to-point connections has no way to satisfy that without building the interface layer anyway. So the choice is not whether to publish interfaces, it is whether you do it deliberately now or under a deadline later.

What to do about the estate you already have

Nobody gets to start clean. The practical sequence for an existing tangle:

1. Find the connections. Not perfectly. Enough to know your top ten most-depended-on data flows.
2. Pick the flow with the most consumers and publish an interface for exactly that.
3. Migrate consumers onto it one at a time, and require new consumers to use it.
4. Retire the connections it replaced. This is the step everyone skips, and skipping it means you now have both.
5. Repeat for the next flow. The second is cheaper because the platform, monitoring, and pattern exist.

Step four deserves emphasis. An interface added beside the connections it was meant to replace makes the estate worse, not better. If the plan does not name which connections die and when, it is not an integration plan.

Where this overlaps with the data work

Integration and data engineering are the same conversation approached from different sides. An interface with a contract, an owner, and a freshness guarantee is a data product. A data product without a stable interface is a report.

So the same discipline applies: contract, ownership, versioning, monitoring. That is why we treat data integration and data engineering services as one body of work, why data governance attaches to the deliverable rather than reviewing it later, and why in a legacy estate the interface usually has to come before any modernization of the systems underneath.

For the industry-specific versions, the healthcare sequencing argument is in digital transformation in healthcare, and the claims-side application is in claims automation.

How to measure it

• Connection count, trending down. The headline. If it only goes up, you are buying speed on credit.
• Consumers per interface. Reuse, which is where the economics live.
• Time to onboard a new consumer. Days, not a project.
• Changes shipped without breaking a consumer. Proof the contracts are real.
• Retired connections per quarter. The step teams skip, so measure it explicitly.

Frequently asked questions

Do we need an integration platform?

Eventually, and it is not the first decision. Platforms make good patterns cheaper and bad patterns faster. Teams that buy a platform before deciding what their interfaces are tend to rebuild the same point-to-point estate inside a more expensive tool.

What is the difference between system integration and data integration?

Overlapping vocabularies for the same discipline. System integration usually implies process and application connectivity, data integration usually implies moving and reshaping data. The controls that decide success, ownership, contracts, versioning, and monitoring, are identical.

How do we find our existing connections?

Network and database logs, scheduler jobs, and service accounts get you most of the way. Do not aim for a complete map. Aim for the top ten by consumer count and business criticality, which is a two to three week exercise and enough to start.

How long before this pays back?

The first interface is roughly break-even against just building the connection. The second and third are where it turns, because the marginal cost of a consumer collapses. Programs that stop after one interface never see the return, which is why we scope integration work in threes rather than as a single project.

Where to start

Identify the single data flow with the most consumers, publish one versioned interface for it, migrate two consumers onto it, and retire what they were using. That sequence, done once, teaches an organization more about its integration debt than a full estate assessment, and it leaves the estate smaller instead of larger.