Posted on

How Dell AI and Data Platform (AIDP) Helps Charlie and Clare Deliver Real Outcomes

So far in this series we’ve built up a picture of the data journey from the ground up — from raw events to refined data, from pipelines to insight, from Charlie’s world to Clare’s. In this post it’s time to connect that picture to the technology designed to support it.

The platform in question is Dell’s AI and Data Platform — AIDP. But before diving into what it does, it’s worth being clear about how to measure whether any platform is actually working.

The value of a data and AI platform isn’t measured in terabytes or TFLOPS. It’s measured in how fast you can go from idea to insight to action, how confident you are in the data and models behind key decisions, and how many AI and analytics initiatives actually reach production rather than dying somewhere between the notebook and the business.

That’s the lens to apply here.

What Dell AI and Data Platform actually is

Think of AIDP not as a single product but as an integrated foundation — Dell’s storage and compute brought together with the software and tools needed for modern data and AI workloads. It’s designed to support the full journey: data engineering, analytics, and AI and ML, end to end.

On top of Dell’s infrastructure, AIDP incorporates modern data platform patterns — data warehouse, data lake, and data lakehouse — a unified query layer via Starburst to access data wherever it lives, AI and ML tooling for model development and operations, and governance and observability across the stack. In other words, it’s an opinionated foundation for the world Charlie and Clare actually work in every day.

How AIDP helps Charlie

Charlie’s biggest frustrations are predictable: platforms that can’t handle volume without drama, bespoke pipelines that multiply every time a new team needs data, and blind spots in quality and observability that turn into production incidents.

AIDP addresses all three. The Dell-validated infrastructure gives Charlie a solid, scalable backbone for both batch and streaming workloads — predictable performance, consistent environments for orchestration and monitoring, and the ability to onboard new data sources without reopening architecture debates every time. Charlie can design against it with confidence rather than working around it.

On the data platform side, AIDP supports warehouse, lake, and lakehouse patterns on the same infrastructure, so Charlie isn’t forced into a single storage model. Governed structured analytics can live alongside flexible data science workloads, on the same foundation, without creating yet another silo. And the integration with Starburst as a unified query layer means Charlie can connect existing sources once, define logical schemas and curated views centrally, and expose them to multiple consumers — BI tools, notebooks, AI platforms — via standard SQL. ETL and ELT still matter for refining critical datasets, but Charlie now gets to choose when to materialise data and when to virtualise and query in place. Less time writing and fixing bespoke pipelines. More time building reusable, governed data products.

Finally, AIDP gives Charlie integration points for DataOps tooling — testing, CI/CD, data quality validation, centralised security and governance controls. Fewer blind spots. Fewer “we can’t trust these numbers” conversations. And a better compliance posture as a baseline rather than an afterthought.

How AIDP helps Clare

Clare’s frustrations are equally predictable: too much time hunting and reconciling data, queries and training runs that struggle on realistic dataset sizes, and models that work in development but never make it to production.

The same curated views and data products Charlie defines in AIDP are exposed directly to Clare’s tooling — BI platforms for analysts, notebooks and ML frameworks for data scientists — with governance and security enforced at the platform level rather than left to ad-hoc exports. Metric definitions are consistent. Lineage is traceable. Clare spends less time cleaning and reconciling, and more time actually analysing and modelling.

On the compute side, AIDP is designed to handle both analytical and AI workloads — scalable compute for large joins and aggregations, GPU and CPU support for model training and inference, storage tuned for high-throughput parallel access. Clare can run complex queries and train models on realistic data, not tiny samples that fit on a laptop.

And for data scientists specifically, the path from notebook to production is where AIDP earns its keep most clearly. A consistent environment across development, test, and production. Integration with MLOps tools for deployment and monitoring. Charlie’s data pipelines and Clare’s model workflows running on the same underlying platform. The result is fewer science projects and more AI features actually embedded in products and processes.

The bigger picture

Step back from the personas for a moment and the business case is straightforward. When Charlie and Clare are well supported, organisations make faster decisions on trusted data, data talent spends more time on high-value work and less on plumbing, and AI projects reach production instead of stalling between experiment and deployment.

But perhaps the most important thing AIDP offers is a platform that grows with your ambitions. Most organisations are on a journey — from basic reporting, to advanced analytics, to machine learning, to GenAI and AI-enhanced applications. That journey rarely happens in a straight line, and it rarely happens all at once. AIDP is designed as a foundation that supports each step without requiring a rip-and-replace every time the ambition moves on. Start with strong data engineering and analytics. Add predictive models when the data foundations are ready. Layer on GenAI when governance and quality can support it.

Going back to the analogy that’s run through this series: AIDP is the refinery infrastructure — the tanks, the pipes, the processing units — that makes it possible to keep producing reliable data fuel as demand grows and the grades required become more sophisticated.

