Installing a network monitoring tool can take weeks, if not months. Even today, when many tools are used as a service rather than an on-premise installation, this issue persists. Tool customization often drives these long lead times. IT organizations integrate network monitoring tools with other systems. Dashboards and reports should reflect the priorities of the network operations team. Alert limits should be tuned to minimize noise.
This status quo of heavy lifting may seem reasonable, but at a certain point, the question is: Shouldn’t the tools deliver more value out of the box?
“When you deploy a monitoring tool, you need to adapt the tool to your environment, train engineers how to use it and build processes around the tools. We need to … build dashboards, reports and custom integration into tools,” a network engineer tool for an $8 billion technology company at Enterprise Management Associates (EMA). “Unless you have the full time to adapt a tool to your network, insights are overlooked or underdeveloped, and that leads to frustration and management questions about whether they’re getting value from an investment.”
Customization versus actionable insights
EMA won’t beat customization that addresses the idiosyncrasies and complexities of an IT organization that wants to do things a certain way. But the tool engineer quoted above touched on something more problematic. He customizes tools because they lack the ability to provide insights to rank-and-file users out of the box.
For a recent market research study on the concept of network surveillance, EMA looked at the issue from that angle. In this context, EMA considers network monitoring as an advanced subset of network monitoring. We asked 402 IT stakeholders to identify what custom work their organizations should do to gain “useful insights” from their network monitoring or network observation tools.
We looked at the issue of customization from a useful insights perspective because EMA believes that network tool vendors need to focus on delivering actionable insights, as opposed 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 document processes when the tool should be the process?
EMA research found that 94% of businesses need to do at least some customization to get useful insights from their tools. The following is a review of the typical customization efforts required to gain actionable insights from a tool.
Integration with third-party systems
More than half of IT organizations (53%) need to integrate network tools with other systems. It makes sense that a network monitoring tool integrates with other systems. In fact, we recommend it. Integrating IT service management, for example, can streamline and automate ticket and event management.
However, vendors must create and support this integration. For example, vendors should make integration with ServiceNow as cost-free as possible. This starts with open and well-documented APIs that can access as many features in one tool as possible. Any insights gained through this integration must be presented in an objective manner to end users. Otherwise, tier-one administrators will continue to bring everything to engineers.
Creating custom development and scripting
Custom development is another common step taken by 47% of IT organizations to gain useful insights from tools. These are programming or scripting tools, which bridge the gap between user requirements and vendor capabilities. Engineers essentially codify their knowledge about networks in 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 in network engineering teams that are hard to find in the labor market. It is disturbing 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 the tools are too hard to use. Tier-three engineers can do almost anything with most network tools, but tier-one administrators are often at sea when they double-click something in a tool console. EMA found that 47% of organizations should document workflows and processes around a tool so low-skilled staff can gain useful insights.
In other words, admins look at an internal wiki that tells them, “If it’s red and it’s red and it’s green, ping that. If there’s no response, restart the device. If the device is not booting, escalate.” This kind of custom documentation probably delivers value, but it’s a time sink — and it’s not comprehensive. A tool should capture this knowledge and present it as a workflow. It must discover the network, understand dependencies, and build processes and workflows based on those discoveries.
Why is the customization problem important?
Tool customization will never go away, but there should be less of it. Some IT organizations will always have idiosyncratic networks, but a tool must be trained to address and reveal the many universal truths in network operations (NetOps).
EMA research found that 94% of IT organizations that customize their network tools to gain useful insights end up experiencing negative business impacts. The most common issue was cost escalation (46%). Internal engineering resources are expensive. External professional services and consultants are also expensive. Our data indicated that cost is particularly problematic in organizations where network engineering and operations teams implement their own tools rather than a dedicated, internal tool engineering team.
Over 39% experienced usability or adoption issues with the tools. These may be the result of customization that fails to take into account the capabilities and habits of the tool’s users. More than 38% of organizations reported significant delays in time to value using the tools. Almost 36% complained of ineffective tools. Thirty-four percent complained that this customization led to delays in other projects because engineers did not have time for other duties.
In general, this pain is felt everywhere. What happens if customization efforts are delayed, suspended or canceled? The tool is weakening, and the IT organization has completely lost track of the tool’s full potential. When the need for new tools arises, the organization often buys another tool instead of optimizing one in which they have already invested time and money.
“The biggest consequence that I see is that these tools are not fully onboarded, so you’re not using them to their full potential,” according to a backbone tool engineer with a $25 billion finance company. “Often, a feature that you’re using doesn’t have full insight into your network because it’s not fully onboarded. Then someone says, ‘We bought this new tool for you to use for X,’ and the engineering, ‘We have three other tools that should do this.’ That new tool was sold to someone who wasn’t technical enough to understand that we already had tools that could do the same thing.”
It’s time for network monitoring and network observability vendors to deliver actionable insights out of the box. They know it. This is why everyone is talking about AIOps. The next time you talk to a vendor that’s rolling out AI and machine learning, ask how they can deliver actionable insights to your NetOps team out of the box.