Redmond Review

Integration, Not Capitulation

Microsoft isn't exiting the business intelligence market; it's redefining it.

Business intelligence (BI) allows users to monitor trends and make adaptive decisions in response. Fittingly, Microsoft applied the same approach to the BI market itself, when it recast the Monitoring and Analytics component of its PerformancePoint Server (PPS) BI package as a subset of SharePoint Enterprise. The Planning module of PPS has been discontinued altogether. Has Microsoft given up on BI?

Hardly. Unlike BI vendors, Microsoft has always pushed BI into the mainstream, accessible to business users and customizable by developers. Essentially, Microsoft thinks BI should be a line-of-business technology. The PerformancePoint change conforms to this approach, and will have a huge impact for developers.

There's plenty for developers to get after. On the platform side, there's the MDX language and ADO MD.NET (an ADO.NET provider), which you use to query Analysis Services cubes. There's XML for Analysis (XMLA), Analysis Services' native protocol, which just happens to be a SOAP Web service. And if that's not good enough, developers can write functions and procedures in .NET programming languages, then load the resulting assemblies into Analysis Services and call the .NET code from queries.

On the presentation side, Excel 2007 can query cubes via PivotTables, visualize the results using PivotCharts and can now even embed MDX expressions within cell formulas. Add Visual Studio Tools for Office (VSTO) to the mix, and the opportunity for full .NET BI solutions within Excel is there for the taking. That's not all. You can use Excel Services to present your programmatically created PivotTables, charts and tables within SharePoint dashboards, making your solutions available to any machine with a Web browser. Add SharePoint's now-included PerformancePoint Services to the mix and you can integrate all this with Reporting Services and PPS's own grids and charts.

As long as your firm or your customer has SQL Server, Office 2007 and SharePoint Enterprise, you can deliver top-notch BI solutions, using your .NET skills, and without a lot of extra baggage. Separate licensing? No longer required. Stand-alone applications and disjointed user interfaces? Not necessary, and far less preferable to delivering analytics capabilities where users need them: in the line-of-business apps you build and in the Office applications users live in. The approach means fewer expensive "big bang" BI projects. Developers can easily add context-sensitive analytics to existing applications and meaningful dashboards to existing SharePoint implementations.

Making the Right Move
Microsoft isn't exiting the BI market; it's redefining it. And the company's doing so on its own terms, bringing to bear three of its core strengths: Office, SharePoint and you-the .NET developer. This may take Microsoft out of the upper-right-hand corner of those market maps analysts like to produce, but so be it. In this economy, businesses don't want maps to the homes of Hollywood stars; they want a GPS to show their location, traffic reports to avoid accidents and optimized routing to get them to their destination quickly.

I'm betting that with Office and SharePoint, Microsoft has made the right move. When Office 2010, SQL Server "Kilimanjaro" and project "Gemini" (which includes a desktop version of Analysis Services and self-service BI features in Excel) are released, that bet will keep paying off. (For more on Gemini, read my December 2008 Redmond Review column, "Selling Self Service," online here.) Building more BI capabilities into the core stack is where the smart money is.

But Microsoft must take this strategy further. Silverlight and the technology acquired from Dundas should be used in every Microsoft BI product for breathtaking data-visualization. ADO.NET Data Services should be another query front-end to Analysis Services. Visual Studio Team System's database features should support Analysis Services. And a real BI offering should be part of the Azure Services Platform.

If Microsoft wants BI to be mainstream, then BI should inhabit early versions of its products as a matter of course. BI shouldn't be an afterthought or an add-on. That's the lesson of PerformancePoint, and that knowledge should drive product decisions in Redmond henceforth. That is, after all, what BI is all about.

About the Author

Andrew Brust is Research Director for Big Data and Analytics at Gigaom Research. Andrew is co-author of "Programming Microsoft SQL Server 2012" (Microsoft Press); an advisor to NYTECH, the New York Technology Council; co-moderator of Big On Data - New York's Data Intelligence Meetup; serves as Microsoft Regional Director and MVP; and is conference co-chair of Visual Studio Live!

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube