« Just what's so manageable about Knowledge Management? | Main | The Value of Being In the Know »

December 9, 2005

Complication versus Complexity: getting Business Value from ITIL

Architecture is what you bring to the party when: (a.) what you want to build requires moving parts but (b.) the diversity of parts resists effective interaction.

Some may say that this is what engineering is for. But engineering determines how the parts should work together, whereas architecture determines what kind of parts should work together.

In that light, we can see that engineering and processes spend a lot of time with each other, organizing functions; meanwhile, architecture and assets spend a lot of time together, organizing resources. Both must make strong contributions to the whole. But it's not just the intensity of their contribution that counts. A special characteristic of architecture and engineering is that they are not about reducing complexity; instead, they are about reducing complication in order to exploit complexity.

Complication features lots of parts whose relationships inhibit the coherence of the whole. Complexity features lots of parts whose relationships enable the coherence of the whole.

I.

Within "operations", co-operation of parts is necessary for the same reason that it is in buildings: a structure is asked to enable functionality that requires its parts to support each other under the varying pressure of "customer" usage and environmental conditions. In operations, it's typical to see processes and systems as component parts.

In business terms, the support-problem that architecture addresses is a balancing act: there are constraints (or restrictions) on what parts are available, yet the blend of available parts must offer a way to provide persistent support of the expected business requirements. From the business perspective, this support is the operation's functional integrity, which depends on whether the quality of its parts supports the functionality demanded from the structure. The basic idea is not hard to grasp: in general, the components of an "automobile" are well known, but you can't make a good jeep from the parts that are best for a family sedan... When you need a jeep, even a perfectly good sedan won't do.

Operations view their underlying individual processes as structural components. Bringing together the aspects of availability, persistence and effectiveness, architecture's selection criteria define and drive utilization of components that are suitable in business terms as resources for operations.

Thanks to architecture, operations assume that the underlying processes can successfully co-operate under presure. This success fosters opportunity for the business. But the mandate for cooperative processes lies not in the opportunity but rather in the needs of the business.

In IT operations, management must coordinate the provision of IT resources against business need, through measurably meeting requirements for availability, persistence and effectiveness. The provision is structured with management processes, so it is logical that an architecture would organize the processes to be used.

II.

IT's management has an architectural reference for this.

ITIL (the IT Infrastructure Library) is generally describable as:
- a framework of
- processes that are
- combined to operate
- the management of IT
- as a business.

The framework directs the identification of types of processes appropriate to the business performance of IT management.

The concept of "business performance" revolves around the complex goal of:
- maximizing benefits and minimizing risks, from...
- an optimized balance of services and costs used to...
- efficiently respond to business requirements and business demand.

The output of that effort is a virtual "product" (provision).

When business needs are prioritized, decisions to act on the priorities creates demand. Response to the demand is allowed within certain tolerances which are identified as requirements. To ensure that provision is appropriate, operations must understand and work in terms of both the requirements and the demand. But what it produces from that must furthermore align with the needs of the business.

The complexity of that performance reflects a three-dimensional view of value that the business wants to receive from the IT management effort.
- benefit/risk ratios (quality) pertain to the choices that the business has for its supporting enablement
- service/cost ratios (economy) pertain to the effective supply-level of support
- response efficiency (availability) pertains to the reliability offered to the business.

The key corresponding challenges are:
- Change (versus quality)
- Expense (versus economy)
- Speed (versus availability)

The business looks for competitive advantage in those same three challenges. Its ability to exploit them repeatedly is what sustains the business in advantageous positions. But most businesses have to consciously make all three factors work together, as experience shows that they will otherwise mutually interfere.

III.

The proactive outlook on this need is most often now described as a business pursuit of agility, productivity and regulation based on operational support. These "business success factors" become objectives for operations.

Agility balances change and speed.
Productivity balances change and expense.
Regulation balances expense and speed.

On the flip side of the coin, the protective or pre-emptive outlook can be described as the following business pursuits: resilience, capacity, and continuity. Likewise, these become objectives for operations.

Resilience is a balance of change and speed.
Capacity is a balance of change and expense.
Continuity is a balance of expense and speed.

Using these as objectives, and keeping in mind that these are descriptions of the business itself, operations drive towards "performance" that creates those significant differences to the on-demand conditions experienced by business. Those differences are the "business value."

For operations, the question is, which processes should be used to support the effort to meet those objectives?

IV.

In ITIL, a set of key management processes for the business use of IT functionality (a.k.a. "services") are identified and labelled in a very consistent way, using a standardized vocabulary that is applied across all descriptions. The vocabulary is extremely important for distinguishing the processes relative to each other, showing clearly where the various processes share and don't share specific responsibilities.

But the vocabulary is not the framework. At a higher level of distinction, ITIL separates operational provision into categories such as "delivery" of product and "support" of product. Those general responsibilities are then articulated with up to five pertinent management processes, each -- according to objectives that represent the business demand and business requirements for delivery and support.

What we want to understand is how the ITIL-identified processes address the six objectives we have outlined above:
- agility, productivity and regulation; and...
- resilience, capacity, and continuity.

The reason for this mapping is to describe the generation of business value from the ITIL-designated processes.

Our value mapping requires that we take the background concepts given for the six objectives as our main perspective. Those concepts pertained to the business challenges that indicate "success factors" to be managed in the business. Value is perceived in terms of those success factors. Management processes support the performance of operations that generate the business value.

Among those factors, agility, productivity and regulation together tell a story of the business capability to exploit circumstances.
Meanwhile, resilience, capacity, and continuity together tell a story of the business capability to bring resources to the occasion.

Both stories are about business effectiveness in the path the business chooses to execute and meet the requirements of its mission. The success factors do not pick the path, but they provide terms by which to plan and assess it. Management processes should be contributing, accordingly, to the planning and assessment.

Giving a general assessment by "stories", we have the following setup of ITIL-named processes.

Now we can reiterate a related earlier observation in more detail. The business support-problem that this architecture addresses is a balancing act: there are constraints (or restrictions) on what processes are available, yet the blend of available processes must offer a way to provide persistent support of the expected requirements.

Blended support suggests process integration, but the more essential move is to orientate the processes to the same objective. Integration is one approach, but negotiation and collaboration are also useful and might initially be more practical.

On the left side of our grid we have processes that address the aspect of agreements and permissions that effectively predefine the usual responses to demand. This impact is what is in common across agility, productivity and regulation; it answers the question, "what are my optimal response options?"

On the right side we have processes that, largely through policies and risks, define the effective characteristics and sources of the resource supply. Running in common across resilience, capacity, and continuity (as we defined them in the discussion), the key question is "what can I count on using?"

Those questions make it even more evident that the management processes must "account to the business" -- by addressing the questions in both planning and assessment.

V.

Business needs come with constraints.

Everyone always wants to satisfy needs with something that has the legendary features of being fast, cheap and pretty -- but the solution most likely obtainable by the business may fall short, while its acceptability -- its value -- is no less described in terms of demand. Managing IT for business enablement can be a "high-performance" activity only when it addresses that demand.

Returning to the discussion's initial description of value, performance reflects a three-dimensional view of value that the business wants to experience from the IT management effort.
- benefit/risk ratios (quality) pertain to the choices that the business has for its supporting enablement
- service/cost ratios (economy) pertain to the effective supply-level of support
- response efficiency (availability) pertains to the reliability offered to the business.

Every business can relate to choice, supply-level, and reliability as the dimensions for evaluating anything from assets to resources, opportunities, and partners. The business always essentially tries to determine whether it has the preferred relationship with these things, and makes changes according to its findings. Detecting and metering the dynamics of value-delivery can be exhausting and esoteric at worst, but managing things towards business value begins with understanding groupings of efforts whose interactions logically produce impacts on desired conditions.

Within the ITIL framework, management processes improve important attributes of IT services themselves, such as service availability, service configuration, or service continuity. But it is the difference made through the service utilization by the business that then counts as improved business attributes -- including business availability, business continuity, etc.

VI.

Aside from details on the internal design of management processes, ITIL provides a perspective that identifies the IT organization as a managed producer/provider with a known customer. This responsibility sets up the compelling logic of the process groupings that ITIL presents. Yet most organizations still find it difficult to prioritize and maintain their ITIL adoption strategically. The substantial difficulties of developing the individual processes to an effective state are superceded by an even bigger challenge -- lack of a model of direct systemic impact on the character of the business, which is what drives the top line instead of the bottom line.

Top-line benefit is the strongest rationale for taking on the profound risks of organizational change associated with management process reorganizations, such as ITIL. Accordingly, the most important framework for the effort is a business value framework, which should then be the basis of managing the adoption initiative as well.

Posted by Malcolm Ryder at December 9, 2005 10:37 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/183

Comments

Post a comment