Why integration projects fail:
the governance patterns behind multi-vendor coordination

The integration fallacy

There's a persistent belief in health IT that integration projects fail because of technical complexity. HL7 v2 message mapping is hard. FHIR resource modelling is immature. Vendor APIs are undocumented. The technical challenges are real. But in twenty years of clinical system integration — pathology, radiology, pharmacy, EMR — I've never seen an integration project fail because of a technical problem that couldn't be solved.

Every integration failure I've seen has been a governance failure. The technical solution existed. The organisational structure couldn't support it.

This article maps the governance patterns that make integration projects fail, using the same structural analysis applied to programme delivery. If you recognise the patterns, you can intervene before the integration becomes the kind of multi-year quagmire that gives health IT its reputation.

The boundary problem

Integration projects are unique because the critical work happens at boundaries. The boundary between System A and System B. The boundary between Vendor X's contract and Vendor Y's contract. The boundary between the project phase and the operational phase. Every one of these boundaries is a governance seam — a place where authority, accountability, and information transfer must be explicitly designed.

In a single-vendor delivery, governance seams exist but they're manageable. One vendor, one contract, one accountability chain. In a multi-vendor integration, the seams multiply. Three vendors sharing a patient identifier interface means three contracts, three interpretations of "compliant," three escalation paths, and one PM trying to coordinate across all three without contractual authority over any of them.

The PM can coordinate. The PM can facilitate. But the PM cannot enforce a contract they're not party to, against a vendor they don't manage, on a specification they didn't write.

This is where Authority Vacuum first appears in integration projects. The integration lead role is created with accountability for end-to-end delivery but authority only over the gaps between vendor scopes. The vendors own their scope. The customer owns the contracts. The integration lead owns the spaces in between — which is where all the problems live.

Three vendors, one interface, no owner

Consider a common health IT scenario: a pathology system replacement where results need to flow to the EMR and the GP communication platform. Three vendors. Three systems. Two interfaces. The interfaces are technically straightforward — HL7 ORU messages, well-defined message structures, established transport protocols.

Here's what actually happens.

Vendor A (pathology) builds the outbound interface to specification. Vendor B (EMR) receives the messages but maps three fields differently from what Vendor A expected, because the specification said "map to local code set" and each vendor interpreted "local" differently. Vendor C (GP comms) receives the messages but their system requires a field that the specification marked as optional.

The technical fix takes a developer two days. The governance argument about who pays for the fix, who changes their mapping, and whose specification was ambiguous takes three months. During those three months, clinicians receive pathology results through a manual workaround. The workaround becomes permanent. The Entropy Ratchet turns.

This happens because nobody owns the interface. Each vendor owns their side of it. The gap in the middle — the semantic interpretation, the data quality, the exception handling — belongs to whoever happens to be in the room when the argument starts. Usually the integration lead. Who has no contractual leverage with any of the vendors.

How leverage erodes at the boundary

Leverage Erosion accelerates in integration projects because the buyer's enforcement mechanisms are fragmented across multiple contracts.

In a single-vendor engagement, the buyer holds a contract with defined acceptance criteria, liquidated damages clauses, and a payment schedule tied to milestones. All the leverage sits in one relationship. In a multi-vendor integration, the buyer holds three contracts, each with their own acceptance criteria, each scoped to that vendor's deliverables, none of which explicitly covers the integration between them.

When the interface doesn't work, who's in breach? Vendor A delivered a compliant outbound message. Vendor B delivered a compliant inbound processor. The fact that they don't work together isn't a breach of either contract — it's a gap in the specification. And gaps in the specification are the buyer's problem.

Each concession at each boundary erodes the buyer's position. "We'll absorb the mapping change this time." "We'll fund the gap analysis." "We'll extend the testing window." Individually rational. Cumulatively devastating. By the time the integration reaches UAT, the buyer has funded every gap, absorbed every specification ambiguity, and the vendors have delivered exactly what their contracts required — which isn't what the programme needed.

