Five tests to qualify value versus commodity – #4 Alarms and Automation
In long-ago days (decades) real-time monitors for IBM® mainframes were chosen by technicians based on what they liked. Over time, technicians became comfortable with their chosen monitor and resisted any arguments for changing monitors. But as mainframes became prime targets for IT cost-cutting, management developed a held belief that “a monitor is a monitor” and essentially a commodity item, so they could select the one with the lowest price.
A strange thing has happened to this approach to mainframe monitoring: mainframe sites are learning that there are differentiations between monitors, and that the choice of the right systems management solution can have quantifiable financial and business benefits. In this series of blogs I’ll share five tests you could use to determine whether your monitor is a business value provider, or…is just a monitor. This blog shares test 4.
Alarms and Automation. As noted previously, the variability and volatility driven by digital disruption present an opportunity for a differentiated monitor to deliver business value in managing the performance of critical services. When delivering alarms, alerts and automation, such a monitor can differentiate between meaningful values and “noise”, which has become nearly impossible for a technician to accomplish at the speed of change created by digital engagement; and, it can distinguish a transient spike from a series of potentially impactful increases.
A differentiated monitor also integrates closely with automation, enabling automated responses that resolve problems before the service is impacted. Automation is also a key target for efficiency gains. Differentiated automation based on codeless rules eliminates three potential trouble spots; 1) Excessive CPU use with REXX coding; 2) On-going maintenance and the skills required to support REXX-coded automation; 3) Manual errors introduced by coding changes.
Where do you stand? So, to reiterate: is a monitor a monitor? Is mainframe monitoring a commodity? How do your monitoring tools stack up test 4, or the other tests? Is it possible you might improve availability and performance, reduce costs and make the mainframe more secure by evaluating a differentiated monitor as an alternative?