The evolution of technical monitoring is occurring as we speak. The underlying tools for processing, communication and nearly everything we do in today’s world is tied to some sort of technology. 10+ years ago, developers and vendors would create technical solutions based on what they knew within their experiences and companies would spend significant effort to reform their business processes to that solution. As we all know, the square peg never fits into the round hole. Over the last decade things have really started to change. Hardware vendors now spend a significant amount of time working with businesses to understand their situation and build out the correct solution. Developers now spend more time with business units and power users then they ever have. The sales cycle is now focused on Line of Business (LOB) decision makers instead of the product or solution support management team. Extensive care and support of the business unit is taken into consideration during implementation and long-term product & service support is then further watched closely by management. But as this evolution occurred, one group has been pushed further and further away. The internal infrastructure and technical support team has been left in the dust.
Somewhere during implementation the technical team probably setup some sort of monitoring. A team of individuals have been identified to react and respond to triggered alerts. Capacity and trending reports have been identified and are closely being watched. And should there be any cloud vendors or solution providers, SLAs have been signed and are being monitored. This is all great and necessary to keep the business unit humming along. But who has the overall picture? Who knows all the ‘ins and outs’ of the solution? Is there ever one person who knows all integration points, the full network path, or what server the database is riding on? Running on a cloud doesn’t solve the solution either. There is a path of critical technical divisions between the cloud solution and the end user’s fingertips. Rarely is there one individual who can connect all the dots from the end user application level all the way to the nuts and bolts of the hardware. Even in those rare circumstances that there is, it’s just one individual – that one single point of failure.
Today’s new age level of monitoring is moving towards Business Service Management (BSM) monitoring. This takes technical monitoring to a whole new level. Building on top of the current hardware and application level monitoring, BSM based monitoring takes every critical segment along that business process into consideration. The lowest levels of network and hardware architecture up through any processes written into the application are closely monitored.
Let’s run through an example. Phil works at ABC Corporation and is in charge of printing checks. Every time Phil runs checks, something seems to break. He starts his troubleshooting by looking to see if the printer is turned on, there is paper in the printer and makes sure the network cable is plugged in. He may walk back to his desk to make sure he properly ran the application. If at that point he can’t figure it out, he notifies the application support team. They’ll investigate and should they not be able to find anything they’ll notify the database team who will eventually pull in the infrastructure team. In a true BSM monitoring solution, Phil contacts his helpdesk friend, Carol, who looks at the BSM monitoring tool. The full BSM overview stack and every component from the network architecture, hardware, O.S., Database, application and processes are shown. Very clearly Carol can see that the network switch port is flashing red and is the obvious problem. Within seconds Carol and Phil know what the issue is, who to contact and can create a support ticket.
As more and more companies begin to adapt the BSM monitoring methodology, we begin to see a happier workforce. Clearly identifying where the problem resides results in faster issue ownership from the responsible parties. It also equates to less ‘hands in the pot’ during troubleshooting during a major outage. These ‘scramble fixes’ often lead to processes and procedures being ignored and unnecessary changes being made that result in future issues down the line. Less interaction from fewer people means easier troubleshooting, better response time, faster resolution, and overall less headaches. And everyone needs less headaches in today’s world.
See how Symmetry addresses these needs with our AppView monitoring tool.