By Hiran de Silva
There is a curious narrative around Microsoft Access.
Access is dead. Nobody uses it anymore. Microsoft has let it die.
I came across it again in a discussion prompted by Paul Barnhurst’s Financial Modelling Corner, where Myles Arnott was talking about Access and apparently suggesting that Microsoft may eventually discontinue it because some of its capabilities are increasingly appearing in Excel.
I disagree.
Quite strongly.
Because underneath this argument is a fundamental misunderstanding of what a spreadsheet is, what a relational database is, and—most importantly—why Microsoft engineered the two technologies to work together in the first place.
Excel is not becoming Access
A spreadsheet is not a relational database.
It isn’t designed to do what a relational database is designed to do.
They are different technologies with different purposes.
Think of a motor car and an aeroplane. An aeroplane can taxi along the ground. Conceivably, you could even engineer a car that could fly.
That doesn’t make the car an aeroplane or the aeroplane a car.
And adding increasingly sophisticated data functionality to Excel does not turn Excel into a relational database.
But here is the much more important point.
Excel doesn’t need to become a relational database.
Microsoft solved that problem decades ago.
Excel was engineered to work with relational databases.
And that distinction changes everything.
The original idea behind Microsoft Office
It is useful to go back about 30 years.
Microsoft Office wasn’t originally conceived merely as a convenient box containing several unrelated applications.
Word, Excel, PowerPoint and Access were intended to work together.
Microsoft experimented with several ways of achieving that integration.
Some survived. Some didn’t.
OLE and embedded Office objects were an interesting example. You could embed an Excel workbook inside a Word document, double-click it and effectively have Excel come alive inside the document.
It was clever technology, although in practice it could become cumbersome.
Other ideas came and went too.
But one enormously important idea survived.
Data connectivity.
By the Office 97 era, ActiveX Data Objects—ADO—provided programmers with a remarkably simple way for Office applications to communicate with databases.
For Excel, the implications were profound.
The data no longer had to live in the spreadsheet.
The spreadsheet could become the user’s working environment while the data lived somewhere else entirely.
That “somewhere else” could be a relational database.
And for the ordinary business user, the most accessible relational database was Microsoft Access.
The spreadsheet suddenly acquired a Digital Librarian
This is where the significance of Access to Excel is so often missed.
Don’t think about this from the traditional IT perspective of:
“Excel as a front end to a database.”
Think about it from the spreadsheet user’s perspective.
Imagine a business process involving 10 spreadsheets.
Then imagine 100.
Then 400.
If every spreadsheet carries its own copy of the data, you have hundreds of independent versions of information scattered around the organisation.
Now make one conceptual change.
Take the data out of those spreadsheets.
Store it once, in a structured central location.
Every spreadsheet involved in the process can now GET the information it needs from that location.
And, where appropriate, PUT information back.
The spreadsheets no longer need to exchange their knowledge with each other.
They communicate through the centre.
That central repository becomes what I call the Digital Librarian.
And Microsoft Access gave ordinary Excel users an extraordinarily low-friction way of building one.
That capability didn’t die.
It is still there.
Access was the gateway
This matters enormously in the real world because there is a huge difference between the technically ideal destination and the practical first step.
Today, for a serious enterprise application, SQL Server may well be the eventual destination.
Moving an Access prototype to SQL Server is relatively straightforward.
But inside an organisation there can be considerable friction involved in getting that SQL Server environment in the first place.
Permissions.
IT involvement.
Infrastructure.
Security discussions.
Procurement.
DBA involvement.
Access provides another route.
Prototype first.
Demonstrate the business concept.
Prove the architecture.
Show people what becomes possible when their spreadsheets stop behaving as isolated files and begin working through a common relational data store.
Then scale the database infrastructure when the business case has already been demonstrated.
That isn’t theoretical for me.
It changed my career.
In one of the cases subsequently mentioned by WIRED in its article about companies paying six figures for spreadsheets, a temporary engagement worth about £4,000 ultimately developed into approximately £540,000 of billing.
Access was the gateway.
It enabled me to demonstrate something the client had not previously realised Excel could do.
That is why the question “Does anybody still use Access?” misses something much bigger.
The interesting question is:
What business capability does Access give to Excel?
The business world has changed around Access
There is also an important historical point here.
Thirty years ago, an ordinary business user who needed a relational database didn’t have today’s enormous range of readily available database platforms and cloud services.
SQL Server belonged largely to the world of IT departments, developers and DBAs.
For an Excel professional sitting inside Finance or Operations, Access was different.
It was approachable.
It was available.
It could be created quickly.
And, crucially, Excel already knew how to talk to it.
Today we have far more choices.
SQL Server Express is free.
SQL databases can be hosted in the cloud for remarkably little money.
Azure and other cloud platforms have made industrial-strength database technology vastly more accessible.
That changes where we might eventually put our Digital Librarian.
It doesn’t remove the architectural principle.
And it doesn’t remove the usefulness of Access as an extraordinarily convenient way of proving that principle.
“But Microsoft hasn’t done much with Access”
Perhaps.
But why does that automatically mean Microsoft “let it die”?
There is a strange assumption in modern technology culture that if something isn’t constantly acquiring new features, being promoted at conferences and appearing in social-media feeds, it must be obsolete.
Consider the wheel.
When did you last see a technology influencer announce:
10 AMAZING NEW FEATURES OF THE ROUND WHEEL!
Probably never.
Does that mean the wheel is dead?
Look outside.
Cars have changed enormously.
Engines have changed.
Navigation has changed.
Electronics have changed.
Manufacturing has changed.
Yet underneath them are four remarkably familiar round objects.
The wheel doesn’t need reinventing every year to remain useful.
It already solves the problem it was designed to solve.
That is how I look at Access.
For the use I am describing, what revolutionary new feature does it actually need?
I need structured tables.
I need relationships.
I need SQL.
I need Excel to be able to read from it.
I need Excel to be able to write to it.
I need to be able to create a prototype quickly.
Access already does those things.
And it has done them for decades.
The irony
There is an irony in the constant “Access is dead” narrative.
For years, businesses have been told that spreadsheets don’t scale.
Spreadsheets don’t collaborate properly.
Spreadsheets create multiple versions of the truth.
Spreadsheets cause consolidation nightmares.
Spreadsheets cannot support enterprise processes.
And if your mental model of Excel is hundreds of independent workbook files exchanging data with one another, many of those criticisms are perfectly understandable.
But Microsoft gave Excel another architectural possibility decades ago.
Don’t distribute the data amongst the spreadsheets.
Put the data in the middle.
Let every spreadsheet talk to the same source.
GET.
PUT.
One Digital Librarian.
Hundreds of spreadsheet clients.
Suddenly a very different class of business process becomes possible.
And Access remains perhaps the easiest place for an Excel professional to discover, prototype and demonstrate that architecture.
So did Microsoft let Access die?
No.
I would put it almost the other way around.
Microsoft gave Excel and Access the plumbing to work together decades ago.
The surrounding technology has advanced dramatically since then. Today that same architectural principle can lead onwards to SQL Server, Azure and globally available enterprise infrastructure.
But the little Access database remains remarkably useful.
Not necessarily because it should be the ultimate database for every enterprise system.
But because it can be the gateway.
The gateway from the standalone spreadsheet to the connected spreadsheet.
From hundreds of files containing hundreds of versions of data to one structured source available to everybody who needs it.
From point-to-point spreadsheet chaos to hub-and-spoke architecture.
And sometimes, as I discovered personally, the gateway from being hired to tidy up a spreadsheet…
…to being paid hundreds of thousands of pounds to transform a business process.
So the next time somebody tells me:
“Microsoft let Access die.”
My response is simple.
Look at what Access was designed to do.
Look at what Excel was engineered to do with it.
Then show me what has died.
Because from where I am standing, the wheel is still round.
Add comment