Integration Blind Spot
Integration falls between organisational boundaries during procurement. Nobody owns the gap between them.
Integration falls between organisational boundaries during procurement. The business unit owns the new system's requirements; enterprise architecture owns the integration landscape. Neither owns the gap between them.
Recognition signals
- Integration architect wasn't in the procurement team. The people who understand the integration landscape weren't involved in defining the requirements or evaluating the bids.
- Requirements specify "must integrate with system X" with no interface specification. No protocol, no direction, no frequency, no error handling, no data mapping.
- Enterprise architecture consulted at gate review but not embedded. They reviewed the business case, flagged integration risk in a comment, and moved on. Nobody acted on the comment.
- Vendor bid has a single line for "integration." It says "supported via REST API" or "standard HL7 interface" — enough to tick the evaluation box, not enough to build against.
- Integration issues are the first to blow out the timeline. Six months in, the integration work package is behind, over budget, and consuming the project manager's entire week.
Structural cause
Why this happens
Integration sits at the boundary between two organisational domains: the business unit procuring the system and the technical function managing the integration landscape. The business unit has procurement authority but not integration expertise. The technical function has expertise but no seat at the procurement table.
The business unit runs the procurement because they own the budget and the business need. They populate the evaluation panel with subject matter experts who can assess functional fit. Integration is technical — it belongs to enterprise architecture or the integration team. But those teams aren't resourced to embed in every procurement. They attend a gate review, write a risk comment, and return to their own priorities. The procurement proceeds without integration depth.
The gap is structural, not negligent. Nobody decided to exclude integration expertise — the organisational model simply doesn't allocate it to procurement teams. The business unit doesn't know what questions to ask. The technical function isn't in the room to ask them. The vendor sees a single-line integration requirement and prices accordingly — knowing the real integration work will surface as variations after contract award.
Risk mapping
| Risk | Description |
|---|---|
| P2 | Integration boundary ownership — integration expertise excluded from procurement by organisational design |
Self-assessment
When to worry
- The integration architect wasn't involved in the procurement or requirements phase
- Integration is described as "supported via API" with no specifics on protocol, direction, or error handling
- Integration testing environment wasn't budgeted
- "We'll work out the integration details during implementation" — the most expensive sentence in project delivery
When you're OK
- Integration architecture document exists before the RFP is issued
- Each interface specifies system, direction, protocol, frequency, and error handling
- Integration is a separately costed work package in the specification
Related reading
- Specification Gap — integration is the most common missing domain in requirements specifications
- Contract-as-Filing — integration clauses buried in a filed contract nobody reads
- Why integration governance fails — the full article on integration as a governance boundary problem
Integration issues are the first thing to blow out the timeline — because nobody specified them before contract award.
A pre-procurement integration review embeds technical expertise in the requirements phase, where fixing gaps costs time rather than variations. 10fifteen — programme governance assessments.