Mark Proctor has long voiced skepticism toward what he perceives as “systems development” with Excel—particularly when it involves relational databases. To him, this appears to cross a line: it’s no longer “Excel work,” but something more technical, dangerous even. He implies it’s subversive—perhaps even something that should be prohibited.
Let’s be clear. What Mark views as subversion is in fact the strategic design intention of Microsoft Office.
This article addresses the historical, technical, and practical case for Excel’s enterprise integration capabilities. And it does so in direct contrast to Mark Proctor’s stance and a revealing real-world example from my own consulting work: the Oracle ERP implementation at Edexcel.
The Misunderstood Purpose of Microsoft Office
Mark’s stance betrays a fundamental misunderstanding of Microsoft’s integration goals for Office. For nearly 35 years, Microsoft has relentlessly promoted the idea that Excel and Access—and later SQL Server—can and should be linked. This integration was part of what Microsoft called the Digital Nervous System, a central thesis in Bill Gates’ 1999 book Business @ the Speed of Thought. Gates made the case that businesses would thrive when their software systems could connect people, data, and decisions instantly.
This wasn’t a fringe idea. It was Microsoft’s flagship enterprise vision.
Around that time, ADO (ActiveX Data Objects) became a cornerstone of Excel’s evolution. In fact, if you watch the 1993 Microsoft Developer Cast—still available on YouTube—you’ll see a young Satya Nadella demonstrating how Excel could connect directly to relational databases.
That’s not subversion. That’s the point.
Case Study: Edexcel and the Oracle ERP
Let me illustrate this with a concrete example. At Edexcel, I had previously built an Excel-driven financial reporting system using a hub-and-spoke architecture. It was streamlined, automated, and invisible. So invisible, in fact, that some in the organization didn’t even realize how much productivity it enabled.
When a leadership vacuum emerged in the IT function, a new Oracle Financials ERP project was launched to replace the Excel system. Millions of pounds were allocated. I was not consulted during the build.
The result? An out-of-the-box Oracle implementation that lacked many critical features—including a reporting module.
After the ERP went live, management realized the new system couldn’t perform key tasks that Excel had quietly delivered all along. I was brought back—at a much higher rate—to patch the gaps. Working with the Oracle team, we rebuilt the missing functionality using Excel and Access to interface with Oracle’s backend. Problem solved. Processes restored. But something revealing happened next.
The Hinton Report
Ian Hinton, the acting IT lead at the time, asked to see how I had enabled this “missing magic.” I demonstrated the workflow using standard Excel functionality: Data → Get External Data → From Access/Oracle, using credentials provided by the ERP team.
He seemed impressed.
Days later, he submitted a report to the board accusing me of bypassing security. He claimed I had shown users how to “hack” Oracle via Excel.
This claim was absurd on three levels:
- Data Ownership: The finance team owned the data. IT’s role was stewardship—not gatekeeping.
- Permission and Design: The Oracle view I accessed was built by the ERP team, at finance’s request, using ERP-sanctioned credentials.
- Standard Microsoft Functionality: What Hinton called “subversive” was, in fact, tested knowledge in Microsoft’s official certification exams (then branded MOUS, now MOS). At Edexcel, we were even a national test center for these certifications.
The real irony? Hinton accused me of using functionality that Microsoft itself promoted as expert-level skill in Excel 97. Yes—Excel 97, Mark’s own benchmark for “basic” Excel.
Back to Mark Proctor
Mark continues to frame enterprise-grade Excel work—like leveraging databases via ADO—as somehow “cheating” or beyond the remit of typical Excel users. He implies it’s unnecessarily advanced and unsupportable by organizations.
But that’s not what the record shows.
Over decades, I’ve delivered scalable, automated spreadsheet systems across multiple enterprises. Clients ranging from telecoms to education to publishing have paid well to build them. These systems often replaced or rescued failed ERP or FP&A tools that couldn’t meet real operational needs.
In every case, the solution used standard Excel functionality introduced in Excel 97.
In contrast, the modern Excel features promoted by influencers—Lambda functions, Power Query, Office Scripts—are technically impressive but practically inaccessible to most users. They are difficult to teach, hard to support, and far removed from the end-to-end process needs of management.
The Real Divide: Literal vs. Lateral Thinking
Peter Bartholomew, who weighed in to support Mark, admits he’s never worked on enterprise-scale, end-to-end processes. His background in aircraft engineering gave him deep expertise in single-user models. That’s a different world. But it’s telling that he still felt confident critiquing enterprise processes he’s never experienced.
Mark sided with him, insisting that what I’ve done is rare, unrepeatable, and unnecessarily complex. But it’s not. It’s repeatable. And it’s been repeated—many times—by clients who grasped the method and made it their own. The key is mindset: embracing the architecture, the flow of data, the modularity of hub-and-spoke design. Not chasing viral features.
A Call for a Showdown
Let’s settle it.
Mark and I both know that budgeting is one of the most common Excel applications in business. I propose a challenge: side-by-side demos.
- Mark: Show how modern Excel (Power Query, Lambda, M Code, etc.) handles a typical enterprise budgeting process.
- Me: I’ll show the same process, delivered via Excel 97-compatible hub-and-spoke architecture, leveraging Access or SQL Server.
We’ll let the audience—especially managers—judge which is simpler, faster, more scalable, and easier to maintain.
Because this isn’t about tech. It’s about thinking. My approach is lateral, process-first, and strategic. Mark’s is literal, feature-first, and tactical.
And the real tragedy? Most management stakeholders know that modern Excel “gurus” leave behind a mess—abandoned models, orphaned formulas, impenetrable logic. The very “Excel hell” they blame on the tool is often caused by poor architecture and overuse of standalone complexity.
Final Thought
Mark believes what I’m doing shouldn’t be allowed. But clients keep paying me to do it. They do so because it works—quietly, scalably, reliably. And most importantly, it puts them in control.
So before dismissing enterprise-grade Excel solutions as fringe, perhaps it’s time we reexamined what Excel was truly designed to do. The truth was never hidden. It was in the manuals. It was in the Microsoft vision. And it was right there—in Excel 97—all along.
Postscript
The know-how is not the problem. The problem is the noise.
Add comment