Can the Spreadmart Beast Be Tamed?

In the real world, users rely heavily on spreadsheets for working with data. Because the spreadmart phenomenon seems to be here to stay, we must ask whether we can tame this beast--or will we instead embrace it?

Brian Moran

June 21, 2006

4 Min Read
ITPro Today logo in a gray background | ITPro Today

In last week’s SQL Server Perspectives article “Spread the Love: The Challenge of Corralling Scattered Data” ( http://www.sqlmag.com/Article/ArticleID/50607/sql_server_50607.html ), I discussed the topic of spreadmart. I gave you a definition of spreadmart as a word meaning both spreadsheet and data mart. The phenomenon occurs when large amounts of data--important data--is stored in a spreadsheet. This environment lacks many of the controls and ability to share information that a real database has. However, because the reality is that lots of business users rely on spreadsheets, I’ve formed two assumptions about the spreadmart phenomenon:

  • A vast amount of corporate data will always reside in spreadmarts rather than traditional databases.

  • Most consumer data (e.g., Christmas card lists, recipes) will always be stored in spreadmarts rather than a real database.

In other words, spreadmarts are here to stay. So we have to ask whether we’ll ever become skilled in managing them.

This week I’m going to offer a potential vision of the spreadmart future that will be sure to annoy database purists. Last week’s column resonated with readers. I’ve received many interesting responses, which I’ll share in future installments of the spreadmart discussion. This week, I simply want to present my potentially antagonistic vision of spreadmart futures.

As I mentioned last week, Microsoft has planned several interesting technologies that will deal with spreadmart in different ways. Microsoft isn’t defining its future based on the goal of “solving spreadmart,” but the company is clearly embarking on a long-term, overarching campaign to support improved collaboration. I don’t want to simplify my thesis too much, but I believe that any discussion of collaborative data management must involve a discussion of managing spreadmarts. It’s a safe bet that Microsoft’s direction will be based on Microsoft Office; a good example of how Microsoft is using Office applications to foster collaboration is the recently announced Office PerformancePoint Server 2007 ( http://www.microsoft.com/presspass/press/2006/jun06/06-06PPS07PR.mspx ). It’s a great direction, and I think the approach will offer tremendous value. I plan to write a lot more about the really cool features in Office 2007 as they relate to collaborative data management.

But what if this approach to spreadmart management is flawed--or if not flawed, simply doesn’t address wide spectrums of the spreadmart problem? In April, I discussed the announcement of Google OneBox for Enterprise and its potential positioning as an application- and data-management environment (“Enterprise-Class Data Management--From Google?” http://www.sqlmag.com/Article/ArticleID/50149/sql_server_50149.html ). Last week, Google launched a test version of a spreadsheet, which you can download at http://labs.google.com . No, it’s not as full-featured as Excel or any desktop spreadsheet. However, the Google spreadsheet is server based and is designed to be used by multiple people editing data at the same time. Hmm. Google didn’t use the buzzword “collaboration,” but this spreadsheet sure sounds like a collaboration tool, which is the market Microsoft is hanging its hat on.

It’s hard to fit all of my ideas on this subject into the tiny space I have each week. But let’s think through this a bit. Is a spreadsheet such a terrible way to view and interact with data from an end-user perspective? Of course not. Spreadsheets are great end-user tools. But spreadsheets are a nightmare for corporate IT people who have to deal with all the problems that large-scale reliance on spreadsheets can create. However, imagine a data tool in which the end-user experience feels like a spreadsheet and the back end feels like a database--and includes some of the more traditional database features, such as security, scalability, versioning, multi-user access, rapid searching, and all of the rest of the features that database traditionalists have come to know and love? What if someone figured out a way to take the best parts of a spreadsheet and merge it with the best parts of a database by using new data-persistence technologies that might not even have been invented yet? Hmm. Sounds like a nifty idea. I’m not saying that this is the direction that Google is going, and I’m not saying that Google will succeed, even if I’ve guessed its direction. But it sure is an interesting idea. And if anyone can do it, I won’t be surprised if the problem is solved by one of the world leaders in search and indexing technology.

One of two things will happen with when people read this editorial. One possibility is that everyone will quickly forget the silly idea I outlined today (except for friends and colleagues who delight in reminding me when I write a dumb editorial). Or perhaps, 3 to 5 years from now, I’ll be writing a new series of editorials discussing a set of recently announced products and services that are poised to dramatically reshape the way consumer and corporate spreadmart data is used and managed. If it’s the latter, I’ll be sure to remind you about this article, which proves that I’m a data visionary who possesses great skill in predicting new trends in data management. Which do you think it will be?

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like