« Critical Mass on the Critical Path | Main | Capitalist Tools in the Garden of Good and Evil »

January 16, 2007

CIs, IT and the Good Life

In the management of information technology items, adoption of ITIL is now nearly automatically a strategic goal, and in pursuit of that, it's not uncommon that a friendly tug of war will erupt between several management practices. These typically include Asset management, Systems management, and now Configuration management.

Each of those three practices spends its day closely attending to lots of the same items -- items that are found and/or intended to enter utilization by the parent business entity so that the corporate work of the business may reliably get done.

Each of the practices also has guides to their respective "best practice"; but it is often a matter of politics, funding, and historical inertia/momentum that determines the true balance of their powers and co-operation. Luckily, the relatively recent concept of the "CMDB" or Configuration Management Data Base has emerged as a presumably indifferent and ultimate information authority able to arbitrate differences between the points of view taken by the three practices -- while the cover discipline of IT Service Management (ITSM) presumes a higher power over all three.

Still, of the three historical areas, Asset management handles most of the money issues and thus often exerts more of a business profile, tending to lay more claim to entrenched authority. Thus its perspective gets a chance to influence thinking in other practices, and the most popular of these cross-over ideas is the idea that items have a "lifecycle".

"Lifecycle" expresses the notion that there is orderliness in the entry, habitation and exit of items within the life of the business itself -- an orderliness imposed by the accountability required of management. An item's "asset lifecycle" covers its birth-to-death milestones that describe how it originated, how it got into utilization and fared there, and how it ended up when no longer needed. All of this stems from a business preoccupation with ownership of the item, the presumed target of all benefits and risks.

Most recently, Configuration management has reared up as an alternate perspective for the accountability of the impact that an item has on the business. A "configuration" is a description of those salient characteristics, particularly in the perspective of the intended "best" utilization for successful work outcomes. If the item is a "business resource" (which of course all IT should be), instead of just business property, then the characteristics of the item are important because they indicate whether the item is fit for the purpose imposed by its utilization. It matters, then, whether the item actually has the desired characteristics, in the heat of the business moment. It is very unfortunate that the term "item configuration" was displaced (for some reason) by the relatively obscure term "configuration item".

Systems management has historically been responsible for making practical characteristics come about in real operational time. But at the business level, Systems management did not offer enough of the authority of "standards". Although "business" would "require" technical standards, there was still a gap between the technology and the logic of the actual utilization that came from business behavior with the technology.

As a result, while items might still have been seen as assets or as systems, there needed to be another way to represent the behavioral standards of the relationship between the business usage and the technology used. This standardization and representation took the form of defined Services. The relationship of the item to the Service became indicated by the item characteristics that were required by the Service -- and those identified characteristics are the "configuration" that defined the item in terms of the service. Thus we have the "configuration item", or "CI"...

Asset management's influence and lust for lifecycle accounting inspired the notion that, since most CIs are assets, CIs must have a lifecycle, too. But taking the notion only that far, confusion has sprouted about what point there is to calling the lifecycle a "CI" lifecycle as opposed to an asset lifecycle. Why have two different names for the same thing?

The answer is that the true lifecycle of a CI is not the same thing as an asset lifecycle, nor the same as lifecycles that might be imagined for engineering, nor other disciplines that manipulate the item. A CI "lifecycle" is not about the management accountability covering the concerns of:
- development
- ownership
- availability
- performance

Instead, a CI lifecycle is about management's accountability of the item's impact on the integrity of a Service. (Service Integrity is a shorthand label that we'll hang on to for future reference to this discussion.)

When prescribed business behavior for the utilization of the item is set up as a service, the two key issues involved are from the service's point of view -- about the progressive degree of provision enabled and the progressive degree of support applied, relative to the state of the CI.

In the matrix above, degrees of provision and support intersect to generate the "milestone" state of the CI that represents a major phase in the CI's "lifecycle". The matrix generates four lifecycle milestones from top left to bottom right, and each milestone represents a degree to which the CI supplies integrity to the structure of the live service. The weakest is relatively conceptual at the top left, and the strongest is very tangible at the bottom right. However, it is important to understand that these four milestones or phases are points on a continuous circle; changes in business needs may require that the deployed and controlled CI undergo "re-modeling" to regain alignment (correct "service ability") with the go-forward business.

One of the most important aspects of that understanding is that an item is not necessarily always a CI: in fact, during its existence, it is a CI from some timepoint to some other timepoint, and for some service or other service. An item may fall in and out of being a CI. The matrix helps to show what management thinking and activity explicitly handles the recognition and association of an item to a service as a CI.

It is also worth pointing out that if there is a dominant historical influence on this thinking, it is actually not Asset management. Instead, as should now be somewhat obvious, the dominant relevant precedent is Architecture, which literally pre-figures and prescribes what should be approved, deployed and controlled in a structure that turns an item into a resource. Where CIs are concerned, the structure is a Service, and the business uses the service to exploit the item.

Finally, all management disciplines are essentially perspectives first and policies second. There is no logical reason why they should by default be mutually exclusive of what they take responsibility for... instead, they should co-operate by together bringing a broader range of attention to any given item. In presenting the CI lifecycle matrix, the intent is NOT to stake out an area of privilege just for "Configuration Management". As further emphasized at the bottom of the illustration, several management processes may have a primary role in attending to the CI's progression through milestones, and these roles are not unusual for most IT management teams. Not coincidentally, the concept of a CMDB will mature into the concept of a Configuration Management System (CMS) leveraging a variety of relevant management information donors in a well-orchestrated manner.addressing service integrity.

Posted by Malcolm Ryder at January 16, 2007 5:51 PM