The transition cliff in integration

Integration projects have the steepest Transition Cliffs of any programme type. The knowledge required to operate an integration — the exception handling, the monitoring, the vendor coordination when something breaks at 2am — is almost entirely tacit. It lives in the integration lead's head, in the test team's institutional memory, in the vendor relationships built over months of joint troubleshooting.

None of this transfers in a handover document.

The operational team inherits the interfaces but not the knowledge of how they actually work — the undocumented workarounds, the fields that technically pass validation but produce clinical nonsense, the vendor contact who actually fixes things versus the vendor contact listed in the contract. When the interface breaks in production, the operational team opens a ticket with the vendor's support desk and waits in a queue, while the integration lead — had they still been engaged — would have called the developer directly and had it fixed in hours.

This is compounded by Information Fog. Integration projects generate enormous volumes of technical documentation — interface specifications, message samples, test scripts, defect logs, configuration guides. The volume itself becomes the problem. When the operational team needs to understand why a particular field is mapped a particular way, the answer is buried in an email thread from eight months ago between the integration lead and a vendor developer who has since left the project.

The narrative capture variant

Narrative Capture in integration projects has a specific variant: the vendor who controls the integration narrative controls the architecture.

In multi-vendor integration, one vendor is usually larger or more established than the others. That vendor's architect becomes the de facto integration architect — not by assignment, but by default. They attend the integration design sessions. They propose the interface patterns. They define the data standards. The customer's integration lead facilitates but doesn't challenge, because the vendor has deeper technical expertise in their platform.

The result is an integration architecture designed to optimise for the dominant vendor's platform at the expense of the others. Interface patterns that suit Vendor A's technology stack but require Vendor B to build custom adapters. Data standards that align with Vendor A's internal model but force Vendor C to transform every message. The architecture looks rational — it's proposed by the most expert party — but it systematically advantages one vendor while the others absorb the integration cost.

The customer doesn't see this because the technical complexity creates a fog of its own. "The architect recommended this approach" sounds authoritative. What it means is "the vendor whose platform benefits most from this approach recommended it."

Designing governance for integration

The fix is structural, not technical. Integration projects need governance designed specifically for multi-boundary programmes:

1. Integration authority must be explicit and contractual. The integration lead needs delegated authority in each vendor's contract — a named role with the power to direct integration-related work, approve interface specifications, and accept or reject integration deliverables. Without contractual standing, the role is advisory.
2. The interface specification must precede the vendor contracts. Design the integration architecture first. Incorporate it as a contract schedule. Vendors bid on a defined integration obligation, not a gap to be negotiated later.
3. Boundary ownership must be assigned, not assumed. Every interface needs a named owner responsible for the semantic gap — not each vendor's side, but the space between. This is typically the customer's role, and it needs to be funded and staffed as a permanent function, not a project role that dissolves at go-live.
4. Transition planning starts at procurement, not at go-live. The operational model for the integration — who monitors, who escalates, who coordinates vendor responses — must be designed before vendor selection, not after implementation.
5. The integration architect must be independent. The customer needs their own integration architect — not one borrowed from a vendor. This role challenges vendor proposals, validates design decisions against the customer's long-term interests, and ensures the architecture serves the programme, not any single vendor.

The principle

Integration projects don't fail because of technology. They fail because governance structures designed for single-vendor delivery are applied to multi-vendor programmes where the critical work happens at boundaries nobody owns. The same structural patterns that undermine programme governance — Authority Vacuum, Leverage Erosion, Transition Cliff, Narrative Capture — appear in concentrated form at integration seams.

Fix the governance before you fix the interfaces. Assign boundary ownership. Ensure the integration specification has contractual force. Staff the integration architecture independently. And start transition planning at procurement, because the knowledge that keeps a clinical integration running cannot be transferred in a handover document written the week before go-live.

This article contributes risks V1-V8, G1, G3, G7, CO1-CO4, K1, K2, K5, and S6 to the practitioner's risk taxonomy.