Don’t tell me CPU, tell me Business Process

business process applied to technology

There are many thousands of metrics available on all of the operating systems ever created. Some of them critical, some of them even the most ardent anorak has to look up in the help menu.

They are all easy to get to, and almost every monitoring package today has some method of displaying when they reach some threshold, exist or not, peak or trough.  Then as you move up the monitoring evolutionary chain some start to show you how the applications most of us possess are performing. They do this most commonly by doing a “best guess” via agentless technologies (I have seen X type of traffic over Y port, therefore its application X that is running).

In reality though, IT has progressed far beyond the enclave that these tools support. CRM alone may encompass your Sales, Purchasing, Logistics, Marketing, and C level teams main source of information.

Wealth management companies, Aerospace, Engineering, Telecoms, Banking, Manufacturing and so on. They all have applications that typically have the usual suspect applications supporting them but these are a component of, rather than the solution itself.

Also the tasks these applications support very often are precisely the exact thing your company does, without them you effectively cease to exist, worse still your “company” ceases to function in the eyes of your customer.

This very fact renders how your CPU is performing more or less superfluous, tools that only tell you how your “marquee” applications are no longer fit for purpose.  These things are details for the techie universe or at best one cog in the machine.

To understand how your business processes are being delivered and experienced by your teams and their customers must now be the goal of monitoring solutions. To understand the most bespoke application and the role it plays in your service delivery. To be able to grasp the relationship between the myriad components and assets that comprise the thing your company actually does. This renders even the most complete collector and display of “metrics” redundant.

Monitoring now, must grasp the bespoke, easily without weeks of coding. Monitoring must understand the relationships between the vast array of data your systems can produce, understand the relationship between these things and your physical assets. It must show the impact these are having to your technicians, your teams and most importantly your customer. Monitoring must inform only the correct team how to deal with, prepare for and cure the task at hand, better still if it automates the solution.

Also in large multi-team environments, working out who owns the problem before you fix it is a game played in meeting rooms all over when the serious stuff happens. Your solution should know for whom the bell tolls.

Monitoring must “see” everything and not only tell only the important information to your teams but interpret for them its role within a service and prioritise that problem. Then it must tell this problem in a way that the audience receiving it understands. Why tell your CEO the Rpclocator service is down, he wants to know his customers can no longer trade online.

They may be the same problem.

As the title of this piece implies, IT has evolved from the days when it spoke only to itself. Your monitoring solutions have now reached this point as well.

GDPR

  • Cookies

Cookies

This website and our partners use cookies to provide you with the best experience. By clicking, “Accept” or continuing to browse, you agree to the use of cookies. Read our privacy policy here.