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!

A typical SAP deployment is usually a sprawling, complex system and is one of the most critical applications an enterprise relies on to keep the business functioning, with it interacting with production, sales, dispatch, HR and other areas of the business.

Monitoring the performance and availability of SAP is therefore key.  Proactive monitoring may allow minor issues to be resolved before they become major issues.  SAP provide a number of tools such as Solution Manager and CCMS which can be used to monitor the platform.  It is however, worth considering the wider picture when it comes to selecting the right tool for this particular job.

Why should I consider a third-party tool?  I have the tools from the vendor, why do I need something else?

As an independent IT reseller and consultancy specialising in security, monitoring and management, these are common questions posed to KedronUK.  At first glance, it’s a sensible question as who should understand the intricacies and key performance indicators of an application better than the producer of that application?

Answering a question with a question doesn’t always provide an answer, but in this case, is a logical response.  What other IT resources does your SAP environment depend on?  For an on-premise environment this will undoubtedly cover storage and virtualisation stacks, networking and more.  Given one of the benefits of virtualisation is to share those expensive hardware resources and make better use of them, a SAP performance issue could actually be caused by another unrelated application which lives in the same infrastructure.  In a modern hybrid cloud / on-premise environment, dependencies will reach out further to include providers such as Microsoft Azure or Amazon AWS.

So, whilst the vendor’s own tools may seem the wise choice, monitoring the wider IT environment brings more visibility.  The phrase “knowledge is power” is commonly but possibly incorrectly attributed to Sir Francis Bacon back in 1597 (I’ll admit I had to look that fact up!) but regardless of when it was first said, it still rings true today. 

The eG Enterprise Suite is application aware, so can monitor the key SAP applications / services such as HANA, ABAP, Business One and NetWeaver to name but a few.  The monitoring of each application includes multiple tests at multiple layers.  As an example, when eG Enterprise monitors an ABAP Server instance, it reports on layers such as SAP Basis, Workload, Work Processes, Gateway and User Sessions.  Alongside this, eG Enterprise can also monitor the wider IT infrastructure such as a VMware vSphere virtualisation environment which may underpin SAP.  Unifying that visibility into a single place not only delivers that sort after knowledge but can also improve productivity for the IT team by reducing the number of tools they need to interact with.

A full list of the platforms and technologies supported by eG Enterprise can be found at:

https://www.eginnovations.com/it-monitoring/technologies

Another common issue we tackle with customers at KedronUK is the dreaded “alert cannon”.  As soon as somebody has the rule in their e-mail client to automatically move e-mail alerts from a monitoring system to a sub-folder as the messages are clogging up their Inbox, it’s arguable the monitoring is no longer doing the right job.  The eG Enterprise Suite capabilities include event correlation and analytics which make use of modern AI/ML techniques to reduce the noise and target something that really matters to an IT team – Root Cause Analysis (RCA).  I’ve never met anyone in IT who doesn’t want to resolve an issue as quickly as possible (we all want to look good, right?) so having a holistic view of your infrastructure with quick and easy RCA drill-down is essential.

Expanding on the previous example of an unrelated application impacting SAP performance, a lot of time, and therefore money, can be saved if your monitoring can indicate that whilst your SAP database server is suffering from poor disk performance, the real underlying problem is a run-away process on another VM, which shares the same virtualisation host and storage array, consuming all the storage I/O.

To understand more about the correlation and analytics functionality of eG Enterprise, I’d recommend reading John Worthington’s blog post:

https://www.eginnovations.com/blog/what-is-event-correlation/

Calling all Operational Teams and Service Providers

Over the years, I have spoken to countless customers whose companies through both organic and acquisitional growth have been faced with the perfect storm of being given numerous management and reporting tools to monitor but without having the critical cross technology view of their infrastructures.

For almost twenty years Kedron have specialised in delivering world class single vision network and application monitoring, improving our customers performance simply via greater visibility in this case of their network devices, servers, applications, traffic and configuration.

I personally have worked for the last 5 years in the KedronUK Service Provider team with our flagship product StableNet which now supports many Global organisations including Major Telco’s, Government institutions, MSPs, etc.

As we have grown we have utilised our experience to become an expert visibility partner to major UK Service Providers, guaranteeing complete single source visibility to both encompass the ever-increasing number of new tools on the market and addressing other areas of IT by enhancing our own product portfolio in two ways:

