Managing Configurations of IT for Services

11 Aggressive Ideas About Getting Back In Control

An archestra notebook.

© 2013 Malcolm Ryder / archestra

Time to completely rethink the CMS/CMDB

• Start “re-thinking” by revisiting vocabulary. The vocabulary of configurations is a vocabulary about an architecture, not about assets.

• As a prerequisite, understand and stay with the following concepts:• Logical means “distinguished by role definition”• Physical means “ distinguished by tangible form”• Virtual means “just as if”• Entity means “a specific type of a logical or physical item”• Component means “a logical part of a logical construction, or a physical part of a physical

construction”• Element means “ a smallest independent ingredient, of any type, of a defined multipart

structure”• Configuration means “specific arrangement of specific elements of a specific construction”

• Do not confuse the terms with each other, and do not use them as synonyms for each other. Maintain that semantic discipline while revisiting the following vocabulary.

Rebuild the Configuration Management Vocabulary

• First set of terms are purely entities: completely avoid any terms that are not defined items that can be version-controlled, or that do not define an item’s characteristics (actually inherent property, or virtually permanent attribute)

• Second set of terms are purely conditions: completely avoid any terms that do not define a state (which is not the same as a status)

• Third set of terms are purely scenarios: completely avoid any terms that do not distinguish a responsibility in a purely logical way.

• Fourth set of terms are purely functions: completely avoid any terms that do not distinguish an affect (an influence of a behavior) in a purely logical way.

• Fifth set of terms are purely circumstances: completely avoid any terms that do not distinguish an instantiation (i.e., time, place, assignment)

• Now you can make an assertion:

<Entity with characteristics> having <state> in <responsibility> is capable of <affects> at <instantiation>

The CMDB is not necessarily the CMS

• Now you can make an assertion:

<Entity with characteristics> having <state> in <responsibility> is capable of <affects> at <instantiation>• Every term in brackets can be decomposed.• Every term in brackets is a variable.

• Note that the assertion can be a hypothesis, a prescription, or a confirmed finding. Never confuse the three things.

• At the assertion level, Designers and Builders hypothesize; Managers prescribe; and Analysts confirm. Those are three different things to manage; never confuse them.

• The CMS (management system) is concerned with the whole assertion

• Any given CMDB (management database) is concerned with at least one of the variables in the assertion.

• Any database that has an acceptable volume of data about the variable can be a CMDB for the CMS.

Configuration management is not about “the operational relationships of assets”• All items are not assets. Only some items are.

• All items are not configuration items. Only some items are.

• All “configuration” items are elements.

• All configuration items (“CIs”) are logical; some CIs are assets.

• Managing “a configuration” is about managing the relationship of the prescribed configuration to the actual configuration.

• Configuration management proactively addresses the real-time probability that the relationship of the prescribed configuration to the actual configuration is within designated tolerances.

• Tolerances are used to manage behavior through governance; configuration management supports governance.

• The tolerances are established FOR the assertion:

<Entity with characteristics> having <state> in <responsibility> is capable of <affects> at <instantiation>

• As a result, priorities about the tolerances can be expressed as rules, and rules can drive tests that call on CMDBs to report on the variables in the assertion.

Forget ITIL and your Vendor. First think ITSM, and where a manageable service comes from.

• An operation is a runtime behavior of an item, where the behavior can be activated and the behavior is regular.

• A service is the role that an operation plays by making the operation’s affects available on demand from a user that is not responsible for providing instances of, nor access to, the operation.

• Theoretically, therefore, any scale of operation of any size item can be a service.

• There is no such thing as a service without an underlying operation. But there are many operations that are not services.

• An item of type “application” is usually a configuration of elements allowing a construction of software to be an operation for a designated purpose. To make the operation predictable, the design of the configuration is based on a system.

• A system is a set of functional interrelationships in a pattern that prescribes responsibilities to a designated purpose.

