Most of the “AI projects” I get asked about aren’t AI projects. They’re integration projects wearing an AI badge because that’s the line item the budget approved this year.

A team wants a model that “predicts” which orders will be late. They already have the data to answer that with a dashboard — they just can’t get to it, because order status lives in one system, logistics in another, and nothing talks to anything in real time. A model won’t fix that. An event-driven architecture and a clean data layer will. And once those exist, the “AI” part is often a footnote.

This isn’t an anti-AI argument. It’s the opposite. AI works best on top of a modern IT architecture, and falls over without one. The trouble is that the two have been collapsed into a single word, and companies are buying the glamorous half while skipping the half that does the work.

The numbers back this up. MIT’s State of AI in Business 2025 found that about 95% of enterprise generative-AI pilots delivered no measurable return. The headline gets read as “AI doesn’t work.” The report says something more precise: generic tools stall because they don’t connect to, or learn from, the company’s actual workflows and data. That’s not a model problem. That’s an architecture problem.

For the rest of us: what these words actually mean

Three terms get used interchangeably and shouldn’t be.

Modern IT architecture is the plumbing. It’s how your systems are organised so that data moves cleanly and systems react to each other. The modern version has a few hallmarks: services that talk through well-defined APIs instead of overnight batch files; an event-driven backbone (when something happens — an order is placed, a payment clears — a message fires immediately and any interested system reacts); and a central data platform where information from every system lands in one queryable place.

Analytics is making sense of the data once it’s flowing. Dashboards, reports, forecasts. Mostly answering “what happened, what’s happening, and — using statistics — what’s likely to happen next.” This is decades-old technology and it is very, very good.

AI — in the current wave, large language models — is the ability to handle unstructured, ambiguous input: reading a contract, summarising a thread, drafting a reply, reasoning over messy text. It’s genuinely new and genuinely powerful.

Here’s the part that gets lost: the first two solve most business problems on their own. AI is the layer you add when the problem is genuinely about ambiguity and language — not when it’s about data that won’t move.

Most “AI problems” are integration problems

When you trace a stalled AI initiative back to its root, you usually find the same thing: the model was never the bottleneck. The data was trapped.

The information needed to answer the question existed, but it was scattered across systems that were never designed to talk to each other. So the project’s real work — the 90% nobody scoped — was extracting, cleaning, reconciling, and joining data. That’s classic systems integration. It’s unglamorous, it’s hard, and no model removes the need for it. A large language model on top of fragmented data doesn’t give you intelligence. It gives you confident, fluent answers built on an incomplete picture, which is worse than no answer at all.

The uncomfortable implication: if you can’t currently answer a question with a SQL query and a dashboard, a model usually won’t answer it either. It’ll just hide the gap behind good prose.

Event-driven architecture is the unglamorous win

The single highest-leverage thing most organisations could do this year has nothing to do with AI. It’s moving from batch to events.

In a batch world, systems synchronise overnight. The warehouse finds out about the order in the morning. Finance reconciles at month-end. Every decision is made on stale data, and every “why didn’t we catch this sooner” post-mortem traces back to a system that found out too late.

In an event-driven world, things happen when they happen. An order placed emits an event. Inventory, logistics, finance, and the customer-facing app all react in seconds. Most of the problems companies hope to solve with predictive AI — bottlenecks, missed SLAs, slow reactions — dissolve once the organisation simply knows things in real time and acts on them. You don’t need to predict a late shipment if your system reacts to the delay the instant it occurs.

This is mature, well-understood engineering. It is also where the durable returns are.

Analytics already answers most “predictive” asks

A surprising share of requests that arrive labelled “we need AI for this” are answered by a competent analytics stack.

Which customers are likely to churn? Regression on usage data. What will demand look like next quarter? Time-series forecasting that has existed for forty years. Where are our margins leaking? A well-built data model and someone who knows how to query it. None of this requires a neural network, let alone a frontier model. It requires data that’s clean, joined, and accessible — which loops back to architecture.

The point isn’t that machine learning has no role. It’s that the marginal value of modern AI specifically is low when the question is structured and the answer lives in your own numbers. Save the expensive, non-deterministic tool for the problems that are genuinely ambiguous.

AI sits on top of the architecture, not instead of it

Picture a stack. Clean data at the foundation. An event-driven backbone moving it. Analytics making sense of it. And then, on top, AI handling the genuinely ambiguous, language-shaped problems the layers below can’t: reading the unstructured complaint and routing it, drafting the first version of the report, turning a vague request into a structured query.

In that order, AI is an amplifier. It compounds the value of everything beneath it.

Invert the order — bolt AI onto fragmented systems and dirty data — and it amplifies the dysfunction instead. It produces fluent, plausible, unverifiable output on top of a foundation nobody trusts. That’s the 95%. Not models that can’t reason, but models asked to compensate for plumbing that was never laid.

What this means

For anyone deciding where to spend next year’s budget, the sequence matters more than the spend.

Fix the plumbing first. Get your systems talking through events. Get your data into one place where it can be queried. This is not the exciting part and it will not make a good slide, but it is the part that determines whether anything built on top of it works.

Use analytics for everything it can answer. It’s cheaper, deterministic, and explainable. Reserve AI for the problems that are actually about ambiguity and language.

Then add AI — and watch it work, because it finally has a foundation underneath it.

The hard truth for the current moment is that “we’re doing AI” is often a way to avoid admitting “our systems don’t talk to each other.” The modern architecture is the prerequisite, not the consolation prize. Build it, and AI becomes the easy part. Skip it, and you join the 95%.

References

  • MIT NANDA, The GenAI Divide: State of AI in Business 2025 — ~95% of enterprise GenAI pilots show no measurable P&L impact; generic tools stall because they don’t integrate with workflows. (Reported by Fortune, August 2025.)
  • Standard event-driven architecture and enterprise-integration literature (event backbones, API-led integration, central data platforms).