The following is an excerpt from Architecture and patterns for IT service management, resource planning, and governance:...
Making shoes for the cobbler's children, written by Charles T. Betz. It is printed with permission from Morgan Kaufmann, a division of Elsevier; Copyright 2006. Click here to download the complete chapter, "Understanding metrics for business process management."
3.1 Metrics: Gateway from process to data
As you have seen, process-centric thinking is a hallmark of modern business practices. COBIT, CMM, and ITIL, at their base, are process frameworks. They focus on overall functional capabilities and the sequences of activities (business processes) that add value for the customer (internal or external).
Business processes require optimization, and to optimize them they must be measured. The concept of metrics management is essential to process improvement frameworks such as Six Sigma. Processes are controlled by metrics.
But what is a metric? A metric is a measurement. It is information, not activity— information that drives activity.
What is information? Information is actionable, context-relevant data. So, metrics at their base are data.
This brings us nicely to the next major architectural view: data. When architecting systems (defined as combinations of people, process, and technology) the concept of "data" is critical. The frameworks imply shared data, but they do not go far in discussing its implications, which are significant.
In reading the major frameworks as requirements specifications, the need for a consistent data architecture emerges; however, to date the major frameworks have been circumspect about this reality, consigning it to some unspecified other forum (which defaults to the intellectual property of consulting firms or vendor application products).
Trends are always carried to the extreme, and business process management (BPM) is no exception. One of the unfortunate extremes of BPM thinking (an extreme not represented by its careful thought leaders but evident among some practitioners) is the idea that process is everything and data is nothing, or is some mere technicality whose consideration can be deferred to the developers.
The consequences of this are clear from an enterprise architecture perspective: processes can't be fully optimized, because the "things" that the processes are managing are still unclear to the process stakeholders. In many cases redundancy is the result: two processes may be managing the same thing but calling it by two different names. Or—for example, with the broad ITIL concepts of Configuration Item and Change— different things may be lumped inappropriately together in a given process context.
This is compounded by the current vendor landscape, in which many vendors are selling overlapping products that refer to the same logical concepts with different terminology—sometimes, this appears to be a deliberate strategy to create the illusion of product differentiation where none exists. Without a sound, product-independent data perspective, ITRP and its implementers will be hostage to product vendors.
Of the views this book takes—process and function, data, and system—data is the most precise. Even at the verbal, conceptual level, it provides the basis for system interoperability, business rules, and application design. The data necessary to the domain of IT management is a fascinating topic. It's not impossible, as some seem to feel—the data structures needed to run IT, although tricky in some ways, are comparable in number and complexity to other functional areas.
Business processes require metrics, and at the most general and abstract the use of metrics to assess and guide process is called "performance management" or "business performance management" (sometimes abbreviated BPM and confused with business process management).
A hierarchical metrics structure is characteristic of performance management and the business intelligence methods supporting it. The hierarchy of metrics may progress from simple operational reporting to complex, derived leading indicators. Such approaches have become well established in many types of business activities, and attention is now turning to measuring IT similarly. Unfortunately, there is no established suite of IT metrics comparable to standard financial measures of corporate performance. This is an area of activity for a number of standards bodies, academics, and other players.
Business intelligence software at its most sophisticated provides robust support for building expressions based on metrics. Before investing in a limited-function service-level management tool, it may be worthwhile considering this as a special case of a business intelligence problem and handle it through standard business intelligence or data warehousing techniques.
Both ITIL and COBIT have extensive coverage of metrics, which this book will not replicate. However, consider a couple of examples from those frameworks.
Example 1: Change Management. ITIL, in the "Change Management" section, calls for tracking the number of Incidents traced to Changes. This implies the existence of separate Incident and Change data entities, which can be joined together and summarized to derive the counts. This is a clear statement of data requirements.
Example 2: Technology Obsolescence. COBIT, in the Acquire and Maintain Technology Infrastructure Control Objective, calls for the metric "# of critical business processes supported by obsolete (or soon to be) infrastructure." This implies the existence of business process and technology entities. The technology entity would require a life cycle state or obsolescence attribute of some kind (implying, in turn, a process for maintaining this information). A good data architect will also question whether business processes should be tied directly to technology platforms or tied first to IT services, which are then dependent on technologies.
IT performance measurement is a nontrivial and evolving field; refer to the references and footnotes for discussion of specific IT metrics. The discussion here is focused on the architectural requirements of metrics management generally, including their basis on clean, normalized, well-architected data (an aspect overlooked in most discussions).
Rollups and dimensions
Most reporting is characterized by a requirement to summarize detailed data along standard hierarchies. In data warehousing, such standard hierarchies are known as "dimensions." In the ITSM and IT governance space, these common dimensions include the following:
- Organizational hierarchy
- Organizational and IT strategic goals
- Application portfolio (rolling up into both the organizational hierarchy and the service-level agreements, or SLAs)
- Service (in the ITSM sense, if separate from application)
- Program or project portfolio
- Data subject areas (hierarchical, not relational)
- Enterprise calendar
- Enterprise operational locations and hierarchy (e.g., District and Region)
Some of these will be well understood by the enterprise's data warehousing group (e.g., calendar and location); others will be new ground. A well-known challenge in data warehousing is "nonconformed dimensions," that is, dimensions that are not in synch across different systems—for example, different calendars in use by different lines of business. Intractable process and political difficulties may emerge in the search for conformance. Generally, the dimensions should be managed by the IT portfolio and architecture processes (preferably with Data Management guidance), and the facts should be managed by the operational processes.
The application portfolio is perhaps the most important and difficult. Organizations may have 10 or more different lists of applications, causing no end of confusion around what IT is doing and who owns it.
The project portfolio can also be a source of pain. As with systems, people tend to refer to projects by myriad imprecise names. What is the system of record for projects? Does every system that references a project do so using an unambiguous project identifier or picklist derived from the system of record? Or is just the project name casually typed in with no check for accuracy?
Another problem is the challenging topic of "slowly changing dimensions." Suppose incidents are rolling up by application portfolio and organizational hierarchy, with trending reports over the years. Then reorganization happens. How should this be handled? There are three approaches, all with pros and cons that need to be understood in depth.
A related matter is the establishment of common IT reference data (generally termed "master data management," or MDM in the industry). Dimension conformance is an issue of MDM, but MDM is somewhat broader in implication (e.g., Server might not be a true dimension, but ensuring that there is an accurate single list is an MDM problem). See Figure 4.26 and the related discussion.
Generally, the metrics-based management control of processes requires carefully and clearly structured data. This chapter thus turns to a detailed examination of the conceptual data structures involved in IT management.
TABLE OF CONTENTS
- Part 1: Understanding metrics for business process management
- Part 2: A guide to conceptual data models for IT managers
- Part 3: Business process management and IT process entities