Network monitoring tools must offer more insights upfront
Vendors' network monitoring tools can require complex customization after purchase. New EMA research points to the need for tools to deliver more out of the box.
The installation of a network monitoring tool can take weeks, if not months. Even today, when many tools are consumed as a service rather than an on-premises installation, this issue persists. Tool customization often drives these long lead times. IT organizations integrate network monitoring tools with other systems. Dashboards and reports must reflect the priorities of the network operations team. Alert thresholds must be tuned to minimize noise.
This status quo of heavy lifting may seem reasonable, but at a certain point, the question is: Shouldn't tools deliver more value out of the box?
"When you deploy a monitoring tool, you have to adapt the tool to your environment, train engineers on how to use it and build processes around the tools. We have to … build dashboards, reports and custom integrations into tools," a network tools engineer for an $8 billion technology company told Enterprise Management Associates (EMA). "Unless you have someone full time to adapt a tool to your network, insights are overlooked or not developed, and that leads to disappointment and management questions about whether they are getting value from an investment."
Bespoke customization vs. useful insights
EMA won't quibble with customization that addresses the quirks and complexities of an IT organization that wants to do things in a certain way. But the tool engineer quoted above touched on something more problematic. He customizes tools because they are incapable of providing insights to rank-and-file users out of the box.
For a recent market research study on the concept of network observability, EMA looked at the issue from that angle. In this context, EMA considers network observability an advanced subset of network monitoring. We asked 402 IT stakeholders to identify what custom work their organizations must do to get "useful insights" out of their network monitoring or network observability tools.
EMA's research found that 94% of enterprises have to do at least some customization to get useful insights from their tools.
We looked at the issue of customization from the useful insights perspective because EMA believes network tool vendors need to focus on delivering actionable insights, in contrast to presenting reports and dashboards that summarize data about the network. We think vendors should do more to make their tools actionable out of the box. Why should it take weeks to build custom reports? Why do processes need to be documented when the tool should be the process?
EMA's research found that 94% of enterprises have to do at least some customization to get useful insights from their tools. The following is an examination of the common customization efforts required to glean actionable insights from a tool.
Integration with third-party systems
More than half of IT organizations (53%) have to integrate network tools with other systems. It makes perfect sense that a network monitoring tool integrates with other systems. In fact, we recommend it. IT service management integration, for instance, can streamline and automate ticket and event management.
Vendors should productize and support this integration, however. For instance, vendors should make integration with ServiceNow as trivial as possible. This starts with open and well-documented APIs that can access as many features in a tool as possible. Any insights gleaned via this integration should be presented in a matter-of-fact way to end users. Otherwise, tier-one administrators will continue to escalate everything to engineers.
Creating custom development and scripting
Custom development is another common step that 47% of IT organizations take to get useful insights from tools. They are programming or scripting tools, which suggests a gap between user requirements and vendor capabilities. Engineers are essentially codifying their knowledge about networks into the tool. They create scripts in a tool that trigger automated actions based on certain alerts generated by the tool.
Coding and scripting are premium skills network engineering teams are struggling to find in the labor market. It's alarming to see so many organizations devoting these resources to network tools that cost millions of dollars in some environments.
Workflow and process documentation
We hear over and over that tools are simply too hard to use. Tier-three engineers can do just about anything with most network tools, but tier-one administrators are often at sea when they double-click on an object in a tool console. EMA found that 47% of organizations must document workflows and processes around a tool so lower-skilled personnel can glean useful insights.
In other words, admins look at an internal wiki that tells them, "If this is red and this is red and this is green, ping that. If no response, restart device. If device doesn't boot, escalate." This kind of bespoke documentation probably delivers value, but it's a time sink -- and it's not comprehensive. A tool should be able to capture this knowledge and present it as a workflow. It should discover a network, understand dependencies, and develop processes and workflows based on those discoveries.
Why the problem of customization matters
Tool customization will never disappear, but there should be less of it. Some IT organizations will always have idiosyncratic networks, but a tool should be trained to address and reveal many universal truths in network operations (NetOps).
EMA's research found that 94% of the IT organizations that customize their network tools to get useful insights ultimately experience negative business impacts. The most common issue is increased cost (46%). Internal engineering resources are expensive. External professional services and consultants are also expensive. Our data indicated that cost is especially problematic in organizations in which network engineering and operations teams implement their own tools rather than a dedicated, internal tool engineering team.
More than 39% experienced usability or adoption issues with tools. These could be a result of customization that failed to consider the capabilities and habits of tool users. More than 38% of organizations reported significant delays in time to value with tools. Nearly 36% complained of ineffective tools. Thirty-four percent complained that this customization led to delays in other projects because engineers had no time for other duties.
Overall, this pain is felt everywhere. What happens if customization efforts are delayed, suspended or canceled? The tool languishes, and the IT organization ultimately loses track of the tool's full potential. When demand arises for new tools, the organization often buys another tool rather than optimizing the one in which they already invested time and money.
"The biggest consequence I see is that these tools aren't fully onboarded, so you're not using them to their full capability," according to a backbone tool engineer with a $25 billion financial company. "Often, the one feature you are using doesn't have full insights into your network because it isn't fully onboarded. Then, someone says, 'We bought this new tool for you to use for X,' and engineering will say, 'We have three other tools that should be able to do this.' That new tool was sold to someone who wasn't technical enough to understand that we already had tools that could do something just as well."
It's time for network monitoring and network observability vendors to deliver actionable insights out of the box. They know this. It's why everyone is talking about AIOps. The next time you're talking to a vendor that brings up AI and machine learning, ask how they can deliver actionable insights to your NetOps team out of the box.