In the next post, we’ll go deeper into the architecture of AIDP itself — how the pieces fit together technically, and how that maps back to the data flows and personas we’ve been building throughout this series.

Posted on

Meet Clare, the Data Analyst and Data Scientist

In the last post we met Charlie, the Data Engineer — the person who designs and runs the pipelines that move data from raw to reliable. But pipelines aren’t the destination. They’re the supply chain. The destination is decisions.

That’s where Clare comes in.

Depending on the organisation, Clare might carry the title of Data Analyst, BI Analyst, Data Scientist, or some hybrid in between. Titles vary, but the core idea is the same: if Charlie is responsible for getting the data ready, Clare is responsible for making it mean something.

Why Clare matters

It’s tempting to think of a data platform as an infrastructure problem — storage, compute, pipelines. Get those right and the job is done. But the business doesn’t care about petabytes or processing cores. It cares about answers:

  • Why did churn spike last quarter?
  • Which products are actually profitable by customer segment?
  • Where are we wasting marketing spend?
  • What early signals predict a failure or a fraud event?

Clare is the person who sits between the data estate and the decisions that leaders actually make. Understanding what Clare needs — and how a platform either helps or hinders them — is just as important as understanding Charlie.

Clare as a Data Analyst: questions, context, and communication

In an analyst role, Clare’s job starts with a business question — “why are returns higher in this region?” or “where are we losing customers in the journey?” — and works backwards into the data. Which tables matter? How do we define the metric consistently? What filters and segments do we need?

That requires a good understanding of the business domain, a working knowledge of the data model Charlie has built, and enough SQL and data skills to pull and join the right datasets. If the underlying platform is inconsistent, slow, or poorly documented, Clare spends more time hunting for data than answering questions — and the business waits longer for insight. And we know there’s cost and lost opportunity when waiting.

Once she has the data, Clare explores, visualises, and explains. The dashboards and reports are what most people see. But the real value is in the interpretation — which patterns are robust and which are noise, what changed and when, and where the data is strong or weak. Good analysts don’t just produce charts. They tell the story of the data in a way business leaders can act on.

Over time, that work compounds. Ad-hoc analysis becomes reusable dashboards. Useful logic gets worked back with Charlie into shared views and models. Agreed metric definitions — one version of “churn”, “active user”, “profitability” — slowly replace the spreadsheet chaos that plagues most organisations. The loop closes: business questions feed data exploration, which feeds agreed definitions, which feed shared data products.

Clare as a Data Scientist: from patterns to models

In a data scientist role, Clare goes a step further. Where the analyst might conclude that customers with behaviour X are more likely to churn, the scientist trains a model to predict it — validates it on historical data, packages it, and works towards deploying it somewhere it can actually be used.

The same applies to demand forecasting, fraud detection, recommendation engines, or predictive maintenance. The goal is to turn data and hypotheses into models that can reliably predict or classify future events, and then get those models out of notebooks and into production.

That last part is where the platform really shows its hand. A model isn’t valuable until it runs reliably, receives fresh data regularly, and is monitored for drift. Getting from proof of concept to production requires Clare to work closely with Charlie and ML engineering teams — and it requires a platform that is consistent across development, test, and production environments. When that foundation is solid, the journey from notebook to deployed model is achievable. When it isn’t, models die in notebooks.

What Clare needs from the platform

Whether she’s in analyst or scientist mode, Clare’s needs come down to five things:

Access — the ability to get to the data she needs without raising a ticket for every new question. Trust — numbers that are consistent across tools and teams, with lineage she can follow back to source. Performance — queries and model training runs that complete in minutes, not hours. Flexibility — the freedom to use the tools she’s comfortable with, whether that’s SQL, Python, R, or a BI front end, all drawing from the same curated data layer. And stability — a platform that behaves consistently when new workloads appear, rather than one that needs babysitting.

None of those are unreasonable asks. But they all trace back to decisions made much further down the stack — in the data pipelines Charlie operates, in the platform architecture underneath, and in the governance and documentation that surrounds it all.

Charlie and Clare: the same chain

Put the two personas together and a simple picture emerges:

Charlie designs and operates the pipelines. He turns raw data into reliable, documented, timely datasets — the refined fuel. Clare takes that fuel and turns it into insight, models, and decisions — the journeys the business actually needs to take.

Everything else — storage, compute, orchestration, infrastructure — exists to help Charlie and Clare do those jobs well. If they can’t get the data they need, trust the numbers, or iterate quickly on new questions and models, the sophistication of what sits underneath doesn’t really matter.

In the next post, we’ll start connecting these personas and data flows to the architecture of a modern data platform — and show how the layers fit together to support the full journey from raw data to decision.

Posted on

Meet Charlie, the Data Engineer

Before we look at what a modern data platform actually looks like, it’s worth pausing to ask: who is it built for?

Platforms don’t create value on their own. People do. And in a world that runs on data and AI, there’s a set of roles that sit at the heart of that value chain — people who design, build, and consume the pipelines that turn raw data into decisions. Understanding who they are, and what they actually need, changes how you think about everything else.

