4 misconceptions about end-to-end monitoring

In many businesses, monitoring is done at the technical or application level. This provides a good insight into the performance of the individual application. However, applications are increasingly interconnected, working together to support one process. With monitoring at application level, you therefore lack insight into the operation of the chain as a whole. It remains unclear how the separate components perform together in a chain – and thus how the end user experiences the service. A good overall picture is necessary to get insight into the performance of the cooperating components.

With end to end monitoring, also known as IT chain monitoring or end user monitoring, you show clearly how the chain is actually performing as a whole. It is a holistic approach to monitoring. It is important to obtain clarity as to when, exactly, the end user is satisfied. The resulting parameters can be monitored, which means the satisfaction of the end user is also monitored.

2. “By outsourcing, I also outsource the responsibility"

Increasingly, businesses are making use of operationally critical applications hosted by major SaaS parties in the cloud. However, the fact that they are provided by major players such as Microsoft, Dropbox, Skype and Salesforce does not necessarily mean that the applications will perform satisfactorily. Despite that, many companies think that by collaborating with an external party they also pass on the responsibility for performance. That is not true; the responsibility for the IT service to be provided remains with their own IT department.

Moreover, the more components that are outsourced, the more complex the application chain becomes, which means the importance of end to end monitoring increases accordingly. With multiple suppliers or technologies in the chain, the likelihood of incidents increases and the IT chain becomes greater than the sum of its parts. If components A and B are each allowed 10% downtime and the application’s functionality depends on both components, the likelihood of downtime increases to A + B = 20%. The problem gets bigger as the number of dependencies in the chain increases. This means that it is exactly when outsourcing comes into play that your own IT department must take responsibility for the performance of the total application chain.

3. “Measurement is knowledge"

Most companies make some kind of effort towards monitoring. In practice, unfortunately, either little is done with the outcomes of the measurements, or the measurements still say nothing about the applications’ availability or performance, or they do not achieve the desired result. Opportunities are usually missed because:

• monitoring is done only at the technical level, but not from the end user’s perspective;
• monitoring is done only at application level, and is not based on the chain philosophy or the operational process;
• the measurements are not carried out independently. You often see suppliers measuring their own applications (so naturally giving them approval);
• no procedure has been established to remedy potential incidents. It’s not enough to configure software; you also have to think about training people and configuring processes;
• the measurements of various applications cannot be compared with each other because each component is monitored in a different way. As a result, consistency is lacking.

4. “The business case for end to end monitoring is difficult to make"

This is a troublesome statement, but frequently heard. It is true, monitoring costs money. But if you don’t have insight into the actual performance of the entire chain, how can you know when problems exist or are on the way? When business processes are slowing down? Or when sales are declining, or when customers are starting to complain? Then it is too late! You have to stay ahead of complaining employees, users or customers and take action before you lose them. Herein lies the business case for and added value of end to end monitoring.

Furthermore, many IT projects are still started without prior thought about non-functional requirements and KPIs. Then, when the application is found not to meet the required productivity, people try to make the best of it using ad hoc solutions. And that’s a shame, because resolving problems after they arise is much more expensive and far less efficient that preventing them from arising. It all starts with drawing up non-functional requirements. Then, during and after implementation, you can use end to end monitoring to evaluate whether the application meets these requirements.

You should therefore take a good look at the service that is provided with an IT chain, and prevent misconceptions about the usefulness of end to end monitoring.