Why is it that most large enterprises have invested so much into monitoring technologies, who typically have so many vendor technologies in place, still can’t see what they need, when they need to see it?
This problem isn’t new, and on the face of it, it’s probably not the most interesting topic to pick to write about, but it’s so prevalent and has such a large impact on running a successful Enterprise IT function, I think it’s worth exploring.
Top 5 Reasons Tool Overload Happens
A health warning; this is not a scientifically generated list, or even one of those annoying LinkedIn polls. It’s just a list of what we, as an independent consultancy, advising in the areas of IT Operation and Security analytics, see, all the time.
Below are the top reasons we come across for monitoring tool overload:
1. Equipment vendors shiny new monitoring toy
This is when organisations purchase new infrastructure, and with that investment there is the option to buy the vendor’s new management software offering. And this time it really is brilliant, honest.
Customers are interested as usually vendors will offer some impressive visibility features for their own equipment. The problem is, typically the feature set is not as rich for other vendors which the customer also has in their environment.
Or, the new shiny software doesn’t cover particular functionality that might not be required for the vendors’ equipment, but is for the other technology.
The upshot of this is creating a new silo to integrate. Of course, this integration is possible and sometimes a good idea, but keeping things simple is best and minimising integration requirements to the most essential is best practice.
Also, a “gotcha” warning here, where this software often seems like a good year 1 commercial decision as its bundled into the initial purchase, check out costs for year 2 and extending the coverage of the monitoring to an increased scale.
2. Not Addressing Bad Configuration of Existing Tools
When things go wrong, such as missing a critical event which results in outage, or even something less dramatic like not being able to quickly generate the reports that the business request from IT, its very easy to blame your existing monitoring tool – the tool is &^^%$!
In reality, there are some very competent monitoring technologies out there that might get bad internal press, when the problem is actually the management of the tool itself.
No monitoring platform is going to work properly if the Operational Teams do not adhere to basic governance and best practice.
Issues such as bad new device onboarding practice, not integrating with your change process and not fixing issues such as SNMP not being enabled all have a major impact on the reliability of your monitoring technologies ability to accurately reflect the environment you are monitoring.
When something major goes wrong and the tool gets blamed, often a business case for a new platform is easy to justify. What is then common is that the new tool is bought in haste and then discovered post purchase that it doesn’t deliver everything the incumbent technology did. So, both technologies remain and the initial problem gets forgotten. Until next time.
3. New Personnel Bringing in What They Know
One of the biggest hurdles we face as a consultancy making technical recommendations is resistance to change from operators.
It’s understandable, these people have a lot of responsibilities and learning a new monitoring technology, when they have built up a competency in another solution is not appealing.
It’s the main reason why we don’t change what’s working and when it’s not necessary, and as far as possible, look to duplicate the current experience of the key system users when it is.
The same logic applies when new employees start within an organisation when their new role involves management and monitoring of infrastructure, applications or services.
Naturally, the recruit wants to start strong and make an impact, especially if visibility has been flagged as an issue. This often results in bringing in the tools they’ve used in previous roles to tackle high pressure issues now. The result is new tooling being added to the environment.
4. New Technology or Projects Including Monitoring Technologies
When planning new projects involving the introduction of something new, for example, a new unified communications solution, new business critical app or Software Sefined Networking, a Programme Manager with their finger on the pulse will consider visibility.
Often, this is tackled by speaking to the provider of the new technology. They will recommend an incumbent technology (see point 1) or a technology they partner with for monitoring. No doubt these tools will do the job perfectly, but did anyone check the capabilities of what’s already in place?
The issue occurs because maybe a monitoring technology has been in place for some time and it’s been pigeon holed into doing a particular thing. However, it very common that organisations are using a lot less of their current solutions total capability. So, it’s worth picking up the phone and speaking with your supplier to see what they can do with the new tech you’re looking to deploy.
5. Application Stack Change
Applications run business, so it’s no surprise that Enterprises spend a lot of money monitoring them.
Application Development is fast moving, but we also find legacy applications often remain largely unchanged. It’s not unusual for Customers we work with to have a mixture of mainframe applications, Service Orientated Architectures and containerised environments within their total application landscapes, with mixtures of coding languages back-end database on Prem and Cloud.
These applications get so much focus because they are the window into IT performance that users benchmark IT against, and often they are revenue generating for the business.
When issues occur, it is justifiable to apply the best possible monitoring technology/ies for that environment and application. This results in multiple monitoring solutions used by multiple teams.
Totally understandable, as tools that are monitoring main frames often are not the one’s to use for monitoring Kubernetes.
However, it also does make sense to pause and review what you have before making that next purchase.
When we are working with a new customer for improving or consolidating APM capabilities, one thing we look for is the best common denominators. Rarely is this a single technology, but I can’t think of one recent project where we’ve not been able to significantly reduce the number individual tools, which invariably saves money, but also offers better knowledge sharing between teams because of shared experience of technology.
6. The Consistant Quest for Single Pane of Glass
I left this one to the end in case the mentioning again of maybe the most over utilised cliché in IT monitoring put you off. The Single Pane of Glass. It makes so much sense, doesn’t it? But at the same time so many projects have failed.
Firstly, let me say we believe that by selecting the correct AIOPs solution, it is possible to integrate with underlying monitoring technologies and business systems and extract meaningful unified insight. But, we also think there isn’t one right technology for every single customer circumstance. I can say this because we are a consultancy with multiple options to offer, not a vendor with one.
And this is what we think happens, the story of end-to-end integrated visibility is easy to sell and everyone like a nice dashboard don’t they?
However, sometimes these solutions are sold and don’t deliver what they promised in presentation slides. Sometimes, they deliver on day 1 and then don’t keep up to date with a rapidly changing environment.
The result is the systems provide some value, but not what everyone hoped for in the beginning. So they remain another layer of tooling in an already complex environment.
So What Can You Do About it?
I’ve listed the why it happens above, which I guess is interesting (hopefully) but not necessarily helpful if you find yourself in this situation already.
So, what can you do about it? You can look to carry out a Tools Consolidation Assessment. This is something you can do internally or invite a consultancy like KedronUK in to help with.
How that works and our proven processes, I’m saving for my next blog post, so sign up below or follow me on LinkedIn and you’ll be notified when its released.
What I will say now is that our initial review is free of charge and a recent project showed a major UK enterprise how we could save them 1.5 million over 3 years. I’ll cover that as a Case Study in the third and final post on this topic.
If you’d like to talk more in the interim, do feel free to get in touch.
P.S. If you think I’ve missed any key reasons above, do feel free to comment and I’ll add the good ones!
