Systems Integration Is A Language Choice, Not A Purchase

How Should You Choose An Integration Tool?

Judge an integration tool the way you would judge a programming language, because that is what it is.

Ask who can read the rules written in it. Ask what happens to a change when two people make one in the same week. Ask what you can see in a diff. Those questions decide the cost of the next decade, and none of them appears on a connector list.

Then ask the prior question, which Byars argues is the one that actually matters: what capability are you putting an interface in front of.

An Integration Product Is A Programming Language

The claim is Byars' and it is stated plainly. Integration software products are programming languages, bundled with a toolchain and a runtime.

Once that lands, the shortlist changes shape. A comparison of two integration platforms is a comparison of two languages, two editors, two ways of reviewing a change and two hiring markets. A row counting prebuilt connectors is a row about the easiest part of the job.

The easiest part is worth having. Nobody wants to hand write an OAuth flow against a well documented API for the fourth time. But the connector gets you to the boundary of the other system, and everything that happens after that boundary is your business logic, written in whichever language you just chose.

That is where the money goes. In my experience, the connector is a week and the rules are the following two years.

The Superpower You Give Up

Byars makes one point that I have never once seen raised in a tool selection, and it is the most practical thing in the article.

The ability to diff changes between source code commits, he writes, is a developer superpower.

A markup based dialect, or a canvas of boxes and arrows, cannot match that. You can usually export something. What you cannot do is read a change the way you read a code review: this line, this condition, this default, changed by this person, for this reason, on this date.

Everything downstream of that depends on it. Code review depends on it. Bisecting a regression to the change that caused it depends on it. Explaining to a finance director why an invoice routed the way it did depends on it.

Byars also points out that low code platforms make parallel development painful and constrain how a team grows. That is the same problem seen from the staffing side. If two people cannot safely change the integration in the same week, the integration becomes one person, and that person becomes a risk you are not tracking anywhere.

Interfaces Over Systems

The strategic half of Byars' argument is a change of question.

He describes a mandate to use a particular integration tool as putting the emphasis on implementation over interface. The organisations that get value, in his account, are the ones that stop asking how to connect system A to system B, and start asking which business capability they are exposing.

His telecom example makes it concrete. Exposing a clean interface for purchasing plans proved more valuable than exposing the underlying billing system's complexity to the developers who had to consume it.

That is not an abstraction. It is the difference between an integration that survives replacing the billing system and one that has to be rewritten when you do. If every consumer is coupled to the billing system's own shape, the billing system can never be replaced. If they are coupled to a purchase interface you own, it can.

So the useful first question in a scoping conversation is not which platform. It is: name the capability, and name who consumes it.

The Two Integrations You Pay For Anyway

Whichever way the tool decision goes, two costs land, and neither is optional.

The first is the interface itself. Someone has to decide what a clean version of your capability looks like, in your language, for your consumers. No product ships that, because no product knows your business. This is the work Byars is pointing at and it is the work most quotes leave out.

The second is everything the other side does when it is not behaving. Retries. Partial failures. The order that arrives twice. The field that is optional in the docs and mandatory in practice. The endpoint that returns 200 with an error in the body.

I have never seen a bought platform remove either. I have seen plenty of quotes that assume it will.

This is the same trap as the wider build or buy decision, which is why I wrote that one up separately using Martin Fowler's differentiator test. Byars' point is the integration specific case of it.

Why The Second Integration Costs More Than The First

There is a cost curve here that nobody draws at the start, and it is the reason integration estates get expensive quietly rather than suddenly.

Connect two systems directly and you have one connection to maintain. Connect three and you have three. Connect six and, if everything talks to everything, you have fifteen. The connections grow faster than the systems do, which is why the second integration always feels cheap and the seventh does not.

That is the arithmetic behind Byars' point about interfaces. If every consumer talks to a capability you own rather than to the system behind it, adding a consumer adds one connection rather than a row of them, and replacing the system behind it adds none.

The reason it stays hidden is that nobody is ever asked to price the estate. Each integration is scoped on its own, against its own business case, and each one looks reasonable in isolation. The cost lands on whoever is holding it when something has to change, which is usually years later and usually a different budget.

So the useful question in year one is not what this integration costs. It is what the fifth one will cost if this pattern is repeated, and whether anyone will be able to tell what the fourth one does by then.

That arithmetic is mine rather than Byars', though it follows from his argument. He is making the case for interfaces on grounds of organisational acceleration. I am making the narrower point that the same change also stops the maintenance bill compounding.

When A Product Is The Right Answer

None of this argues for writing everything from scratch.

Byars is not against commercial tools. His conclusion reorients their value proposition towards simplifying tactical implementation concerns, which is a real and useful thing to buy. Scheduling, retry semantics, queueing, monitoring, credential storage and the connector to the well documented API are all work you do not need to repeat.

The line I would draw from that, and this is my reading rather than his claim, is that a product is worth buying for the plumbing and worth resisting for the rules. Buy the runtime. Keep the business logic somewhere you can diff, review, test and hire for.

Where the rules are trivial and stable, that distinction costs you nothing and you can leave everything in the tool. Where the rules encode how your business actually works, putting them in a dialect only one vendor's editor can read is a decision you make once and live with for years.

Signs Your Integration Estate Is Storing Up Cost

Five signals.

1. The shortlist compares connector counts and nobody has written down which capability is being exposed.
2. One person can safely change the integration, and everyone knows who it is.
3. You cannot produce a readable history of what the integration did differently this month compared with last.
4. A system you want to replace cannot be replaced, because every consumer is coupled to its internal shape.
5. The business case has a licence line and no line for the rules, the retries or the failure handling.

Signal four is the expensive one. It is usually discovered years after the integration was signed off as finished, at the exact moment someone wants to change something else.

If any of those apply, you can Request The Free Scoping Audit. The What We Build section is on the main site.

Common Questions About Systems Integration

What Are Systems Integration Services?

Work that connects separate applications so data moves between them without a person retyping it. In practice it covers the interface you expose, the business rules that run inside it, and the handling of everything the other system does when it misbehaves. Tools cover the connection, not the rules.

Is Buying An Integration Platform Cheaper Than Building?

It depends what you count. Byars describes integration products as programming languages bundled with a toolchain and a runtime, so the platform gives you the plumbing rather than the logic. The rules, the interface and the failure handling remain yours to write and maintain either way.

What Is Wrong With Point To Point Integration?

It couples every consumer to the internal shape of the system being consumed. That is fine until you want to replace that system, at which point every consumer has to change too. Byars argues for putting a clean interface in front of the capability instead of exposing the underlying complexity.

Why Does Byars Say You Cannot Buy Integration?

Because the product is a language, not an answer. His article, published on martinfowler.com in December 2021, argues buying decisions exaggerate what such tools deliver, and that the principles behind modern integration are best managed in a general purpose language rather than a vendor dialect.

What Should I Ask A Systems Integration Supplier?

Which capability is being exposed and who consumes it. What a change looks like in a diff. Whether two people can change the integration in the same week. What happens on a partial failure. Those four answers predict the cost of the next five years better than a connector list.

Part of The Development Guide. See also What Decides Whether A Web Application Is Safe To Ship and How To Decide Whether To Build Or Buy.