The first person worth introducing is Charlie — the Data Engineer.

Why the Data Engineer exists

Not long ago, data lived inside systems. The database behind the ERP. The CRM. The billing platform. IT looked after servers, storage and availability. Business teams raised tickets when they wanted a report. That model worked when data was a by-product of running the business.

It doesn’t work like that any more.

When analytics needs to be near real-time rather than batched once a month, when AI teams need large consistent training sets and continuous feature feeds, and when data scientists are expected to build models that drive real decisions — someone has to sit between raw application data and the people and systems consuming it.

That’s Charlie.

What Charlie actually does

At its core, Charlie’s job is to move data reliably through its lifecycle — from raw and messy, to clean, modelled, and ready for use. If a dataset appears in a dashboard, a model, or an AI assistant, somewhere behind it is a data engineer making it flow.

Think back to the refinery analogy. If raw data is crude oil, Charlie is the refinery engineer — designing and operating the pipelines, monitoring the process, and making sure the right grade of fuel reaches the right engine at the right time.

In practice that means four things.

First, building and operating pipelines that handle ingestion, transformation, storage, and serving of data — repeatably, reliably, and at production grade. Not one-off scripts that work once and break on a Monday morning.

Second, turning messy source data into trustworthy data products — clean, modelled, documented, and timely. Tables and views that reflect how the business actually thinks: customers, products, assets, events. Data as a product, not just a dump from a system.

Third, making pragmatic technology choices. It’s easy to chase the latest tool or architectural pattern. Charlie doesn’t have that luxury. Every decision — warehouse, lake, lakehouse, stream processor, orchestration engine — has to be weighed against cost, performance, operational reality, and whether it will actually play nicely with the rest of the stack.

Fourth, making governance real. Data quality isn’t a policy document; it lives in the pipelines Charlie builds and operates. Validation checks, lineage tracking, access controls, schema versioning — this is where the business’s aspiration for a “single source of truth” either becomes reality or stays a slide on a deck.

And through all of it, Charlie collaborates — with architects who set direction, analysts who know what business users need, scientists who know what their models require, and stakeholders who own the outcomes. When that collaboration works, projects move from proof of concept to production. When it doesn’t, you get dashboards nobody trusts and models that never leave the lab.

Why this matters

Understanding Charlie’s world reframes what a data platform needs to be. It’s not just storage and compute. It’s the foundation that keeps pipelines reliable, helps teams serve analysts and scientists faster, and makes a complex job simpler rather than more complicated.

In the next post, we’ll meet the colleagues downstream of Charlie — the data analyst and the data scientist — and see how all three fit into the same data value chain we’ve been building through this series.

Posted on

Just What is the Fuss About Data?

We talk about data constantly, but most of us never stop to ask what it actually is. In everyday life, we swim in data without noticing. None of it feels dramatic — but all of it is data:

  • Your phone counting steps and heart rate during a walk
  • Your car logging speed, mileage, battery or fuel usage
  • A supermarket barcode scanner recording what you bought and when
  • A streaming app tracking what you watch, pause, rewind, and abandon
  • A website logging every click, scroll, and form field you touch

Each of those is simply a captured observation about an event, a behaviour, or a state. On its own, it’s just a record. Raw. Inert. Waiting.

Data only becomes information when it has context. And it only becomes knowledge when it drives a decision. That three-step ladder — data, information, knowledge — is worth holding onto, because it explains why so many organisations sit on vast amounts of data and still struggle to act on it.

Most people only ever see the polished outputs: an activity ring closing on a smartwatch, a “recommended for you” row on Netflix, a monthly bank statement. They never see the raw data stream behind it.

Here’s a useful way to think about what separates those who do.

In The Matrix, most people only see the illusion of the world. A few stare directly at the green code and can see “the woman in the red dress” — the meaningful signal hidden inside the data stream. Modern businesses face exactly the same divide:

  • Some only see systems and reports on the surface.
  • Others have learned to read the data behind those systems — and spot patterns, risks, opportunities, and inefficiencies that everyone else misses.

Data is the stream. The real advantage is knowing how to find the woman in the red dress. How to find the signals in the noise.

Why Data Matters to Modern Business and Decision-Making

If data only becomes knowledge when we can interpret and act on it, then modern business success is really a competition in how well you can move from raw events → information → knowledge → decisions → actions.

Almost every important decision in a business can be traced back to data, even if people don’t realise it:

  • Which products do we build next? Driven by sales, returns, customer feedback, and competitor moves.
  • Where do we invest, and where do we cut back? Driven by margins, pipeline, utilisation, risk, and market signals.
  • How do we improve customer experience? Driven by NPS, churn, ticket volumes, digital journeys, and operational metrics.
  • How do we run our operations? Driven by inventory levels, lead times, failure rates, staffing and capacity data.

