From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

Evaluating An IT Purchase: Take Your Eyes Off The Shiny

1,634 Words. Plan about 11 minute(s) to read this.

The sales cycle. Go ahead and groan. No matter where you are in the IT ecosystem, all of us have to deal with purchasing technology – from the CIO on down to the help desk technician working inbound triage. Sales cycles are *awful* things, filled with presentations, evaluations, pricing exercises, parts lists, bundling deals, end-of-quarter incentives, trade-ins, lead times, and the odd lunch or two. The sad part? Dealing with vendor sales folks is all too often adversarial in nature – a battle of wits. The salesperson wants to sell you what they’ve got. If all they have is hammer, every problem you’ve got looks like a nail. Therefore, you as the consumer can’t expect the vendor to tell you their product is wrong for your situation. You’ve got to figure that out for yourself.

Do Your Technical Homework

I don’t care what piece of networking technology you’re buying, you simply must find out exactly what it does and what it does not do. Forget about what the SE told you it does. Get your hands on it and make certain all your needs are met. Make no assumptions about what the device does based on your past experience with similar devices.

For example, consider Ethernet switches. If you change from a Cisco Catalyst platform to the Cisco Nexus, you might assume feature parity. This is just not the case (although that situation has gotten better over time). You need to review in detail the capabilities of the Nexus line cards you are considering. Not all of the cards do the same things, or have the same laundry list of features. You have to do your homework, starting with a list of what you require in the new product you are considering.

As far as vendor roadmaps go, my advice is for caution. Don’t buy a product based on what it might someday do. Buy it because you’ve proven what it can do today. Roadmaps are a vague promise – a distant unicorn wearing a veil and giggling at you as it gallops into the thick underbrush. Yes, maybe someday you’ll be able to catch the unicorn and ride it. But I wouldn’t bet my budget money on it.

Get An Unbiased Opinion

Go beyond the vendor you’re working with to get some opinions about the product you are evaluating. Search Google and try to find bloggers that have written about their experiences. Talk to the Twitterverse. Find a user group in your area that might be able to offer some feedback. The key is to find someone who doesn’t have a reason to be biased in their opinion. (Which is why I have a disclosures page so that you know what could potentially influence me, BTW.)

I personally don’t find much value in Gartner-style analysis reports. That’s not to say those reports aren’t of value, because clearly they are. Gartner and many others provide market analysis and product positioning for valid reasons. But that content is not aimed at engineers with networks to operate. Also beware of sponsored reports and tests that are effectively pre-determined outcomes paid for by the vendor that commissioned the report. Read the fine print.

Be Committed During An Evaluation

Evaluations of products your organization is considering should be major events for all impacted parties. Managers need to treat an evaluation like a project with priority, making sure staff has the time required to accomplish the work. Engineering staff needs to commit to a testing process, as well as define a list of “what we expect from this evaluation” goals.

Too often, evaluations are of the “we loaded it and it ran fine” type, without the sort of deep, structured analysis required to properly form an opinion of the product in question. That should never be, as any sort of IT product has the ability to impact all areas of the organization. A product evaluation should get the same care and consideration hiring new staff gets. New products are a really big deal.

Engage Other Teams for Feedback (even non-IT)

New products should not brought into an organization in a vacuum. New networking hardware affects the sysadmins and virtualization engineers. A new security product could have impact all the way to the end user. A new billing or CRM system could affect a great numbers of users. Migrating apps to the public cloud will have usability and performance implications that will impact users across the organization. The point is a simple one: very often, IT doesn’t buy technology – businesses do. When the business is a key stakeholder, then the business must be engaged so that they can provide input into the process. Even if the product doesn’t impact the business users directly, any new product will inevitably impact other members of IT. Everyone potentially impacted needs to take part in the evaluation process.

Don’t Overlook Open Source Options

Some businesses dismiss open source software automatically. This is often driven by policy or a generic fear of “who will we call if it breaks?” I am an ever-stronger advocate of open source as I go on in my career; I think leaving open source off of the candidate list when looking at new software is a mistake.

  1. Consider that many commercial networking appliances leverage open source software as a significant part of their product offering. This speaks to the relative maturity and trustworthiness of a great deal of open source code.
  2. Understand that the much-vaunted vendor support you’ll pay dearly for is frequently awful. Poorly-trained engineers, language barriers, lackluster response times, vendor support engineers reviewing the same public knowledge base you’ve already reviewed, internal escalations to more senior engineers because the front-line support is ineffective, etc. are all typical of the support you’ll get from a commercial vendor, especially the large ones with a follow-the-sun strategy. On the other hand, open-source software with any significant adoption will usually have a community built around it. That community is likely to be at least as comparable as paid vendor support, and there’s a decent chance it will actually be better.
  3. Open source software might not have every knob and lever a commercial variant does, but it’s frequently good enough. Considering the financial commitments needed for a commercial purchase, “good enough” might just be good enough in certain circumstances.

Consider Total Impact

Bringing anything new into a complex IT environment has an impact well beyond capex and opex. Yet, sometimes these far reaching impacts are minimized or overlooked. They should not be. It’s possible that integrating the new product is more trouble than its worth, no matter how shiny the considered purchase might be. Don’t rely on the sales team to tell you how easy it’s going to be to integrate the new product into your environment. Let’s consider the following.

  • Operations is often impacted by a new product. At the very least, processes and procedures will change to incorporate the new element. Workflows could be impacted. Data reporting and backup might need to change. Impact to the way the IT team does its work in light of the new product must be considered.
  • Infrastructure might be impacted. For instance, a VoIP system might require an upgrade in switching hardware to properly support PoE, voice VLANs, and a QoS scheme. A backup system might require more servers to incorporate new data and still complete the backup in a timely fashion. And so on. An IT purchase of any complexity is rarely an isolated one.
  • Staff might well require training to make proper use of a newly purchased IT resource. IT managers do their staff and their organization a great disservice by withholding training on new gear, but I find that training is often overlooked. Why spend $75K, $150K, or more on a new and probably complex tool, but then cheap out on $5K to teach staff how to use it? Believe me when I say that “looking over the shoulder” of the vendor performing the installation is not the same as proper, structured training. It’s silly to think that an engineer who’s never seen a given product will be able to grasp in a day or two what took a highly trained and specialized engineer months to become an expert with.
  • Physical infrastructure might also be impacted. Addressing data center planning for a moment, understand that any new hardware infrastructure will have power, weight, rack units, and heat characteristics to be managed. Physical data center space is almost always a concern. Power availability can’t be assumed; for example, a new Cisco Nexus 7000 chassis might require new power plumbing, increasing both project cost and delivery lead-time. Weight is perhaps less of a concern, but can’t be assumed in data centers located in multi-story facilities. Air flow and heat management is always a data center concern, and every BTU is (or should be) tracked. A hardware purchase must be done in light of the facility in which it will be installed. In the era of virtualization, software-only purchases can’t assume resource availability on physical hosts, either. Virtual appliances tend to be RAM intensive, and can also be rather hard on storage, depending on the nature of the appliance. And all of that says nothing of the required network infrastructure. Are there enough 1GbE ports available to uplink the new shiny (probably)? What about 10GbE (less likely)?

The point is be sure to make sure there’s an available hole to put your new shiny into.

Conclusion

Buying anything for IT is hard. If you think it’s easy, you might be doing it wrong. Think broadly about all of the people, processes, and resources that will be impacted by a new purchase. Then evaluate accordingly. Your IT engine is finely tuned data power source that makes your organization go. Any engine modification must be carefully considered.