ServerVultr

Are You Catching the Data Wave or Floundering in the Deep?Analytics isn’t about tracking everything. It’s about selecting what should influence behaviour. In 2026, with better tools than ever, the question is simple, are you surfing the data wave, or struggling to stay afloat?

Why this matters: we measure too much, and decide too little

To continue the series on data-driven storytelling, I want to build on something we touched on recently: good analytics is about measuring the right things and answering the right question. That sounds obvious. It isn’t. Because most organisations still behave as though the goal is to measure everything.

But good analytics doesn’t track everything that can be measured. It identifies which signals matter, which patterns are meaningful, and which changes require attention. It selects what should influence behaviour.

Data is like oil (and that’s the point)

I’ve always liked the analogy that compares data to oil. In its raw form, oil is messy, sticky, unpleasant, and largely useless. You don’t pour crude oil into your car and expect it to run. You refine it. You process it. You extract value from it.

Data is the same. Raw data, straight from operational systems, is chaotic. It’s incomplete, duplicated, and inconsistent. It contains signal and noise tangled together. It only becomes valuable when it’s refined, cleaned, structured, modelled, and interpreted. And here’s the part of the analogy that people don’t mention enough: if you spill oil where you shouldn’t, you’re in serious trouble.

Data is the same. Poor governance. Misuse. Exposure. Misinterpretation. All of it creates risk. So yes, data is valuable. But only when handled properly.

From “swimming in data” to “drowning in it”

I recently wrote on LinkedIn while promoting “Analytics Decision Support: Why Reporting Alone Isn’t Enough” that we’re not short of data,  we’re drowning in it. Someone replied that  Ralph Kimball had said something similar  around the turn of the century ~2003 ish:

We are swimming in data. We just can’t get to it.

At the time in the early 21st century, that was largely true. Data lived in silos. Access was limited. Querying was slow. Integration was painful.

Fast forward to 2026, and the tools have evolved dramatically: cloud platforms, modern warehouses, Fabric, Power BI, semantic models, and self-service analytics.

In many organisations now, access isn’t the primary constraint. Although governance processes and politics can still play a part. You can get to the data. The more interesting question is: Can you do something meaningful with it?

The surfing analogy: same wave, different outcomes

The Kimball comment made me think of another water analogy. If we were “swimming in data” twenty years ago, today we’re facing waves. Some organisations are surfing them. Others are floundering in the deep. When you watch a skilled surfer, it looks effortless. They don’t try to ride every wave. They don’t panic when the water moves. They read the conditions, position themselves, and commit at the right moment. They ride the wave to the shore.

Now watch someone inexperienced: they wait too long, go too early, try to stand without balance, or get knocked down and spend the next few minutes recovering. The wave is the same. The outcome isn’t.

The data wave isn’t slowing down

The wave isn’t going away. If anything, it’s accelerating:

• More telemetry
• More AI outputs
• More behavioural tracking
• More integration between systems

The difference between companies isn’t who has the most data anymore. It’s who can ride it.

What “surfing” looks like in analytics

Organisations that surf the data wave have usually learned to:

• Define the decision before diving into the dataset
• Identify the 3–5 signals that truly matter
• Build reports that reduce noise instead of adding to it
• Move from “interesting” to “actionable”

What “floundering” looks like

Others respond to uncertainty by adding more dashboards, metrics, and pages, hoping that clarity will emerge from volume. It rarely does.

Measuring what influences behaviour

One of the most important lines in this entire series is this:

It is not about tracking everything that can be measured. It is about selecting what should influence behaviour.

Because people do what you measure them by.

If you measure twenty things, none of them feel urgent. If you measure the right three things, behaviour changes.

That’s the difference between swimming and surfing.

Swimming keeps you afloat and moving slowly. Surfing takes you somewhere on the wave quite quickly.

Are you catching the wave?

So here are the key questions.

• Are you surfing the data wave, or floundering in the deep?
• Do your reports clarify what matters, or do they mirror the chaos of the underlying systems?
• Does your analytics function refine raw data into decision-ready insight, or does it simply make more of it visible?

Because the tools are no longer the excuse. Access is no longer the excuse. The wave is here.

Next step

If this resonates, it’s exactly the shift we focus on inside the Data Accelerator: moving from drowning in data to riding it with intent, by starting with the decision, refining the signal, and designing reports that create clarity.

From Data to Insight: Why Meaning Must Be Made ExplicitThere’s a dangerous assumption inside most BI solutions: if we show the numbers clearly enough, the insight will land. It won’t.From data to insight only happens when meaning is made explicit.

The invisible gap in most dashboards

Think about the typical BI workflow.

• Collect the data
• Clean the data
• Model the data
• Visualise the data

And then we stop. We assume the insight is now “in there” somewhere, waiting to be absorbed by whoever looks at the report.