In the past, a lot of this ran on experience and instinct, with data used mainly to justify decisions after the fact. Today, that simply doesn’t scale. Markets move faster, supply chains are more fragile, customers have more choice and more voice, and regulators expect more transparency. You can’t manage that complexity with periodic spreadsheets and static reports. You need continuous, trustworthy, integrated data feeding analytics and — increasingly — AI.

That’s where the Matrix metaphor earns its keep. Two companies can have access to roughly the same raw data:

  • One treats it as exhaust — something systems happen to log.
  • The other treats it as knowledge fuel — the foundation every decision is built on.

The second company invests in building what you might think of as a supply chain for data: capturing it consistently from key systems and devices, bringing it together so it can be compared and combined, cleaning it so people actually trust it, and modelling it so it reflects how the business really works. Only then do analytics and AI have something meaningful to work with.

Because here’s the uncomfortable truth:

The quality of your decisions is limited by the quality of the data that reaches your decision-makers — not by how clever your dashboards or algorithms are.

That brings us to the next question: how does raw data from all these sources actually become decision-ready? The answer lies in the layers and pipelines that sit between source systems and the dashboards or AI models that consume them — and that’s where ideas like ETL and ELT come in.

From Raw Oil to Refined Fuel: Why Data Must Be Transformed (refined)

So far we’ve established that raw data needs work before it becomes useful. But it’s worth being honest about just how much work that actually is.

Think of crude oil straight out of the ground. It’s thick, dirty, and full of impurities. Enormously valuable — but you can’t pour it directly into a car engine or a jet turbine. It has to go through a refinery first, to become petrol, diesel, or kerosene. Only then can engines use it efficiently and safely. Data is exactly the same.

The realities of raw data

Raw data coming off real systems is messy in predictable ways. Outliers — impossible values like negative ages or a million units sold in a single second — creep in through bugs or misuse. Fields are blank, records are partial, events are logged without IDs or timestamps. Rows get truncated, formats clash, codes are inconsistently typed. And then there’s the sheer volume of data that simply isn’t relevant — verbose logs, granular events, fields nobody needs for the use case at hand.

Feed that raw stream directly into analytics or AI and you get dashboards people don’t trust, models that learn the wrong patterns, and insights that fall apart the moment someone checks the underlying numbers. Just like engines need refined fuel, analytics and AI need refined data.

ETL and ELT: the data refineries

This is where data transformation comes in — and why concepts like ETL and ELT matter. Both approaches take raw data from source systems and turn it into something cleaner, more consistent, more focused, and easier for analytics and AI to consume. They just differ in where the heavy lifting happens.

With ETL (Extract – Transform – Load), data is pulled from source systems, transformed in a separate processing layer — cleaned, standardised, reshaped — and only then loaded into the target warehouse. Think of it as a refinery that sits outside the storage tank: crude comes in one end, refined product goes out the other. This approach made sense when storage was expensive and tightly controlled, and you wanted only highly curated data to ever land in the warehouse.

With ELT (Extract – Load – Transform), the order flips. Raw data lands in the warehouse or data lake first, and transformation happens inside the platform using its own compute engine. The refinery, in effect, is built inside the tank. This became the dominant approach as storage and compute got cheaper, and teams wanted the flexibility to experiment directly against raw data before deciding what to curate.

Why transformation matters

Regardless of which approach you use, the goals are the same: fix or flag bad data, standardise and integrate across sources, reduce to what actually matters for the use case, and shape the data into structures that reflect how the business thinks — customers, products, assets, locations, periods.

Done well, analysts spend more time analysing and less time cleaning. Dashboards match reality — and match each other. AI models train on consistent, documented data rather than whatever happened to be easiest to pull.

Which brings us back to the analogy that ties it all together:

Raw data is crude oil. ETL and ELT are your refineries. Analytics and AI are the engines. And business decisions are the journeys you can take once you’ve got reliable fuel.

In my next blog, we’ll look inside a modern data platform — exploring the layers from raw through to curated and semantic — and show exactly where this refining work happens at each stage.

Posted on

Data: The Foundation of Analytics and AI

AI is not the starting point. Analytics is. And for most organisations, getting that order wrong is the single biggest reason AI projects disappoint.

Every week I’m pulled into conversations framed as “AI strategy” that are, in reality, data and analytics problems in disguise. Beneath the ambition — copilots for sales teams, chatbots for customer service, predictive maintenance on the shop floor — you usually find the same things: siloed application data, legacy warehouses built for yesterday’s reporting, data lakes that became data swamps, and spreadsheets filling the gaps.

Until those foundations are solid, AI won’t fix the problem. It will just produce more sophisticated confusion.

This first post in the series makes that case explicitly. Before we argue warehouse vs lake vs lakehouse, we need a shared view of how analytics underpins decision-making — and how AI builds on, not replaces, that foundation.

The analytics spectrum: a ladder, not a leap

