BI Mashups

Tuesday I attended an interesting session presented by J.R. Arredondo and Dave Pae about putting together Enterprise Mashups using SharePoint Designer for WSS or SharePoint 2007. 

Mashups are one of those buzzwords, not unlike Twitter, FaceBook, etc., that sounds like a cool technology my 13-year old would be interested in but which I always try to approach with a bit of skepticism given my focus on business solutions that have ROI requirements.

And so it has been with "mashups" for me...on the radar but a bit unproven in terms of business value.

I think that needle has moved for me as a result of this session.  Of course, my primary focus is whether each new technique or technology is relevant to real-world BI solutions (not just something entertaining during a demo).

So how do I see mashups extending a traditional data-driven BI solutions?  Well, the ideal would be to take (A) traditional, planned data in a database or cube; (B) add in unstructured data (like sharepoint lists), and (C) access information on the web or from LOB systems using web services.

Modern BI solutions like PerformancePoint solve A+B, but C is not usually in the realm of end-users or analysts who assemble BI solutions.

While the Arredondo & Pae session didn't address a BI environment directly, I can see quite well how to adapt their techniques to do some interesting things. Using PerformancePoint we already have the ability to link to non-BI components, and by combining this with SharePoint designer mashup capabilities I can easily see integrating maps, internal web services and public services via various protocols.

If you haven't looked at Microsoft's Mashup page, take a look at it here: Enterprise Mashups.  And if you're not aware that SharePoint designer is now free, download it here and take a look at ways to design rich mashup pages in sharepoint.

Business Intelligence (BI) often invokes images of sophisticated, complex technologies that organizations sometimes feel they’re “not ready for yet”.  Often this comes from a feeling that we’re so busy just keeping up with user requests that there’s not enough time available to get to the next level or assimilate new technologies.

For organizations that are heavily dependent on information, part of the overwhelmed feeling stems from what sometimes is called the reporting treadmill—that feeling that every completed report or information extract request generates two additional requests.

While BI initiatives are often geared toward strategic initiatives—such as performance management, business analytics or financial budgeting/planning—the tactical and operational benefits of even a modest BI implementation are just as important.  One operational impact often realized is a reduction in time spent by IT specialists designing custom reports, and a subsequent redeployment of those staffers to more value-added activities.

By using BI-enabled applications along with a well-designed multi-dimensional data model, end-users become more empowered than ever before to dig out answers to their questions directly (and more quickly), rather than relying on data specialists. Moreover, these centralized data marts provide one-stop shopping and a single version of the truth that’s hard to achieve with dozens or hundreds of individual, customized reports.

For IT, the reduced time spent designing reports is available for other activities—like advanced data modeling, data mining and data integration—all activities that provide yet more resources for business users.

A well-planned, strategic BI implementation provides a business-changing paradigm shift in how organizations use information.  However, even when a strategic investment isn’t in the cards, more modest ones can yield real, measurable benefits—and provide foundational experience for a future strategic BI implementation.

When planning a deployment of PerformancePoint Monitoring & Analytics (PPS M&A), an often overlooked component in the business solution is the ProClarity Analytics Server (PAS) application layer.  

PAS is sometimes not deployed by customers, and their analysts aren't trained in the effective use of these analytical tools. In my view, this is often a mistake.  Analytics has at least two constituencies--and all need to be considered when planning a successful BI deployment.

A sales specialist I have a great deal of respect for, Mac Hussey, once explained it this way...this isn't a direct quote but my interpretation of his ideas: PerformancePoint server M&A's native scorecards, analytic grids & views cover "Little a" (lightweight analytics), while PAS covers "Big A" (heavy analytics). 

Two A's...so what's the difference? "Little a" is flashy, cool and as easy to use as a web page--often requiring no training beyond a quick overview.  In most industrial and service industries, perhaps 85% of BI dashboard users are executives, managers and line of business users.  These users don't use analytics in their primary job function, but use analytics to support their "real" jobs. 

Even in the long-run, they may only want/need "Little a". If your organization fits this mold, it may seem that reaping the low-hanging fruit using "Little a" is really where all the value lies--and that's certainly true at first. Eventually, though, the "Little a" users want to know root causes, and analysts really need to dig and develop further insights.  That's when "Big A" is needed (ProClarity Analytics). 

"Little a" is certainly a "low hanging fruit picker" and brings in quick ROI in for any BI dashboard deployment.  Yet time spent deploying and training on "Big A" is where the game-changing ROI comes from over the mid/long-term. Currently this means deploying an additional application (PAS) and training end-users.  

Eventually I'm sure we'll see ProClarity Analytics fully integrated into PerformancePoint, and the "ProClarity" product brand will be just a fond memory. When that happens, every user will have access to both the "Big a" and "Little a", even if--as with Excel's features--they only know how to use the most common analytical capabilities offered by the product.  Until then, Microsoft BI practitioners who address the needs of users in the "here and now" will need to continue to pay close attention to the spectrum of user needs when planning BI deployments.