Conway's law is your integration bill

Your integration bill is Conway's law with a price tag. Systems end up shaped like the organisations that build them, so if you buy order capture, stock, loyalty and delivery from four different vendors, you have bought four system boundaries. Each one needs an API contract, a mapping layer and a standing steering meeting. Middleware is the invoice for that structure. The fix is one team owning one domain model, end to end.

Where does the integration tax come from?

Melvin Conway first stated it in a 1968 paper: any organisation that designs a system produces a design whose structure copies the organisation's own communication structure. Read your route-to-market architecture back through that lens and it stops being a technical diagram. It is a redraw of your procurement decisions. Four vendors means four account teams, four release calendars, four support queues and, the expensive part, four different definitions of the same outlet, the same SKU and the same order.

The boundary between order capture and stock is not a law of physics. It is the seam between two purchase orders. Nothing about capturing an order and decrementing stock requires them to live in separate systems speaking different dialects; that separation exists because two suppliers sold you two products. The architecture inherited the org chart exactly as Conway said it would, and every seam it inherited now needs owning, translating and reconciling for as long as the platform lives. The disagreement is never resolved, only mediated, invoice after invoice.

What does a single boundary actually cost?

A vendor boundary is never one line item. It is a bundle that arrives quietly and stays for the life of the contract.

None of these are strategic. They are the running cost of a seam that neither vendor owns and neither will remove, because the seam is where their responsibility ends and the invoice begins. Put a number on it and the scale becomes hard to ignore. In Forrester's 2019 Total Economic Impact study of MuleSoft Anypoint Platform, the composite organisation was assembled from four interviewed companies, roughly the vendor count of a large brewer's route-to-market stack, and Forrester put the platform's three-year benefit at $7.8 million against a 445% ROI. The reduced-maintenance line alone, the cost of simply keeping integrations breathing, came to $1.6 million over three years, with a 90% cut in the time engineers spent maintaining APIs. Read the direction of that number: the saving is that large only because the maintenance bill was that large to begin with. Middleware is Conway's law monetised, and the same seams show up again in your cost-to-serve per order.

Why doesn't more middleware fix it?

Because an integration platform industrialises the boundaries; it does not remove them. It makes each seam cheaper to build and faster to monitor, which is real value, but it also makes the seams permanent. You now employ, or rent, a team whose entire job is to keep the boundaries healthy, and a boundary with a dedicated owner never dies. You have optimised the collection of the tax, not repealed it. The four models still disagree about what an outlet is; you have simply automated the argument and put it on a support contract. Every new capability you add has to be threaded through all four seams before it reaches a customer, so the platform that was meant to speed you up quietly sets your ceiling instead.

How do you actually repeal it?

The fix is structural, not another tool. If the architecture copies the org, change the org that designs it: the move Team Topologies calls the reverse Conway manoeuvre. Concretely, in the order you should do it:

1. Map the value stream, not the org chart. Draw order to delivery to cash as one continuous flow. The vendor logos sitting on that diagram are an accident of procurement, not a boundary the business actually needs.
2. Agree one canonical domain model. Outlet, SKU, order, delivery and returnable get defined once, not renegotiated at every seam. This is also the precondition for automation: an agent that can only see one system at a time cannot plan a route or reconcile stock without a human stitching the models back together first.
3. Give the whole stream to one team. Team Topologies calls this a stream-aligned team: one team owns the slice end to end, builds it and runs it, with no hand-offs. Shape the team you want the architecture to have, and the architecture follows the team.
4. Put every capability on one event bus. Order capture, stock, loyalty, returnables and delivery emit to one shared event spine as internal modules rather than integrated products. The seams become function calls instead of contracts, and the event stream doubles as the audit trail your finance and compliance people were going to demand anyway.
5. Keep the one boundary you actually want. The SAP financial core stays the system of record. That is a single, deliberate, well-documented seam, the opposite of four accidental ones, and it is the boundary worth paying to maintain because it earns its keep.
6. Measure translation layers, not story points. The health metric for this programme is the count of mapping layers and standing integration meetings still on the books. Every one you delete is a line of the org chart you have stopped paying rent on.

The brewer we onboard next year will not ask us to integrate four systems well. The sharper question is why there are four at all. As agents start to plan delivery routes and reconcile returnables on their own, the ceiling on what they can do is the number of models they have to reconcile before they can act at all. One domain model has stopped being a tidiness preference; it is the substrate the next wave of automation runs on. Whatever org chart you sign off this year, you will be paying for its diagram in next year's integration budget.