Integration: Where Projects Actually Die

The four connections

Every deployed AI system needs four connections, and each is a place work hides:

📅 Timeline

Data inThe input must arrive automatically, in the right shape, reliably, on time. Usually the largest single piece of work.

Output outThe result must reach the system where the decision is made — the ticket queue, the CRM, the finance system — not a separate dashboard.

Exception routingLow-confidence cases must reach a person, in their existing tool, with enough context to act.

Feedback inCorrections must be captured and stored, or the system cannot improve and you cannot measure it.

The fourth is the one omitted most often, and its absence is invisible for about a year — until someone asks how the system is performing and discovers nobody can say.

The system being replaced

There is a specific, expensive and entirely avoidable failure: building an AI system against infrastructure that is being replaced.

The best-documented example is the MD Anderson Cancer Center's Oncology Expert Advisor, built with IBM Watson. According to a University of Texas System audit reported in early 2017, the project consumed at least $62 million over roughly four years — about $39 million to IBM and $23 million to a consultancy — across a series of contract extensions.

It never went live. The project was terminated in 2016.

Among the audit's findings, one is directly relevant here: the pilots that had been developed — for leukaemia and lung cancer — were built against the institution's previous medical records system, and had not been updated to integrate with the records system the institution had since moved to.

Read that plainly. A very large amount of money bought a system that worked against infrastructure the organisation no longer used.

The audit also raised governance concerns that are inseparable from the outcome: the procurement reportedly did not follow standard procedures, was not approved by the institution's IT function, and payments were reportedly structured so as to stay below thresholds that would have required board approval.

The transferable lessons for a manager, none of which require any medical or technical context:

Ask what platform the system will integrate with, and whether that platform is being replaced. It is a five-minute question that would have surfaced this.
Involve the IT function early, even when it is slower. The approval that feels like an obstacle is frequently the control that would have caught the mistake.
Treat procurement structured to avoid oversight as a warning about the project, not as clever administration. Governance thresholds exist because projects of that size need review; a project routed around them has lost the review it needed most.
Contract extensions are a signal. A series of them, without a live system, is the shape of a project that should have been stopped.

Integration is most of the project

AI for Non-Technical Teams made this point with the invoice pipeline: of seven steps, one was genuinely AI. That ratio is typical.

The consequences for planning:

Weight the team accordingly. If most of the work is integration, the project needs integration engineers more than it needs data scientists. Many projects are staffed the other way round and then stall.

Build the connections before the model is ready. Data in, output out and exception routing can be built and tested with a stub — something that returns a fixed answer — which de-risks the schedule and means the model plugs into a working chain when it arrives.

Budget for the systems you do not control. The source system may have no usable interface, may charge for one, or may be supplied by a vendor with no incentive to help. This is a procurement lead time, not an engineering estimate.

Expect the last mile to be political. Putting output into someone else's system means asking a team who did not request this, and has their own roadmap, to accept a change. Start that conversation early; it is often the longest-lead item in the whole project.

Before an implementation is approved, ask these of the people who own the surrounding systems — not of the project team, who may not know.

"Which systems does this read from and write to, and is any of them being replaced, upgraded or migrated in the next eighteen months?" The MD Anderson question. Roadmaps are usually known to somebody, just not to the project.
"Who owns each of those systems, and have they agreed to this?" Not been informed — agreed. An owner who first hears about it at integration will not prioritise you.
"Does the interface we need already exist, or does someone have to build it?" If it must be built, by whom, on whose backlog, and at what priority.
"What is the change process for the system where our output lands, and how long does it take?" Some systems accept changes weekly; others quarterly, with a freeze period.
"If this system is unavailable for a day, what happens to the work?" Establishes whether you need a fallback, which is a design requirement rather than an afterthought.
"Who is on the hook when it breaks at 2am?" If the answer is nobody, you do not have a production system, whatever the launch announcement said.

None of these are technical questions. All six are answerable in a single meeting with the right people, and any one of them can save the project. The reason they are so often skipped is that they sit between departments — which is precisely why they are a manager's job rather than an engineer's.

❓ Knowledge Check

MD Anderson's $62 million Oncology Expert Advisor pilots were built against the institution's previous records system and never integrated with its current one. What is the transferable managerial lesson?

📚 Flashcards1 / 6

Term

The four connections

Click to flip

Definition

Data in, output out, exception routing, and feedback in. The fourth is omitted most often and its absence stays invisible until someone asks how the system is performing.

Click to flip back

💡Key Takeaway

Every deployment needs four connections — data in, output out, exceptions routed, feedback captured — and integration is usually most of the project, so staff and schedule it that way. Ask early which systems are involved and whether any are being replaced: MD Anderson spent a reported $62 million on pilots built against a records system the institution had already moved off. And treat procurement that routes around IT approval or board thresholds as a warning about the project, because those are the reviews most likely to have caught the mistake.