By Hiran de Silva
Why This Reflexive Pushback Misses the Entire Point of Enterprise Reality.
Every time I talk about Excel Hell—the familiar pain of scalability failures, broken links, version chaos, collaboration bottlenecks, and the dreaded monthly consolidation circus—something amusing happens.
I demonstrate a solution that removes all of it.
A solution that is faster, simpler, cleaner, multi-user, live, and—crucially—scales to the enterprise.
And instantly, the influencers say:
“But that’s not Excel.”
This article is written to pre-empt that reaction entirely.
Because the truth is very simple:
Enterprise processes—no matter the tool—always run on a client–server architecture.
Data separate from logic.
Logic separate from interface.
This is a universal non-negotiable truth.
It isn’t about “Excel vs Not Excel.”
It’s about whether you are using any technology in the way enterprise systems have been designed since the 1980s.
And modern Excel is a client–server technology.
Most people simply don’t know it.
1. Client–Server Architecture Is the Universal Default
Pick any enterprise system—SAP, Oracle, Workday, Salesforce, Anaplan—it doesn’t matter.
They all share the same architecture:
- Data lives outside the user’s file.
- Logic can be in the database, the application layer, or the client.
- The user interface is lightweight and disposable.
This is how every serious business system has worked for decades.
So when influencers say:
“That’s not Excel!”
…what they really mean is:
“I’ve never been taught that Excel can operate as a client in a client-server architecture.”
But that is exactly what Microsoft designed Excel to do.
2. Bill Gates Told Us This in 1999 — And Everyone Forgot
In Business @ the Speed of Thought (1999), Bill Gates launched the slogan:
The Digital Nervous System.
The vision was crystal clear:
- Office applications become intelligent, connected clients
- ADO becomes the universal plumbing
- Data flows frictionlessly between desktop tools and enterprise databases
- Users are empowered to build their own systems without waiting for IT
This was not marketing fluff.
By the time that book was released, Microsoft had already delivered everything required:
ADO (ActiveX Data Objects)
The single biggest evolutionary leap in desktop business computing.
ADO turned Excel, Access, Word, Outlook—the entire Office suite—into full participants in client–server architectures.
That was 25 years ago.
Strangely, in Excel’s 40th anniversary celebrations…
nobody mentioned it.
Not one timeline.
Not one retrospective.
Not one influencer.
Arguably the most important capability Excel ever gained—
erased from history.
3. The First Demonstration of Excel–Database Connectivity Was in 1993
This is the part almost nobody believes until they see the video.
In December 1993, at the Microsoft DevCast quarterly briefing, a young engineer named Satya Nadella—yes, the future CEO—demonstrated live:
- Excel
- connected to
- an enterprise relational database
- pulling and updating data
- through an early prototype of what became ADO.
1993.
Before Power Query.
Before Power Pivot.
Before VBA matured.
Before most influencers had even touched Excel.
So when people say:
“Databases and Excel are mutually exclusive.”
They are factually wrong.
Historically wrong.
Architecturally wrong.
And commercially misled.
4. You Don’t Even Need Access to Use a Database
Excel can natively create a relational database file—in microseconds.
Just by saving an .accdb (or the legacy .mdb) file.
No IT department.
No change request.
No governance bottleneck.
No approvals.
No provisioning.
Excel itself can create the database, schema, and tables.
But in practice, almost every business user already has Access installed as part of Office.
Very few know this.
Almost none have been taught it.
Yet the capability has been there for decades.
**5. Influencers Repeat the Same Falsehood:
“It Takes IT a Year to Give You a Database.”**
This line is posted often on LinkedIn and YouTube by highly visible influencers.
It is simply not true.
Excel can create a relational database in under one second on a shared drive.
And Access has been bundled with Office Professional for most business users since the 1990s.
Microsoft did not create Access and ADO so that users had to wait for IT.
They created them so that users could stop waiting.
Empower the edge.
Empower the analyst.
Empower finance.
This was the whole point.
6. VBA Exists Because Users Need Control
There is no ribbon button for:
- Sending SQL commands
- Choosing connection types
- Managing transactions
- Performing inserts/updates/deletes
- Orchestrating Get–Put cycles
- Building multi-user processes
This is intentional.
VBA is there because serious users need direct control of Excel’s objects—
and of ADO.
ADO requires VBA.
Just as SQL Server requires T-SQL.
Just as SAP requires ABAP.
Just as every enterprise system requires an interface to its data layer.
There is nothing “non-Excel” about this.
It is Excel.
It is Excel as designed.
7. Why Power Query Cannot Replace ADO
Power Query is an excellent tool for:
- one-off imports
- transformations
- cleaning
- reshaping data
But it was never designed to be the backbone of enterprise collaboration.
Three fundamental limitations:
1. Power Query can Get data, but cannot Put it back.
No outbound transactions.
No multi-user workflow.
No write-back.
No enterprise process.
2. Power Query is massively overcomplicated for something trivial.
I can teach a complete novice to Get and Put data using ADO within minutes.
Power Query requires a skillset far removed from mainstream finance.
3. Power Query stores the data model inside the workbook.
This is a fatal architectural flaw.
You cannot build a scalable, multi-user, collaborative process
when the data lives inside a file.
That is not client–server.
That is 1980s thinking in modern UI clothing.
8. Why the Influencers Say “That’s Not Excel”
Because their entire world is:
- One spreadsheet
- One user
- One task
- One machine
- One workbook as “the system”
This is the inside-the-box universe of YouTube Excel content.
Enterprise architecture does not exist there.
So anything outside that worldview is interpreted as:
“You’re cheating.”
“That’s a database.”
“That’s not Excel.”
But this is like saying:
“If you plug a monitor into your laptop,
that’s not really a laptop anymore.”
No.
It’s simply using the laptop as designed.
9. The Excel Replacement Industry Depends on This Misconception
FP&A SaaS companies grew by promoting the myth that:
- Excel cannot scale
- Excel cannot consolidate
- Excel cannot collaborate
- Excel cannot manage enterprise processes
- Excel cannot be connected to a database
None of it was ever true.
Excel can do all of these things natively.
Just not with 1980s spreadsheet thinking.
They rely on the public remaining unaware of client–server Excel.
If they acknowledged it, their business model collapses.
10. In the End, the Proof Is Simple
My demonstrations show:
- Multi-user workflows
- Real-time consolidation
- Live data retrieval
- Write-back
- Department-wide collaboration
- Zero copying and pasting
- Zero broken links
- Zero version conflicts
- Seamless auditability
- Instant scalability to thousands of users
All using:
- Excel
- ADO
- An Access database file (or any relational database)
- A few lines of VBA
Nothing exotic.
Nothing external.
Nothing “non-Excel.”
Just Excel used the way Microsoft intended.
Conclusion: “That’s Not Excel” Is the Last Refuge of 1980s Thinking
Excel is a client–server tool.
Always has been.
It simply wasn’t taught.
Influencers were trained on isolated spreadsheets,
and so they believe isolated spreadsheets are all Excel is.
But the enterprise does not care about influencer preferences.
The enterprise runs on architecture.
Excel fits that architecture natively.
And when you separate data from spreadsheets—
when you use Excel as the client and a relational database as the server—
the Excel Hell evaporates.
Collaboration appears.
Scalability appears.
Consolidation becomes instant.
Processes become transparent.
And the organisation finally breathes.
This is Excel.
This has always been Excel.
The only thing that wasn’t Excel…
was the way we were taught to use it.



Add comment