Most organisations jump straight to AI use cases while still struggling with the basics. It helps to think of analytics as a spectrum, where each stage depends on the one before it.

Descriptive – “What happened?” Reports, dashboards, KPIs. Revenue by region, tickets by channel, machines that failed by shift. This is where most business decisions are still made today, and where most organisations need the most work.

Diagnostic – “Why did it happen?” Drill-downs, cohort comparisons, root-cause analysis. Why did returns spike in that region? Why did NPS drop after the launch? This is where data moves from a record of events to an explanation of them — and many “analytics projects” live here, without any AI in sight.

Predictive – “What is likely to happen?” Now we step into data science: demand forecasting, churn prediction, time-to-failure estimates. Classical ML techniques — regression, classification, time-series models — let businesses anticipate outcomes and act before issues hit.

Prescriptive – “What should we do?” From prediction to recommended action. Given stock levels, demand signals, and lead times, what’s the optimal replenishment plan? This is optimisation, simulation, and decision engines — again, often without a single line of GenAI.

AI and GenAI – “What can we automate, augment, and generate?” Finally, AI on top of that foundation: ML models embedded in workflows, copilots that explain performance, RAG systems that answer questions over enterprise data. Powerful — but only as powerful as the analytics beneath them.

The dependency chain matters: weak descriptive and diagnostic analytics produce weak predictive models. Weak analytics produces AI that surfaces those weaknesses faster and at greater scale.

What this looks like in practice

Manufacturing: the cost of skipping the basics

A mid-sized manufacturer wanted ML-based predictive maintenance. Reasonable ambition. But when we dug in, OEE dashboards didn’t exist, downtime wasn’t being captured consistently, and maintenance history lived in three disconnected systems. There was no foundation to train a model on — and no way to validate one if you did.

The right first move wasn’t a model. It was centralising OT data from IoT sensors, PLC logs, and work orders, then building basic descriptive analytics: downtime by line, scrap rates by batch, top failure modes by site. That work alone drove measurable improvements. Statistical MTBF estimates followed. ML-based failure prediction came later — and actually worked, because the data beneath it was trusted.

The lesson isn’t that AI is bad. It’s that the sequence matters.

Retail: analytics as the backbone of personalisation

In retail and e-commerce, AI gets a lot of credit for personalisation — but the analytics layer does most of the heavy lifting. Sales trends, basket analysis, promotion effectiveness, seasonality-aware forecasting at category or store level: these are all analytically tractable problems that don’t require a foundation model to solve.

ML propensity models and recommendation engines amplify that foundation. GenAI can summarise performance and suggest campaign tweaks. But retailers who skip straight to AI without first understanding their own sales patterns, customer segments, and channel dynamics tend to automate their confusion rather than their insight.

Financial services: where auditability limits shortcuts

In heavily regulated sectors, the stakes of a weak analytics foundation are higher than embarrassment — they’re regulatory. Descriptive and diagnostic analytics aren’t optional extras here; they’re the basis for regulatory reporting, risk management, and audit trails.

ML fraud detection and GenAI investigation assistants are genuinely valuable in financial services. But they’re layered in carefully, on top of scorecards, delinquency models, and segment-level risk analysis that have been validated and governed over years. The analytics estate isn’t just fuel for AI — it’s the compliance record that makes AI defensible.

AI readiness is analytics maturity

When organisations talk about AI readiness, the conversation often turns to GPU capacity and model choice. For most businesses, that’s the wrong question. The right questions are:

  • Do you have trusted KPIs and shared metric definitions?
  • Can you trace those metrics back to source systems?
  • Are your analysts and business users comfortable challenging assumptions with data?

If the answer is no, adding AI won’t close those gaps. It will expose them at scale.

Two things worth noting for teams at this stage. First, analytics teams are the natural bridge to AI — they already understand the business context, the data quirks, and the stakeholder expectations that make models useful rather than academic. Second, the artefacts analytics teams produce — curated datasets, semantic models, metric definitions — are exactly what AI projects need: feature stores for ML, knowledge bases for RAG. Reusing them avoids rebuilding from scratch in every AI initiative.

The better the analytics foundation, the faster and safer AI can be introduced. Your data platform decision — warehouse, lake, or lakehouse — is an analytics decision first and an AI decision second. I’ll unpack those architecture choices in the next post.

Don’t start with the model. Start with the metrics.

Pick one high-impact decision your organisation makes today. Write down what data is used, how it’s analysed, and what would change if the analytics were more reliable — before AI enters the picture.

That single exercise will tell you more about your AI readiness than any consultant assessment. And it will tell you whether your next conversation should be about models, or about the metrics and data quality that would make those models worth deploying.

Posted on

In Praise of Boring, Everyday AI: A tale from Manchester Dell Heroes

Yesterday in Manchester, at a Dell Heroes event, I set out with a simple mission: talk about AI reality, not AI hype. In a room full of technical practitioners, I said: “Real AI is the everyday boring AI that just works in the background. You know, the silent AI.”

