Introducing PerformancePoint Server Monitoring

PerformancePoint Server 2007

Updated: 2009-04-30

Everyone wants dashboards! PPS 2007 Monitoring makes designing, publishing, and managing dashboards simple and the resultant solution very powerful. From this chapter onwards, we will look at all aspects of the Monitor and Analyze (M&A) part of the Monitor, Analyze, Plan paradigm introduced Chapter 1. We will simply refer to it as “Monitoring” throughout the remainder of the book. Don’t worry, though, we will cover both the Monitor and Analyze parts in plenty of detail.

(This article is an excerpt from The Rational Guide to Monitoring and Analyzing with Microsoft Office PerformancePoint Server 2007, by Nick Barclay and Adrian Downes, and is property of Mann Publishing Group (978-1-932577-41-9), copyright November 2007, all rights reserved. No part of this chapter may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.)

This chapter briefly looks at the history of applications that have contributed to where we currently find ourselves in the Microsoft performance management roadmap. We also take a high-level look at the Monitoring architecture and just what pieces are necessary to produce the dashboard solutions end users really want.

PerformancePoint Planning

The Planning component of PerformancePoint Server 2007 is not covered in this book. Originally, we were going to write a single Rational Guide covering the Monitor, Analyze, and Plan paradigm in one publication, but there was simply too much to cram into one guide. So we wrote a companion book, The Rational Guide to Planning with Microsoft® Office PerformancePoint Server 2007, available from Each book provides specific details about its particular aspect of the PPS product. Wherever possible, we’ll note how the two halves of the product can interact.

Monitoring History

The Monitoring part of PerformancePoint is very definitely not a v1 product, as many would think. The software discussed in this Rational Guide is the end product of quite a few years of evolution, integration, and development.

While there were certainly many smaller steps along the way, the major punctuation marks in the lead up to the product we are writing about are summarized in Figure 2.1.

In 2004, Microsoft released the Business Scorecard Accelerator. This was a completely SharePoint Portal-based solution for creating KPIs and grouping them underneath specifically defined objectives and perspectives in a scorecard.

In the second half of 2005, Business Scorecard Manager 2005 (originally codenamed Maestro) was released. BSM provided much enhanced functionality in creating scorecard-centric dashboards, complete with interactive reports. BSM used the base SharePoint product included with Windows Server 2003 licenses as the delivery mechanism; reliance on the SharePoint Portal Server product was removed. BSM shipped with a development and management application named BSM Builder to create KPIs and scorecards and manage the central web service.

In April 2006, Microsoft acquired ProClarity, one of the world leaders in analytic and visualization technologies, an area where Microsoft found itself a bit behind. The BSM team in Redmond were already hard at work on the next version of BSM, codenamed Concerto. The dashboarding and analytical technology acquired from ProClarity was to be merged with this new version. At the same time, another team was working on a completely new budgeting and forecasting tool codenamed Biz# (pronounced Biz Sharp). There was some speculation as to just how many specific products would result from all this. In mid-2006, it was announced that the next version of BSM (Monitor), the acquired technology from ProClarity (Analyze), and the fruits of the Biz# team’s labor (Plan) would become PerformancePoint Server 2007.


The integration of the next version of BSM and ProClarity technology was a prime objective of the two teams: Microsoft in Redmond and ProClarity in Boise, Idaho. The current functionality of Monitoring does not yet encompass the full breadth of the ProClarity toolset. However, a PerformancePoint license does extend to the full ProClarity suite, so while they may not be an integrated part of the product itself, decomposition trees, performance maps, or perspective views can still be surfaced in dashboards using the ProClarity server products. Subsequent versions of PerformancePoint will incorporate more of the ProClarity features into the base product, along with a few new ones.


The architecture of Monitoring is really quite simple. It is centered around the Monitoring server web service as seen in the simplified architecture diagram in Figure 2.2. Dashboard Designer (DD) is the primary design tool and management interface to the Monitoring server web service. DD is used to build and publish XML definitions of elements to the web service; these XML definitions are stored in a SQL database managed by the Monitoring server. When users interact with published dashboards, SharePoint 2007 retrieves element definition and security information from the Monitoring system database, queries data from configured business data sources, and then exposes the finished product to users using custom Dashboard web parts.

Figure 2.2: Simplified Monitoring Architecture.


A number of different components make up the Monitoring server installation. Depending on the desired architecture, these components can be installed on any machine that meets the minimum requirements. We will go through the installation process and hardware and software requirements in the next chapter. In the meantime, the more fleshed out architecture diagram in Figure 2.3 shows more detail on where each component fits within a complete Monitoring server.

Figure 2.3: Monitoring Component Architecture.

Let’s review the components.

  • Dashboard Designer — Primary application for building out element definitions and management interface to the Monitoring server.

  • Monitoring Server — The central engine that controls all Monitoring processes; manages element definitions published through Dashboard Designer in the Monitoring Database, surfaces dashboards through SharePoint web parts.

  • Monitoring System Database — A SQL Server 2005 relational database used to store and manage element definitions.

  • Dashboard Viewer for SharePoint Services — Facilitates deployment and viewing of completed dashboard content through SharePoint. Custom web parts render individual items contained in published dashboard pages.

  • Monitoring Central — A launch pad site that is created on any machine is running a Monitoring server web service. The site contains links to the local Dashboard Designer installation site as well as the Dashboard Designer preview site (see Figure 2.4).

  • Dashboard Designer Installation Site — Site from which Dashboard Designer can be installed using ClickOnce technology.

  • Dashboard Web Preview Site — ASP.NET preview site used to emulate the dashboard viewer functionality. This site enables designers to test the functionality of their dashboards without the need for a complete SharePoint installation.

  • Scorecard Viewer for Reporting Services — Data extension that enables Reporting Services to generate and render Report Definition Language (.rdl) files based on the definition of a scorecard.

  • Reporting Services Plug-in (VS2005) — Data extension that allows developers to view generated scorecard .rdl files in Visual Studio 2005 using the Report Designer plug-in.


Elements are the essential building blocks of Monitoring. They are created using Dashboard Designer and subsequently published to the Monitoring server. Each element plays an important role in a complete performance management solution. There are six elements in total: indicators, data sources, KPIs, scorecards, reports, and dashboards. Many of the six elements depend on definitions of another element type in order to be complete. These relationships form a simple hierarchy that can be seen in Figure 2.5.

Let’s look at each of the elements.

  • Data Sources — Contain connection settings that are used to gain access to various types of structured data. KPIs and reports utilize this element to access the data they require.

  • Indicators — Provide visual prompts pertaining to the status of a particular KPI. They use differing graphics, background colors, or text settings to convey their message.

  • KPIs (Key Performance Indicators) — Bring metrics together from one or more data sources in order for comparisons or calculations to be made. These elements utilize more than one data source element and more than one indicator element as part of their definition.

  • Scorecards — Collections of one or more KPIs organized hierarchically under a series of zero or more objectives or grouped by members of a dimension. Scorecards provide the mechanism for both grouping and rolling up the values contained in their constituent KPIs.

  • Reports — Expose business data in a number of different formats in order to suit requirements. There are many report type options available, ranging from Analytic Grids or Charts to SQL Reporting Services reports. Some report types connect to data using a data source element; others use data from a scorecard or a connection defined within the report itself.

  • Dashboards — Bring all the elements together by exposing the data contained in scorecard and report elements. They are the delivery mechanism to the end user in SharePoint via the Dashboard Item web part. Dashboards contain all the logic used to control what the user sees, and how they can interact with the elements contained therein.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for PerformancePoint Monitoring Server.