NMS Migration Made Easy: Get Stakeholders Aligned
Summary
Migrating network monitoring solutions is more than just a list of devices and technical requirements. It’s also about ensuring that all stakeholders are aligned - from team members to customers and everyone in between.
As we mentioned last week, we are more than a little nuts about Kentik NMS. It’s a monitoring solution that’s right-sized for today’s technology and use cases, with a nod to the past (SNMP) and an eye to the future (streaming telemetry).
But technology migrations—whether we’re talking about a CRM, email, or monitoring—are never trivial. We wrote the NMS Migration Guide with that problem in mind, to help folks avoid some of the pitfalls and challenges of moving from their old solution into Kentik NMS.
That said, nobody’s time is infinite, so digesting a detailed ebook just isn’t in the cards for some folks. That’s why you’re reading part 2 of this series, where we take the major topics and concepts from the guide and provide them in a smaller and easier-to-consume package.
The vast majority of us here at Kentik – from the CEO down – are folks who came up through the ranks of IT, even if our current jobs are less technical than past roles. So, we understand entirely the reluctance you may feel regarding the more political aspects of a systems migration. We will encourage you to work through this because, as a bit of old wisdom goes, most projects fail at layers 8, 9, or 10 of the OSI model.
Customers, consumers, and constituents
One of the first (and most pernicious) mental disconnects among IT practitioners is the misunderstanding of customers versus consumers (we’ll get to constituents in a minute). This is a problem vis-a-vis migrating to Kentik NMS because it causes folks to ask the wrong questions, fail to obtain authority, and ineffectively set expectations. So, let’s take a minute to thread this needle:
- Customers are, broadly speaking, the person, people, department, or whatever that pays for something. They might not use it, but they are funding it.
- Conversely, consumers are the folks who use or benefit from the item, service, or whatever. To be explicit: Consumers (users) are not always customers (payers), and customers are not always consumers.
- Constituents is a term I’m stretching to indicate people who care about the service or product, even if they neither pay for it nor use it.
How do these three terms relate to monitoring and observability?
Our experience at Kentik is that the customer is usually an executive sponsor or leader or sometimes a guiding organization like security or compliance. These folks know monitoring is needed in the organization, but neither consume the output nor particularly care (on a personal, visceral, experiential level) about its execution. They may care as individuals because they understand monitoring and observability are vital to the healthy operation of any business. But the semantics of how it’s done must be added to their radar.
Meanwhile, the consumers of monitoring and observability – which includes the folks who design, install, and maintain Kentik in the environment as well as the teams who receive Kentik’s output (alerts, reports, dashboards, and more) – are almost always not the ones with purchasing authority.
Finally, there are constituents. These folks use the applications and systems monitored by Kentik and supported by the consumers (typically Ops, DevOps, SREs, and such). They care about the health and performance of the systems they use to do their job but aren’t on the hook if they go down.
We’ve spent time outlining this here because when you want to achieve stakeholder alignment, you must first understand who those stakeholders are and what kind of stake they have when migrating from your existing solution to Kentik NMS.
With that done, we can begin to address how to get each of these groups on board and avoid the common pitfalls that cause migration efforts to fail.
Monitoring is not management
The first, loudest, and longest complaint you’ll likely hear is that there are already solutions to monitor individual systems, and the company doesn’t need to “add another brick.” Almost always, the tools people talk about are vendor/platform-specific management tools with some monitoring aspects.
The problem is that one vendor’s tools can never adequately monitor other parts of the infrastructure, certainly not as comprehensively as something like Kentik. On the other hand, nothing will ever help manage equipment or applications as well as the purpose-built systems from the vendor itself.
Ultimately, you’ll need to make clear to these folks that nobody is asking to remove or replace the management tools they rely on. However, using those tools as de facto monitoring and observability solutions is ineffective because they lack the range, flexibility, or interoperability concerning the overall corporate infrastructure and the scope of other monitoring and observability tools at hand.
What matters?
The next issue is a common fault of IT people—they need clarification on what matters in a tech context and what matters to the business at large. Just because most companies have become highly reliant on technical solutions to deliver products and services does not mean they are technology companies.
A quote from tech pundit Bob Lewis holds as true today as it did when he first said it back in 2004: “There’s no such thing as an IT project. There are only business projects with an IT component.”
Whether you can get behind this philosophy or not is beside the point. We promise it’s more accurate than not for the people running the business, making the decisions, and (most importantly) signing the checks for new monitoring solutions. No matter how different we wish it were, nobody ever won debate points describing the advantages of streaming telemetry versus SNMP to the CFO.
You need to spend a few minutes learning about what matters to the business and then considering how to frame a monitoring migration in those terms.
If that last sentence makes you want to throw your hands in the air and give up, don’t worry. We felt the same way, too. It’s not easy, and don’t let anyone try to tell you otherwise. But you can do it. Here are some helpful hints:
- Discomfort over convenience: Technical folks often lead with how much better (meaning time-saving, easy to use, less brittle) a new system is versus the old. “The time we’ll save!” is the rallying cry. While we don’t want to paint all leaders with the same brush, saying, “I will have to work less hard on this,” is not a winning argument. On the other hand, “this thing is causing us pain [meaning loss of business], and here’s a solution” is incredibly convincing.
- Identify critical systems: In any organization, some applications are seen as desperately important, and others are viewed as unessential. That may not be objectively true, but objective truth doesn’t matter here. You must know which business tools are mission-critical and attach your monitoring migration to those systems. It’s hard to say no when an IT practitioner shows how a new monitoring solution will maintain 30% more uptime on the critical application versus the old tool.
- Understand the rhythm of the business: No matter how convincing your argument may be, you will get turned down if it’s the wrong time to ask. Whether it’s month-end closing, the (historically) worst quarter of the year, or the middle of an industry-wide downturn, you must be cognizant of the external business factors influencing your boss’s ability to say “yes.” You may not necessarily have to give up, but you must acknowledge the business landscape’s truth and account for it in your discussions.
- Know whose baby you call ugly: Everyone’s application belongs to someone. The monitoring solution you want to replace was brought in-house by someone who (to more or less a degree) made their career on that success. Suppose that employee is gone now are gone now, all the better. But in far more cases, they’re still here, and you really don’t want to give the impression you are calling their choice (or worse, their work) wrong. It may require some frank (and even uncomfortable) side conversations, but you’ll need to get past this hurdle or face a dragged-out period of bickering, backstabbing, whisper campaigns, or worse. And to be clear, this isn’t just for the monitoring tool you want to replace with Kentik NMS. It’s equally valid for what you want to monitor with Kentik NMS. Ensure the owner doesn’t interpret your arguments about improving application performance and uptime as an accusation that their baby is unstable.
- There are no ugly babies: All applications and systems have issues, and it’s equally valid that they perform their intended role well enough. When working with owners and teams, emphasize your desire to help make their stuff – and, by extension, them – show at their best within the business and reduce the interruptions and unplanned work caused if things go sideways.
Finally, polite persistence pays. Let’s say you did everything we suggested above and were still told “no.” Seasoned IT folks know a last, almost magical phrase to use:
“What would you need to hear that would make you comfortable saying ‘yes’ to this project?”
Most leaders want to approve projects and see things get done – especially when those things have the potential to increase the stability, performance, and velocity of the business. By asking what specific things drive a leader’s decision, you are demonstrating both an interest in and a willingness to understand the things that are important to them. It’s hard to understate how powerful that can be.
Become an IT polyglot
What we’re getting at is that you need to become more fluent in the language of business. Many IT folks find this idea distasteful, if not downright disturbing. It’s as if we’re saying, “Eschew all your technical skills, let all your certifications lapse, vow never to touch another computer again, and become a Luddite hermit.”
That’s simply not how languages work. Taking the time to learn Python (or French) doesn’t cause you to forget everything you knew about Java (or Klingon). Learning additional languages is usually an additive experience, where the new knowledge reinforces and enhances what you already know.
So, learn business terms, concepts, and methods of relating ideas. Not because you need to “dumb it down.” That’s insulting and infantilizing to your colleagues who manage teams and run the company. Instead, think about standing on a corner in France and shouting at people walking by in English. You are not going to get much of a positive response. In that same vein, pushing technical arguments with increasing intensity at the business office isn’t going to magically make them more technical or care about your opinion more.
So, what is this so-called language of business? It boils down to three things. You need to take your goal (migrating to Kentik NMS) and frame it as helping accomplish one of three basic things:
- Increase revenue
- Reduce cost
- Remove risk
The good news is that monitoring and observability tools, in general, and Kentik NMS, in particular, are very good at numbers two and three. Creative IT practitioners can also find ways to make them fit into item number one.
What’s next?
To be honest, if you’ve gotten this far—both in terms of reading the blog series and in the actual migration—the hard part is behind you. But that doesn’t mean there’s nothing of value left for me to tell you, for you to read, or for you and your team to do. So, I hope you’ll stick around for the third installment in our series.
Or you could download the entire guide now and skip the wait.
