How I Think About Business Value in Data

I’ve been working in data warehousing since the year 2000. Over that time, I’ve seen technologies come and go, architectures rise and fall, and plenty of “next big things” quietly disappear again. What hasn’t changed is the question people keep asking:

How do we get value from data?

Not theoretical value. Not something we promise for “phase three”. Real value that helps a business make better decisions, earn more money, or spend less of it.

The longer I work in this field, the more I realise that the answer is much simpler than most data discussions make it.

Why we bother with data at all

We don’t manage data because it’s interesting. We don’t build platforms because it’s fun. We do it because data is supposed to help the business. In practice, that help almost always shows up in just two ways:
  • Increase revenue
  • Reduce cost
There are, of course, exceptions. Regulatory reporting is a good example. Nobody is excited about building a GDPR report — but we do it because we must. Still, for most initiatives, business value is the real driver. Whenever I look at a data project, I always start with one question: Which business outcome is this meant to support?

What really makes data valuable

Over the years, I’ve noticed that value doesn’t come from complexity or sophistication. It comes from a few very practical things. In my experience, data creates value when:
  • It arrives earlyValuable insights compound over time. Every month of delay quietly destroys potential impact.
  • It’s delivered efficientlyEven great ideas lose value if they take too long or require too much effort to implement.
  • It answers the right questionsBusiness priorities shift constantly — quarter-end, strategy changes, new regulations. Data teams must be able to adjust without starting from scratch.
Put together, it comes down to this: Value comes from delivering the right things, early, and without wasting effort.

Why “agile” isn’t the point

People often talk about agility in data projects, but I’ve stopped using the word when I talk to business stakeholders. Not because agility isn’t important — but because the word itself doesn’t mean much outside IT.

What does make sense to everyone is delay.

If an important insight arrives too late, the decision based on it is also too late. And that delay has a cost. Sometimes it’s lost revenue. Sometimes it’s unnecessary spending. Sometimes it’s just missed opportunity.

That’s how I think about agility: it’s simply about reducing the cost of delay. Automation, tools, and frameworks only matter if they help us do that.

Why big “perfect” solutions rarely survive

Early in my career, we spent months designing enterprise-wide data models. They were impressive — and often irrelevant by the time they went live. Business moves faster than design documents. That’s why I no longer believe in big, up-front solutions. I believe in:
  • starting small
  • delivering something useful quickly
  • adjusting continuously as needs change
A slightly imperfect solution that’s useful today beats a perfect one that arrives too late.

The part everyone tries to avoid 

Many teams try to skip the messy middle of data work — integration, history, shared definitions — hoping it will sort itself out later. 
It rarely does. I’ve seen what happens when everyone defines key concepts on their own. Even when each definition makes sense, the result is confusion, rework, and endless discussions. No matter which architecture you choose: data lake, data mesh, centralized or decentralized. You still need: 
  • shared definitions 
  • consistent logic 
  • a place where data is integrated and understood 
That middle layer is unavoidable. 

When data teams turn into software companies

Another pattern I see often starts with good intentions. Companies want flexibility, so they assemble a stack of open-source tools and build their own platform.

What they don’t always realize is that they’ve just signed up for a second job.

Suddenly, the data team isn’t just delivering insights. They’re also maintaining frameworks, upgrading tools, documenting custom solutions, and training new colleagues on a setup that only exists inside that company.

I like to ask a simple question here:
If data management is as complex as ERP, would you build your own ERP system?

Most companies wouldn’t — and for good reasons. The same logic should apply to data platforms.

Why automation changed my perspective

Automation doesn’t remove all complexity, but it removes a lot of repetitive, low-value work. Used well, it helps teams:
  • deliver value earlier
  • adapt faster to changing priorities
  • reduce long-term maintenance and risk
And most importantly, it frees people to focus on understanding the business rather than rebuilding plumbing.

What I’ve learned after all these years

If there’s one thing I’d like people to take away, it’s this:

Data projects don’t fail because people are incompetent.
They fail because value arrives too late, or in the wrong form, or at too high a cost.

If we stay close to the business, keep things simple, deliver early, and automate what doesn’t need human creativity, data can finally do what it was always supposed to do — help people make better decisions.

And that, in the end, is what this work is really about.