At the BI Conference in Seattle, Microsoft unveiled some components of project code name Kilimanjaro, a sort of R2 release for SQL Server expected in the first half of 2010. Here’s a couple of relevant news sources:
- Doug Henschen on Intelligent Enterprise – “Microsoft Will Bow In-Memory Analysis, Appliance-Ready Database in 2010”
- Short Kilimanjaro posts on SQLBlog.com from Marco Russo and from Mosha Pasumansky
- Project Gemini notes from the SQL Server Customer Advisory Team (SQLCAT)
- Information Week story on Kilimanjaro
Here’s the part I really like: Gemini centers around Excel as its user interface.
Let’s face it: our power users live, eat and breathe Excel. They’re all over it. They know it forwards and backwards, and they pull tricks with pivot tables that make DBAs scratch their heads. My bosses have always been able to out-Excel me, and that’s been fine with me.
If Excel is going to be the future interface for self-service BI, with SQL Server as the back end, I for one welcome our new spreadsheet overlords.
Why am I embracing Excel so much? Because the cloud is coming, open source is coming, and our competitors just keep coming. The one thing none of them do well is the front end, the power user interface. None of them have anything even remotely close to a user interface as rich and powerful as Excel.
If my BI team comes in and says, “Give me one good reason we shouldn’t switch our data warehouse over from SQL Server to Oracle/cloud-based MySQL/cheap Postgres/fast-database-du-jour,” I’ve got a new cool answer: our power users love self-service BI with Excel, and nobody else is going to be able to touch that.
Are there beautiful BI front ends out there that put lipstick on Oracle, MySQL and cool new databases? Sure – but most companies are already licensing Excel on the desktop, and their users know how to use it. Cheaper, less training, less implementation time – it’s a win all the way around for SQL Server.
And you know what I like the most? It lets the SQL Server Management Studio team focus on day-to-day DBA task management and stay out of the BI power user business.
3 Comments. Leave new
When all you have is a hammer every problem looks like a nail.
The problem with users creating their own reports is that very few really know their databases intimately enough to be sure that they are getting accurate data. Or rather, getting data that really represents what they think it is.
In my current position, I use Excel regularly for the reasons you mentioned. However, I (as the DBA) create the SQL statements and document them appropriately so the user gets the data they want.
My opinion – and just take this for what it’s worth – is that in the companies I’ve worked, the BI power consumers have their own data sources that the BI team doesn’t even get access to. For example, we had a marketing team who had access to rapidly changing promotional data from a client, and they wanted to do sales mashups between the data warehouse and the client’s advertising data. We couldn’t put that client data into the warehouse because it changed too fast, wasn’t really ours, and we didn’t have the ETL resources to turn it into a process.
The end result: the BI power consumers were slicing and dicing this stuff in Access, in Excel, and on an SSAS server they’d cobbled together out of an old laptop. Was the data right? Who knows, but we didn’t have the time to build it, let alone vet it.
That’s the beauty of self-service BI. Actually, I’ll write a blog post about that now that I’m thinking of it.