A Framework of Business and Technology Architecture Supporting Performance Management

Over the last several years, my colleagues and I at the National Center for State Courts have recommended that courts design, develop and implement automated performance measurement systems. Such a system is supported by multiple interlocking layers of technology and business architecture that translates a court’s mission and strategies into clear performance metrics. We agree with Wayne W. Eckerson, the director of research and services for the Data Warehousing Institute and the author of the 2006 book, Performance Dashboards: Measuring, Monitoring, and Managing Your Business (John Wiley & Sons, Inc.) that the system should be built on a multilayered business intelligence and data integration architecture including the processes, tools, and technologies required to turn data into information and knowledge. Further, we’ve recommended that the performance information needs to be communicated quickly and concisely in the form of performance dashboards, scorecards or other computer-screen displays.

Just like a car’s instrument panel is built simultaneously with the car’s operational systems, a performance dashboard should be developed in coordination with the design and development of a court’s production or operational systems (e.g., case management, financial and jury management systems). Surely, car makers do not think about the design and development of the car’s dashboard only after all the other pieces of the car are built and finished!

A Framework

According Eckerson, an effective performance management system consists of business process (organization) architecture and technology architecture, each with one or more elements at various layers. The figure below shows the two parts and multiple layers of this architecture and how they relate to each other. Specific elements or components -- methods, tools and technologies -- may appear in one or more layers of this architecture.

Business Architecture

The business process architecture (top of the figure) has four layers. The layers and the elements contained in them should be harmonized and aligned.

1. The top layer includes the perspectives and expectations of a court’s internal stakeholders (e.g., judges, managers and staff) and external stakeholders (e.g., the court’s justice system partners and the public) which, ideally, are reflected in the outputs and outcomes of the court’s program and services.
2. The key success factors or major performance areas (e.g., access, timeliness, efficiency, and fairness) which, again ideally, are aligned with stakeholder expectations.
3. The strategies (e.g., case management) and tactics (e.g., calendaring) of a court.
4. The performance measures aligned with the foregoing (e.g., time-to-disposition, clearance, case inventory or backlog, trial certainty, and cost per case).

The first two layers of the business architecture contain the perspectives and expectations of internal and external stakeholders and key success factors, expressed in terms of values, visions, mission statements, goals, strategic plans, budgets, and objectives. Ideally, all the elements in these first two layers are performance-based and oriented toward specific performance indicators and measures.

The third layer of the business architecture contains the specific strategies and tactics to achieve goals. The strategies and tactics are shaped by the performance-based orientation of the elements of the first two layers, and further clarify the specific performance required to achieve the strategies. Finally, in the bottom layer of the business architecture, a court translates strategies and tactics into specific performance measures, and performance targets and objectives.

Technology Architecture

The technology architecture has five layers. From top to bottom in the figure, they are:

1. Performance dashboards, scorecards, and other displays of the performance measures populated by data moved up and through the layers below.
2. A layer including software applications for monitoring, analyzing and managing performance data for strategic, tactical and operational decision-making.
3. A data store layer which gives users access to the performance data for purposes of monitoring, analysis and management.
4. An integration layer for extracting data from data sources.
5. A layer of data sources including legacy systems running on mainframes, packaged applications running on relational databases, Web pages, Excel spreadsheets, Access databases, and other data sources.

This summary of the five layers of technology architecture of a performance management system is intended only to highlight functionality, and not necessarily to identify specific tools and technology in these layers, especially, emerging technology like semantic composite applications. Emerging technologies in Web services and composite applications in service-oriented architecture (SOA) may especially blur the distinctions among the three middle technology layers – applications, data stores and integration. (For example, although the functionality of data stores is critical, service oriented architecture (SOA) has made large data warehouses a thing of the past. Further, composite application platforms eliminate a number of issues of integration such as copying data from one location to another that ETL (extraction, transforming and loading) and EAI (enterprise application integration) tools are designed to do. See Raden, Neil. “Start Making Sense: Get From Data To Semantic Integration.” Intelligent Enterprise, October 1, 2005. Accessed at http://www.intelligententerprise.com/showArticle.jhtml?articleID=171000640.) The functionality highlighted by these layers, however, is critical for the consideration of how a court might in improved business and technology architectures.

Aligning the Architecture

As the two arrows in the figure above suggest, performance measures – first, their operational definition in the bottom layer of the business architecture and, second, their display in the top layer of the technology architecture -- tie the two parts of the architecture together. Without harmonized business and technology architecture courts are unlikely to execute a coherent strategy and its technical team will fail to deliver viable performance information system.

On the business side, a court must translate mission and goals into strategy and tactics, strategy and tactics into objectives and, finally, objectives into targets, clearly identified in the language of performance indicators and measures which are easily accessible to users. Ideally, all these layers are harmonized and work together. Performance measures focus and define in operational terms the expectations of a court’s internal and external stakeholders, its key success factors or major performance areas, its strategies and its tactics.

On the technology side, performance measures determine what a court’s internal and external stakeholders monitor (what they see on performance dashboards, scorecards or other performance data displays), analyze and manage. A performance dashboard, scorecard or other display consists of software applications that monitor, analyze and manage performance. They include the rules that define what data to collect, how it is calculated, and how it is aggregated and disaggregated.

A court does not necessarily need to have a specific number of components in each layer of the business and technology architecture (e.g., a certain number and types of performance measures as part of its business architecture; or specific integration tools as part of its technology architecture). Instead, the number and types of components should be driven by its needs. However, it should have at least one component at each layer.

For the latest posts and archives of Made2Measure click here.

© Copyright CourtMetrics 2006. All rights reserved.