The glue code is a system, and it needs an owner

Ask an enterprise for its architecture diagram and you will receive boxes. The ERP, the CRM, the warehouse, the portal: named, bordered, owned. The lines between the boxes arrive as an afterthought, thin and unlabeled, as if data moved between systems by good manners.

Then ask where the last five production incidents happened.

The lines are a system. They have always been a system. The industry has now spent three decades learning this lesson, filing it under a new acronym each time, and forgetting it during the next reorganization. It is worth walking the history, because the pattern in it is not about technology at all.

The first era had the honesty to say so out loud. Enterprise Application Integration, the EAI wave of the middle 1990s, was born from the observation that point-to-point interfaces grow quadratically: connect n systems pairwise and you are maintaining on the order of n squared links, each one written under deadline by whoever owned neither end. The hub-and-spoke brokers of that era proposed a fix, and enterprises bought them in quantity. Some integration estates shrank. Many simply gained one more box, with the old point-to-point links continuing quietly underneath, which is a sentence that will recur.

The second era gave the hub a standards body. The Enterprise Service Bus of the 2000s promised that if every system spoke to the bus, in XML, contracts first, the glue would finally be governed. The promise was not absurd; parts of it worked; the reader who was present may remember what the rest was like. The bus became a team, the team became a queue, the queue became the place where projects went to wait, and by the early 2010s "bypass the ESB" was not a confession but a project plan. The glue had acquired governance without acquiring an owner who felt its pain.

The third era, the iPaaS and low-code integration platforms of the 2010s and since, moved the hub to someone else's cloud and sold the connectors ready-made. Genuine progress, for the connections that fit the catalog. The connections that do not fit still get hand-written, except now they hide inside the platform's scripting layer, where they enjoy the oversight of neither the integration vendor nor the enterprise's own review process.

Three eras, one constant: the glue always ends up owned by everyone, which is the institutional spelling of no one. The technology changed; the org chart's blind spot did not.

What would it mean to treat glue as a first-class system? Not another middleware purchase. Three practices, none of them expensive.

First, the connections get drawn. An integration inventory, one row per data flow: source, destination, transport, transformation, owner, and what breaks downstream when it stops. Practitioner write-ups are rarer than vendor papers here, which is why a documented integration platform build is worth reading in full: the inventory and the ownership column do more work than any component choice, and the case makes that visible. Every estate that has suffered a mystery outage already believes this; the inventory merely converts the belief into a document before the next one.

Second, the connections get reviewed. The same architecture board that debates a new service's database for an hour should spend equal time on any new flow crossing a system boundary, because the flow is the part with two owners' assumptions baked into it and no one's tests. A contract is defined here as: the fields, their meanings, their timing, and who is told when any of the three change. Most integration incidents are a contract change that was never announced because no document said announcing was owed.

Third, the connections get budgeted. Glue decays: endpoints version, certificates expire, the file that was always under a megabyte one day is not. An estate that spends zero on integration maintenance is not spending zero; it is borrowing at incident rates, which are the payday-loan rates of enterprise finance.

The conclusion is the one the 1990s reached before losing it in the filing. Connections between systems are load-bearing in proportion to how invisible they are, and drawing them, reviewing them and paying for them costs a fraction of the incidents that follow from treating them as manners. The strongest counterexample deserves its acknowledgment: some glue really is trivial, and an enterprise that reviews every CSV drop with a full board has invented a new way to stop shipping. Judgment about which flows are load-bearing is precisely the skill the inventory builds.

The boxes were never the architecture. The architecture is what happens between them, which is why it fails there.