« Coping with Katrina | Main | Demystifying ITIL »
September 1, 2005
IT Operations Intelligence - The Business Logic of the CMDB
Without question, business is overwhelmingly predicated on the ability to service needs through leveraging IT resources.
The ever increasing frequency in the variation of business needs means that there must be an increasingly intelligent mechanism for determining the current appropriateness of the available resource for the need, on demand.
I.
Technical advances have made it economical to store and communicate increasingly vast amounts of descriptive data about resources. It is now feasible to at least federate myriad descriptions into a single logical reference database.
But a key issue is how to actually increase the effective intelligence of the usage mechanism, which means increasing its ability to determine the relevance of the data in qualifying the resource for active assignment. Meanwhile, an accompanying problem is of course to ensure and confirm the availability of appropriate resources.
The sensible thing to do about those issues is to use the information to develop profiles of resources that allow quick identification and anticipation of productive associations with existing and predicted business needs.
But with the pace of change and the proliferation of business process variations, that would be a logically improbable achievement unless there was some framework of business demand that could help to define and anticipate the most likely requirements that resources need to meet -- thereby bringing order to the task of vetting the ocean of descriptive data by relevancy.
II.
For example, a business process makes functional requests that require the support of appropriate resources; this offers a step towards making a framework (or frame of reference). The functional requests establish what is appropriate by specifying resource characteristics that are known or predicted success factors. In reality, that specification may just as likely be discovered through trial and error (i.e., testing) as it is proactively designed. Still, in either case, any given resource can (at least hypothetically) be certified for its compatibility to the functions of a business process.
Then, by cross referencing multiple business processes, it will eventually become evident that a given type of resource applies to the range of constructive assignments. Patterns of both common and exceptional functional dependencies on the given resource-type emerge in more or less architectural perspective. Particular instances of a type of resource can then be audited and rated within their type or class.
Conversely, preventing and remedying destructive (or counterproductive) resource assignments means determining in timely fashion that an existing or probable mismatch of resource characteristics is imminent versus the expected demand.
Related to that, another challenge is that a resource, as a discrete unit, may not have all of the characteristics necessary to meet the requirements. In this case, its relationship with other complementary resources may allow it to offer a virtually complete profile for the specifications of the business need. Here, an accompanying problem can be that existing inter-resource relationships may actually reduce the effective availability of a discrete resource for duty, by too strongly capturing the resource within a virtual profile that is inappropriate for the current demand.
III.
Creating the composite of a resource's functional assignments and inter-resource relationships, the characteristics making up the functional profile of the resource are its configuration.
In this light, a defined configuration's lifecycle, from inception to retirement, is consequential only to the degree that at any time it's current phase is associated with business demand.
That association -- seen in terms of whether the resource is both appropriate and available -- translates into quality and capacity management issues mainly significant for addressing the performance of the business processes being served.
But the configuration itself -- seen in terms of the patterns of its utilization -- translates into access and impact management issues addressing the measurable value of creating, deploying, modifying or retiring the configuration in the face of feasible alternatives.
IV.
We can support management decisioning through storing descriptions in a configuration management database (CMDB) and analytically processing them.
As the nexus of business process management and asset value management, configuration management uses and controls the view of resources that evolves in those two dimensions -- emerging as an explanation of how to translate the IT architecture from an investment to a benefit.
Just as strategic product management connects market requirements to engineering, configuration management strategically connects business process requirements to asset management. The connection can be expressed as responsibilities that formalize the major intersections or "coordinates" of the two dimensions.
As seen in the following framework of such responsibilities, the dimensions are:
- the utilization performance spectrum (as in market or business process) ranging from enabling to strategic -- i.e. from a willingness to exploit the resource, to a need to optimize it;
- the production value spectrum (as in product or asset) ranging from planned to actual -- i.e., from initial discovery of an appropriate asset to proactive release of the asset (into production).

(click here for enlargement.)
While the framework does not intend to presribe any overall method for managing resource information, it does provide a context that presents resource description data as business intelligence. As an example of the implications of the framework, the illustration further observes that the intelligence can be approached from the general operational perspective of aligning resource versions with business practices that operations logically direct through usage accounts and usage models -- providing effective management of services.
Note: in this framework, the idea of "discovery" is important to the purpose of communicating that whether assets are built, borrowed or bought, the key business production issue is for the business process to find an appropriate available asset for use as a resource.
Posted by Malcolm Ryder at September 1, 2005 8:58 PM
Trackback Pings
TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/122
Comments
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)