By Hiran de Silva
This morning I came across an excellent post from Michael Polan on LinkedIn.
His starting point was simple:
Excel gets a bad rap.
And instead of joining the familiar chorus of people blaming Excel itself, Michael asked a much more intelligent question:
How do we teach people to use Excel better?
He talked about better data structures. Better architecture. Better separation of data, logic and presentation. Better use of Power Query, automation and integrations. Better governance.
I agree with virtually all of it.
In fact, Michael’s argument comes remarkably close to something I have been saying for years:
The problem isn’t Excel. The problem is how we architect solutions with Excel.
But the discussion underneath his post revealed something else that I think is even more important.
It demonstrated how we arrived at our distorted perception of Excel in the first place.
The Standards Aren’t Wrong
Bediako George joined the discussion and recommended the FAST and ICAEW guidelines for building effective spreadsheets.
Again, nothing particularly controversial there.
These are valuable disciplines for constructing reliable spreadsheets.
My qualification was simply this:
They primarily address the spreadsheet as an individual workbook.
If your problem is an isolated workbook, then standards governing the design, structure, formulas, documentation and maintainability of that workbook are extremely useful.
But that isn’t the problem I spend most of my time talking about.
My concern is what happens when Excel becomes part of a business process.
What happens when there are 10 users?
Or 100?
Or 400?
What happens when information needs to flow between them?
What happens when one person’s spreadsheet needs information created by somebody else’s spreadsheet?
What happens when hundreds of spreadsheets need to operate from the same version of the truth?
At that point, beautifully engineering each individual workbook doesn’t solve the architectural problem.
You can have 400 beautifully engineered spreadsheets and still have a dreadful business process.
Then the Discussion Became More Interesting
Bediako responded by making a much broader point.
He argued that Excel should not be thought of merely as an interactive desktop application. Paired with a workflow server — in his case, the Pebble Stream platform — Excel can participate in sophisticated back-end processes.
Now we are talking about something much closer to my world.
And Bediako certainly has serious experience behind what he is saying. I have actually met him. He was involved with the Global Excel Summit, and we spoke after the conference.
Our disagreement is therefore not about whether Excel can participate in sophisticated enterprise processes.
On that, we are remarkably close.
The interesting difference is where we believe that capability comes from.
Because I don’t believe Excel needs to be rescued from its desktop limitations by some new invention.
Those limitations are largely imaginary.
Microsoft Didn’t Pigeonhole Excel
This is the historical point that is continually being lost.
Microsoft did not design Excel merely as an isolated desktop application and leave it there.
By the mid-1990s, Excel already had connectivity to relational databases.
The professional Excel books of the period covered database connectivity.
Microsoft’s own professional material covered it.
Excel could communicate with structured external data sources.
And once you understand what that means, something profound happens.
The spreadsheet no longer has to contain the data that drives it.
The workbook becomes a client.
The data can live centrally.
One spreadsheet can PUT information into that central store.
Another can GET it.
A hundred spreadsheets can do the same thing.
So can 400.
The central relational database becomes what I call the Digital Librarian.
Instead of sending books from person to person, everybody goes to the librarian.
Instead of hundreds of spreadsheets each carrying their own copies of business data, the data is stored once, centrally, where every authorised spreadsheet in the process can reach it.
That capability isn’t something invented last Tuesday.
The plumbing has been sitting there for decades.
So Who Pigeonholed Excel?
This is where I think the story becomes fascinating.
If Microsoft didn’t reduce Excel to an isolated personal productivity application, who did?
My answer is:
We did.
More specifically, the modern Excel education and social-media ecosystem did.
Look at the overwhelming majority of Excel content online.
Someone has a spreadsheet.
They have a problem inside that spreadsheet.
Here is a clever formula.
Here is a PivotTable.
Here is Power Query.
Here is a LAMBDA.
Here is a dynamic array.
Here is a dashboard.
Here is an automation.
All potentially excellent techniques.
But notice the invisible boundary around almost every demonstration:
the workbook.
The world begins at the left edge of the Excel window and ends at the right edge.
The person watching is implicitly treated as an individual knowledge worker trying to become more productive with their own spreadsheet.
That makes perfect sense for social media.
It is easy to demonstrate.
It fits on a screen.
It can be recorded.
It produces an immediate before-and-after transformation.
And it serves an enormous audience of people who themselves think of Excel primarily as a personal productivity tool.
But repeat that framing thousands upon thousands of times and something extraordinary happens.
The demonstration format becomes our definition of the product.
Social-Media-Compliant Excel
This is what I would call social-media-compliant Excel.
The subject has been compressed until it fits comfortably into a screen recording.
That isn’t Microsoft’s limitation.
It isn’t Excel’s limitation.
It is the limitation of the educational lens through which millions of people have learned to see Excel.
And then comes the great irony.
Having spent years teaching Excel almost exclusively as an isolated personal productivity tool, we discover that isolated spreadsheets create problems when used across an enterprise.
Files get emailed around.
Copies proliferate.
Consolidation becomes difficult.
Versions disagree.
Governance becomes challenging.
People overwrite formulas.
Nobody knows which workbook contains the truth.
And eventually somebody announces:
“This proves Excel doesn’t scale.”
No.
It proves that the standalone spreadsheet architecture doesn’t scale.
Those are very different statements.
The Problem Was Never the Spreadsheet
This is why Michael Polan’s original post matters.
If Excel gets a bad rap, the answer isn’t simply to teach people more Excel features.
We need to teach people to think about architecture.
Teach the distinction between data and presentation.
Teach people that information used by an organisation does not necessarily belong inside somebody’s workbook.
Teach them that collaboration doesn’t have to mean emailing files or placing them in shared folders.
Teach them that a spreadsheet can be one participant in a much larger information system.
And above all, teach them to recognise the difference between a local spreadsheet and a global spreadsheet.
The local spreadsheet lives inside its own little universe.
The global spreadsheet has reach.
It can retrieve information created elsewhere.
It can submit information for other people and processes to consume.
It can participate in workflows.
It can serve hundreds of users while maintaining one central version of the underlying data.
That changes the conversation completely.
Better Excel Is Not Enough
So I would add one thing to Michael’s excellent question:
How do we teach people to use Excel better?
Yes.
But before that, perhaps we need to ask:
How do we teach people to think bigger about what Excel actually is?
Because better formulas inside badly conceived architecture merely give us more sophisticated badly conceived architecture.
Better spreadsheet standards can give us beautifully engineered individual workbooks.
Better Power Query can give us wonderfully automated retrieval of data into individual workbooks.
All useful.
But none of those things, by themselves, answer the enterprise architecture question.
For that, we have to remove the artificial boundary around the workbook.
Excel Wasn’t Dumbed Down by Microsoft
And that brings me back to the claim that started this particular exchange.
Microsoft did not convince the world that Excel was merely a desktop application.
If anything, the opposite is true.
The connectivity was provided decades ago.
The professional community knew about it.
The documentation existed.
The capability existed.
Somewhere along the journey, however, our collective understanding of Excel became narrower.
We became fascinated by what one clever person could make happen inside one workbook.
Then social media industrialised that fascination.
And eventually we forgot to ask what happens when the spreadsheet becomes part of an organisation.
That is why Excel gets a bad rap.
We took an extraordinarily capable application, taught generations of users to think of it primarily as a personal productivity tool, deployed thousands of those personal productivity tools into collaborative business processes…
…and then blamed Excel for the resulting architecture.
Perhaps Excel was never the problem.
Perhaps we simply forgot how big Excel can be.
Add comment