By Hiran de Silva
This article began with a deliberately outrageous comment I made on a recent LinkedIn post by Paul Barnhurst.
Power Query is dead.
Paul responded, equally mischievously:
Yes, it is. And so is the human race.
Of course. And allegedly.
Because, obviously, Power Query isn’t literally dead.
It is an extremely capable ETL tool. Extract, Transform and Load will continue to be necessary. Power Query will continue to be useful. People will continue using it, teaching it and building excellent solutions with it.
So my headline isn’t really a prediction about Microsoft’s product roadmap.
It is an argument about architecture.
And I want to make that argument properly.
Because once we stop asking how to make an individual spreadsheet user more efficient, and instead ask how Excel should operate across an organisation, something rather extraordinary happens.
Power Query begins to look like part of the old world.
And Excel itself becomes part of the new one.
Hence:
Power Query is dead.
Long live Excel beyond Power Query.
Meet Tim
Let’s begin with Tim.
Tim works with Excel every day.
He receives spreadsheets from colleagues. He downloads CSV files from an ERP or an Excel-replacement planning system. He may enter some information himself. He combines data, transforms it, analyses it and produces something useful.
Perhaps Tim is an accountant.
Perhaps he works in FP&A.
Perhaps he produces management reports.
Whatever his particular job, eventually he finishes his work and sends a spreadsheet to Tom.
And while he’s at it, he might copy Tom’s boss.
And his own boss.
Perhaps the rest of the team might be interested too.
Why not?
It costs nothing to attach another recipient.
Now consider Tom.
Tom’s actual job may be completely different from Tim’s, but his working practice looks remarkably similar.
Tom receives information from multiple places. He combines it. He transforms it. He adds his own expertise. He produces another workbook.
Then Tom sends that somewhere else.
Ted does the same.
Todd does the same.
Multiply this beyond our little group of Tim, Tom, Ted and Todd and you have hundreds, perhaps thousands, of people doing variations of essentially the same thing.
That is the enterprise spreadsheet environment.
And architecturally, it is point-to-point data processing.
Data moves from person to person, usually encapsulated inside files. Spreadsheets simultaneously become calculation engines, user interfaces, data stores and data-distribution documents and mechanisms.
At enterprise scale, the result can become a huge criss-crossing network of dependencies.
And this is where nearly every familiar criticism of spreadsheets begins.
The Problem Everyone Already Agrees On
We hear the criticisms constantly.
Spreadsheet processes don’t scale.
They create silos.
Collaboration is difficult.
Governance is weak.
Security becomes dependent upon protecting files.
Audit trails are inadequate.
Nobody quite knows who changed what, when, or why.
Different versions circulate.
Consolidations become complicated.
Processes become fragile.
And eventually something that began as an extraordinarily agile solution becomes difficult to manage precisely because its data and processes have become geographically dispersed across workbooks, folders, inboxes, people and locations.
I don’t particularly disagree with that diagnosis.
In fact, it is fundamental to my argument.
The mistake is what happens next.
Because we blame Excel for an architectural decision.
Enter the Excel Replacement Industry
For nearly 30 years, I have watched an industry demonstrate an alternative.
Its demonstration is enormously persuasive.
Instead of hundreds of files moving between hundreds of people, put the data somewhere central.
A database.
Users then interact with that central system through clients.
The clients don’t have to be sent around the organisation.
The data doesn’t have to travel inside documents.
Everyone interacts with the same centrally managed information.
Diagrammatically, the contrast is devastatingly simple.
Point-to-point:
Tim → Tom → Ted → Todd → somebody else → somebody else…
Spreadsheets everywhere.
Data everywhere.
Versions everywhere.
Now compare that with:
Hub-and-spoke:
Tim ↘
Tom → CENTRAL DATA ← Ted
Todd ↗
Suddenly we have clarity.
Control.
Governance.
Security.
Auditability.
Scalability.
This is essentially the architectural argument that the ERP, planning and Excel-replacement industries have been making for decades.
And on the architecture, I agree with them.
Hub-and-spoke beats point-to-point.
That isn’t where our disagreement lies.
Our disagreement is over something much more interesting.
What Has Modern Excel Been Optimising?
Now go back to Tim.
Tim’s life has improved enormously over the last 15 years.
We have given him Excel Tables.
Power Pivot.
Power Query.
XLOOKUP.
Dynamic Arrays.
LET.
LAMBDA.
Python in Excel.
Co-pilot.
And more.
These are extraordinarily powerful capabilities.
But ask a different question:
What exactly are we making more efficient?
We’re making Tim more efficient.
Tim receives information from different sources.
Power Query makes extracting and transforming that information much easier.
Wonderful.
Tim produces his output.
Wonderful.
Then Tim sends it to Tom.
And Tom becomes more efficient too.
And wonderful!
Then Ted.
Then Todd.
We’ve made every individual node in the network more sophisticated.
But we haven’t necessarily changed the network.
We have automated the people inside the point-to-point architecture without questioning the fundamental flaws in the point-to-point architecture itself.
That is the crucial distinction.
Power Query may make Tim dramatically more efficient while leaving the enterprise process architecturally unchanged.
Indeed, the better Tim becomes at receiving, transforming and combining disparate sources, the more tolerable the fragmented architecture becomes.
We haven’t eliminated the fragmentation.
We’ve become better at coping with it.
And That Is Why Power Query Is Dead
Now my headline should begin to make sense.
I am not arguing that Power Query suddenly stops working.
Nor am I arguing that ETL (extract, transform, and load) disappears.
I’m asking something much more fundamental.
What happens if the organisation stops designing spreadsheet processes around files moving between people?
If enterprise processes move towards hub-and-spoke architecture, then an Excel capability whose great strength is helping individual users ingest and transform data from disparate sources no longer occupies the centre of the architectural story.
It becomes a tool.
A useful tool.
Sometimes an extremely useful tool.
But it is no longer the governing philosophy of how Excel should work across the enterprise.
And there is an important qualification.
If Tim is genuinely the end of the line, none of this matters.
Let me explain.
Suppose Tim runs a small business. He imports data, analyses it, produces his own dashboard and makes his own decisions.
Nobody needs his workbook.
Nobody needs to contribute to his process.
Nobody downstream depends upon his output.
Power Query may be perfect for Tim’s purposes.
The architectural problem begins when Tim’s spreadsheet becomes part of a process involving other people.
At that moment we should at least ask whether moving files between those people is the correct architecture.
And the higher you climb through an organisation, the more important that question becomes.
Tim cares about completing Tim’s job.
The CFO must care about the system created by thousands of Tims.
That is a completely different problem.
The King Is Dead. Long Live the King.
This brings us to the second half of my title.
As a child, I remember being puzzled by the expression:
The king is dead. Long live the king.
If he’s dead, how can he live long?
Of course, the expression refers to two kings.
The old king has died.
The institution continues.
There is immediately a new king.
And that is precisely what I mean here.
Power Query is dead.
Not because data transformation disappears.
But because I am challenging the architectural world in which Power Query has become king.
So what replaces it?
Long live Excel beyond Power Query.
And this is where the story becomes much more interesting.
What If Excel Can Already Do Hub-and-Spoke?
Look again at our beautiful hub-and-spoke diagram.
There is a central relational database.
Tim’s spreadsheet seamlessly connects to it.
Tom’s spreadsheet seamlessly connects to it.
Ted’s spreadsheet seamlessly connects to it.
Todd’s spreadsheet seamlessly connects to it.
Data is PUT centrally.
Data is GET centrally.
Nobody needs to send anybody a workbook.
Everyone can continue using Excel.
Read that again.
Everyone can continue using Excel.
That is the part missing from the conventional debate.
We are usually presented with two choices:
Excel chaos
or
centralised enterprise system.
But those aren’t the only choices.
There is a third:
Excel operating as the client within a hub-and-spoke architecture.
And here is the shocker!
And Excel has had the native capability to participate in that architecture for decades.
Excel Has a Secret Door
You won’t find this capability prominently displayed on the ribbon.
It isn’t a fashionable new formula.
It isn’t LAMBDA.
It isn’t Power Query.
It isn’t Python.
It isn’t Co-pilot.
And it isn’t some proprietary add-in that I invented.
One of the principal technologies is ActiveX Data Objects — ADO.
Excel can connect to centrally located relational data.
That might be Access.
SQL Server.
Oracle.
Or another relational database.
Excel can retrieve the information it needs.
But critically, Excel can also PUT information back.
That changes everything.
Because now the workbook no longer needs to be the permanent data store.
And it no longer needs to be the vehicle by which data travels around the organisation.
The spreadsheet becomes what it is exceptionally good at being:
the client.
The interface.
The analytical environment.
The modelling environment.
The place where Tim applies Tim’s expertise.
Meanwhile, the organisation’s data belongs to the organisation.
Centrally.
GET and PUT
The conceptual leap is remarkably small.
There are really two ideas.
GET.
Get the information that this user needs from the central store.
And:
PUT.
Put the information created or changed by this user back into the central store.
That’s it.
Once you understand GET and PUT, an entirely different Excel architecture becomes possible.
Instead of:
Spreadsheet → Spreadsheet → Spreadsheet → Spreadsheet
we have:
Excel ↔ Data
Excel ↔ Data
Excel ↔ Data
Excel ↔ Data
The spreadsheets no longer need to know about one another.
Tim doesn’t need Tom’s workbook.
Tom doesn’t need Ted’s workbook.
Ted doesn’t need yesterday’s consolidation workbook.
And because there is only one version of the truth, we need no reconciliations. This is a big win.
Each user interacts with the process, through Excel.
And because the data is central, everybody can potentially see the consequences of everybody else’s authorised actions immediately.
One Version of the Truth.
That is collaboration without circulating documents.
That is consolidation without collecting files.
That is scalability without building ever-larger workbooks.
And that is Excel operating beyond Power Query.
Why Power Query Isn’t the Answer to This
Power Query is an ETL tool.
Its purpose is principally about bringing information in, into Excel, and transforming it.
That is tremendously useful.
But a collaborative enterprise process requires something else.
It requires two-way interaction.
The spreadsheet needs to GET.
The spreadsheet also needs to PUT.
An authorised user changes something.
That change goes centrally.
Another authorised user retrieves it.
The central store becomes the librarian of the process.
Excel becomes the client.
Or, as we now say, an app.
ADO provides this kind of direct database interaction on Windows desktop Excel; other architectures can achieve similar patterns using more modern web/cloud mechanisms. Such as Office Scripts.
The important point isn’t therefore that everybody should replace Power Query with ADO.
That would simply replace one feature obsession with another.
The important point is:
Stop beginning with the feature. Begin with the architecture.
Power Query answers:
How can I get and transform this data efficiently? For me.
The enterprise question is:
Why is this data travelling between people in spreadsheets in the first place?
Those are profoundly different questions.
The CFO’s Question
And now imagine showing both architectures to a CFO.
First, the familiar spreadsheet network.
Files everywhere.
Versions.
Attachments.
Shared folders.
Password protection.
Manual consolidation.
Dependencies.
Then show the hub-and-spoke alternative.
Central data.
Controlled access.
Audit.
Immediate consolidation.
Excel clients accessing precisely what each user needs.
And then tell the CFO:
Both of these can be Excel architectures.
I think the CFO’s first question might be rather obvious.
If Excel could do this, why on earth have we been doing that?
And the second question might be even more uncomfortable.
Why didn’t anybody tell us?
That is the question I believe the Excel community now needs to confront.
The Strange Economics of the Excel Debate
There is something fascinating about the modern Excel ecosystem.
The communities containing the people most dependent upon Excel — CFOs, FP&A professionals, financial modellers and Excel practitioners — naturally attract vendors selling alternatives to spreadsheet-based processes.
And what architecture do those vendors tend to demonstrate?
Hub-and-spoke.
Of course they do.
Because hub-and-spoke is compelling.
The chaotic spreadsheet picture makes the sales presentation extraordinarily easy.
Yet at the same time, the Excel education surrounding those audiences remains overwhelmingly focused on making the individual spreadsheet practitioner better at working inside the workbook.
Ironically, the two worlds almost perfectly complement one another.
One industry teaches Tim to become spectacularly efficient inside Excel.
Another industry points at the resulting enterprise spreadsheet architecture and says:
Look at this chaos. You need to replace it.
My challenge is to insert one missing possibility between them.
What happens if Tim keeps Excel — but we change the architecture?
Beyond the False Choice
This isn’t an argument that Anaplan is bad.
Or Workday Adaptive Planning is bad.
Or Planful is bad.
Or Datarails is bad.
Nor is it an argument that every organisation should build everything itself in Excel.
That would be as intellectually lazy as saying Excel should always be replaced.
My argument is about choice.
Before spending substantial money replacing an Excel process because its spreadsheet architecture is fragmented, surely we should establish whether the fragmentation is actually a limitation of Excel.
What if it isn’t?
What if the problem is merely the way we chose to architect Excel?
Then the decision changes.
The comparison is no longer:
Bad Excel versus enterprise software.
It becomes:
Point-to-point Excel versus hub-and-spoke Excel, versus alternative enterprise platform.
Now we have a meaningful comparison.
Cost.
Control.
Flexibility.
Customisation.
Governance.
Speed.
Risk.
Maintainability.
User experience.
Integration.
Business value.
Put all three on the table.
Then choose.
That is all I am suggesting.
The Missing Professional Excel
There is another historical irony here.
What I am describing isn’t futuristic.
The underlying capability has existed for decades.
ADO and related database technologies were part of the professional Excel landscape long before Power Query existed.
In all professional Excel books it was front-and-sentre.
Somewhere along the journey, however, our conception of advanced Excel became increasingly synonymous with advanced workbook features.
More sophisticated formulas.
More sophisticated transformations.
More sophisticated functions.
More sophisticated code.
We became fascinated with what could happen inside the box.
But …
The enterprise problem exists outside it.
The question isn’t merely:
What extraordinary things can this Excel feature do?
It is:
How does this workbook participate safely and efficiently in an organisation involving hundreds or thousands of people?
That is Professional Excel at an entirely different level.
Long Live Excel Beyond Power Query
So let me state my argument as clearly as possible.
If the future of enterprise processes is point-to-point — if we genuinely believe that thousands of people should continue exchanging data through files, shared folders and workbook dependencies — then Power Query has an extraordinarily bright future at the centre of that world.
It makes that world much easier to live in.
But if we believe the future is hub-and-spoke…
…if we believe organisational data should be centrally located …
…if we believe spreadsheets should interact with processes rather than carry processes between people…
…if we believe collaboration should mean interacting with common data rather than circulating documents…
…then the role of Power Query changes.
And another Excel emerges.
Not Excel the document.
Not Excel the document-editor.
Not Excel the emailed attachment.
Not Excel the isolated workbook.
But Excel the enterprise client. The app.
Excel managing data in a centrally located relational data.
Excel able to GET.
Excel able to PUT.
Excel retaining the agility, familiarity and analytical freedom that made people reluctant to abandon it in the first place.
That is the Excel I discovered nearly 30 years ago.
And it is the Excel I believe we urgently need to rediscover today.
The Excel of the future, as any Excel professional time traveller will tell you.
Because he has seen it.
And you have seen it today.
So yes, Paul.
I stand by my deliberately provocative headline.
Power Query is dead.
Not literally.
Architecturally.
Because the really interesting future of Excel begins when we stop asking how efficiently Tim can process another incoming spreadsheet…
…and start asking why Tim needed to receive that spreadsheet at all.
Power Query is dead.
Long live Excel beyond Power Query.
Add comment