You could feel the room lean in. Heads nodded. People smiled. For a technical audience that spends their days building, fixing, and maintaining systems, that line hit home. This blog is really an extension of that moment.

The Manchester Moment

The event was packed with conversations about backup platforms, infrastructure, data, and AI. But as we talked through architectures and use cases, one theme kept surfacing: Most of the AI that really matters doesn’t look like a demo. It looks like data pipelines and information flows being processed to becoming knowledge – plumbing. So when I said, “Real AI is the everyday boring AI that just works in the background,” it wasn’t a throwaway line. It was a recognition of the work Data Engineers, Infrastructure Architects and Data Scientists do each day:

  • Architecting and maintaining data centre infrastrucutre
  • Building data pipelines that never get a slide in the keynote
  • Maintaining models that no one outside the team even knows exist
  • Integrating “intelligent” components into systems where the business only cares that it “just works”

The resonance in that room convinced me this story needed to be told more widely.

Headlines vs. Reality

We’re surrounded by AI headlines:

  • New models with more parameters
  • Viral screenshots of chatbots and image generators
  • Predictions that AI will either save or destroy everything

But that’s not what most technical people are dealing with day‑to‑day.

The reality looks more like this:

  • A model quietly reducing fraud by a couple of percentage points
  • An optimization algorithm saving a few milliseconds on a call that happens millions of times a day
  • A recommender system nudging customer behaviour just enough to move the needle
  • A forecasting model helping a business stock the right things at the right time

None of that is glamorous. All of it is real value.

And none of it works without the unglamorous effort behind the scenes.

The AI That Just Works (and Never Gets Thanked)

In Manchester, I asked the room to think about how many AI‑driven systems they rely on that nobody ever talks about:

  • Routing and logistics that adapt intelligently to changing demand
  • Monitoring and anomaly detection that flag issues before humans even notice
  • Capacity planning and autoscaling that keep services available under load
  • Security and fraud detection that run 24/7 in the background

These systems don’t win awards for “cool factor,” but the business would feel their absence in minutes.

Good AI in production is like good infrastructure:

  • When it’s working, you hardly think about it
  • When it fails, everyone suddenly realises just how important it was

The Silent Engineers Behind the Magic

There was another reason that line resonated in Manchester: the audience recognised themselves in it.

Behind every “boring” AI that quietly delivers value, there are people:

  • Data engineers wrestling with messy, fragmented, inconsistent data to build pipelines that are robust, reliable, and governed
  • Data analysts who understand the business context, define the questions worth answering, and interpret what the models are actually telling us
  • Machine learning engineers and MLOps teams wiring models into production, monitoring their behaviour, and keeping them healthy over time
  • Platform and infrastructure engineers ensuring there’s a secure, scalable foundation to run all of this on

None of these roles are “headline jobs.” You won’t see a press release about a beautifully designed data pipeline. But without them, the whole AI story collapses.

In the room in Manchester, I could see this land. For once, the narrative wasn’t “AI will replace you.” It was: AI depends on you.

Reliability Is the Real Innovation

We tend to celebrate AI for novelty:

  • “Look what this model can do!”
  • “Look at this amazing demo!”

But the practitioners in that Dell Heroes audience know something different:

Reliability is the real innovation.

  • A system that quietly does the right thing millions of times a day is more impressive than a one‑off demo
  • A model that improves a business metric by a small percentage, consistently, is more valuable than a viral moment
  • A solution that can be observed, governed, audited, and trusted is more important than one that simply looks clever

That mindset shift—from spectacle to stability—is what will determine which organisations actually win with AI.

The Discipline of Responsible Boredom

One thing that doesn’t get talked about enough is how often responsible AI work ends in the word “no.”

In Manchester, several conversations after my talk turned to the same themes:

  • “We could do this, but the data quality isn’t there yet.”
  • “We can’t deploy that; we don’t fully understand the bias.”
  • “It looks good in the lab, but it’s not robust enough for production.”

Saying no isn’t anti‑innovation; it’s the foundation of trust.

The “boring AI” that just works in the background only exists because teams were disciplined enough to:

  • Clean the data
  • Engineer the features
  • Monitor the models
  • Design for failure
  • Respect governance and policy

It’s not exciting. But it’s exactly what separates a toy from a system the business can depend on.

A Shout‑Out from Manchester to the Quiet Heroes

So this blog is, in many ways, a written version of that shout‑out I gave in Manchester. To everyone who saw themselves in that line: “Real AI is the everyday boring AI that just works in the background.” This is for you.

  • To the data engineers whose success is measured in the number of issues that never occur
  • To the data analysts who keep bringing the conversation back to “does this actually help the business?”
  • To the ML and MLOps teams who lose sleep over drift, latency, and edge cases so users don’t have to
  • To the platform and infra teams who keep the foundation secure, scalable, and compliant

