When PerformancePoint Server
2007 was released, it was deployed as a product that integrated with
Microsoft Office SharePoint Server 2007 (MOSS). PerformancePoint Server
2007 enabled you to publish dashboards to SharePoint sites, but it was
not fully integrated. For example, you managed users and permissions to
dashboard elements outside of SharePoint, and all definitions of key
performance indicators (KPIs), reports, and scorecards were stored in a
proprietary database, not in a SharePoint content database.
With the release of SPS, PPS is
now fully integrated into SPS as a service application (SA). SAs replace
the shared service provider (SSP) architecture introduced with MOSS.
The purpose of SAs is to enable for ease of deployment, management, and
scalability of services deployed to application servers within a SPS
farm. Figure 1 shows an example of SA deployment
and its relationship to Web Front End (WFE) and database servers.
Typical SPS SAs include
Excel Services, Business Connectivity Services, Search, and Visio
Services (to name a few). You can also create your own custom SAs.
In terms of manageability,
PPS is managed using the SA page available in Central Administration
(see Figure 2).
The SA
architecture makes scalability easy. You can add additional application
servers into your SPS environment and deploy PPS to those servers to
accommodate more users. You might want to do this to handle heavy
workloads. For example, if the user response time is unacceptably high
during peak load times during the workday, you can deploy another
application server to handle the increased workload. You might also want
to do this to provide uninterrupted service (for example, when you take
an application server offline to upgrade the machine’s memory and then
bring it back online without any interruption to service).
