Trap 9 - The integration

The bridge that missed by 54 centimeters

Laufenburg is one town split in two by the Rhine: half German, half Swiss. In 2003, the two sides started building a new bridge to join them. Each country built from its own bank, with its own engineers, toward a meeting point in the middle.

Everyone knew the trap in advance. Germany measures heights from the North Sea, Switzerland from the Mediterranean, and the two references differ by 27 centimeters. So the engineers planned a correction. Somewhere in the calculations, it was applied in the wrong direction.

A few days before Christmas, at a routine check, the site team noticed that the two halves would meet 54 centimeters apart. Two sections were already poured in concrete.

The story ends well. The error was caught in time, corrected, and the bridge opened as planned in December 2004. But it surfaced only once concrete was poured, not on the day both teams agreed what “zero” meant. Both teams had done excellent work. Each half was right. The bridge was wrong.

Each half was right

Large programs are built the way that bridge was. The work is split between teams, vendors and systems, each with its own plan, its own backlog and its own definition of done. Each team builds its half carefully. Each reports green.

What no team owns is the middle: the interfaces, the data that flows between systems, the shared environments, the assumptions everyone thought were obvious. So the middle gets built last, at the integration phase near the end of the plan, when everything is supposed to just connect.

That is where programs discover that two systems mean different things by “customer,” that test data looks nothing like production data, that the migration takes three days instead of one weekend, and that the performance test nobody ran fails at a tenth of the expected load. Every one of these problems was there from the first week. They were just invisible until the two halves met.

That is the integration trap: building the parts in parallel and discovering the whole at the end, when every surprise is at its most expensive.

The ten faces of the trap

In 25 years, I have seen it take ten shapes, in three families: when we connect, what we assume, and what we find too late. Most programs that stumble at go-live show at least four of them.

When we connect

Each team on its own bank. The program is split by team, vendor or system, and each part has its own plan. The integration between them belongs to everyone’s plan, which means no one’s.
No walking skeleton. Months into the program, there is still no single flow that runs end to end, from the user’s screen to the last back-end system and back. Every component exists; the journey doesn’t.
Big-bang integration. All the parts are connected at once, in one “integration phase” near the end. When something breaks, nobody can tell which of the twenty new connections caused it.

What we assume

Contracts only on paper. The interfaces are described in a specification document, signed months ago. Nobody tests them automatically, so each side implements its own reading of the same page.
Same word, different meaning. For one system, a “customer” is a person; for another, a contract; for a third, a household. “Date” means booking date here and value date there. Every team is right in its own context.
Environments that don’t match. Integration is tested in an environment with different versions, different configuration and a tenth of the data. It works there. Production is another country.

What we find too late

Migration in one weekend. Moving years of data is planned as a single cutover, rehearsed once, if at all. It takes three times longer than the window allows.
Dirty data, discovered late. Duplicates, missing fields, values nobody can explain. Real data only meets the new system at the first full rehearsal, and every rule written against clean test data breaks.
Performance after sign-off. Functional tests pass, the business signs off, and then the load test runs for the first time. The architecture decisions it would have changed were made a year ago.
Security at the end. The penetration test is scheduled two weeks before go-live. What it finds can only be fixed by delaying the launch or accepting the risk.

Where the truth lives

The integration trap is hard to see because every local signal looks healthy. Each team’s tests pass. Each component is demoed. The risk doesn’t live inside the parts; it lives between them, and the cost of a gap grows with every month it stays hidden.

Two halves, two units. In 1999, NASA lost the Mars Climate Orbiter after a journey of nine months. One team’s software produced thrust data in pound-force seconds; the navigation team expected newton-seconds. Both teams were competent, both pieces of software worked, and the spacecraft came in too low and was lost. The interface was the only thing nobody tested end to end.

Seven servers out of eight. In August 2012, Knight Capital deployed new trading code to its order-routing servers, but one of the eight never received it. An old flag, repurposed for the new feature, woke up a dormant program on that server. In about 45 minutes, the firm accumulated losses of over 400 million dollars, and needed a rescue within days. Every server worked exactly as configured. They just weren’t configured the same.

The pattern behind both stories is the same one programs live every day. Integration problems are not harder than other problems; they are later. A mismatch found in week two costs a conversation. Found in the integration phase, it costs a replan. Found in production, it costs the program’s credibility.

Early signals

You can measure the gap in the middle long before the halves meet:

Months into the program, no user journey runs end to end.
The plan shows integration as a phase near the end, not as continuous work.
Nobody can name the owner of the integration between two given teams.
Interfaces are described in documents, but not tested automatically.
Two teams use the same business term and give different definitions.
The test environment has a fraction of production’s data, or data that is far too clean.
The data migration has never been rehearsed with real volumes.
The load test and the security test are scheduled after functional sign-off.
Every team is green, and nobody can say whether the program works.

Build the bridge from the middle

The answer isn’t to stop splitting the work. Large programs need parallel teams. It is to agree on “zero” first, connect early, and keep connecting: make integration the program’s daily heartbeat, not its final exam.

Build a walking skeleton first. Before any component is complete, connect the thinnest possible end-to-end flow through every system, in a production-like environment. Then thicken it. From week one, the bridge exists; it just isn’t wide yet.
Name an owner for the middle. Every interface between two teams has a named owner, and the end-to-end flow has one accountable person. Integration is a deliverable, not a phase.
Turn contracts into tests. Describe every interface in a machine-readable form and test both sides against it on every change, with contract tests. A broken contract fails a build, not a go-live.
Agree on the words. Write a short shared glossary for the business terms that cross system boundaries, with an owner for each definition. When two systems mean different things, make the translation explicit, in one place.
Keep environments honest. Build every environment from the same code and configuration, and check that what is deployed is what you think is deployed. Differences between environments should be deliberate and listed.
Rehearse the migration, again and again. Migrate real data early, with real volumes, and reconcile the results automatically. By go-live, the cutover should be the tenth rehearsal, not the first performance.
Meet the real data early. Profile production data in the first month. Its duplicates, gaps and oddities are requirements, not surprises.
Test performance and security from the start. Make load and security checks part of the pipeline, against the walking skeleton, so their findings arrive while the architecture can still change.
Integrate continuously, release often. Small, frequent integrations mean that when something breaks, only a few changes could have caused it. Big-bang integration means everything did.

What to avoid

An “integration phase” at the end of the plan.
Interfaces that exist only as signed documents.
Assuming two teams mean the same thing by the same word.
Testing with clean, small data and calling it representative.
A single, unrehearsed migration weekend.
Load and security tests scheduled after sign-off.
Reporting each team’s status without an end-to-end view.

The AI twist

AI makes each team build its half of the bridge faster. That sounds like good news, and inside each team it is. But faster halves don’t meet more precisely; they just meet sooner, with more concrete poured on each side. When every team can generate a service, a schema or an API in an afternoon, the number of interfaces grows faster than anyone’s ability to check them. And an AI agent working inside one team’s repository sees that team’s world: it will happily implement “customer” the way that codebase defines it, with no idea the system next door means something else.

Used on the middle rather than the halves, AI changes the game the other way. It can read two interface specifications and list where they disagree. It can generate contract tests, synthetic data with realistic oddities, and reconciliation scripts for each migration rehearsal. It can compare environments and flag configuration drift before it reaches production. The best use of AI in a large program may well be the least glamorous one: patiently checking that the two halves will meet.

Agree on zero

The Laufenburg bridge stands today, carrying cars and pedestrians between two towns that were always one. Locals still smile about the 54 centimeters. The engineers fixed it because someone checked the middle before the deck was closed.

The best programs I’ve worked on were not the ones with the best teams on each side. They were the ones where someone walked the middle every week: running the end-to-end flow, comparing definitions, rehearsing the migration until it was boring. Their go-lives were quiet. That is the highest compliment a program can earn.

So at your next program review, ask one gentle question: can you show me one real transaction, end to end, through every system, today? If the answer is “not yet, that’s planned for the integration phase,” you already know where your 54 centimeters are hiding.

Have you ever watched two halves of a program meet in the middle, or miss? I would genuinely love to hear your story.

All situations described here are composites, drawn from many programs over 25 years.