Before We Replace the Wheel, Can We Ask Why It Is Broken?
By Hiran de Silva
There is an interesting discussion taking place in the GenCFO community around the familiar subject of “broken spreadsheets.”
And I find myself agreeing with an important point being made there.
Something is broken.
But I think we are jumping far too quickly from that observation to the proposed solution.
Before we redesign anything, replace anything, or buy anything, shouldn’t we first ask a much more fundamental question?
What exactly is broken — and why?
Because until we understand the cause of the problem, how can we possibly know what the appropriate solution is?
That thought led me to a rather simple analogy.
The Square Wheel
Imagine a vehicle fitted with square wheels.
It will move.
But it won’t move very well.
As the wheel rotates, the axle has to rise and fall. The vehicle has to be repeatedly lifted as each corner of the square passes underneath it.
That requires energy.
The ride is uncomfortable.
The faster you go, the worse the problem becomes.
So we can quite legitimately say:
“This wheel is broken.”
But now comes the important part.
What do we do about it?
We could simply declare:
Square wheels don’t work. Wheels are fundamentally unsuitable for serious transportation.
And then along comes a salesman.
Fortunately, his company sells skis.
“Exactly!” he says.
“We’ve been saying this for years. Look at all the problems you’re having with wheels. They’re inefficient. They’re uncomfortable. They don’t scale. Your passengers hate them.
You need skis.”
There is only one problem with this sales pitch.
Round wheels exist.
Diagnose Before You Replace
Once we understand why the square wheel performs badly, the solution becomes rather obvious.
Change the architecture of the wheel.
Make it round.
Now the distance between the axle and the ground remains constant as the wheel rotates. The vehicle no longer needs to be repeatedly lifted and dropped.
We haven’t replaced the concept of the wheel.
We’ve removed the architectural characteristic that was causing the problem.
And that, to me, is remarkably similar to the debate we have been having about Excel for decades.
We are constantly shown examples of spreadsheet processes that are difficult to control, difficult to consolidate, difficult to audit and difficult to scale.
Hundreds of independent workbooks.
Copies of copies of copies.
External links.
Manual consolidation.
Different versions of the truth.
People emailing files backwards and forwards.
And somebody quite reasonably says:
“Look. Excel is broken.”
But wait.
What exactly is broken?
Is Excel broken?
Or is the architecture in which Excel has been deployed broken?
Those are two completely different propositions.
The Architectural Alternative
For around 30 years, Excel has been capable of operating as a client to a relational database.
That database might be Access.
It might be SQL Server.
It might be another relational database.
Instead of storing the enterprise’s data independently across hundreds of spreadsheets, the data can be stored centrally in structured relational tables.
Excel becomes the interface.
It can GET the information required by a particular user.
It can PUT information back.
The relational database becomes what I sometimes call the Digital Librarian.
One central structured repository serving many Excel clients.
Suddenly the architecture is completely different.
Instead of:
Spreadsheet → Spreadsheet → Spreadsheet → Spreadsheet
we have:
Excel clients ↔ Relational Database
The spreadsheets are no longer trying to be the database.
And many of the problems normally attributed to “Excel” disappear because we have removed the architectural feature that was creating them in the first place.
That is our round wheel.
This Is Not a New Excel Feature
And this is the part of the discussion that I find particularly fascinating.
I’m not talking about some clever new feature Microsoft introduced last year.
I’m not talking about AI.
I’m not talking about Fabric.
I’m not talking about Power Query, Power Pivot, Python, Office Scripts or dynamic arrays.
I’m talking about something Excel has been able to participate in for roughly three decades.
Excel and relational databases have been able to work together since the 1990s.
So perhaps the really interesting question isn’t:
“Why is Excel broken?”
Perhaps it is:
“Why has an architectural capability we’ve had for around 30 years become so invisible in today’s Excel conversation?”
My GenCFO Challenge
And that brings me back to the GenCFO discussion.
I would love to see actual examples of these broken spreadsheet processes.
Not because I want to defend every spreadsheet.
Quite the opposite.
Give me the broken ones.
Show me the 400 spreadsheets.
Show me the consolidation nightmare.
Show me the version-control problem.
Show me the reconciliation problem.
Show me the audit problem.
Show me the process that takes three days every month.
Then let’s examine it.
Why is it broken?
Which architectural decision created the problem?
And most importantly:
Could that problem have been avoided while retaining Excel as the user’s interface?
That is a much more useful business question than simply asking what product should replace Excel.
The GenCFO Panel
There is a particular reason this interests me in the context of GenCFO.
I participated in a GenCFO Academy panel in November 2023.
One of the other panellists was Justin Merritt from Planful.
During that discussion, Justin made the perfectly reasonable point that organisations were using Excel for activities such as reconciliations and consolidations when there were better tools available for those purposes.
And that raises a fascinating practical question.
Consider my own budgeting architecture.
A manager is reviewing a budget in Excel.
The manager can move from Group to Region, Country, City or Shop.
The underlying information is held centrally.
The consolidation is available immediately.
As information changes, the consolidated view reflects the information held centrally.
So suppose we are sitting together in a live budget review meeting.
We are reviewing France.
Someone changes something.
We want to see the effect at European level.
At what point do we leave Excel to perform the consolidation somewhere else?
Do we adjourn the meeting?
Do we export the data?
Do we send it to another system?
Do we come back later?
Why?
The consolidation is already there.
That doesn’t prove that Excel is universally the right tool.
Nor does it prove that Planful, Anaplan, Workday Adaptive Planning, SAP, Oracle or any other platform is the wrong tool.
It asks something much simpler:
What problem are we actually solving?
“But Nobody Else Does That”
There is another response I have encountered over the years.
Something along the lines of:
“Yes, Hiran, you know how to do that. But most Excel users don’t.”
I find that response extraordinary.
Because if the architecture solves the problem, then lack of awareness of the architecture is surely an education problem.
It isn’t evidence that the architecture doesn’t work.
Imagine saying:
“Yes, technically round wheels solve the problem. But most of our customers have only ever seen square wheels.”
That doesn’t strengthen the case for skis.
It strengthens the case for teaching people that round wheels exist.
And That Is Where This Gets Awkward
Because there is now an enormous industry built around solving the problems associated with spreadsheets.
And many of those products undoubtedly solve genuine business problems.
But there is an uncomfortable question worth asking.
How much of that market depends upon the customer believing that the problems demonstrated are intrinsic to Excel?
Because if the customer believes:
“This is what happens when you use Excel,”
then replacing Excel appears perfectly logical.
But if the customer discovers:
“This is what happens when you use Excel with this particular architecture,”
the conversation changes.
Now there are alternatives.
Replace Excel?
Perhaps.
Or redesign the process while retaining Excel?
Perhaps.
Or combine Excel with a relational database?
Perhaps.
Or use a specialist planning platform?
Perhaps.
Now management has an architectural decision to make rather than a product pitch to accept.
The Missing Question
So my message to Christopher Argent and the GenCFO community is not:
“Excel isn’t broken.”
That would be far too simplistic.
My message is:
Show me what is broken.
Then let’s investigate why.
If the wheel is square, let’s establish that the shape of the wheel is causing the problem.
Then we can compare the possible solutions intelligently.
Maybe skis genuinely are the best answer.
Maybe we need a completely different vehicle.
But perhaps — just perhaps — all we needed was a round wheel.
And before an organisation spends hundreds of thousands, or millions, replacing something that supposedly doesn’t work, surely somebody in the room should be allowed to ask:
Have we first tried fixing the architecture?
Add comment