1.     Selected collaboration with specialist vendors in this area

2.     Developed our own Single Framework for IT “Totuus”

So, whether it be Network, Applications, AIOps, your Security Platforms Servers, EoL and Vulnerabilities on-Prem or in the Cloud, we can take the information from multiple feeds, amalgamate and deliver a single view of IT service availability and performance across all types of hybrid platforms.

My mantra is simply: “If you can see it, you can do it” however conscious of staying current, relevant leading edge I would welcome your feedback on visibility, how you have addressed your visibility requirements and how do you guarantee visibility of performance across your hybrid infrastructures?

Do you have the right tools for the job in your Security Operations Centre? This is why you need network detection and response in your armoury.

Security teams have to navigate a constant stream of new threats to protect hybrid networks and sensitive data. Often they’re reliant on legacy tools that don’t quite match the scope and complexity of the environment. But you can’t secure what you can’t see. Ideally, your team needs eyes on every interaction that takes place across your network. 

But cloud and hybrid environments expand your attack surface and make it harder to see into critical areas, especially in the case of multi-cloud. So, where do you turn to get the visibility you need? 

Network detection and response (NDR) tackles the problem from the inside out. Cloud-native NDR in particular can eliminate blind spots and cut through the complexity in hybrid, cloud, and multi-cloud scenarios. 

There are few solutions on the market that provide complete visibility through a combination of discovery, identification, contextualisation, framework support, and real-time threat detection, as well as guided investigation. In our opinion, ExtraHop Reveal(x) is the industry leader. 

Reveal(x) is currently the only product on the market to provide full-spectrum detection and response for security and performance teams. Taking the wire as its data source, it reduces finger-pointing and MTTR by acting as a single source of truth, provides faster time to value, and gives your team eyes on every interaction that takes place on your network. So you’ll know about problems before your users even notice, and benefit from correlated visibility to filter out the noise and pin down the issue quickly.

Malicious actors can bypass or shut off EDR and SIEM tools, but – implemented properly – Reveal(x) NDR addresses the blindspot they leave and integrates with complementary software like CrowdStrike to give you full coverage. Other features that make it stand out from our perspective to include:

• Holistic view of E-W and N-S traffic that can’t be spoofed or evaded.

• Line-rate decryption of SSL/TLS 1.3 encrypted traffic with perfect forward secrecy.

• Built in visibility into framework requirements, including CIS controls 1 & 2, MITRE and NIST CSF recommendations.

• 100 Gbps of full payload analysis from L2 to L7 based on wire data with complete context.

• Automatic, continuous device discovery, identification and classification.


It might sound trite, but it’s true that prevention is better than the cure. If you’re going to secure your enterprise proactively from insider and outsider threats, if you’re going to deliver a cybersecurity strategy that protects your data and reduces risk, you need to make sure your tools are up to the job.

Book a demo here if you would like to see for yourself what Reveal(x) can reveal.

Do you have the right tools for the job in your Security Operations Centre? This is why you need network detection and response in your armoury.

Security teams have to navigate a constant stream of new threats to protect hybrid networks and sensitive data. Often they’re reliant on legacy tools that don’t quite match the scope and complexity of the environment. But you can’t secure what you can’t see. Ideally, your team needs eyes on every interaction that takes place across your network. 

But cloud and hybrid environments expand your attack surface and make it harder to see into critical areas, especially in the case of multi-cloud. So, where do you turn to get the visibility you need? 

Network detection and response (NDR) tackles the problem from the inside out. Cloud-native NDR in particular can eliminate blind spots and cut through the complexity in hybrid, cloud, and multi-cloud scenarios. 

There are few solutions on the market that provide complete visibility through a combination of discovery, identification, contextualisation, framework support, and real-time threat detection, as well as guided investigation. In our opinion, ExtraHop Reveal(x) is the industry leader. 

Reveal(x) is currently the only product on the market to provide full-spectrum detection and response for security and performance teams. Taking the wire as its data source, it reduces finger-pointing and MTTR by acting as a single source of truth, provides faster time to value, and gives your team eyes on every interaction that takes place on your network. So you’ll know about problems before your users even notice, and benefit from correlated visibility to filter out the noise and pin down the issue quickly.