You are the reason AI can move from slideware to reality.

From Hype to Habitat

If there was a single takeaway from that Dell Heroes session in Manchester, it’s this: AI will matter most when it stops being a headline and becomes silent habitat. It should be something we live and build inside:

  • Embedded in systems
  • Integrated into workflows
  • Governed, observed, and trusted
  • Invisible most of the time—until you look at the outcomes

The future of AI isn’t about constant “wow” moments. It’s about a steady, compounding “of course it works like that” reality. And that future belongs to the boring AI in the background—and to the quiet experts who make it possible.

From Manchester, here’s to the boring and the silent.
You’re the real heroes of AI reality.

Posted on

Getting AI Right First Time: From Hype to Durable Capability

Every week, we see a new headline promising that artificial intelligence will transform our business overnight. Yet when you strip away the hype, most successful AI journeys look surprisingly similar to any business systems development and deployment. AI is not different. AI is not magic. And AI for business is definitely not instant. Be prepared for structure and strategy.

In my experience, the organisations that really unlock value from AI tend to follow five strategic steps.

Step 1 – Gain Awareness: Confront Your AI Reality

The starting point isn’t technology – it’s conversation.

Bring business, IT and data teams into the same room, often with a trusted Partner in the mix, and ask a simple question: where could AI create meaningful value in our business? That might be reducing manual effort in operations, accelerating customer support, or spotting patterns in financial or sensor data that humans miss.

Those conversations do three important things:

  • Expose opportunities: You’ll quickly hear recurring pain points and ideas for automation or augmentation.
  • Surface constraints: Skills gaps, fragmented data, legacy systems and budget limitations all come into focus.
  • Build early buy-in: People feel consulted, not “done to”, which matters later when you need adoption.

From there, you can assess your skills, infrastructure and budget, and sketch a lightweight AI roadmap. At this stage, you’re aiming for awareness and alignment – not a 200-page strategy. A one-pager with 3–5 candidate use cases and some honest assumptions is often enough.

Step 2 – Experiment and Prove Value: Earn the Right to Scale

Once you have a shortlist of candidates, resist the urge to boil the ocean. Pick small, high-impact projects where you can clearly measure success.

The most effective teams:

  • Form a joint delivery team that blends business experts, internal IT/data talent and partner support to fill gaps.
  • Focus on use cases where they can move a real KPI – for example, cutting call handling time, reducing scrap, or improving forecast accuracy.
  • Define clear, measurable outcomes and time-box the work. If the pilot can’t be measured, it’s a science project, not a business initiative.

You should absolutely expect some failures here. That’s healthy. The goal isn’t perfection; it’s proving that AI can pay its way in your environment. A handful of well-designed experiments that deliver tangible ROI will do more to build credibility than any slide deck.

Step 3 – Make Scalable, Measurable Impact: Escape the Pilot Graveyard

After a few successful pilots, a new question appears: how do we scale this responsibly?

This is where many organisations stumble. They have one or two great proofs of concept, but they’re stuck in what I call the “pilot graveyard” – isolated successes that never become part of how the business actually works.

To move beyond that point, you need to:

  • Check your data foundations: Are the sources trustworthy, governed and repeatable? Can other teams reuse the same data without rebuilding everything from scratch?
  • Address explainability and trust: Can you show users and stakeholders how the model works, what its limits are, and how decisions are made?
  • Maintain executive sponsorship: Scaling AI often touches process, policy and sometimes jobs. You need senior backing to navigate that change.

At this stage, you should be thinking in terms of re-usable data products and pipelines, not one-off experiments. That might mean standard feature sets, modular components, and shared services rather than bespoke, project-by-project builds.

Step 4 – Scale Capabilities: Build Your AI Operating Model

Once you’ve proven that AI can work for you and you’ve escaped the pilot graveyard, it’s time to invest more seriously.

This typically involves three themes:

  1. Strengthen your data and AI platforms
    Whether you’re primarily on-premises, in the cloud, or running a hybrid strategy, you need platforms that can reliably support model training, deployment and monitoring at scale. Performance, security, cost efficiency and data locality all matter here.
  2. Formalise your AI strategy and governance
    This is where you move from a handful of projects to a portfolio of AI initiatives aligned to business priorities, with clear standards around ethics, compliance and risk.
  3. Democratise data and AI usage
    Push data literacy and AI awareness into the wider organisation, not just the data science team. Business–tech “translators” are especially valuable at this stage: people who can connect business problems to technical solutions, and vice versa.

You’ll also want some central coordination so you don’t end up with dozens of disconnected AI efforts that duplicate work and create inconsistent experiences for customers and employees.

Step 5 – Leverage Full Capabilities of Data & AI: Make AI Boring

By this point, you’ve moved beyond experiments. AI is starting to touch multiple processes and teams. The next step is consolidation.

