Tag: Business Value of IT

Incident Management Demystified

INCIDENTALLY SPEAKING

Due to the easy recognition that a service offers a modular approach to assembling supporting facilities for operations at any scale, the concept of “services” is a hot topic at many levels of organizational production. In turn, that makes the experience o using services a top priority in the consideration of operational and production performance.

This leads to a quick appreciation of why difficulties in service utilization become so prominent in an organization: services in effect become the “API” that is provided to the workforce for exploiting industrial-grade support of their efforts — in particular, the support provided by any enabling automation technology.

Since worker operations power the progress of maintenance, change and exploration, any expectation of competitively advancing rests on how well workers can leverage their resource. Thus, Performance is inhibited by interruptions of that leverage, which means that performance is also constrained by the capability to manage incidents.

Inspired by that prominence, the topic of incident management stays in the foreground alongside most other considerations of competitive advantage. However, even though the above understanding is commonplace, somehow the matter of how to define, track and handle incidents falls into debate.

We think this ambiguity starts at the level on which organizations demand accountability, which in turn subjects the issue to any preferences or habits of sub-organizations given responsibility along with the accountability. Many of these preferences and habits are institutionalized in local terminology, which brings up the need for a frame of reference that allows different specializations to identify when one of them is actually talking about the same thing or working on the same thing as is another one.

A SINGULAR CLARIFICATION

One hugely important observation is that an incident is largely psycho-logical. Unlike an mere unspecified difficulty which could simply be tolerated, it has to be noticed in order to be managed (accounted for), and it has to be defined in order to be noticed.

In general, an “incident” is:

  • a detected significant departure from …
  • a condition of an activity, …
  • where that condition was defined by the expectations of a known intent.

Yet, while detection is, by definition, always involved, reporting the detection is not. There can be a very significant difference between the presence of incidents and awareness of the incidents by any parties other than the immediate directly affected party.

In general, the management distinction of “an incident” has value in terms of the prevention of an incident and/or the response to the incident.

Prevention demands a clear view of the environmental dynamics that allow or cultivate activity without incidents. Options are mainly in the design, distribution, and prerequisites of the contact between workers and their various resources.

Response requires understanding, weighing and prioritizing relevant options to regain (resolve) a systemic stability in the interactions that accompany normal uninterrupted effectiveness.  Options are:

  • Circumstantial – a recovery of superficial user progress for the moment
  • Relational – a restoration of prescribed reliability on an underlying dependency
  • Fundamental — a re-engineering of the intended permanent infrastructure

Different parties should be able to map their existing roles and scope of authority to the design/distribution/prerequisites of prevention, or likewise to the recovery/restoration/re-engineering of response.

A COMMON-SENSE STANDARDIZATION

To assure that there is a commonality of perspective across those multiple points of view, we go to the fact that the operational environment discovered and exploited by workers is to some degree found ad hoc (which creates opportunities), and to some degree commissioned by design (which creates expectations). We also recognize that the environment at hand is typically far more extensive than any worker’s practical familiarity with it. Consequently, there is a degree of uncertainty about what will occur, while there is a degree of prescription about what should occur. This is the normal condition in which incidents are found.

The following lays out a common-sense understanding of how to recognize incidents and approach them from both the proactive and responsive standpoints, simultaneously. That kind of recognition allows the organization to be working on the environment continually with the ability to systematically compare intents to actuals in a closed loop of service production, deployment and service feedback. In this view, any whole or part of a service is a logical item to be addressed, since a service may itself be composed of other services, and the exposure of any service may be specifically significant at the whole or component level.

This version of the framework predicts the possibility of 49 generic types of incidents, completely without any binding reference to a particular organizational entity or infrastructure. Example: From one moment to the next, the likelihood of an “access error” may be greater or lesser than an “output omission”, but standard guidance predicts that both can occur depending on prevention and response.

Incident Definitions Framework

 


The Tao of “New”

“New” changes. Newness doesn’t.

Back in April of 2007, Optimize Magazine ran an article by M.S. Krishnan titled Moving Beyond Alignment. Its summary: strategic business innovation requires a flexible infrastructure so that the company can utilize the business models needed to achieve goals. Thus IT governance and architecture must enable the enterprise to “synchronize with changes in the business environment”.

Meanwhile, scheduled for late 2010, the book from strategic technology architects Greg Suddreth and Whynde Melaragno called The Path to Real Business Transformation discusses “dynamic synchronization… a rigorous, business-case-driven collaboration between the business-process owners and their IT counterparts.” For this, the framework of problem-solving is what they call business architecture.

“Innovation” always has an aura that suggests the big moment of arrival of the new. But getting to utilize the new is the only way that value is derived from innovation, and utilization requires integration into, and synchronization of,  the operational scheme of things. This emphasis on synchronization firmly declares that the problem of follow-through on business strategy is fundamentally about coordinating the moving parts.

Anyone who has tried to manually shift gears in a moving vehicle knows that synchronization has two operator-controlled aspects: time spent in the gear, and timing of gear changes. In a competitive context, where time and timing are pre-planned and managed for variances and circumstantial adjustments, this plan is even seen as a strategy itself. The performance level of the plan’s execution, especially in complex or volatile environments, is then most often seen as “agility”. Achieving agility is, for that reason, a common business objective related to scoring business goals.

Suddreth and Melaragno further state that “business architecture” is developed through a process that defines and institutes long-term change within a framework of strategy (for example of goals, related positions and directions), planning (for example, of resources), and execution (for example, of services). They go on to point out that multiple business areas must be complementary in the context of solving a defined business problem.

To assure proper pursuit of that agreement, it becomes necessary to appreciate the difference between innovative business uses of IT versus business use of innovative IT.

  • In the former case, the emphasis is on the business-level understanding of how moving parts might be aligned in a new way.
  • In the latter, the point is to introduce moving parts that have a different set of characteristics and interactions than those typically tried before.

From the point of view of these authors, the former issue is a concern of business architecture; and the latter issue is a concern of IT architecture, in which (among other things) the business architecture is  “physicalized” according to Suddreth and Melaragno.

Given those points above, it would seem that the challenge is to prioritize business innovation, then leverage business architecture to identify and incorporate IT innovation that can be scheduled within IT architecture for a reasonable chance of sustained synchronization.