THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

In software engineering, a design pattern is a general solution to a common problem:  A design pattern isn’t a finished design that can be transformed directly into code; it is a description or template for how to solve a problem that can be used in many different situations.

If the scope of this book were ten times larger, the material might extend into an exhaustive survey of recommended IT processes, all the way down to specific workflows, tasks, and responsibilities. Some of the major IT service providers and research firms have detailed material at this scale, and it’s not the purpose of this book to replicate such.

However, there is not a lot of added value in yet another workflow analysis of incident management. Again, the focus of this book is on the less obvious questions raised in stitching together seemingly disparate functions in IT. Therefore, the remainder of this book is devoted to patterns: named nuggets of insight addressing particular recurring problems in large-scale IT management.

The concept of patterns, originating in building architecture and city planning, has been applied in computing for almost two decades. This book also uses a pattern language, but at a higher level than the software engineering pattern literature; patterns of process, organization, data sourcing and flow, and human motivation are discussed. The objective of the pattern analysis is to tie the system’s architecture, data, and processes together across the functional barriers, so that the value chain (and its governance) is enabled.

The patterns focus especially on breaking down the functional boundaries between IT planning, solution development, and service management, and enabling the accuracy of the core information store at the heart of well-managed IT. The concepts of Demand and Portfolio Management cross these boundaries and are advisable places to start. The concept of the Configuration Management System (aka CMDB) also is a tricky area, and it’s hoped the patterns described here will assist the many organizations pondering how to keep such a comprehensive data store current.

Many more patterns will hopefully surface as IT management begins to truly mature and find their way into vendor products. Everything described in these patterns is achievable.

The “patterns” in this book are loosely defined; sometimes they are expressed as data, system, or interaction models, and sometimes they are simply expressed as narrative. They are structured thus:

• Patterns for IT processes
  
• Patterns for IT lifecycles

This ordering is deliberate, as maturation tends to follow a progression from function to process to lifecycle – the larger, emergent structures require maturity and organization of the smaller structures.

The author decided against doing for the functional, data, and system layers; instead, those layers are the building blocks. The patterns are restricted to the measurable, countable processes and lifecycles where true value can be ascertained.

The more formalized patterns are interspersed with various essays and extended discussions providing context and point of view.

This chapter focuses on patterns for the nine major IT processes:

• Accept Demand
  
• Execute Project
  
• Deliver Release
  
• Complete Change
  
• Fulfill Service Request
  
• Deliver Transactional Service
  
• Restore Service
  
• Improve Service
  
• Retire Service

Rummler and Brache state, "Through the application of Process Management, we have learned that managers . . . should concentrate as much or more on the flow of products, paper, and information between departments as on the activities within departments. Process Management provides a methodology for managing this white space between the boxes on the organization chart."¹

Because processes are known for crossing functions and sharing data, describing specifically how these coordinations may take place is the primary goal of this chapter.

There also is a “Lifecycle implications” section at the end of each process discussion to examine how that process affects the longer-lived IT portfolio lifecycles (application service, infrastructure service, asset, and technology product).

Pattern approaches in forming this book include Gamma1995; Buschmann1996; Fowler 1997, 2003; Hohpe and Woolf 2005; Silverston 2001a, 2001b, 2008.

IT Process Principles

Many discussions of IT improvement, continuous improvement, and Lean more generally start with process management objectives of shrinking cycle time and improving quality (or at least consistency) of results.

Improving these both (1) improves the process value itself and (2) improves the lifecycle entities that the project affects (applications, infrastructure services, assets, and technology products).

To understand this second kind of value, however, one needs to ensure that the processes are properly linked to what they affect.

What does this mean?

For example, in lower-maturity Change Management systems, the Change record is not linked to any Configuration Item. Higher-maturity systems link the Change to the Configuration Item.

In terms of grammar, it’s equivalent to adding an object to a basic subject and predicate. Instead of just:

                         Change completed

Restructure the sentence thus:

                         Change completed to the Human Resource Management System.

The lower-maturity Change Management capability might document in a freeform text field that the change affects the HR system. But the higher-maturity approach is when the object is managed, meaning that it is represented in a structured form somewhere with clear identification; in this case, the HR system being represented in the Configuration Management System or IT Portfolio Management system as a distinct record, independent of any processes that affect it. (In reality, the object of the change might be even finer-grained, such as a specific subcomponent of the HR system.)

Without this approach, process measurement is much more difficult. It is important to be able to group processes by the objects they act upon; without this, we cannot really understand the value of the process or the nature of bottlenecks or constraints to it.

Most processes do have some categorization or assignment of ownership that can assist in such measurements, but ask yourself:

• Can I report in a structured way on all the Configuration Items related to unsuccessful Changes?
  
• Can I report on all Applications that have been the subject of unsuccessful Projects?
  
• Can I report on all Applications that have required service restoration in the past 30 days (i.e., suffered an Incident)?

Most IT shops with formalized processes in these areas would be able to count the unsuccessful Changes and Projects and count the Incidents. But being able to report on the objects of those processes is more difficult. Yet how can one fully understand root-cause and improvement opportunities without understanding the impacted portfolio?

Furthermore, the process actions on the object should be rigorously tracked: who changed what, when. Common terms will be effective dating, time-stamping, and/or audit trail (use these in vendor discussions).

Business process meets the entity through these techniques, especially when audit trails are collected on the changing roles and responsibilities for an entity. A trail of who “owns” an incident and where it has been referred is a feature of most incident management tools; this is a specific example of the general principles here. Time-stamping of status changes is (in part) how Service Level Agreements are monitored for things like Incident, Service Request, and Problem resolution.

Similarly, IT enablement tooling should manage audit trails on other entities and their role assignments:

• Who have the Application Managers been for this Application?
  
• What Projects have built upon this Application? Who has been on them?
  
• Who has approved this Change? When was it approved? Completed?
  
• Who performed the work?
  
• What processes (e.g., Service Requests) were related to it?

So, the next time you get involved in a process improvement discussion, or are troubleshooting some specific process cycle, ask yourself: “What’s the Object?”

Reference:

1. Rummler and Brache 1995, p. xvi.