Reframing enterprise integration from infrastructure tolerated into product surface chosen.
Enterprise integration is almost always framed as plumbing. It is the work of connecting systems that were not designed to talk to each other, in environments that resist being changed, for organisations that have paid for integration before and do not want to think about it again.
This framing has a cost. When integration is treated as plumbing, it gets built, priced, and sold that way: as an operational expense rather than a product surface. The organisations that buy it do so reluctantly, and the teams that build it are rewarded for making it invisible.
We think this framing is doing quiet damage to a large category of enterprise software. And we think reframing it — treating integration as the product surface, not the thing behind the product surface — opens up a different kind of platform opportunity.
What “plumbing” gets wrong
The plumbing framing assumes integration’s job is to move data. From source to destination, with fidelity, reliably, at scale. Move more of it, faster, with fewer failures.
This is true and insufficient. The work that determines whether integration creates value or destroys it is almost never about moving data. It is about modelling it. Deciding which relationships exist between systems, which transformations are canonical, which edge cases to normalise, and which to preserve. Those decisions are not infrastructure decisions. They are product decisions, made by the team that writes the integration.
And because they are made invisibly — inside code, inside pipelines, inside middleware — they are made without the rigour that product decisions normally attract.
The decisions that determine whether integration creates value are not about moving data. They are about modelling it. Those are product decisions.
What changes when integration becomes a product surface
If integration is a product surface, three things shift.
The customer-facing shape of the integration matters. Not just what it does, but how operators think about it, configure it, observe it, and trust it. The best integration platforms treat this surface with the same care a SaaS team would treat a core dashboard.
The modelling decisions become explicit artefacts. What the integration considers the canonical shape of an invoice, or a contact record, or an order line, becomes a thing the team documents, defends, and iterates on. These are no longer hidden inside mapping code; they are the product.
The commercial framing changes. Integration-as-plumbing is sold as infrastructure — priced on throughput, connectors, or data volume. Integration-as-product is sold on the clarity of the model it offers, the decisions it has made on behalf of the customer, and the ongoing value of those decisions. Different pricing, different customers, different competitive landscape.
What we recommend
If you are building an integration platform, stop treating integration as the thing behind the thing. The modelling work your team is doing every day — deciding what is canonical, which edge cases matter, how the integration shapes what customers end up treating as true — is your product. Make it visible.
Document the modelling decisions as first-class artefacts. Build the surface that exposes them to operators, not just to engineers. Price on the value of the model, not the cost of the movement.
The organisations that treat integration this way tend to outcompete the ones that treat it as plumbing, because they have a product to defend and a thesis to iterate on. The plumbing category commoditises quickly; the integration-as-product category does not.