• An IT system can consist of any combination of software and hardware.

IT services are just one dimension of business infrastructure and one view of IT itself

• Managing a system means directing the compliance of the system’s behaviors to the pattern prescribed for its responsibilities.

• Managing an operation means directing the deployment and regularity of the operation’s activity.

• Managing a service means directing the occurrence of a service according to the requirements of Demand.• Based on the requirements of Demand, occurrence can include any stage of the

birth-to-death lifecycle of a service, at all points during the lifespan of the service.

• A service-oriented perspective on management generates the following:• Logically, demand requirements can change without changing the service; • a service can be changed without changing the operation; • an operation can be changed without changing the system.

Service mapping and service modeling provide definition for the views of IT

• A map and a model may be complementary; they are not synonyms.• Map means to diagram a bounded environment of activity, to convey that the activity is

affected by the location of selected entities in the diagram• Model means to diagram an intended combination of elements, to convey that particular

interactions of the elements will probably result from the structure of the combination

• Dependency, criticality, and impact are all variables; under management efforts, they are meaningful in certain ways. They are not synonyms.• Dependency means a state required for a designated responsibility• Criticality means a prerequisite intended for a designated interaction• Impact means a verifiable affect as associated with a designated effect

• An <impact> may rely on a <criticality> that is sustained by a <dependency>

• A model can help explain why a service can perform in an environment that can be mapped.

Transparency via Clarifications

• Transparency means removing what obscures a clear view. Because of information overload, “less can be more”…

• Simple: can be good if…• Less detail improves recognition in context

• Otherwise, can mis-inform

• Elegant: can be good if…• Less complexity improves strength of logic

• Otherwise, can fail to explain

• Optimal: can be good if…• Less range of choice improves acceptance

• Otherwise, can risk being myopic

Transparency versus Information Overload

• Problem: information about IT routinely overwhelms realistic opportunities for analysis, and it may not clearly distinguish what is being analyzed• Configuration management addresses service integrity

• service levels are addressed by performance management

• Problem: IT deployment is increasingly heterogeneous and dynamically (not statically) formal • Service reporting (actual deployment @ experience) is like weather reporting

• Service planning (prescribed deployment for experience) is like forecasting

• Strategy: start thinking about a Big Data solution

• Strategy: define demand before defining services and CIs

Assumptions for modeling

• An item is always logically defined; the item may be simple or compound, and may be large or small.

• Any item that can be activated as an operation can possibly be offered as a service.

• An item that can be offered as a service may be used by some other service.

• Every service will request that an operation fulfills a role.

• An operational item performing a role is always a logical item and may also be a physical item or a virtual item; the physical or virtual form is packaging that dictates how the item can be administered.

• However, the properties and attributes of an item are meaningful to a service if they are required for assuring the integrity of the service; therefore, the important properties and attributes are the ones that enable the role to be executed “correctly” on (managed) demand.

The Who Cares TestView of Service

MAP vs. Demand MODEL vs. Demand Configuration Assumption

(Environmental presence) (Functional behavior) (Enabled validations)

PLAN Set policy for acquisition and for access

Designs per patterns of request and of change

<Entity with characteristics> having <state> in <responsibility> is capable of <affects> at <instantiation>

REPORT Portfolio status and catalog provisioning

Versioning and categorization

An <impact> may rely on a <criticality> that is sustained by a <dependency>

DIAGNOSE Operational events by logical location

Standards vs. Changes Decisive interactions occur within rules-based tolerances

The importance of the concept of “services” is based in the reason for having a service-oriented view. The reason is “business demand for IT”. Choosing IT to get things done means choosing how it should behave and how to get it in place for use. The “service” directly associates the composition and distribution of IT to demand, creating a particular way to recognize whether IT is having its actual affect on the company in the desired way. Different audiences require different views, but all views must be reconciled.

© 2

01

3 M

alcolm

Ryd

er / archestra