Category: Architecture

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

 


Managing Assets in a Free-Wheeling World

Trillion-dollar dotcoms get trillion-ized by not carrying inventory. Wall Street creates “products” by packaging things that were NOT provided (payments due).  Employees bring their own devices. Lines-Of-Business grab what they want from the external Everything-As-A-Service buffet. And obsession with innovation, fueling the pace of change, makes almost anything in hand at risk of being “obsoleted” far sooner than was ever projected.

Story after story, being in charge of Stuff is an authority that has fallen on hard times.

Or not… A division of Needs has simply taken over from a division of Belongings, and the solutions to Needs are more clearly and vigorously attached to how things are obtained instead of what things are already in hand. It’s a natural evolution, allowed more speed and prominence by technology having finally gotten us past institutionalized scarcity.

It doesn’t mean, however, that assets have just gone away. It does mean that Resourcing is the big issue, and that managing assets is a requirement of resourcing. Resources are assets that have been given an operational assignment. Resources are derived from assets.

This takes place in three interesting scenarios, summarized in the chart here, and detailed in the document linked below it.

Managing Derived Resources

For a full description of why and how resourcing is the lead POV on asset management, see Assets as Resources in the Next Normal.

The provided logic, and the objectives of resourcing, explains how assets apply to innovation, XaaS, collaboration, “freemiums”, services, and many of the other defaults that have collectively and concurrently become “the next normal” of production.


Digitized Production Service Solutions

Some companies are literally in the business of engineering IT infrastructures and managing the exposure of the company operations to those infrastructures.

For them, ITSM is part of a strategy to protect the value of providing IT to the business operations.

But from the demand side of things, credible providers are increasingly non-proprietary to the company. Meanwhile, the production value of IT utilization simply outweighs the impact on the Providers of doing the providing.

For companies not operated directly to engineer IT infrastructures, services still align IT to usability. The concept of a service and the agreement that defines service availability remains instrumental to making IT a part of business capacity.

But business seeks to align services to productivity. The point is that productivity dictates the requirements of capacity — instead of capacity dictating the potential value of availability.

 

SERVICES VERSUS DEMAND

Actual demand for service is linked closely to production requirements.

The value of production is far more sensitive to (a.) exposure to complexity and (b.) unreconciled scheduling. From the demand-side point of view, the primary assumption is that engineering creates an environment in which there can be reliable standing conditions supporting the opportunity to deliberately generate desired real-time outcomes. But, the on-demand world is emerging under management as a compilation of innovation, mobility, A.I., predictive analytics, dev/ops, lean, virtualization, and broadband. Meanwhile, the influence of competition, economies and cultures now more frequently causes changes in requirements. Consequently, use of services must be more flexible.  This means that the specific pathways and requirements of production may not be predefined and may need to be detected and composed “on the fly” with easily tolerable risk. Systems must continually or even suddenly generate processing that is immediately available to business operators.

Production Services Digitization

 

MANAGEMENT FOR BUSINESS

Demand-based strategic management of the production environment can be viewed thematically.

The management themes put an explicit emphasis on recognizing systemic conditions that promote immediate and adequate throughput of technology power, at low risk of misalignment to work objectives. The key themes ( in gray below) address the throughput constraints of on-demand production including target outputs, adaptability, governance, optimization and standards. They expect that management, services and needs are always negotiated in production.

Production Services Digitization2

 

Solution Providers are expected to address the elements of the model and the alignment of the elements. The elements shown in the model (such as context, knowledge or presentation) are all independently variable. But this means that the components of a solution can change asynchronously, directly affecting the complexity and integrity of the overall production system.

Elemental variability also highlights the hypothetical case of implementing full production throughput on terms other than through a single-source provider. A provider’s components offer more or less elegance and coherence to the production, and from one component to another, different providers have different levels of achievement in that regard.

In turn, that highlights the true importance of current-state digitization in IT.

 

DIGITIZATION

Digitization primarily means two things: one, the difficulty of engineering functional objects is greatly reduced; and two, the practical access to any implemented functionality is greatly increased. Digitization gives the same benefit to multiple sources, making each of the sources more likely useful to a given customer.

As a result, business requirements, for rationally maximizing the utilization of automation technology to exploit information, can be more generically defined by the customer aside from particular sources.

Said differently, essential business-relevant information uses such as explanation, instruction, communication and recording can be more readily modeled with a simpler architectural level of logic. In turn, the implementation of that logic in action can proceed in a faster time frame and with more assurance of operational stability.

Production Services Digitization3

 

THROUGHPUT DESIGN GLOSSARY