But insight doesn’t automatically emerge from a bar chart. What actually happens is this:

• People see patterns
• They interpret those patterns differently
• They fill gaps with assumptions
• They argue about what it means

And suddenly the conversation shifts from decision-making to interpretation.

The data was correct.
The visual was clear.
But the insight never landed.

Insight is not information

This is the key distinction.

Information answers: What is happening?

Insight answers: Why does it matter?

Those are not the same thing.

You can show that churn has increased by 2%. You can show that revenue dipped in Q3. You can show that customer acquisition costs are rising.

None of those are insights on their own. They are observations.

Insight only exists when someone can articulate:

• Why this change matters
• What it implies
• What should happen next

Until that happens, you have information, not insight.

Why this matters more than ever

As we’ve already discussed in this series, we’re not short of data,  we’re drowning in it. We are not swimming anymore!

In a high-volume environment, the ability to extract insight becomes more important than the ability to produce visuals.

Because when information increases, ambiguity increases with it, unless someone deliberately reduces it.

If insight isn’t made explicit, people will invent it. And when different people invent different interpretations, you get friction instead of forward motion.

Stories are the bridge

This is where storytelling comes in.

Not storytelling as theatre.
Not storytelling as spin.

Storytelling as structure.

A story connects numbers to the real world. It frames what we’re seeing, highlights what’s important, and explains the implications.

For example:

“Revenue declined by 3%” is information.

“Revenue declined by 3%, primarily driven by a drop in mid-market renewals following the pricing change in June, which puts our annual target at risk unless retention improves”   that’s insight.

The second version doesn’t dumb anything down. It makes the meaning explicit.

It removes the need for interpretation for the audience.

This is not about simplifying the data

There’s a common objection at this point:

“Surely people should draw their own conclusions?”

Sometimes, yes. But if your role is decision-support, your responsibility is clarity.

Being intentional about meaning isn’t manipulation. It’s discipline.

It means asking:

• What is the core takeaway here?
• What assumption needs to be removed?
• What decision does this support?

If you don’t answer those questions, the dashboard leaves too much open. And open interpretation in business environments often leads to stalled decisions.

In Power BI, structure matters more than visuals

This is the part that most people underestimate. Insight doesn’t come from choosing the “right” chart type alone.

It comes from:

• structure
• layout
• sequencing
• titles
• annotations
• narrative flow

A Power BI page with five technically perfect visuals can still fail if it doesn’t guide the viewer through a clear story.

• What are we looking at?
• Why does this matter?
• What changed?
• What should we do?

If that flow isn’t obvious, insight isn’t landing.

The cost of leaving meaning implicit

When dashboards leave meaning implicit, three things happen:

1. Meetings get longer
2. Interpretations fragment
3. Decisions slow down

Because the audience is doing analytical work that should have been done before the report was published. That’s not empowerment. That’s inefficiency.

The role of analytics is not to present options endlessly. It is to reduce uncertainty. And reduction requires making meaning explicit.

The shift we work on inside the Data Accelerator

Inside the Data Accelerator, one of the core exercises we run is simple:

Take a dashboard and force the team to write, in plain language:

• What is the key insight?
• Why does it matter?
• What is the implication?

If that statement is difficult to produce, the dashboard isn’t finished.

We don’t start by changing visuals.

We start by clarifying the meaning.

Because insight isn’t something the viewer extracts.

It’s something the analyst must articulate.

A simple test

Look at one of your key charts and ask:

If I removed the title and labels, could two different stakeholders interpret this differently?

If the answer is yes, then the insight hasn’t been made explicit.

Data is raw material. Visuals are presentation. Insight is interpretation. And interpretation doesn’t happen by accident.

---

In the next post, we’ll explore how structure, beginning, middle, and end, turns isolated insights into decision-ready stories.

From the series: Dashboards Don’t Drive Decisions (And That’s the Real Analytics Problem)

Data Overload Is Killing Decision-Making (And More Dashboards Won’t Fix It)We’re not short of data. We’re drowning in it.Every year, organisations collect more information than the year before. More systems. More integrations. More telemetry. More tracking. More metrics.

And the default response? Build another dashboard. Add another page. Track another KPI. Create another breakdown.

The assumption is simple: more visibility equals better decisions.

But that assumption is collapsing under its own weight.

The real constraint isn’t data. It’s attention.

Here’s the uncomfortable truth.

Data has scaled exponentially. Human attention hasn’t.

Executives still have the same number of hours in the day. Managers still have the same cognitive limits. Teams still operate under time pressure, competing priorities, and constant distraction.

When everything is measured, nothing feels important. People do what you measure them by when you measure everything that priority is lost. When every metric is highlighted, none of them stand out.

And when dashboards present ten signals at once, the brain quietly gives up.

What data overload actually does

There’s a belief in analytics that more information reduces uncertainty. In reality, after a certain point, it increases it. When people are confronted with too many metrics:

• They hesitate.
• They defer.
• They look for confirmation of what they already believe.

Data overload doesn’t create clarity. It creates cognitive friction. And friction leads to avoidance.

That’s why so many dashboard conversations end with:

• “We need to dig deeper.”
• “Let’s break this down further.”
• “Can we see this by…?”

Exploration becomes a substitute for decision-making.

The illusion of sophistication

Dense dashboards often look impressive.

• Multiple charts
• Rich interactivity
• Filters everywhere
• Granularity on demand

Technically, they’re sophisticated. Practically, they’re exhausting.

When a report demands that the audience:

• scan ten visuals,
• compare five dimensions,
• remember values from previous charts,
• and infer cause from correlation,

You’re asking them to do advanced analytical thinking on the fly. Most won’t. Not because they’re incapable. Because they’re busy.

When everything matters, nothing does

One of the quiet dangers of modern analytics is that we treat measurement as inherently good (People do what you measure them by because that is what is important). But measurement without prioritisation is noise.

If revenue is up, churn is slightly down, engagement is flat, costs are rising, and pipeline is volatile,  what matters most? Who cares?

If the dashboard doesn’t make that clear, the audience must choose. And different people will choose differently. That’s how you end up with debate instead of direction.

Data overload doesn’t just slow decisions, it fragments them.

Why do more dashboards make it worse?

When organisations sense confusion, they often respond by adding more analysis.

• A new page
• A deeper drill-through
• An extra KPI.

But adding more information to an overloaded environment is like adding more tabs to an already busy browser.

It doesn’t increase clarity. It increases switching costs. Without intentional reduction, dashboards evolve through addition, not refinement. They grow. They rarely improve.

Good analytics is about reduction

This is the part that makes people uncomfortable. Effective data storytelling isn’t about showing everything. It’s about choosing what not to show.

It’s about making deliberate decisions:

• What decision is this report supporting?
• Which metrics directly influence that decision?
• What can be removed without harming clarity?

Reduction isn’t dumbing down. It’s discipline. It’s acknowledging that the goal isn’t to display the richness of the data model, it’s to help someone act.

Focus is a design decision

Clarity doesn’t happen by accident. It’s created by:

• limiting the number of simultaneous messages,
• creating a visual hierarchy,
• sequencing information intentionally,
• and being explicit about what matters most.

This is why the earlier posts in this series matter.

Dashboards don’t drive decisions.
Data, charts, and insight aren’t the same thing.

And now this: Even correct charts won’t help if you overwhelm the human brain.

The Accelerator and the discipline of reduction

One of the core shifts inside the Data Accelerator is teaching teams to design for focus, not volume.

We work on:

• starting with the decision, not the dataset,
• identifying the 3–5 metrics that genuinely matter,
• structuring reports with intent,
• and reducing cognitive load before adding visual polish.

When teams adopt this mindset, something changes.

• Meetings get shorter
• Arguments reduce
• Decisions accelerate

Not because there’s less data, but because there’s less noise.

A simple overload test

Look at your main dashboard and ask:

• How many visuals are competing for attention?
• If I removed half of them, would the core decision still be supported?
• What is the single most important signal on this page?

If that answer isn’t obvious within five seconds, your audience is already overloaded.

Data isn’t the problem. Overexposure is. And until we design analytics around human limits instead of system capacity, more dashboards will continue to produce less clarity.

---

In the next post, I’ll look at how the human brain actually processes visual information, and why understanding cognitive limits is the key to designing dashboards that work.

Read the previous post: Data, Charts, and Insight: Why Seeing the Numbers Isn’t Enough

Start at the beginning: Dashboards Don’t Drive Decisions (And That’s the Real Analytics Problem)

In the previous post, I made a deliberately provocative claim: Dashboards don’t drive decisions.If you haven’t read that yet, it’s worth starting there, because this post explains why that problem keeps showing up,  even in organisations with good data, good tools, and capable analysts.The short answer is this: We keep confusing data, charts, and insight as if they’re the same thing. They’re not.

The dangerous assumption at the heart of analytics

There’s a deeply ingrained belief in analytics that goes largely unchallenged:

If we collect the right data and visualise it clearly enough, insight will emerge on its own.

It sounds reasonable. It’s also wrong.

Data plus charts does not equal insight. What it usually equals is more to look at.

When organisations struggle to make decisions, the response is often to add more dashboards, more visuals, more breakdowns. The hope is that clarity will eventually appear if we just keep refining the charts. But insight doesn’t magically appear when you put numbers into a bar chart.

What actually happens instead

What usually happens is cognitive overload. People look at a dashboard and they do see patterns:

• trends going up or down
• outliers that look worrying
• comparisons that seem interesting

But they don’t know:

• which patterns matter
• what’s driving them
• whether they’re signals or noise

