The Customer Is the Integration Layer

Tuesday, 5:01 PM. The store is officially closed now, though the lights are still on and the gate is half-down.

The cashier has been on the phone for fourteen minutes. The pair of sunglasses I bought online sits on the counter between us, in its original box, with the receipt visible through the cellophane. I have given my order number three times — once to the cashier's terminal, which could not look it up; once to the automated phone system that answered when she dialled customer service, which asked for it before the system itself could match it to a human; and a third time, just now, to the live agent who has finally picked up, who is reading it back in case the line drops before he can find my account. Like it did last time.

There are four systems in this exchange, by my count. The in-store point-of-sale, which knows about purchases made here. The e-commerce system, which knows the sunglasses exist. The IVR system, which knows my account number when I say it. And the customer service application the human agent is working in, which is the only system that can authorise the refund and the only system, apparently, that none of the other three is connected to.

The cashier apologises for the fourth time. I am not angry. I am taking notes.

The work I am doing right now — saying my order number aloud to four systems in series — is what an integration layer is supposed to do. There is supposed to be middleware that does this. There is supposed to be an enterprise architect, somewhere, whose KPI is preventing exactly this. The work has not gone away. It has been redistributed. The integration layer is me.

The seams are the experience

Here is the line I keep coming back to. The customer does not experience your org chart. They experience the seams between your org chart.

The bot does not know what the website knows. The agent asks the customer to repeat what the bot already heard. The email campaign references a promotion the contact centre has no record of. The mobile app shows one balance, the web portal shows another, the call centre representative has access to neither. The order placed online cannot be returned in store, except by a phone call to a third system that needs the order number recited a fourth time.

These are the seams. Each one is a place where the org chart is leaking through to the customer's experience. Each one is small. Each one is a tax the customer pays in time, frustration, and goodwill that the company collects without recording it as revenue.

The seams are not the result of any individual team's failure. The seams are the result of every individual team's success. Digital owns the website and has built it beautifully. The contact centre owns the agent desktop and has built it expertly. Loyalty owns the points programme and has tuned it to within a basis point of the optimum. Each team has a roadmap. Each team has a KPI. Each team has done what was asked of it. The seams exist precisely because none of those KPIs include the spaces between them.

That is what your customer is paying for.

When systems can't share context, the customer does

The integration cost was supposed to be someone else's problem.

For thirty years, every enterprise architecture diagram has had a layer in the middle. The word for it has changed every five years — middleware, ESB, integration platform, agentic orchestrator. The function has not. The job is to make systems share context so that humans do not have to.

The job has not, generally, gotten done. The layer exists, the cost has been quantified to the dollar, but the residual work that does not fit on a balance sheet has been redistributed. For thirty years, it has flowed downhill to the customer.

A version of this argument appeared in my last piece, on CCaaS and CRM. The line was: bolt-on architectures do not eliminate the tax. They redistribute it. In the CCaaS context, the tax was on the agent. In the customer-service context, on the contact-centre team. In every context I have ever seen, the bottom of the redistribution chain is the same person. It is the customer.

The customer is the integration layer because no other layer is doing the whole job. The agent in the live chat is doing some of it. The cashier in the store is doing some of it. The middleware is doing some of it. The customer is doing the rest, in real time, every time they say their order number to a fourth system.

This is the integration cost. It just does not appear in any vendor's pricing.

The seamless lie

The word seamless appears in every vendor pitch. The word seamless is also, by my own deliberate choice, banned from the style guide of this publication. The reason for the ban is in the seams.

The seamless experience is not the one where the seams do not exist. It is the one where the customer cannot feel them. Those are different conditions. A reasonable enterprise architecture might aspire to either. Twenty-five years of CX investment has aspired to the second one — make the seams invisible, hide them in handoffs, soften them with apologies — and ended up producing experiences full of seams that the customer feels but cannot describe.

Real seamlessness is the first condition. The seams cannot exist. Not because the systems have been wallpapered over, but because the architecture beneath them was not built four systems wide in the first place.

That is a different shape from the one most enterprises are buying. The next CCaaS contract on your desk cannot deliver it, because that contract is a fifth system in a five-system stack.

The customer at the four-system retailer's counter can describe none of this. She just knows that something is wrong, and that she is paying for it.

I walk back through the empty store and out to the car. Before pulling out of the parking lot, I sit for a moment thinking about which of the four teams behind the counter could have built it better. The answer is none of them. Each of them, given the project, would have built it beautifully. The systems would still have been four systems, and I would still have been the integration layer between them.

That is the realisation. The seams I felt at the counter were not built by anyone in particular. They are produced by an architecture that produces seams in the same way water produces a coastline. Whether anyone meant to or not.

There is a sixty-year-old principle in software engineering that explains exactly why. I will name it in the next piece.