For many customers, that means:

  • Setting up an AI Center of Excellence (CoE) to provide shared expertise, standards and best practices.
  • Putting robust MLOps and governance in place to handle lifecycle management: data pipelines, model versioning, deployment, monitoring, retraining and decommissioning.
  • Standardising how models are built and reused, with clear patterns and templates so teams don’t reinvent the wheel each time.

The real goal here is to make AI boring and repeatable – something that’s just part of the operating model, not a special project needing a steering committee every time. When AI looks more like a utility and less like an experiment, you know you’ve built a durable capability.

The Thread Through All Five Steps

Across all five steps, the pattern is the same:

  1. Start small – with honest conversations, pragmatic scoping and focused pilots.
  2. Prove value – in language the business cares about: revenue, cost, risk, speed, experience.
  3. Industrialise – by investing in platforms, governance and people so you can repeat success, not chase one-offs.

Partners play a crucial role in that journey. They bring hard-won experience of what works (and what doesn’t) across different industries and architectures. And platforms like Dell’s AI Data Platform provide the bedrock – scalable data infrastructure and data capabilities – that help customers move from AI “science projects” to AI as a durable, enterprise-wide capability. Data first, GPUs second is my advice.

Getting AI right first time isn’t about avoiding all mistakes. It’s about designing your journey so that each step builds confidence, creates value, and lays foundations for the next. When you do that, AI stops being a buzzword and starts being how you run your business.

Posted on

Why AI Projects Fail: The Importance of Architectural Discipline

Architecture at the Gate: Decisions, Drift, and the Cost of Getting it Wrong

I was speaking at an event yesterday. At a break, a guy from the audience asked, ‘Why do so many AI projects fail?’ I thought about this for a moment. And I got to thinking about AI technical debt on shiny new hardware. Then I thought, ‘This is nothing new, software and IT infrastructure projects have been failing since forever.’ But with AI, the problem is amplified. Failures are real loud because the promise of mysterious AI magic has failed.

AI is not magic. And AI should not be treated as a black box. It’s still data, software, algorithms and data centre hardware. What seems to be missing here is architecture best practice — that’s the magic.

Every deployment decision is a bet. The question isn’t whether risk exists — it always does — but whether you’ve looked at it honestly, documented what you found, and made a conscious choice rather than a convenient one.

The Go/No-Go Moment

When a large-scale deployment arrives at the gate with partial compliance coverage, the pressure to approve is real. Time-to-market feels urgent. Stakeholders are watching. The system mostly works. That’s precisely when architectural discipline matters most.

A go decision requires evidence, not confidence. Evidence that availability targets are met, that security controls are implemented and tested, that recovery procedures work under realistic conditions. Confidence without evidence isn’t readiness — it’s optimism wearing a hard hat.

A no-go is the right call when critical risks are unaddressed, when evidence is absent, or when the business impact of a production failure exceeds the cost of delay. That calculation is rarely comfortable, but it’s always honest.

The conditional go is where mature architectural judgement lives. It acknowledges that real systems rarely arrive at deployment gates perfect. Minor gaps, known residual risks, conditions with named owners and defined timelines — these are manageable. The conditional go converts vague concern into accountable commitment. It keeps delivery moving without pretending the gaps don’t exist.

What separates a sound conditional go from wishful thinking is specificity. Vague conditions — “security will be reviewed post-launch” — are not conditions. They are deferrals wearing governance clothing. Every condition needs an owner, a timeline, and a definition of done.

The Drift Problem

Approving a deployment is not the end of the architectural story. It may be the beginning of its most dangerous chapter.

Organisations change faster than their success criteria. SLOs defined at project inception drift out of alignment with business priorities that have shifted beneath them. KPIs that once reflected genuine outcomes become targets that teams optimise for rather than indicators of real performance. Architectural decisions made under one set of assumptions quietly become load-bearing under a completely different set.

The mechanisms that prevent this aren’t complicated, but they require discipline. Observability data should be reviewed against SLOs on a regular cadence — not to confirm things are fine, but to detect early signals that alignment is eroding. Decision registers should carry version history, because a decision that made sense in one context may be actively harmful in another. Stakeholder reviews shouldn’t wait for crises — scheduled, structured conversations about whether the architecture still serves the business are cheaper than the conversations that happen after it doesn’t.

The organisations that handle this well share one characteristic: they treat architectural knowledge as a living organisational asset rather than a set of diagrams produced at project start and forgotten at project end.

The Real Cost

So, my answer to why AI projects fail… The AI adoption wave of the last two years produced a generation of systems deployed without honest go/no-go governance, without versioned decisions, without success criteria anyone could measure. The technical debt was predictable. The security debt was avoidable. The governance debt is still compounding.

Architecture evaluation isn’t bureaucracy. It’s the mechanism by which organisations stay in control of the systems they build — and accountable for the ones they don’t.

ISO 42010 makes sense. Better to have Conway’s Law than Murphy’s Law.