The Radical Semantics ofManaging Configurations

An archestra notebook

© 2014 Malcolm Ryder / archestra research

Assumptions

• When something is built to a design, we should be able to evaluate it in terms of the design's intentions.

• That design should include behaviors.

• Since the behaviors become impacts, and the impacts become qualities of service, successfully managing a service has dependencies on acknowledging its design.

• A design explains what kind of behaviors are attributable to (and expected from) what kind of conditions and what kind of parts.

Who Cares

• We can trace increasing disillusionment with the viability of configuration management back to two things: • mangled CMDBs• unresolved battles between information modelers or between management systems

• Contention and confusion becomes typical due to mismatched and misunderstood information.

• The following discussion is an argument for a certain type of common ground, based on a simplified semantic representation of how management cares about an item.

• In the argument, there is a stipulation: if we don’t need an item then we don’tcare about it, and if we do need an item then we need it in a certain way.

How to use this discussion

Note: This discussion requires thinking abstractly.

• STEP 1: ignore the vocabulary you currently use

• STEP 2: do not replace terms provided in the discussion with “substitutes” or “synonyms” from outside of the discussion

• STEP 3: Use the terms provided in the discussion to go label things you already know and to imagine organizing those things per this discussion’s provided terms.

• STEP 4: Assess whether the results are easier to understand by mixed audiences, compared to what you had before.

What are “items”

• An item is anything that is distinguished as a single instance of something that can be provided, counted, added, moved, or removed.

• The entirety of this discussion is about items.

• Any item has a form and a presence.

• There are two kinds of form: Logical and Physical (=As Is)

• There are two kinds of presence: Virtual and Actual (=As If)

• There are four kinds of items. Each kind is a combination of the form (“As Is”) of something and the presence (“As If”) of something.

The semantics of Item Types

• FORM (=As Is)• Logical is based on Definition – a fixed selection, that we made, of properties

• Physical is based on Properties – a detectable set of inherent (not attributed) characteristics

• Using a café (physical) as an office (logical) is not unusual.

• PRESENCE (=As If)• Virtual is based on “the Required” – a state recognized based on a need

• Actual is based on “the Absolute” – a state occurring regardless of need

• A hardback novel (actual) acting as a doorstop (virtual) is not unusual.

DEFINITION

PROPERTIES

(AS IF)

(AS IS)

PRESENCE

FORM

ABSOLUTE

DEVICE

MATERIAL

REQUIRED

ROLE

COMPONENT

Mapping the relationships of form to presence gives this simple, unchanging

framework that groups all “items” consistently into

four generic types.

© 2

01

4 M

alcolm

Ryd

er / archestra

research

ACTUAL

LOGICAL

PHYSICAL

(AS IF)

(AS IS)

DEVICE

MATERIAL

PRESENCE

FORM

VIRTUAL

ROLE

COMPONENT

As If/ As Is: Hierarchy• Virtual/Logical• Actual/Logical• Virtual/Physical• Actual/Physical

Item Type: Hierarchy• ROLE• DEVICE• COMPONENT• MATERIAL

© 2

01

4 M

alcolm

Ryd

er / archestra

research

ACTUAL

LOGICAL

PHYSICAL

(AS IF)

(AS IS)

DEVICE

MATERIAL

PRESENCE

FORM

VIRTUAL

ROLE

COMPONENT

Managing Items: Why?A Role is used for a Purpose

A Device is used to do a DeliveryA Component is used for a Function

A Material is used as a Resource

© 2

01

4 M

alcolm

Ryd

er / archestra

research

ACTUAL

LOGICAL

PHYSICAL

(AS IF)

(AS IS)

DEVICE

MATERIAL

PRESENCE

FORM

VIRTUAL

ROLE

COMPONENT

e.g. SYSTEM

e.g. OBJECT

e.g. SERVICE

e.g. TOOL

© 2

01

4 M

alcolm

Ryd

er / archestra

research

Form/Presence: Hierarchy• Virtual/Logical• Actual/Logical• Virtual/Physical• Actual/Physical

Item Use: Hierarchy• ROLE• DEVICE• COMPONENT• MATERIAL

Managing Items:Role for a PurposeDevice to do a DeliveryComponent for a FunctionMaterial as a Resource

Item Instance example:• SERVICE• SYSTEM• TOOL• OBJECT

Item Instance:• SOLUTION• CAPABILITY• APPLICATION• SOURCE CODE

Item Instance:• UTILITY• FACILITY• PLATFORM• ELEMENT

Item Instance:• SERVICE• SYSTEM• TOOL• OBJECT

These are GENERIC terms These are IMPACT VALUE issues These are ABSTRACTIONS

PurposeDeliveryFunctionResource

performs asenablesconstitutes

This is the TAXONOMY

examples examples examples

© 2014 Malcolm Ryder / archestra research

Semantic Classification

• The semantics of item types has only one objective: to provide identification directly related to the value of an item’s impact on a need.

• Any given instance of a given type of item is distinguished and tracked for the same reason as all other instances of that item type: its intended impact value.

• Any type of item can be produced from instances of a variety of different subordinate types. For example, different kinds of tools can produce the same kind of system.

• There is no compelling reason to track an item without reference to its identified type. Different types are not meaningfully “synonymous” with each other and cannot substitute for each other. For example, the only way a tool can be a service is to fully qualify in service terms regardless of what it presents as a tool.

Items in Configurations

• A “configuration” is simply an arrangement of parts that is established for a known purpose. By definition, a configuration is intentional.

• An Item Model can prescribe a desired configuration of that item type.

• Any type of item can itself be a configuration of subordinate types of items.

Instance and Scale of an Item Type• A given unit of a type of item can be a simple instance or a compound

instance. A compound instance is one in which multiple single instances are intentionally co-operative or integrated as a “single” form and single presence, with no intent to be independent of each other.

• An item type hierarchy makes sense of an item at a given operational scale.For example, in one scale of operation, an item may be a “service”. That same item might only be a “tool” in a larger scale of operation.

Smaller Scale X, e.g. training in company education

Larger Scale Y, e.g. competencyin industrial competition

© 2014 Malcolm Ryder / archestra research

Managed Configurations• The only reason to use the term “configuration item” is to signify a status of a

management responsibility for an item, meaning in this case that:

the arrangement of the parts constituting

the item in deployment

is an intentional arrangement

meant to be sustained

at the designated level and scale of the type of the item.

• Only some entities qualify for that status at any given time.

• The reason to manage item configurations is to support the purpose of the arrangement (the type), not to support the item.

© 2014 Malcolm Ryder / archestra research

mryder@malcolmryder.com