Malicious actors can bypass or shut off EDR and SIEM tools, but – implemented properly – Reveal(x) NDR addresses the blindspot they leave and integrates with complementary software like CrowdStrike to give you full coverage. Other features that make it stand out from our perspective to include:

• Holistic view of E-W and N-S traffic that can’t be spoofed or evaded.

• Line-rate decryption of SSL/TLS 1.3 encrypted traffic with perfect forward secrecy.

• Built in visibility into framework requirements, including CIS controls 1 & 2, MITRE and NIST CSF recommendations.

• 100 Gbps of full payload analysis from L2 to L7 based on wire data with complete context.

• Automatic, continuous device discovery, identification and classification.


It might sound trite, but it’s true that prevention is better than the cure. If you’re going to secure your enterprise proactively from insider and outsider threats, if you’re going to deliver a cybersecurity strategy that protects your data and reduces risk, you need to make sure your tools are up to the job.

Book a demo here if you would like to see for yourself what Reveal(x) can reveal.

I’m often ridiculed for how frequently I use the expression ‘garbage in garbage out’, in fact many of my colleagues know when I’m about to say it and mouth it back to me, so let’s get it out of the way now; When it comes to commissioning, or onboarding, an NMS I believe the administrators mantra should be GARBAGE IN GARBAGE OUT!

An NMS comes into its own when alerting an incident, providing the location of a root cause or allowing you to obtain data for a report, and if the commissioning and maintenance of the system has been sloppy, then you will get what you deserve.

With the best will in the world, however, unless data input is managed and controlled to defined best practises, users will often resort to ‘minimal input’ to achieve their goal. This is often exacerbated by new and or inexperienced users being tasked with the process of commissioning or on-boarding, which often occurs a little while after initially installing a new NMS, when the experienced engineers move onto the next project.

During the initial commissioning phase of a new NMS, time and emphasis is placed on the quality of the input, only later for this repetitive task being given to less experienced users with ‘Local Work Instructions’ (LWI’s). LWI’s provide a guideline of best practise, but provide little if no governance of best practises, add to this human error, and a company quickly moves to the ‘garbage in garbage out’ situation, there, I said it again.

Usually at the outset of deploying a new NMS platform, great emphasis is placed on the presentation and structure of the solution:

• Will device grouping be geographical, service, business unit, device type or the like?
• Will augmented data be required from additional sources, such as address or Geo data, service contracts and SLA details?
• What device tags will be required for filtering and reporting?
• Which user groups will have which roles and visibility?
• What views will be created and who will have visibility?

Defining these, however, is only the first step; enforcing them, moving forward, is entirely another.

Why, though, is this so important? Carefully crafted reports, for example, with filters that include inventory items based on specific attributes, will only continue to include all the required inventory, if the specific attributes used in your filters are completed correctly by your users. It is very common to see systems that looked so complete and fit for purpose, when initially commissioned, to be far from being fit for purpose just six months later.

Additionally, understanding what’s missing from an NMS, continues to present a major challenge to administrators; how do we know what we don’t know?

For well over a decade, KedronUK have worked in conjunction with some of the UK’s leading network management companies with best of breed network analysis and management tools and platforms, in the process we have defined best practises in utilising these tools and platforms. In recent years, our Customers have increasingly called for automated processes and procedures to enforce these defined practises.

Therefore, we have developed our ‘Commissioner Portal’ to define and enforce configured inputs, reducing human error and ‘free form’ inputs to a minimum. Empowering inexperienced users to on-board devices exactly as administration define and presenting network management tools with a clean set of data.

The Commissioner Portal allows for the definition of associated data sets to be created in advance which are simply selected by the end user rather than having to be input at the point of inventory insertion each time. This could be a data set related to a physical site location for example. The data set for a Site can be as extensive as required but does not require re-entry every time an inventory item is added to that site.

With a set of predefined reports, the user is able to see at a glance the current status of his onboarding attempts and ‘see’ what is missing from the NMS, when compared to the commissioning database.

We have recently made the decision to combine the Commissioner Portal with the KedronUK TOTUUS solution. The Commissioner Portal now becomes a module of the already extensive TOTUUS solution, with its Data Connectors (DCX) providing automation of Inventory updates from 3rd party systems and flat file locations, along with automated data normalisation, allowing for seamless commissioning of an NMS solution from 3rd Party systems or element managers.

If any of the above strikes a cord with you please get in touch with us here.