A CMDB. A What?

An archestra notebook.

© 2013 Malcolm Ryder / archestra

IF YOU’VE FORGOTTEN THE QUESTION,A CMDB MAY NOT BE THE ANSWER.

Saturday Night LiveSeason 1, Episode 9

RootsIt’s a fact: even without adding new users, the increases in demand for services are generated by these business issues: spontaneity, interoperability, speed, and continuity.

And, the utilization of services increasingly requires that infrastructures beyond the local scope of management be “available enough” to participate effectively in meeting that demand.

From a distance, the idea of the CMDB’s desired value has been in having infrastructure management be the foundation for supporting services.

The support view sees a service as a deliverable, provided at a given level of quality to be defended – essentially, as a product.

Arguably, the “level of quality” always shows in two ways: the business-requested functional level (performance) and the IT-recommended operating constraints (scope). But that doesn’t help explain support. Instead, both the quality and the level must be managed and then related. What quality is obtainable from what level?

One interpretation of the “quality of the service” always applies: quality is an experience, of the service being used. Difficulties here mainly map back to whether rules are being followed.

• A mismatch between performance and scope is going to originate either in architecture or in exceeding the prescribed use.

The “level of service” is a different issue. If a service is having difficulty being provided, infrastructure management could be the resolution.

• A degradation of the level of service is going to originate in the integrity of the infrastructure.

Purpose

Usually, on its own, a CMDB will fail because people don’t know how the things it tracks were made in the first place, so the baseline records are suspect.

But let’s be clear. What people really think a CMDB “tracks” is changes and compliance. That is, if they didn’t need to track changes and compliance, they wouldn’t need a CMDB.

Since actual configurations are simply whatever got released into the environment, you would think that the real initial requirement would be for a release database.

After all, most differences between what used to be present and what is next present will result from (a.) a release that puts something new there, and (b.) what happened to it after it showed up.

What does happen to something post-release? Mainly, it has exposure - to utilization and to the presence of yet other things both new and old.

IT organizations exist largely to manage that exposure, among other duties. A CMDB should either help do that, or get out of the way.

Scope

The CMDB is not the CMS (configuration management system).

That is, a database is just part of a larger system.

Configuration management itself is just part of a larger system. Consolidated management of services consists of more than configuration management.

CMDBs that are built to “cover” consolidated management of services cannot be monolithic because the monolithic data schema will likely never stabilize. Object taxonomy alone normally defeats this effort.

But, lacking logical integration within an information model for consolidated management, a more specialized CMDB will not affect the things it needs to affect.

So, a “CMDB” actually needs to be not a data base but an information network.

Vizzini: You fell victim to one of the classic blunders, the most famous of which is, "Never get involved in a land war in Asia.“

Wallace ShawnThe Princess Bride

ContentAges ago, before CMDBs, Industry Analysts roamed the earth, stalking management practices. Many preferred just the basic kinds of management behavior: transactional, operational, or analytic. Analysts were pretty good about explaining why there were only three behavior types, and why the behaviors didn’t take on each other’s roles even when they shared territory and affected the same things. Most importantly, they were good about pointing out that the different behaviors had different uses for the information that was available.

Management behaviors were always discussed as processes; feeding the processes meant sending the right kind of information into the process at the right time. In other words, even in a shared information environment, each process used the available information, differently.

The description of something released into the environment makes sense to management processes when the information in the description properly feeds the respective management behaviors. But some given piece of information simply may not be needed by all processes. In the end, the different processes have different views and understanding of the exposure of items occurring through release, deployment, and utilization.

The management processes want to know what kind of exposures can occur, and when a given type of exposure is important. In effect, processes are interested in events, and the information that explains events is what processes further want to know. Without a model of these events and their importance, the detailed data describing the involved items is probably arbitrary.

StrategyFor the most part, IT operational processing can create conditions that “drive” (help or hinder) IT transactions, and that drive analytics about effects. Transactional or Analytic management both look for certain conditions, seeing them as alerts to trigger their respective inspections and other validation actions. For example: a change in a request status, a notification, or an error message, are all alert conditions.

