The business impact of a failed IT asset

Few useful tools exist to show actual connectivity between operational infrastructure and business outcomes. 

Determining the relative value of various business processes is a fairly straight forward proposition:  we all can easily understand that accounts payable and receivable are more important than the database that maintains the corporate parking stickers, for example.  Because of this, we are able to move the more robust equipment and processes over to support our business-critical applications.

But what about understanding things in reverse order?  What if we want to understand which processes will be impacted if a particular asset goes offline?  In complex IT environments, this is no small challenge.

Applications that swear they place technical issues in a business context usually have a tough time proving their claim.  It’s not easy to design such products because they invariably require two entirely different knowledge sets.  How often, for instance, do you come across someone within your own organization who combines IT knowledge with savvy insight about the way your business runs?

Certainly, we now have software that achieves some connectivity between business value and IT performance, although these are certainly not common.  Nowhere are such solutions rare than when it comes to analyzing and quantifying the downstream consequences to business processes when some piece of the infrastructure fails.

Such products that have appeared (and that actually work) are very situation-specific, operational only within a select set of business outcomes and with a limited subset of your infrastructure.

A more generalized instrument is needed.

Conceptually, such a tool would be very simple.  The first piece of any such solution would have some form of monitoring capability that gathers the data associated with the infrastructure.  If we want to monitor the storage piece of the infrastructure for example, this means software that can gather SMI-S data, or data from the APIs the storage vendors provide for their products.

The customer-facing part of the solution will have hooks into the various business applications being used, and will understand the hardware dependencies of each.  Ideally, this part would have knowledge of a process’ provisioning requirements, and would be able to raise a flag if any link supporting the process were ever threatened.

Between these two pieces is a black box that ties the two ends together.

The first piece already exists in the form of monitoring applications from a number of storage vendors.  Several system vendors and networking companies also provide such data, most typically via CIM or SNMP.  It is the middle piece, the “black box,” that is lacking.

More on this next time.