Choosing the right network analytics software is no small task. But before taking the first step, it's imperative to assess your company's current network architecture to see which analytics product will best meet the demands created by this unique environment.
One of the biggest mistakes an organization can make when choosing network analytics software is to purchase a product based solely on vendor preference or, even worse, a bulleted list of features outlined on a product website. Because the successful operation of a network analytics platform depends on its ability to tightly integrate with all the network components generating streams of data, the best place to start is with an assessment of the network itself.
Assess the current network architecture
While evaluating the organization's network, the first thing to define is the overall architecture framework. Was it designed primarily for on-premises data flows? Or has the network been revamped for hybrid or multi-cloud connectivity? Keep in mind, as apps and data migrate further into the cloud, it's easy to become dependent on the network monitoring tools the cloud service provider supports. While most network analytics tools support some level of cloud monitoring, it's important to ensure the specific features within a platform are fully compatible with the organization's cloud partners. Additionally, once network analytics are in place, all future cloud partnerships should first be assessed to confirm compatibility with the network analytics platform in use.
It's worthwhile to consider purchasing network analytics software based on the network vendor products the organization already has implemented. Most enterprise network vendors allow network telemetry data to be streamed from devices, including routers, switches and wireless LANs (WLANs). Depending on the network analytics software your organization is reviewing, setting up the collection and analysis of these proprietary streams can be a challenge. Yet, because network telemetry data is such a critical part of gaining the necessary visibility and granularity required to monitor modern networks, the ease with which network analytics can ingest and analyze telemetry information is important. Thus, it's imperative to inventory the various network components and verify how well the analytics platform integrates with them.
Evaluate the business' network monitoring tools
Next, inventory the organization's current stable of network monitoring tools. Record the value they provide today as well as what's expected after the new analytics tools are installed. Network analytics works best when it pulls in data from both legacy and modern sources. Thus, most legacy monitoring tools will be duplicated and, ultimately, made obsolete.
Don't be surprised if some network admins have grown attached to certain monitoring products and are at least initially unwilling to give them up. These include such tools as legacy Simple Network Management Protocol pollers, Cisco NetFlow, and syslog collectors and packet tracers. Network and security admins who aren't fully aware of the increased benefits gained with network analytics software may take the "if it ain't broke, don't fix it" approach to their current monitoring tools. However, your goal should be to retire all legacy siloed tools that no longer provide value.
But be sure to fully consider the pitfalls associated with migrating away from legacy tools and onto an analytics platform. Remember that network monitoring isn't simply for retrospective root cause analysis or future capacity planning. These tools are also used to identify and notify operators about immediate network incidents. So, it's a good idea to run both legacy tools and the network analytics tools in tandem for a specified period of time. That way, any configuration kinks can be worked out prior to completely relying on the new analytics tool.
But if you're hoping to quickly shoehorn in network analytics before your company's legacy monitoring tool licensing or support contracts are about to expire, you run the risk of the network analytics software inadvertently missing critical alerts. That's why it's best to renew legacy monitoring licenses and support contracts so they remain fully operational for several months following the installation of a network analytics platform.
Maybe the organization already has network analytics?
Is it possible that your organization may already have network analytics software in place, yet not even know it? Many software-defined WAN architectures, advanced data center components and a few of the latest WLAN controller platforms operate using the same concepts and mechanisms that end-to-end network analytics tools also provide. The difference, obviously, is that deep analytics and visibility only cover a segment of a network as opposed to the entire network.
Yet, analytics of a specific segment of your network may be all that's needed. In fact, the WAN/internet edge, data center and WLAN are the three spots where the organization will likely gain the most value from network analytics. If the company has one or more of these segment-focused products already in place, be sure to include this as a consideration when doing a cost and benefit analysis of an end-to-end platform. You may actually conclude that your organization already has all the analysis capabilities it needs.
How much analytics does the organization really need?
When reviewing the various commercial network analytics products available for enterprises today, most fit into one of two categories. On one side are platforms that are more heavily focused on monitoring and reporting with a few out-of-the-box analytics features. On the other are platforms that have greater focus on deep root cause analysis and AI customization.
But there's a tradeoff between customization and implementation. While some products offer the potential to gain more analytical insight into the network -- which translates into automated responses that point to specific root causes -- the complexities of implementing this level of intelligence increases. The process of getting the network analytics software tuned to produce accurate results becomes more involved. That's why it's important to evaluate the benefits gained from advanced analytics features versus the time and money spent to fine-tune and maintain them.
Consider vendor support requirements
Because the network analytics market is still young, it has attracted both well-known vendors as well as a burgeoning group of startups. Within the commercial network analytics market, these new entrants are viewed as visionary trailblazers, offering a host of features and flexible deployment options. While that's great, it's important to consider the startup's ability to support the network analytics software throughout the entire product lifecycle. Since many startups are laser-focused on a single product, they may be the ones to provide the best support in terms of getting the organization's network analytics platform up and running.
Yet, the same may not be true in terms of ongoing maintenance and support post-install. This is especially true in two specific situations. The first is the vendor's ability to provide 24/7 global support. If you manage a global network, you'll certainly want worldwide and round-the-clock support. This may not be something that a smaller startup can offer. Second, it's important to also consider whether the startup will ultimately succeed, fail or become acquired by a larger vendor. Each of these outcomes can dramatically affect long-term support. Ultimately, weighing the risks and rewards between startups and their well-established counterparts must be fully considered in the product evaluation process.
Editor's note: Using extensive research into the network analytics market, TechTarget editors focused this article series on 10 products that address monitoring all or part of a corporate network or hybrid/multi-cloud environment using advanced data collection, data pooling and analytics. Our research included data from TechTarget surveys and reports from other well-respected research firms.