A CMDB. A What?

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 Live
Season 1, Episode 9

Roots
It’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.

Wallace Shawn
The Princess Bride

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.“

Content
Ages 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.

Strategy
For 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.

TRANSACTIONS
Of Resources

Functions of
OPERATIONS

WHAT
Dependencies

ANALYTICS
Of Impacts

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.


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?

TRANSACTIONAL
Resource
Demand & Supply

OPERATIONAL

WHY
How and Where

ANALYTICAL
Impact
Demand & Supply

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?


What Management needs to know
about an item:
• Where did it come from
• What is it doing
• What is the effect
But 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.

Function
Demand & Supply

Defined
ITEM

Data References

Desired

Authorized

Actual

Status

As Required by
request

As Approved
by policy

As Discovered
by inspection

Information source
ITEM ID
Frequency
Standard

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.

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.

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.


A CMDB. A What?

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to A CMDB. A What? (20)

More from Malcolm Ryder (20)

Recently uploaded (20)

A CMDB. A What?