So the brain does what it always does when meaning isn’t explicit, it fills the gaps.

Different people bring different assumptions, experiences, and incentives into the room. The same chart produces multiple interpretations. And suddenly the conversation isn’t about action anymore. It’s about debate.

Why “correct” charts still lead to bad outcomes

This is the part that frustrates analysts the most.

• The charts are technically correct.
• The measures are accurate.
• The data model is sound.

And yet… nothing happens.

That’s because correctness is not the same as usefulness. A chart can be accurate and still be ambiguous. It can show a trend without explaining its cause. It can highlight a change without indicating whether it’s good, bad, or expected.

When insight isn’t explicit, analytics quietly shifts responsibility onto the audience:

• You decide what this means
• You decide what matters
• You decide what to do next

That might feel neutral, but it’s actually abdication.

The insight gap no one talks about

There’s a gap in most analytics workflows that rarely gets named.

We go from:

• data collection
• to modelling
• to visualisation

And then we stop.

We assume insight lives somewhere inside the charts, waiting to be discovered by the viewer.

In reality, insight only exists when someone makes meaning explicit:

• This matters because…
• This is happening due to…
• This means we should…

Without that step, dashboards become pattern libraries rather than decision tools.

Why conversations end with questions, not conclusions

If analytics conversations in your organisation tend to end with:

• “We need to dig into this further”
• “Let’s take this away”
• “Can we get a breakdown by…?”

That’s not curiosity. It’s uncertainty. Those questions aren’t a sign of engagement,  they’re a sign that the report didn’t do enough thinking on behalf of the audience.

Exploration has its place. But when every dashboard invites exploration, and none of them land a conclusion, decision-making slows down dramatically.

This is how you end up with organisations that are “data-driven” in theory, but instinct-driven in practice.

Insight requires intent, not just visuals

The missing ingredient isn’t a better chart type. It’s intent.

Insight only appears when analytics is designed to answer a specific question for a specific decision-maker at a specific moment.

That means:

• deciding what the chart is for, not just what it shows
• choosing what to exclude as deliberately as what to include
• making the implication clear, even if it feels uncomfortable

This doesn’t mean removing nuance or hiding uncertainty. It means guiding interpretation instead of leaving it to chance.

Why does this keep happening

So why do organisations keep falling into this trap? Because most analytics teams are rewarded for:

• accuracy
• completeness
• technical sophistication

They are rarely rewarded for:

• clarity
• decisiveness
• influence on outcomes

As a result, dashboards optimise for being right rather than being useful.

Until that changes, we’ll keep producing analytics that looks impressive but struggles to change behaviour.

From charts to insight: the shift we work on in the Accelerator

This distinction,  between data, charts, and insight,  is one of the foundations of the Data Accelerator.

The Accelerator exists to help teams:

• Stop assuming insight will emerge on its own
• Design analytics around explicit decisions
• Reduce cognitive overload instead of adding to it
• Turn Power BI outputs into a shared understanding, not competing interpretations

When teams make this shift, the quality of conversations changes. Fewer questions are asked at the end of meetings — not because curiosity disappears, but because clarity increases.

A simple test for your dashboards

Here’s a quick way to spot the problem. Look at a chart and ask:

• What conclusion should everyone reach?
• What assumption does this remove?
• What decision does this support?

If those answers aren’t obvious, the chart isn’t finished yet.

Data is not insight. Charts are not understanding.

And until we stop treating them as interchangeable, dashboards will continue to fail at the one thing we expect them to do: help us decide.

---

In the next post, I’ll look at how data overload makes this problem worse,  and why more dashboards often lead to less clarity, not more.

Read the previous post: Dashboards Don’t Drive Decisions (And That’s the Real Analytics Problem)

Why Platforms Like Microsoft Fabric Don’t Fix Broken Data CultureAfter dashboards fail, organisations often reach for a bigger answer.

• A new platform.
• A more integrated stack.
• A promise that this time things will be different.

That’s where platforms like Microsoft Fabric come into play.

• Fabric is powerful.
• Modern.
• Well-architected.

But it’s also one of the most misunderstood investments organisations make. Because platforms don’t fail organisations. Organisations fail to change how they work around them.

The platform myth

There’s a comforting belief that goes something like this:

“Once we’re on the right platform, everything will fall into place.”

• Data will be trusted
• Reporting will be faster
• Teams will align
• Decisions will improve

The platform becomes a proxy for leadership, strategy, and culture. That belief is understandable, but it’s wrong.

What platforms are actually good at

Let’s be clear: platforms like Microsoft Fabric are not the problem.

They are exceptionally good at:

• Centralising data
• Standardising tooling
• Reducing architectural sprawl
• Enabling scale and performance
• Supporting modern analytics patterns

Fabric can remove technical friction. What it cannot remove is organisational friction.

Broken data culture looks like this.