Because conditions by definition occur and recur, most conditions (not just alerts) can be defined as events, and this means that Transactional and Analytic processing are both looking for sets of information that may not even need to describe configurations but instead need merely refer to them or relate them.

Instead, for any defined item, the key question in mind for transactions or analytics is: what is the configuration that can be accepted in order for intended business results to be achieved?

Both transactions and analyses are concerned about the variability of the configuration versus the variability of the results.

Configuration management helps provide a basis for determining what variability there is and why. It helps identify items that are suspects for the clues (events) that have someone’s attention. No clues, no suspects. In configuration management, associations of items are attributes of the item. Associations correspond to types of events, or else there is no reason to refer or relate to the item.

OPERATIONS

TRANSACTIONS ANALYTICSOf Resources

Functions of

Of Impacts

© 2

01

3 M

alcolm

Ryd

er / archestra

As shown here, the relationship that business most wants to be manageable is the one between its investments in resources and the effects obtained from them.

Operations are the mediator. Operating with resources, or operating on them, is predisposed primarily by architecture to be more or less successful through the

processes employed. Architecture designs both item usability and impact probability.

Dependencies

WHAT

Operations refer to resources they need and to what makes resources usable. And Operations relate to impacts they encourage and to what makes impacts probable. The common concern is the states of what was used when the operation executed. The occurrence of undesired states is an event.

Process Content Demand Supply Event Associations per:

Transactional Resource Request Delivery Status Policy

Operational Function Requirement Method Stage Logic

Analytical Impact Effect Outcome State Rule

Management influences whether deliveries are enforceable, whether methods proceed correctly, and whether outcomes are regular. Items are involved through associations. That is, an item also gets managed according to policies, logic, and rules.

Management also drives throughput resulting in service level and in service quality.• Transaction status is often a prerequisite of an operation requirement

• Approved, attended, complete, accepted, etc.• Operation stage is often a prerequisite of an analytic effect.

• Ready, activated, on-schedule, etc.• Analytic state is often a prerequisite of transaction requests.

• Threshold, match, criterion, etc.

Events signal whether current reality conforms to the policy, logic and rules. Non-conformance involves identifiable items. The key question in mind is then: what is the item configuration that can be accepted in order for intended business results to be achieved?

OPERATIONAL

TRANSACTIONAL ANALYTICAL

Resource Demand & Supply

FunctionDemand & Supply

How and Where ImpactDemand & Supply

WHY

What Management needs to know about an item:• Where did it come from• What is it doing• What is the effectBut the different management views have different ways of accounting for those facts. This creates differences in the explanations of why things happened as they did.

© 2

01

3 M

alcolm

Ryd

er / archestra

Additional considerations of the above include the following: when are functions resources? What impacts are caused by intangible (logical) items? Can the desired, authorized, and actual versions of demand, and of supply, be reconciled across the

different management processes?

Defined ITEM

Data References Desired Authorized Actual

Status As Required by request

As Approvedby policy

As Discovered by inspection

Information source

ITEM ID

Frequency

Standard

Timestamp

Operations demand resources, and supplying resources becomes transactional. The operation will want a minimum specified configuration to be available. Then the

operation will cause certain detectable, measurable outcomes. All of this progress is managed. The basic example of interactivity between management processes

highlights the need to understand how references and relations can rely on data lookups to assure that comparisons between former and current states can be made.

The information collected, verified, and maintained in here will come from numerous processes and repositories that need their data model transposed into reconciled information across platforms, timeframes, and norms. As it turns out, the scale of the challenge for doing this is not similar to financial accounting; instead, it is similar to meteorology.

Four unsuspected “CMDBs”

• Wikipedia (knowledge items)

• AutoCAD (engineering items)

• Major League Baseball Team Roster Depth Chart (sports items)

• The Periodic Table of the Elements (atomic items)

JUST A THOUGHT.

© 2013 Malcolm Ryder / archestra