When IT doesn't work in its business use, referring to how IT is structured in supply is no longer enough of an explanation. Regardless of any ITSM orthodoxy, the business needs its demand perspective to define how "configuration" of IT makes logical business sense. That perspective must shape the next normal CMDB.
3. The Point of Diminishing Returns
A business increasingly has to get things done using things it didn’t make, provided from
external sources it does not control.
At the same time it usually has a culture of risk prevention that is enforced in what it
makes itself, for its own use or use by customers and partners.
For management of risks in operations, the business needs information that explains why
something behaves in the business the way that it does.
But that is not the same as the information that explains how something works.
When something does not work, the need is to know if the why is because of the how.
If the link between the how and the why cannot be openly clarified, then who cares about
how much detailed data there is on either side?
What’s necessary is someplace dependable to get that clarification, on demand.
The more variable the data is on each side, the more obvious it is that the clarification
must come from rapid analysis of timely, reliable discoveries.
4. The Who Cares Test
Successfully leveraging “prospects” despite current challenges is the business of business.
In business tactics, the leverage involves a balancing act: the probability of losing an opportunity or
a customer, weighed against the difficulty of gaining new opportunities and customers.
Any imbalance necessitates a trade-off – a calculated risk. In any given business, that calculation can
be a strong point or a serious weak point in capability.
Discovering valuable new opportunities and customers (development) requires more intensive and
difficult analyses than does assuring continuity (support).
But for business, continuity essentially has meaning as “continual effectiveness from preparedness”,
not as “don’t change anything”.
Preparedness should always mean being able to do different things at different times, as necessary.
The new normal for business is that there is continuous environmental change exerting influences
that create imbalances and the subsequent need for re-evaluating trade-offs.
That puts pressure on whether the business’s current preparedness actually does include the ability
to do different things at different times as necessary.
Current preparedness fails if it cracks under pressure. It is necessary to understand how the
pressure threatens continuity, and how to organize management of the threats.
6. Engineering outcomes
Service Management is, of course, about managing services. But the point of management per se is
independent of what it is managing.
Management is always concerned that:
• The right thing is resulting
• in a reliable way
• with predictable effects
• that are not counter-productive
• and that immediately have adequate value
Increasingly, tasks that provide assurance of the above outcomes are tasks that can be automated.
Automation makes the production of desired outcomes significantly more readily achievable as
intended. Automation essentially turns the producing into persistent engineering.
Engineering is expected to “pre-configure” both a service for business and the underpinnings of the
service. If services as originally engineered were then impervious to damage and/or did not need to
change, then further managing their configuration would not be necessary. But damage and change
are both facts of life.
Due to the impacts of damage and change on finance and performance, management of the
configurations of services is not optional.
Services help management,
but a service itself must be managed.
7. What is a Configuration
In IT, a “service” has typically been a logical view of a “configuration” of components,
important for supply to the business.
A component is meaningful as a static item; components are sub-units of system
structures.
Components are managed through systems management, and there are component
topologies to describe their managed arrangement.
But, a “configuration” of a service is not just a structure of components; it is an
arrangement of elements.
An element is meaningful as a dynamic item: an element is a required aspect of a cause of
action. It is a logical view, important to demand by the business.
Action elements are implemented through forms that may be virtual (emulated) or real
(physical).
The implementation of the forms amounts to the configuration of the service.
8. What is a Configuration Item
A “CI” (configuration item) is not simply a component that has specified attributes.
An “item” of a service configuration is a logical view of an element (a cause of action) of a
service in operation as prescribed.
That logical view is identified as a form used to implement an element.
A configuration item is, therefore, a form used to implement an element of a service.
The form called a “CI” has a prescribed behavior as an element of an action or event that
constitutes a function.
The behavior may have dependencies on particular components made available as
resources, but the prescribed behavior is the focus of managing the service configuration.
In other words, an identified CI is a resourced instance (an identified “actor”) of a role.
9. The essential CMDB
An identified CI is a resourced instance (an identified “actor”) of a role.
The form called a “CI” is accountable as an element that has its prescribed behavior
engineered in a function.
What makes the entity behavior “engineered” is intentionality.
The intentionality is a combination of definitions identifying what is (to be) appropriate ,
with evidence indicating that the realization of the behavior (as is) correctly corresponds.
The definition and evidence data necessary to accurately account for the form in terms of
the intentionality are usually expected to be contained for management in a configurations
management database (CMDB).
The CMDB also includes identifiers of the interaction of the forms in terms of intentionality.
10. The Anti-agile CMDB
Up to now, a conventional Configuration Management Data Base (CMDB) has cataloged
and mapped managed components according to the dependent interactions that describe
the mechanics of production systems. It has called those components “CIs”.
In effect, it attempts to instrument quality assurance of system implementations that make
up a production environment.
Both as a purpose and as a result of that, the most prevalent use of a conventional CMDB
is to provide a blueprint allowing reverse-engineering and support of what it tries to
descriptively document. That amounts to supporting the systems usage by business.
But for current businesses, flexibility at high speed is the order of the day. Conventionally, a
system’s mechanics are not known to have flexibility without high levels of complexity.
In those mechanics, stabilizing complexity for the purpose of gaining reliability
(preparedness) usually involves high-energy optimization and/or high resistance to change.
That increases the risk of “stability” becoming rigidity or brittleness, reducing its relevance
to different future conditions than already existed.
A conventional CMDB, focusing on components, is thereby always at risk of becoming
either unmanageable or obsolete, unless the level of investment in its maintenance can be
sustained at any necessary intensity.
11. CMDB for Business Meanings
On the business side, the influences of competition, of technology innovation, and of cost-
efficiency are now each strongly escalated and together endlessly re-combined.
That has overwhelmed many traditional assumptions about how business production
environments work and evolve.
Most evolution is now user-demand driven, with remarkably low barriers against rapid and
dramatic changes at many architectural levels of production.
Consequently, the conventional CMDB is more unlikely to keep up with the velocity,
volume and variety of changes – except through extraordinary amounts of labor.
Its fundamental weakness for business use lies in the difficulty of maintaining complete and
accurate data despite the continually increasing dynamic (not mechanical) complexity of
what it tries to describe.
For business purposes, a corrected CMDB focus would be on service implementations
rather than on systems implementations.
12. Self-Healing Systems vs. Management
Everyone knows that automation is the principle solution to labor burdens.
Automation essentially brings execution power at high speed. More automation means
that, through any combination of prediction and response that it offers, significant
production can occur closer and closer to real-time demand.
In I.T., automation now must be understood as a phenomenon of intelligence driving
instructions that in turn are driving machine-based procedures.
That definition clearly involves analyses, communications, and commands – all matters
that are dramatically amplified and optimized by advanced information systems and
information management technologies available today.
I.T. automation brings both recovery (maintenance) and re-engineering (change) of the
production systems to much higher levels of effectiveness versus complexity, diversity or
volatility of operational circumstances, without manual intervention.
Even more significant, I.T. (intelligence-based) automation increasingly means that the vast
majority of adjustments may be made without requiring the notification and response of
people.
13. Management Automation
To operations, a major implication of the automation of management is that there is an
unprecedented availability of real-time transparency of all current effects and states.
Operations in a maintained engineered environment then automatically uses that
intelligence to guide immediate follow-up re-engineering at whatever intensity is
appropriate.
For managing continuity, that automation ultimately means promoting, adjusting and
correcting behaviors of service elements in real time, continuously.
For managing services, the automation dramatically reduces the required level of real-time
human attention to risks in the viability of systems underlying service elements.
That automation allows shifting management’s attention mainly to addressing the
business’s interpretation of service behaviors.
14. Value Recognition
The implications of intelligent automation are big and already very real.
Automation can detect, analyze and respond to vast amounts of data, both local
and remote, with otherwise unattainable speed and consistency.
Programming in automation removes the need for continual human interventions
in existing detection, analysis and response – and accommodates decentralization
of the data.
The data processing in automation drives automated interpretations of current
conditions.
Advancing along the lines of A.I., machine learning, Big Data, IoT, and digital
(virtual) architectures, configuration management will evolve to resemble the
operation of quantitative analyses driving trading behaviors on Wall Street.
Behaviors are evaluated for their meaning with regard to gains, stabilities, and
losses (i.e., value) in the market.
15. Central Intelligence
In the stock market, the enormous amount of intelligence is not held in some container as
a static reference.
Instead, it is continually streaming input.
The “central database” of significant information exists mainly as a channel with a credible
point of contact, for federated real-time reporting (feeds of data) about entities that are
recognized through qualification by rules.
Recognition rules process detected entity attributes (called fundamentals).
Those attributes logically correlate with when demand leads to gains, stabilities, and losses
in the market through transactions.
And they correlate with how arrangements of the events and behaviors underpin the
transactions.
The actual real-time correlations may or may not conform to prescriptions or expectations.
16. Business Model Logic
For business managers, the example of the stock market management processing is clearly
important.
In an environment where change continuously occurs aggressively and intentionally, the
market management model is a more logical approach than conventional component-
based factory management of IT services requiring control of a master inventory.
That is, the environment of business capability is described and interpreted mainly as a
selective market of opportunities for “provision” (offer) of benefits, not mainly as a
proprietary factory of machines for “production” (inventory) of systems.
Services are responsible for organizing the elements that make offers viable, feasible, and
available.
To support pursuing and exploiting business-relevant opportunities:
• the business expects the benefits manager to practice Portfolio management.
• the business expects the service provider to practice Performance management.
• the business expects the systems manufacturer to practice Product management.
17. Business Management perspective
The business brings its demand-orientated perspective to management.
It interprets current conditions in terms of their impacts on its portfolio.
The portfolio is a registry of items (including assets, capabilities, and positions) having a
specific type of value.
Current events and opportunities represent potential impacts on value.
Desirable impacts are explicitly pursued with services that are directed behaviors.
The services offer behaviors of recognized roles (entities and actors) in the environment.
The roles are “change agents” that themselves rely on supporting resources.
The business can tolerate a high volume of changes occurring at the resource level without
having to do anything about it – as long as it can still directly manage the current states at
the service level.
18. “Configurations” of Business Capability
For pursuing opportunities on demand, the business is offered prescribed capabilities to use.
The capabilities are based on co-operative functioning of prescribed entities.
Under management, services offer prescribed behaviors of recognized roles in the environment.
The roles rely on prescribed resourcing.
• Systems instantiate the entities and actors that resource the roles.
• Components constitute prescribed modules of systems.
To enable managed business capability:
An operations director deals with functional (entity) relation.
A service provider deals with behavioral (role) orchestration.
A systems manufacturer deals with structural (resource) integration.
A component supplier deals with unit (part) assembly.
Four Types of
prescribed
Configurations
20. Configuration Information
for Business
A “CI” is a resourced instance (an identified “actor”) of a role.
A configuration is a purposeful arrangement of the instances for a capability.
21. Engineering desired effects with
prefabrication and orchestration
Innovative technology automation has created a new range of infrastructure patterns by offering
more of what appears to be “prefabricated” functionality.
Prefabrication suggests to the business user that there is little-to-no need for “micro-managing” the
item engaged as the source of the functionality.
In this view, the quality and integrity of the item’s “internals” are the responsibility of the item
producer, not the item user. The producer, not the user, is held accountable for a reliable assurance
that the item’s functionality will be available as advertised.
The overall approach is to assemble modules of capability, where a module has “no user-serviceable
parts inside” but can work with other modules in a user-required way called a “deliverable”.
A defined deliverable comes with a designated scope, time and cost – all of which apply to a module
of capability providing enabling behaviors. But with modularity, assurance of capability shifts from a
basis of producers building things with user-owned assets to a basis of providers enabling things
with user-defined behaviors.
Assembling behavior modules for their co-operation means that they must be coordinated. The
coordination is aimed at all modules supporting the same designated function requested by
demand. Orchestrating the behaviors is a sophisticated mode of coordination that addresses the
diversity and variability of requirements imposed by demand on the modules. The resulting
coordination is called a configuration.
22. Defining Capability Modules: Actors
Functions exist at all scales and scopes
of responsibility.
To execute a function, operators within
the boundary of the function perform
actions in a specified role within a
production.
Operators can be solo, integrated,
chained, bundled, or sequenced in
order to have them generate production
progress through a coordination of their
responsibilities.
A defined operator, when included by a
function, is an actor.
Actors exist at all scales and
complexities of form, as necessary to
retain singular accountability for a
defined influence recognized as an
effect.
The effective influence is the value of
the actor to the function.
Small/simple
large/simple
Medium/complex
Medium/simple
large/complex
Medium/complex
23. Producing Actors (functional operators)
Actors in a role are created through a combination of:
Character definition (conception)
Training and support (development)
Casting and Rehearsal (testing)
Direction (monitoring, evaluation and adjustment)
As a result, we can say that the behavior supplied by the role has been engineered, where all
aspects from the “expectation” to the “reality” are being managed to have a particular outcome.
Successfully creating needed actors generates the availability of production capability, through role
performance.
One actor can perform several roles.
One role can be performed by several actors.
One actor can interact distinctively with several other actors.
Capability is the existing potential for an intended performance, which is expressed in operation.
The on-demand delivery of effects to known users is the target function of production.