Before blaming tools, it’s worth recognising the symptoms of a broken data culture:

• Metrics are debated more than decisions
• Reports exist, but trust is low
• Teams optimise locally, not collectively
• Data ownership is unclear or political
• Leadership asks for insight, but rewards speed over rigour

In these environments, a new platform doesn’t create clarity; it amplifies confusion.

Why platforms don’t fix culture

Here are a few reasons explaining why data platforms don’t fix and organisations’ data culture

1. Platforms don’t define purpose

A  data platform can answer:

“Where does the data live?”

It cannot answer:

“Why does this data matter?”

Without a shared understanding of:

• Business priorities
• Critical decisions
• Success measures

Even the best platform becomes an expensive filing cabinet.

2. Platforms don’t align with leadership

Data culture is set at the top of a business or organisation.

If leaders:

• Ask for different numbers in different meetings
• Override data with instinct when it’s inconvenient
• Reward delivery over quality

Then no platform will create trust. Culture is reinforced by behaviour, not architecture.

3. Platforms don’t resolve ownership

Modern platforms centralise data, but they don’t magically assign accountability.

Without clear ownership:

• Data quality issues persist
• Definitions drift
• “Someone else owns that” becomes the default

Fabric can host your data estate. It cannot tell you who is responsible for it.

4. Platforms don’t simplify decision-making

A common failure mode is more capability, less clarity.

With powerful platforms:

• More data becomes accessible
• More metrics get surfaced
• More dashboards get built

But without decision discipline, this leads to:

• Cognitive overload
• Slower meetings
• Analysis paralysis

Better tools don’t automatically mean better decisions.

5. Platforms don’t change incentives

People respond to what they are measured on. If teams are incentivised to:

• Deliver quickly rather than accurately
• Protect their numbers rather than challenge them
• Avoid uncomfortable insights

Then culture won’t shift, regardless of platform.

Technology follows incentives, not the other way around.

When platforms do work

Organisations that succeed with platforms like Microsoft Fabric tend to do a few things differently:

• They establish clarity before migration
• They define decision ownership early
• They align leaders on what “good” looks like
• They treat the platform as an enabler, not a saviour

In these environments, Fabric accelerates progress rather than exposing cracks.

The uncomfortable truth

If dashboards are already struggling…
If trust in data is fragile…
If reporting feels slower every year…

A new platform will not fix those problems. It will surface them faster.

Why this matters

Many organisations invest heavily in platforms expecting transformation. What actually  they get instead is:

• Better plumbing
• The same arguments
• New tooling layered on old habits

The gap between capability and impact grows wider. That’s not a platform failure. It’s a leadership and culture challenge.

Where this fits in the bigger picture

This article builds on Why Dashboards Fail and leads into the next questions many leaders face:

• If platforms don’t fix culture, what does?
• How do we know whether we’re observing the right things?
• Why does reporting slow down as complexity grows?

Those are the questions explored in the next parts of this series:

They’re also the questions organisations bring into our Data & Analytics Accelerator often after investing in the platform first.

A better starting question

Instead of asking:

“Is Fabric the right platform for us?”

A more useful question is:

“Are we ready to get value from it?”

That answer has very little to do with technology, and everything to do with clarity, ownership, and culture.

Useful Links

Building a Data-Driven Story: From Reports to Impact

Introduction to the Microsoft Data Platform – Data Platform Roles

What is Microsoft Fabric and How Does It Relate to Power BI?

A four-part framework for leaders

Most data initiatives don’t fail loudly.

They stall.

Dashboards exist, but confidence is low.
Platforms are in place, but value feels elusive.
Reporting works, just not quickly enough.

From the outside, it looks like a tooling problem. From the inside, it feels like friction everywhere.

This series exists to explain why that happens, and why so many organisations experience the same problems at the same stage of growth.

---

The pattern leaders recognise (but rarely name)

Across sectors and sizes, the story is remarkably consistent:

• Early reporting delivers quick wins
• Adoption grows organically
• Complexity creeps in
• Confidence declines
• Momentum slows

Leaders often respond by:

• Building more dashboards
• Investing in new platforms
• Adding layers of monitoring
• Asking for more detail

And yet… things don’t get simpler. They get heavier.

---

The uncomfortable truth

Most organisations don’t have a data problem. They have an outgrown approach to data.

What worked when the organisation was smaller no longer works at scale, but nothing has replaced it.

This framework is designed to make that visible.

---

The four questions that explain almost everything

1. Why do dashboards fail?

Dashboards fail not because of bad visuals or poor tools, but because they are built before clarity exists.

Without shared definitions, decision intent, and ownership:

• Trust erodes
• Reports multiply
• Decisions slow

Dashboards become outputs without purpose.

2. Why don’t platforms fix broken data culture?

Modern platforms are powerful—but power amplifies whatever already exists.

If culture is unclear:

• Platforms expose disagreement faster
• Capability outpaces understanding
• Confusion scales with tooling

Technology removes friction.
It does not create alignment.

3. Why isn’t monitoring enough?

Monitoring tells you when something breaks.

It doesn’t tell you why something changed.

As organisations grow, leaders don’t just need alerts—they need confidence:

• Where did this number come from?
• What changed upstream?
• What decisions are affected?

That gap is the difference between monitoring and observability.

4. Why does reporting slow down as organisations grow?

Reporting slows not because teams work less efficiently, but because:

• Alignment doesn’t scale automatically
• Ownership becomes blurred
• Risk sensitivity increases
• Manual work creeps back in

Speed disappears when trust has to be rebuilt every time.

---

One problem, four symptoms

Taken together, these aren’t separate issues.

They’re different expressions of the same underlying challenge:

Organisations outgrow their original data assumptions—without realising it.

Dashboards fail.
Platforms disappoint.
Monitoring feels insufficient.
Reporting slows.

Not because people aren’t capable—but because clarity hasn’t kept pace with complexity.

---

Why this matters for leaders

When this pattern goes unaddressed:

• Decisions slow quietly
• Risk increases subtly
• Frustration becomes normalised

Teams work harder.
Leaders wait longer.
Confidence erodes in small, compounding ways.

The danger isn’t broken reporting.

The danger is accepting friction as inevitable.

---

A better way to think about data maturity

Data maturity isn’t about:

• More dashboards
• New platforms
• Bigger teams

It’s about:

• Clear decision-making
• Agreed definitions
• Explicit ownership
• Designed-for trust

Tools then accelerate progress instead of exposing cracks.

---

How to read this series

This series is designed to be read in order:

1. Why Dashboards Fail
2. Why Platforms Don’t Fix Broken Data Culture
3. Monitoring vs Observability for Business Leaders
4. Why Reporting Slows Down as Organisations Grow

Each article tackles one symptom.

Together, they form a single framework for understanding why data initiatives stall, and what needs to change before technology can help again.

---

The question that changes everything

Instead of asking:
“What tool should we invest in next?”

A more powerful question is:
“What assumptions about data, decisions, and ownership have we outgrown?”

For most organisations, answering that is the real turning point.

Data Platform Accelerator

Dataflows Gen2 vs Data Factory in Microsoft Fabric: What’s the Difference? I have been asked this question several times in recent training sessions on Microsoft Fabric, so I jotted some notes down here.

Microsoft Fabric brings together the best of Microsoft’s data engineering, data integration, analytics, and AI capabilities into a single unified platform. For many teams adopting Fabric, one of the first questions that arises is:

“What’s the difference between Dataflows Gen2 and Data Factory Pipelines?”

Both can move, transform, and prepare data. Both live inside the Fabric experience. And both can be scheduled, monitored, and orchestrated. However, they serve different purposes, offer different strengths, and work best in different parts of the modern data lifecycle.

This post explains the key differences and provides practical examples to help you choose the right tool for your scenario.

What Are Dataflows Gen2?

Dataflows Gen2 are Fabric’s low-code data preparation and transformation solution. They are built on Power Query, the same engine used in Power BI and Excel, giving analysts and citizen developers a familiar, friendly interface.

Key Characteristics

• Low-code / no-code: Drag-and-drop transformation steps rather than writing SQL or Python.
• Power Query based: Ideal for data wrangling, cleansing, merging, shaping, and enrichment.
• Works well for mid-volume data: Excellent for business data preparation and M-code transformations.
• Outputs straight into Fabric: Can load data into Lakehouses, Warehouses, and KQL databases.
• Accessible to analysts: You don’t need a data engineering background to use it effectively.

When to Use Dataflows Gen2

Dataflows Gen2 shine in scenarios such as:

• Self-service data preparation for analysts building semantic models.
• Ingesting business application data (Excel files, SharePoint lists, Dataverse, SQL).
• Quick transformations such as splitting columns, merging tables, cleaning text, or deduplication.
• Prototyping datasets before handing them over to engineering teams.

If you know Power Query, you’ll feel at home immediately.

What Is Data Factory (in Fabric)?

Fabric’s version of Data Factory combines two things:

1. Pipelines – orchestration and data movement.
2. Dataflows (Power Query) and Notebooks (Spark) – heavy-duty transformation for engineers.

It is Microsoft’s full data integration and ETL/ELT platform, now tightly integrated into Fabric.

Key Characteristics

• Enterprise-grade orchestration with pipelines, triggers, and dependency management.
• Powerful connectors for large-scale ingestion, especially from cloud and on-premises systems.
• Supports Spark notebooks and data engineering workloads.
• Handles high-volume, complex pipelines.
• CI/CD friendly and suited for production data engineering.

When to Use Data Factory

Data Factory is designed for more complex engineering tasks, such as:

• High-volume ingestion from operational systems, APIs, or files landing in cloud storage.
• ETL/ELT using Spark notebooks, SQL scripts, and pipeline activities.
• Orchestrating multi-step workflows, including branching, loops, and conditional logic.
• Copying terabyte-scale datasets from Azure SQL Database, Synapse, ADLS, AWS S3, Oracle, and more.
• Building production-ready pipelines with monitoring, retries, and error handling.

If you are familiar with Azure Data Factory, this will feel like its next evolution within Fabric.

Dataflows Gen2 vs Data Factory: How to Choose?

Here is a simple way to think about it:

Choose Dataflows Gen2 when:

• You want low-code data shaping.
• Business analysts are preparing their own datasets.
• You need simple ingestion or transformation.
• The data volumes are small to medium.
• The source systems are Excel, SharePoint, Dataverse, or SQL.

Choose Data Factory when:

• You are building enterprise pipelines.
• You need orchestration, scheduling, and dependencies.
• You are working with large or complex datasets.
• You require Spark, notebooks, Data Engineering, or SQL pipeline logic.
• Data movement needs to be integrated into CI/CD or operated at production scale.

A Combined Approach

In many organisations the best approach is both, working together:

• Data Factory pipelines handle ingestion from source systems into the Bronze layer.
• Dataflows Gen2 then apply transformations to shape and enrich the data for the Silver layer or the semantic model.

This layered approach provides scalability, governance, and flexibility while still enabling self-service analytics.

Need help applying this in practice?

If your organisation is using Power BI or Microsoft Fabric and needs clarity around architecture, governance, or next steps,
The Data Platform Accelerator is designed to help.

It’s a focused engagement that assesses your current setup and delivers a practical roadmap you can execute.

👉
Learn more about The Data Platform Accelerator

Summary

While Dataflows Gen2 and Data Factory sit side-by-side in Microsoft Fabric, they target very different users and workloads:

• Dataflows Gen2 → Best for analysts, low-code transformations, quick data preparation.
• Data Factory → Best for engineers, enterprise data pipelines, complex ingestion, and orchestration.

Understanding these differences ensures your team uses the right tool for the right job, helping you build efficient, scalable, and well-governed data solutions in Microsoft Fabric.

If you’re teaching or adopting Fabric, this distinction is one of the most important concepts to get right early.

Our 2026 Microsoft Data & Analytics Training Schedule Is Live

We’re excited to share our public training schedule for 2026, covering three of the most in-demand Microsoft data certifications:

• PL-300 – Power BI Data Analyst (3 days) – £995 per seat
• DP-600 – Implementing Analytics Solutions Using Microsoft Fabric (4 days) – £1,200 per seat
• DP-700 – Implementing Data Engineering Solutions Using Microsoft Fabric (4 days) – £1,200 per seat

Across 2026, we will run 24 instructor-led courses, split evenly between UK time and North American time. UK and US courses do not overlap and do not run in the same week, and we’ve planned around key UK bank holidays and US federal holidays.

---

2026 Course Schedule (UK & North America)

All dates below are scheduled in separate weeks for UK vs North America delivery each month.

Month	UK (UK time)	North America (NA time)
January	PL-300 — Mon 12 Jan to Wed 14 Jan 2026	DP-700 — Mon 26 Jan to Thu 29 Jan 2026
February	DP-600 — Tue 10 Feb to Thu 12 Feb 2026	PL-300 — Tue 17 Feb to Thu 19 Feb 2026
March	PL-300 — Tue 10 Mar to Thu 12 Mar 2026	DP-700 — Tue 24 Mar to Fri 27 Mar 2026
April	DP-700 — Tue 7 Apr to Fri 10 Apr 2026	PL-300 — Mon 20 Apr to Wed 22 Apr 2026
May	PL-300 — Tue 12 May to Thu 14 May 2026	DP-600 — Tue 26 May to Fri 29 May 2026
June	DP-700 — Tue 9 Jun to Fri 12 Jun 2026	PL-300 — Tue 16 Jun to Thu 18 Jun 2026
July	PL-300 — Mon 6 Jul to Wed 8 Jul 2026	DP-700 — Tue 14 Jul to Fri 17 Jul 2026
August	DP-600 — Tue 18 Aug to Fri 21 Aug 2026	PL-300 — Tue 25 Aug to Thu 27 Aug 2026
September	PL-300 — Mon 7 Sep to Wed 9 Sep 2026	DP-600 — Tue 15 Sep to Fri 18 Sep 2026
October	DP-700 — Tue 6 Oct to Fri 9 Oct 2026	PL-300 — Tue 20 Oct to Thu 22 Oct 2026
November	PL-300 — Tue 10 Nov to Thu 12 Nov 2026	DP-700 — Mon 30 Nov to Thu 3 Dec 2026
December	DP-600 — Tue 8 Dec to Fri 11 Dec 2026	PL-300 — Tue 15 Dec to Thu 17 Dec 2026

