PerformancePoint Services for SharePoint

Microsoft announced that by mid-2009, Office PerformancePoint Server 2007 Service Pack 3 (SP3) would be released, which will include updates to the current product's planning module. That's the end of release for stand alone version of PPS.

The scorecard, dashboard and analytical capabilities from Office PerformancePoint Server would be consolidated into Microsoft Office SharePoint Server Enterprise and rebrand them as PerformancePoint Services for SharePoint.

I have worked on a project that comprised of SSRS, SSIS, SSAS, PPS and Sharepoint. As per my views, this news would come as a bit of shock to the projects that have relied on the stand-alone version of PPS. Although the end deliverable of M&A module of PPS is delivered/deployed on Sharepoint, but I feel that the development environment would be now integrated as a service/feature in Sharepoint.

Microsoft's move should make the total cost of using PerformancePoint lower. Formerly, to get started with PerformancePoint Server cost $50,000 -- $20,000 for the license (PDF document), another $30,000 to let users create scorecards, plus a $195 license fee for every employee using PerformancePoint. By comparison, a license for Office SharePoint Server 2007 costs $4,424, while enterprise licenses, which offer features in addition to PerformancePoint, will cost a total of $169 per employee.

Analytics (formerly ProClarity) and "scorecarding" (formerly Business Scorecard Manager) would be bundled into SharePoint Server Enterprise. The FRx, Forecaster and Management Reporter components of PPS Planning will return to the Microsoft Dynamics environment where they originated. The new offering, PerformancePoint Services for SharePoint, will run on SQLServer.

This would make Sharepoint a more integral part of MS BI Stack, but it would also require BI developers to learn more on the Sharepoint side as different technical consituents of BI stack like SSRS (Sharepoint Integrated mode), PPS(which would now be merged with Sharepoint) are tightly integrated with Sharepoint, and Sharepoint itself too has BI capabilites. I have already applied for MOSS 2007 Training !! Learning never stops for you if you are a knowledge worker on Microsoft Platform :)

SSIS 2005 : Staging data in RAW Files

In SSIS 2005, RAW File is one of the fastest way to stage data extracted from any source system. Also there's a corresponding source adapter available to read data from the same. We used this mechanism in one of our projects, and considered RAW File as the staging mechanism for a huge number of extracts which were of course delta based. This mechanism works fine and faster, but the real trouble is visible after the extract is dumped in the RAW file. There are two issues now:

1. Firstly there's no tool available out of the box to read the same. A package that reads from a RAW File and dumps in to a text file, needs to be developed. Luckily we have a tool like RAW File reader that can read the RAW file. To download the tool go to http://sqlblogcasts.com/files/folders/ssis_tools/default.aspx
2. The biggest issue is, if the schema at the OLTP level changes; then you are ready for the big bang. When the load reads from the raw files that are created from the updated schema, the RAW File Source Adapter immediately fails. This component stores the schema in the package when it reads the schema for the first time. Also the DelayValidation property is of no use as this adapter does not support reading of the schema dynamically. Effectively your loads would fail, and require modification.

My experience and finding is that, think twice before considering RAW file as the staging mechanism; especially if there's a scope that your source system schema might undergo a level of change.