The business version of the production throughput model applies strategic goals (productivity, provision, management) to the production conditions, not just to the production outputs. It also applies goals (convenient, dynamic, integrated) to the runtime experience of the production.

In that demand oriented framing, the model broadly solicits the pertinent elements of a desired production solution. For example, catalogs and  location-triggered alerts both address service awareness. Collaboration functions and publishing both address knowledge. Discovery and mapping both address surveillance. Rules address interpretation; versions address referencing; and user interfaces address workflow.

More of the logic: demand-based management views on systems involve solution features that are automated and integrated specifically to apply to supporting production’s enablement with IT.

  • Presentation: consistent recognition and display of symptomatic evidence
  • Interpretation: formulaic or heuristic semantics and analyses
  • Referencing: policies, standards and specifications
  • Surveillance: real-time detection and exploration of states

Those assignments are part of the model’s persistent logic, while allowing both current and future components to apply.


The Design of Services

We intuitively understand that services allow us to have or do things that we don’t make or perform for ourselves. In theory, the best case scenario is that available services are tightly aligned to both our desires and our expectations. That brings in a variety of stakeholders who can create, use, and assure things heading in the right direction. But expressing what is needed, and how, to achieve the best scenario is often too imprecise and confusing to adequately work out, complete, and sustain or remodel against current and future circumstances.

The Archestra framework of service design parameters is an evolving artifact. Shown here is the framework as of May 2015.

The framework is an instrument for consistently identifying variable factors by which a service is obtainable and evident across its varying states of relevance (what service is the “right” one) and worth (what is the “upside” of the service). A single service may be “identified” through a variety of descriptive points of view; the framework contains them within a logical system of cross-references. Note (again) that the whole framework is used to refer to any single given service.

Service Design Parameters 2015

Goals of the framework:

  • Simple, explicit overall perspective
  • Uniformly global and pragmatic
  • Equally synthetic and diagnostic
  • Based on observable practices and events

 

  • No logical redundancies or contradictions
  • No reliance on a specific industry, business, process or technology vocabulary
  • No need for synonyms

 

  • Completely neutral: devoid of marketing, sales and philosophy clutter
  • Entirely compatible with governance, risk and asset management
  • Agnostic to physical vs. virtual, and actual versus logical, service formats
  • The semantics work the same way across Blueprints, Inventories, CMDBs, Portfolios and Catalogs, which intentionally select and assert distinctive views

 

  • Recognizes any manageable variable that can change the service structure or service status
  • Assures that any instantiated variables (realized actuals) are fully contextualized
  • Assures that different variables are never mistaken for each other

 

  • Supports classic modeling by exposing the identification, selection, integration and coordination of instantiated variables.
  • Shows that construction and deconstruction follow the same pathway
  • Shows that absence-or-presence of service is a logical threshold in a defined context, thus enabling knowledge-driven systematic problem management, policy determination, and renovation/innovation

 


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.

 


Business Reference to ITSM

The business reference to ITSM has an overall subject matter of why the business has the services that it does, in the form and availability that they have.

The business perspective on IT Service Management is generated primarily from a demand-based point-of-view. This is because the fundamental requirement of the business Client is to use IT-based services, not to make them. In the role of service user, the top issue is to identify the key factors and flavors of business change, while the ability to obtain and leverage service is derived from the objectives of managing the services. Unless the objectives are aligned to the business factors, there is no reason to expect significant levels of benefits from the service.

The reference framework here identifies essential actions of the business that are the appropriate direct business influence on the management of the service. All of the business actions represent decisions that may retain the status quo or change it. The sensitivity to the level and scope of change is often arbitrarily limited or disorganized, creating complications between the service user and service provider. However, the default situation is that the business is the customer and is always responsive to a need for change, while the provider is always a replaceable option at some level of risk and convenience. Overall, the business needs an organized way to refer to its intent to influence the service impacts.

In general, the business has three groups of demand-side influence.

  • An environment of guidance is established. (Leadership / Strategy / Best Prractices)
  • Services and their lifecycle are built and managed. (Production / Operation)
  • The means of production are chosen and applied. (Processes / Tools)

The management of the service, from the business POV, also falls into three general areas.

  • Design service. (Transform / Plan)
  • Provide service. (Implement / Run)
  • Align service. (Optimize)

ITSM

 


Performing Innovation Under Governance

For those who manage performance, governance appears to offer a layer of security for meeting performance targets. But the scope of governance’s concern naturally exceeds the scope of production performance, representing a need to protect opportunity above and beyond performance targets. Inappropriate performance management will hold back innovation unless governance is appropriately influential on production.

Performing Innovation Under Governance

The notebook accompanying this table traces the influence on the production environment that governance brings, with regards to supporting innovation. Click here to access the notebook.