---

Who These Courses Are For

Our public courses are particularly well suited to:

• Data analysts and BI professionals
• Data engineers and analytics engineers
• Consultants and contractors
• Teams transitioning to Microsoft Fabric
• Organisations standardising on Power BI and the Microsoft data platform

We aim for an average of 10 attendees per session, keeping class sizes small enough for meaningful interaction, questions, and discussion.

---

Reserve Your Seat

If you would like to reserve a seat, discuss group bookings, or explore private or tailored delivery, please get in touch.

👉 If you would like to reserve a seat, please get in touch and contact us.

Early expressions of interest help us confirm capacity and ensure you get the dates that work best for you and your team. If your prefer team training contact me directly and we can disucss what you need

When the Data Is Right (and I Ignore It Anyway): A Festive FPL Reflection

I’ve been picking my Fantasy Premier League team for a few weeks now using what I’d like to believe is a sensible balance of data, logic, and gut feel. Unfortunately, every now and then, the gut gets a bit too confident, the excitement kicks in, and I convince myself that this is the moment a player finally explodes into life.

This week’s confession: I wasted a transfer on Isak.

On paper, the logic wasn’t completely mad. He scored, he looked sharp enough, and I told myself that the first goal would open the floodgates. Classic FPL optimism. The kind that ignores everything you’ve learned over years of playing the game and replaces it with vibes and hope.

The problem? The data never agreed with me.

Despite the goal, the underlying numbers never really shifted. The xG didn’t spike, the involvement didn’t suddenly increase, and the minutes picture wasn’t as convincing as I wanted it to be. I chose to ignore that because it felt like the right moment. Unsurprisingly, the data won that battle.

To make matters worse, Isak hasn’t really made the impact I hoped for, and with Ekitike now firmly in possession of the shirt and actually scoring goals, it’s becoming harder and harder to justify holding him. If I’m being brutally honest, if I were Arne Slot, Ekitike would be my starting option right now. He’s converting chances, influencing games, and doing exactly what you want your striker to do.

And FPL, at its core, is a game about minutes and impact.

So that naturally leads to the next question: if not Isak, then who?

Going Back to the Numbers

This is where my Power BI model earns its keep. I track xG, xA, shots in the box, touches in the penalty area, and a few other useful indicators that help separate “good FPL picks” from “players who look busy but don’t return”.

With Christmas approaching and fixtures piling up, I thought it would be a bit of fun (and vaguely sensible) to look at which players are currently overperforming and underperforming their xG. Not as gospel, but as context.

Overperformers are often riding a hot streak that can cool quickly. Underperformers can be traps… but they can also be opportunities if minutes and fixtures line up. This is where judgement still matters.

And yes, I say all this while fully aware that I’d just ignored the data the week before.

The Wolves Problem (and Why It Matters)

I’m writing this having already made my transfer for the week, and Wolves played Manchester United on Monday night. As a Wolves fan, that match was painful. As an FPL manager, it was alarming.

Wolves somehow managed to make a distinctly terrible Manchester United side look competent. That tells you everything you need to know about where they are right now. They look beaten before games even start, confidence is low, and structurally they’re all over the place.

Which brings us neatly to Arsenal.

Wolves are away to Arsenal, Arsenal are in strong form, and this has all the makings of one of those games where things could get ugly quickly. Arsenal at home against a side with no belief is exactly the kind of fixture I want to attack over the festive period.

So I made the move.

The Transfer: Isak ➝ Gyökeres

Out goes Isak, in comes Gyökeres.

The thinking is fairly simple. He looks fit again, the minutes should be there, and Arteta (or “Lego Head”, depending on your preference) will want him involved. Arsenal will dominate the ball, create chances, and if Gyökeres gets service early, this could be one of those statement games.

Is it risk-free? Absolutely not.

But this feels like the right moment to take a calculated punt, especially with Manchester City and Haaland facing a tricky trip to Palace. That fixture has “awkward, frustrating, low-return” written all over it.

Captaincy Roulette

Which brings me to the captaincy.

I’m seriously considering captaining either Gyökeres or Rice this week and backing Haaland to blank. It’s uncomfortable, it goes against rank-protection instincts, and it could backfire spectacularly — but this is also the time of year when calculated risks can pay off big.

Playing safe over Christmas is often how you get quietly overtaken.

Looking Ahead

The other big positive is squad flexibility. When the gameweek rolls over, I’ll have five free transfers and one still in hand before the next deadline. That puts me in a strong position heading into the festive chaos — rotation, injuries, surprise benchings, the lot.

The key lesson this week? Trust the data — but also understand why it’s saying what it’s saying. Ignoring it entirely rarely ends well, but blindly following it without context is just as dangerous.

