By Hiran de Silva
For well over a decade, one of the most widely quoted pieces of marketing in the enterprise planning industry has been Workday Adaptive Planning’s white paper, originally published as “The Nine Circles of Spreadsheet Hell.” (Originally titled “The Nine Circles of Excel Hell.”)
It has been cited repeatedly by software vendors, consultants and finance transformation specialists as evidence that spreadsheets are fundamentally unsuitable for enterprise planning.
I have never objected to the idea that poor spreadsheet practices create problems.
What I have questioned—ever since the white paper first appeared around 2013—is something much more fundamental.
I believe the comparison itself is flawed.
What exactly is being compared?
The white paper presents a comparison between two approaches.
On one side is a modern cloud planning system.
On the other side is an organisation exchanging spreadsheet files by email, maintaining multiple versions, manually consolidating data, struggling with broken links, lacking audit trails and constantly reconciling conflicting copies.
Everything described on the spreadsheet side certainly exists.
Many organisations really did—and still do—work that way.
But there is a problem.
That is not the only way Excel can be deployed.
The white paper quietly compares two completely different system architectures.
Not two different software products.
Two different architectures.
On one side:
- Shared database
- Connected users
- Centralised data
- Live updates
- Transaction processing
- Permissions
- Audit trail
On the other:
- Independent files
- Email attachments
- Local copies
- Manual consolidation
- Document management
That is not a software comparison.
It is a comparison between a client-server architecture and a document-based architecture.
Those are fundamentally different things.
The comparison I believe should have been made
The real comparison should have been this:
Cloud Planning Client-Server
versus
Excel Client-Server
In other words:
If Excel users are connected to a shared SQL Server or Access database…
If every spreadsheet becomes simply a client…
If data is stored centrally…
If updates are written directly to the database…
If every user sees the same live information…
If permissions, audit trails and business rules are implemented centrally…
…then how many of the “Nine Circles of Spreadsheet Hell” actually remain?
That comparison was never made.
Instead, the white paper compared modern enterprise software with what is effectively a digital version of circulating paper documents.
This isn’t a theoretical argument
This isn’t an architecture that I imagined after reading the white paper.
Long before cloud planning systems became mainstream, I had already been building enterprise Excel systems based on exactly this client-server model.
The spreadsheets themselves contained very little permanent data.
Instead, they performed two simple operations.
GET information from a central database.
PUT information back into the same database.
Everything else—security, auditability, consolidation, reporting, workflow and history—came from the shared data architecture rather than from passing spreadsheet files around.
In other words, the spreadsheet was simply the user interface.
Exactly the same role played today by many browser-based cloud applications.
An interesting development
Perhaps the most interesting twist is what has happened since.
When the original white paper was published, the industry narrative was largely presented as an either/or choice.
Either:
Continue using spreadsheets.
Or:
Move to a cloud planning platform.
That was the message promoted by many software vendors and implementation partners.
Today, however, even Workday promotes deep integration with Excel.
Users can retrieve live data into Excel.
Refresh models.
Submit planning information.
Work directly between Excel and Adaptive Planning.
Architecturally, this is a very different message from the original “Spreadsheet Hell” narrative.
It recognises something many finance professionals already knew.
Excel is not the enemy.
Excel remains one of the best user interfaces ever developed for financial analysis.
Which raises an obvious question
If Excel can now connect directly to Workday…
Why is the cloud platform assumed to be the only possible server?
Why couldn’t the central database sit inside the organisation?
If Excel is simply acting as a client…
Why couldn’t it connect directly to SQL Server?
Or PostgreSQL?
Or Oracle?
Or Azure SQL?
Or another centrally managed database?
Once we recognise that the spreadsheet is simply one client within a client-server architecture, the question changes completely.
The debate is no longer:
“Should we replace Excel?”
Instead it becomes:
“What should Excel connect to?”
That is a much more interesting architectural discussion.
A category error?
Looking back more than a decade later, I believe the original white paper made what philosophers would describe as a category error.
It compared:
- client-server architecture
with
- document management.
Those are not equivalent categories.
A fair comparison would have been:
- client-server planning software
versus
- client-server Excel solutions.
That comparison has rarely been discussed publicly.
Instead, much of the industry has spent years debating whether spreadsheets are inherently flawed, when many of the problems being criticised were actually consequences of disconnected document workflows rather than properties of Excel itself.
The question that still remains
Workday’s modern Excel integration acknowledges something important.
Excel and enterprise planning systems are not mutually exclusive.
They are complementary.
I welcome that recognition.
But it also leaves one final question.
If Excel works so effectively as a connected client…
If the data can be stored centrally…
If audit trails, permissions, workflows and version control can all be managed within a shared database…
Then perhaps the real architectural question is not:
“How do we replace Excel?”
But instead:
“Do we need an additional planning platform at all?”
That is the question I believe should have been asked from the beginning.
Add comment