Written by: Neil Chandler
This research describes the common architectural approach of the dashboards and scorecards that are used to monitor and track corporate performance. IT managers should use this information to understand the components of a typical implementation and how these solutions fit into a wider business intelligence (BI) and performance management framework.
- Dashboards and scorecards replace and reduce dependencies on traditional performance-measuring reports.
- Scorecards are more sophisticated and complex than dashboard implementations that require strategy alignment to operational activities.
- Operational dashboards often include an event-processing server to provide real-time alerting and event monitoring.
- Dashboards and scorecards increasingly are available from a wide range of software vendors from disparate markets.
- To avoid creating information silos, organizations should incorporate dashboards and scorecards into a broader BI and performance management framework.
- The data that supports the key performance indicators (KPIs) and metrics displayed in dashboards must be in synch with the underlying detail data that is used for drill-down analysis. Hence, the application that supports the dashboard should provide consistent data and metadata for both uses.
WHAT YOU NEED TO KNOW
Organizations turn to dashboards and scorecards to increase information relevance while reducing the number of traditional reports and ad hoc query tools that are needed to support better decision making. Dashboards and scorecards are useful deployment tools that can deliver personalized and summarized key information to large user communities. IT and business users must be aware of the architectural components that are used to understand typical dashboard and scorecard implementations.
Dashboards and scorecards increasingly are deployed to better understand and manage business performance, but many organizations implement these components on a stand-alone basis, disconnected from the rest of the BI and performance management framework. This research provides IT and business users who are interested in dashboards and scorecards a clear understanding of the components that are used in typical deployments. Analysis The Components of Dashboard and Scorecard Architectures A dashboard typically is a Web-based application that delivers key information in a highly visual format to a key user group or groups; simple dashboards can be delivered using custom clients and Microsoft Office components, such as Excel and PowerPoint. Dashboards contain summarized data that enables users to quickly interpret and understand a snapshot perspective of organizational performance, with the ability to drill down to greater levels of detail. Dashboards are becoming the preferred method for delivering and displaying BI to users, because they are more visual and intuitive than grid-based reports and typically provide linkages that enable immediate action to be taken.
Business application vendors often provide role-based "operational" dashboards that enable more-frequent updates and, in some cases, are real-time, linking directly to underlying business applications or prebuilt operational data stores. These operational dashboards enable users to drill back to transactional data to support the contextual exploration of KPIs. Drilling to the transaction data and offering real-time updates may be more difficult (and not required) to support the use cases that typically are supported in a management dashboard. Many leading BI and ERP technology providers, such as SAP, Oracle and Cognos, offer prebuilt data marts/data warehouses to support these types of dashboard deployments as part of their BI and performance management frameworks. Additional data may reside in other sources, such as Excel spreadsheets, or may be provided by external data feeds, such as from Thomson Reuters, Edgar Online and Nielsen.
Scorecards take the concepts of dashboards to a higher level, helping organizations to measure and align their tactical activities with their strategies. Scorecards require a more structured approach, making use of a methodology, such as the balanced scorecard. Scorecards incorporate specific strategy management capabilities (such as strategy maps) to enable users to link KPIs into hierarchical cause-and-effect models linking and analyzing the relationships among KPIs.
Dashboards are adopted more widely than scorecards, because they are easier to implement, from a managerial perspective, and do not require aligning KPIs with strategic objectives (see "Scorecard or Dashboard: Does It Matter?" and "Q&A: Important Integration Considerations for Scorecards, Dashboards and Portals"). Although used for these different purposes, dashboard and scorecard architectures are similar and use components that are common to modern Web applications. These components (see Figure 1) are described below.
Figure 1. Components of a Dashboard or Scorecard Architecture in Use
Client or Desktop
As user communities become more diverse and the variety of delivery devices grows, these solutions are delivered with a zero footprint, Web-based or "lightweight" client/server application. The client interface is the visual component of the overall architecture, and the nature of the display varies widely. The typical interface comprises a menu with a customizable (sometimes, by the end user) pallet of Web objects with specific content types, such as a data grid, document list or chart object. These objects enable users to see data in the form of visual representations, such as gauges, speedometers, traffic lights, graphs, charts, maps and metrics. From these initial objects, users can move or drill into context-centric information in the form of more-traditional BI reports. Hence, the data that supports the KPIs must be in synch with the underlying detail data as part of a single platform. There is increased use of flash-based dashboards, such as Business Objects' Xcelsius, which provide easy-to-use visualization and what-if capabilities but offer limited scalability for large amounts of data and no drill down to detail or other BI content. These flashbased dashboards need an aggregation layer to deliver performance on large amounts data, enable security and provide integration with other BI components.
The Web application server provides responses to requests from the different supported user and client types — users, administrators, thick or thin clients and other devices. This typically is based on Microsoft Internet Information Server and/or on Java and Java Platform, Enterprise Editionbased servers, such as Apache. The Web server receives browser requests and manages or brokers the necessary security before processing the request, which is a data response, if the answer has been prepared or cached, or initiates a database or application request. This could be in any format, such as a Structured Query Language statement, Multidimensional Expressions or a proprietary procedural call. However, because metrics and detailed reports must be updated and coordinated around one definition, data typically is sourced from an optimized data warehouse and/or multidimensional database, such as Microsoft Analysis Services or Oracle Essbase.
Activity Monitoring/Event Server
Operational dashboards often include an event-processing server that provides business activity monitoring (BAM). BAM uses complex event processing to detect process state changes and to perform a sequence of analyses as soon as a new event is detected on high-volume transactional information. BAM provides real-time access to key business metrics, which can be updated as processes run. The reasons for deploying BAM are to:
- Monitor key business objectives
- Anticipate operational risks
- Reduce the time between a material event and taking effective action
BAM is emerging as a key differentiator for dashboards that support real-time event analyses.