« People, Process and Technology | Main | Business Process Management and Organizational Architecture: a performance ecology »

May 25, 2005

Data, Dictionaries, and Organizational Performance Alignment

Engineering is often where we find crisp statements of problems and solution-approaches that are already pretty far along but may not have found their way to routine use in a more general population of managers.

An example of this is from a BMC Corporation technical whitepaper that stated the following: Nowadays each IT infrastructure component has its own language or dialect when communicating with the outside world. This makes it extremely difficult to derive and understand the impact certain events or combinations of events have on the business. BMC is, shall we say, very much "on the case" in creating a system for more uniform identification of components-in-deployment.

Not coincidentally, this same type of problem is cited quite explicitly by at least two other sources of tremendous import to performance management -- the Zachman Framework (for enterprise architecture) and the IT Infrastructure Library a.k.a. ITIL (for IT service management). Both Zachman and ITIL go on to provide a logical framework of how the semantics and syntax of an organization allow efficient and effective construction of complex functional products.

The online Wiktionary offers the following explanations:
Semantics - the science of the meaning of "words"...
Syntax - A set of rules that govern how "words" are combined to form "phrases" and "sentences" ...

These definitions literally look at communications as a construction process, with the quality of the output being at stake. But what Zachman, ITIL and other development aides take from that is a way of looking at construction as a communications process.

Why is this meaningful instead of just a handy twist of phrase?

Performance Legos

First, items like words, sentences, etc. all point to "information", which we use as a construction material in the business.

Second, when complex constructions require that "components" are developed and integrated to make higher-level "subsystems", then the functional compatibility of the components becomes the primary goal of managing their development and provision.

Altogether, that throws focus on how information itself is developed, and thus on how that information development effort is managed.

The objective of that management effort is to assure that the quality of the construction process minimizes the risk that its "product" will fail to meet its requirements. The development process must create components that support the construction process.

For business purposes, the management effort for information has at least two major issues:
- how does the information have meaning (semantics), and
- how are the meanings combined for practical use (syntax)?

What makes information usage practical?

First, "information" is itself a component of the business because it is used to create, for example, "processes" and/or "workflow" -- in other words, subsystems of the business.

Second, "business" information describes the characteristics of the business itself. Successful identification of a business entity, condition or characteristic is fundamental to the point of the info's usage.

Practically speaking, the information is usable only when the user understands the information's way of providing identification. The semantics always come first. The biggest challenge in transporting information across a progression of different users is the risk of the semantics being lost along the way. This is not a matter of "what" something means but instead a problem of "how" it comes to mean what it is supposed to mean.

Here, Wiktionary again is convenient. It offers the following:

Protocol - A rule which guides how an activity should be performed.
Context - the circumstances or settings which determine, specify, or clarify the meaning of an event.

Interestingly, this suggests that business terminology probably should be managed as a thesaurus, and that business information should primarily be managed as terms of requirements and agreement (i.e., specifications).

Construction quality as a performance factor

Communications protocol comes to the foreground as the mechanism by which the business constructs its understanding of where it is and how it is doing.
- Protocol represents the quality requirements issued to those activities that construct and convey meaning across the enterprise.
- The organization uses those meanings to determine and drive performance.
- The mechanism for utilization is the problem that the organization (and solution providers) must solve.

Decision support as an organizational constructor

Let's go back to the original issue at hand, which is to "derive and understand the impact certain events or combinations of events have on the business."

Decisions shouldn't be made without having that understanding in hand. But naturally, recognizing events must precede any determination of their impact.

Of course, decisions don't just make themselves. The organization makes decisions -- including the ones that change the organization. So we have two additional things to consider here.

First, from the vast universe of business data, what are the essential classes of information to derive -- for example, "entities", "events", "impacts", and so forth... And second, to what extent does our idea of "the organization" rely on demonstrated usage of this information instead of on prefabricated boundaries (silos) of data ownership and custodianship?

Does the organization define itself by the way it actually uses information, or instead by what it thinks it should "know"?

The emerging consensus is that what distinguishes high-performance businesses from lesser ones is their smarts in the midst of environmental change; but therefore, information usage must drive the business and the "organization" should conform to the necessity of making information useful. This spawns a couple of giant trends in organizational management: standardization of operating language and automation of decision support -- or put differently, vocabulary and analytics.

Together, the two trends do nothing less than attempt to reconstruct the organization.

The off-hand expectation would be that a standardized vocabulary should make analysis easier, since the terms in the analyses wuold be more efficiently validated and transmitted. For this, we would be looking for a new and improved "dictionary".

But organizations can certainly fail faster when they try to replace the need for communication with analysis. If they had to have one without the other, communication should win every time. And dictionaries don't make communication successful: protocol does.

In what follows, we'll go through the key points of this graphic:

The use and abuse of "universal vocabularies" and "analytics"

Let's use ITIL as a case where a better single dictionary, in fact a great one, is available and necessary -- but insufficient.

Many IT organizations are attempting to implement quality improvement initiatives aimed at their service management processes. Taking ITIL as a guide, standardization of vocabulary is a strategically critical dimension of their efforts. IT organization leaders realize, both instinctively and empirically, that the standardization will be disruptive to a significant degree, as adoption of the standards must run through the current configuration and linkage of most people and systems in the IT organization. The expectation, however, is that the resulting changed organization will be leaner, faster and more powerful as a services provider.

In a recent article, Pennsylvania consultant David Pultorak, president of Fox IT, provided the following citation:
Organizations implementing ITIL saw the following benefits:
according to a 2003 itSMF survey...
- Improved customer satisfaction
- Motivated staff and increased productivity
and according to a 2002 survey by DMR...
- More consistently implemented changes
- Reduced repetitive problems
- Reduced amount of time spent "firefighting"
- Produced more business-focused metrics

These outcomes are highly worthy goals. How were they reached?

ITIL's intended impact, on the capability to manage IT services to high levels of business value, is promoted primarily through improvement in management processes. That improvement is heavily predicated on the standardized vocabulary for identifying actions, conditions and events. With ITIL, one management process can more readily understand another management process, making their interactions more dependable and predictable.

But finally, a successful "ITIL implementation" requires (and means) that the organization has adapted itself to be a suitable and healthy host for the management processes and for their integration.

Success rates with ITIL implementations might always be measured in terms of goals such as above, but ITIL implementation failures are most often discussed in terms of being overwhelmed by the difficultes of adaptation. Organizational change management discplines emphasize that adaptation should be both strategic and evolutionary, so we assume that the "successful" implementations will actually exhibit accomplishments that are both strategic and phased.

Does this mean that in successful implementations, the vocabulary standardization was incomplete at various points along the way? If we look at ITIL consultants' frequent references to capability maturity models, the answer is evidently "it depends". If "process improvement" was intermittently verified, and IT organizational performance was also measured trending up, the real situation is that the terms of measurement allowed the evaluation outcome to be positive. This suggests that a certain amount of the process vocabulary was identified for inclusion in the implementation, and that somehow it translated into business vocabulary, "completely enough" to support definitive assessments.

But how did that those assessments take place? Measurement puts vocabulary to the ultimate test. Even with ITIL's dictionary, processes can improve in quality independently of the change in their business impact. Why? Because process utilization is by choice. At first, the impact of a new process may be mainly a reflection of the degree to which the process is used effectively, regardless of its inherent quality. So if process quality does not equate to business quality, what vocabulary is universally applicable? This is the issue.

A business communications protocol

Standardized process terminology can be quite different from process information. Terminology that helps to conduct the process may describe the integrity of the process without describing the impact of the process. This is likely the terminology in a model.

Process information, on the other hand, should describe the availability and relevance of the process to participate as a component in the business operations. Standardized process information would concentrate on bringing consistency to describing availability and relevance. This kind of information might be found in a catalog or registry.

As identified earlier, business terminology, managed with a thesaurus, should allow observations to cross contexts without losing their meaning. Attaching certain perspectives to terminology, the thesaurus provides "persistence", yet not rigidity, in the ways that business operations are observed.

And finally, business information should supply the description of impacts, risks, benefits, goals, and other value judgements that distinguish the state of the business from one situation to another. The most prevalent example of this is a contract.

Deriving "business intelligence" from business communications

As shown in the graphic above, these four approaches in protocol anchor the development of certain types of communications, to which numerous business roles can subscribe without fear of confusion. Thereafter, business performance analysis mainly relies on integrating the different types of understanding derived through the protocol, not on integrating the data.

The conceptual integration of those different kinds of understanding will require models of operation and models of performance that define the chains or networks of influence expected amongst the associations of actions, events and states. But it is higher-level frameworks that provide the mechanism for identifying the actions, events and states which need to be observed in order to build the models.

Since most performance measurement analyzes compliance to existing models, the initial frameworks actually lay out the "foundations" for the business analysis as well. Business vocabulary should therefore concentrate on the frameworks, first.

Posted by Malcolm Ryder at May 25, 2005 6:03 AM

Trackback Pings

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

Comments

Post a comment