TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Microsoft's PerformancePoint Shake-up

Why did Microsoft shuffle PerformancePoint Server into its SharePoint Server group, and how will the shake-up affect customers?

• By Stephen Swoyer
• January 28, 2009

Call it a case of odd timing: just one day after Microsoft Corp. announced its first-ever companywide lay-offs, its Business Intelligence group announced a lay off and reshuffling of its own. It's PerformancePoint Server, a performance management (PM) tool that Redmond released 14 months ago, was moved into Microsoft's Office SharePoint Server group.

Officials say there's no connection -- that the reshuffling had, in fact, been planned for months. They concede that the timing, coming on the heels of Microsoft's first-ever layoffs (and just one day after Redmond reported earnings that fell short of Wall Street's expectations), is nonetheless unfortunate.

"Part of our regular strategy reviews at Microsoft is looking at what we're doing relative to what the market is doing -- how people are purchasing software, how they're using it," says Kristina Kerr, lead product manager with Microsoft's Business Intelligence product management group.

"About 6 or 7 months ago, we started a review across all of our business intelligence assets at Microsoft, inclusive of SQL Server, PerformancePoint Server, [and] Excel. What we were doing was looking at how the market's evolving, what our use cases scenarios [are] for people -- [i.e.,] what does the competitive landscape look like, and does our product strategy match the vision that we have for business intelligence?"

Microsoft's decision to fold PerformancePoint Server into the SharePoint stack, where -- as with SQL Server's complementary BI services (Analysis Services, Reporting Services, and Integration Services) -- it will henceforth be known as PerformancePoint Services.

PerformancePoint Services won't ship with all versions of SharePoint Server, however. Nor will it interoperate with all versions of SQL Server. Enterprise editions of both products will be required, according to Kerr: "It will actually be part of SharePoint Server Enterprise Edition, so it will be part of that SKU."

Microsoft's PerformancePoint reshuffling isn't an organizational or taxonomical or even purely logical move, Kerr contends. Instead, she maintains, the software giant very much has the interests -- and common deployment strategies -- of its customers at heart.

"We found that there was a very strong linkage between customers who had purchased SharePoint Server and then were looking at PerformancePoint Server to round out their deployment," she explains. "There are a lot of customers who are currently using SharePoint for collaboration, search, and so on, and BI is a logical extension of that work environment."

The reshuffling is the work of Microsoft's BI leadership team, which includes representatives from from Redmond's SQL Server, SharePoint Server, Excel, and PerformancePoint Server groups. "It also includes the marketing lead for the business intelligence overlay team, which works across all the product groups. That team was formed a little over a year ago and has been very concentrated on making sure that the products [are] connecting very well, [that] the assets we have are being optimized, and [with] closing any gaps" in product strategy, according to Kerr.

Its first fruit is Project Gemini, Microsoft's still-gestating effort to introduce -- via an add-on -- an in-memory, column-based store for Excel (see http://www.tdwi.org/News/display.aspx?id=9154). Project Gemini will also focus on ratcheting up the already tight integration between Excel and SharePoint, according to Kerr.

"When you think of our business intelligence stack, think SQL Server, SharePoint Server, and Excel. It's those three products moving forward. Excel is very much the most widely used BI front-end in the market today," she points out. "What we're doing is tying [Excel] to the data security in SQL Server as well as the collaboration and workflow capabilities in SharePoint," she continues. "We will definitely continue to develop both the PerformancePoint Services capabilities as well as the rest of the stack. An example would be in connecting something like Excel Services to SQL Server Analysis Services, where real-time data is being surfaced through the Web part in SharePoint. Another example is creating much tighter linkages between the scorecarding and analytic capabilities within the platform itself."

What does Microsoft's PerformancePoint reshuffling mean for customers? Kerr, not surprisingly, spins it as a win-win. In the near term, she says, existing PerformancePoint users will continue to receive product updates via Software Assurance. Likewise, Microsoft still plans to release at least one more service pack (SP3) for PerformancePoint later this year. Beyond that, Microsoft plans to include PerformancePoint Services as part of the next release of SharePoint Server Enterprise Edition.

"PerformancePoint customers who bought Software Assurance [with] rights to the next version of SharePoint will get SharePoint Server licenses in exchange," Kerr says, "and if they bought PerformancePoint Server, they'll get SharePoint. If they bought a PerformancePoint CAL [client access license], they'll get a SharePoint CAL."

What about existing customers who don't with to wish to transition to (or otherwise deploy) SharePoint Server? Kerr says they can continue to ride it out on PerformancePoint -- although from now on development of that product will continue in lockstep with SharePoint. "The existence of PerformancePoint will continue to be supported per Microsoft's regular support policies, which is roughly ten years from the initial release. We'll continue to support those products on an ongoing basis," she indicates.

Wayne Eckerson, director of research with TDWI, sees the shift as a competitive response on Microsoft's part. Not that it does much to simplify Microsoft's confusing portfolio of BI assets.

"On the one hand, this consolidates BI into three Microsoft products: Excel, SQL Server, and SharePoint, simplifying matters for customers. On the other hand, it consolidates BI into three Microsoft products: Excel, SQL Server, and SharePoint, which are still three separate products," he points out.

Microsoft is under pressure from its BI rivals as well as ERP vendors. Thanks to consolidation in the BI and PM spaces, BI and ERP are increasingly two sides of the same coin: both Oracle and SAP now field best-in-class BI and PM packages, for example.

"Obviously, there is some pressure to keep up with its primary BI competitors and create a true BI platform with a client, application server, and database server that support a multiplicity of BI [components]. It's also competing with ERP vendors who have built BI platforms on robust 'middleware' services that support workflow, security, APIs, collaboration, etc.," Eckerson continues. "The question here is how tightly integrated the three products are and whether individual components are leveraging a common set of metadata."

Microsoft has been criticized in the past for its lack of a coherent metadata strategy. "[Their] stock answer is always that they have metadata in SSIS -- it's in XML files [that] you can access. [Getting at] BI [metadata is] a little harder, but [it's] there. They don't tell you about how you need a third-party product to make any real use of it," said data warehouse architect Mark Madsen, a principal with consultancy Third Nature, in an interview last October.

Redmond officials concede the point. "The metadata story spans a couple of different uses today. [We have] metadata for the application itself, metadata for the data itself, metadata for the presentation layer," said Herain Oberoi, group product manager for SQL Server, at the same time. "The broader metadata story … which also includes some of the work we're doing with the master data management team, that's something we're working on."