Image may be NSFW.
Clik here to view.

This (see above) is an actual screen capture of a security question I encountered earlier this week. Understandably, recent high profile hacking incidents motivated companies to take extra measures to protect sensitive personal data, but this is a great example of poor design coupled with unnecessary complexity.

I wholeheartedly support the concept of adding an additional layer of security questions, but how many different ways can one incorrectly answer this security question – let me count the ways.

It took me three tries before a system lockout forced me to call into their customer support center to get my account unlocked. The next 45 minutes were the most frustrating and dumbfounding minutes in recent memory. As a result, I moved my account to another service.

Why simplicity is key

According to Wikipedia, the KISS Principle was a design principle created by the U.S. Navy in the 1960s. The acronym stands for Keep It Simple Stupid. The last letter is a bit harsh, but I get the point. The core idea is that systems work best when it’s kept simple, therefore simplicity should be the key goal in design.

While this concept has engineering beginnings, it resonates well across many disciplines. If you’re responsible for keeping your company’s IT infrastructure humming along, keeping things simple should matter a lot.

Simplifying your monitoring needs can mean reducing the myriad of tools being used to monitor the health and performance of your network. It could also mean reducing the amount of effort and skills required for you or your staff to implement, use and maintain these tools. Bottom line: you want to spend your time doing the things that matter most to your business as opposed to being buried in the complexity of the tools that were supposed to help you better manage your IT environment.

You also want the ability to be proactive as opposed to being reactive. Why? Because it means less time wasted for triaging, troubleshooting, root cause determination, accurate resource allocation and better end-user experience – just to name a few.

So how do you determine if a monitoring solution is KISS-able? In the spirit of keeping it simple, there are five high-level questions you should ask (yourself or your vendors). You may have more questions as you ask these questions and that’s a good thing. Good questions should stimulate the thought process.

Question 1: What’s the required approach for harvesting fault, availability and performance data from your infrastructure?

You need to understand the level of effort, resource and skills required to collect needed data. Do you have the resources and skillset needed for the required data collection approach? What’s the likelihood of being able to maintain this effort for the long haul?

Question 2: Is the data being collected actionable, relevant and makes it easier for you to monitor and manage your infrastructure?

At the risk of stating the obvious, data collection is only important if it improves your ability to monitor, manage and make decisions regarding the health and performance of your IT infrastructure. To that end, depth and breadth of data aren’t enough.

Can the information be presented in a fashion that helps your staff take quick and effective actions? Can a dynamic profile of what’s “normal” for your network be built from the data collected? Are there built-in workflows to help your level 1 or level 2 staff be more productive, thus alleviating the impact on higher cost staff?

Question 3: What does it take to scale for change/growth?

Change is a constant for companies that employ technology to help achieve strategic priorities. And change that involves growth typically means more resources, increased complexity, as well as the potential risk of impacting what you have working currently.

Will adding a new location to your monitoring architecture be simple or painful? Can you validate that your changes have the expected outcome? Can you handle the growth and impact of traffic such as video on your shared network? How much longer can you maintain performance levels with your existing infrastructure before additional investments are needed?

Question 4: Do you have insight into application performance?

It’s no longer feasible to have a network only or an application only approach to monitoring. Granted network experts don’t need to dig down to the offending code to troubleshoot as opposed to an application expert, but having insight as to where application performance lags, deliver high impact in terms of improving triage. The reason networks exist at all is to support the applications and services that traverse across it. Targeted visibility into application performance lets network experts validate the performance of the network itself.

Question 5: Can you strike a balance between extensibility and maintainability?

Can you to augment core capabilities with capabilities (from the same vendor or others) that address your environment’s specific needs, yet still take into consideration maintainability? What often happens with highly extensible systems over time is they become unwieldy to maintain. The ideal solution should offer an architecture that allows a fair level of customization without jeopardizing maintainability.

By no means, this post is intended to replace your rigorous and detailed RFI/RFP process. To use a food metaphor, it’s just an amuse-bouche to stimulate your mental appetite. Bottom line, your network monitoring solution should not be more complex to deploy, utilize, maintain and grow than the infrastructure it monitors.

Is your network performance monitoring solution KISS-able?

Image may be NSFW.
Clik here to view.

The post Is your network performance monitoring solution KISS-able? appeared first on Highlight.

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.