As a Solutions Architect with over 25 years of experience, I have participated in a large number of requests for information/proposals (RFI/RFP) and other technology evaluations. Often these evaluations include extended long and detailed lists of requirements and features. Due to my deep industry experience, I can easily recognize some patterns in how these lists are created. These lists are either based on the market leaders’ datasheets or information from 3rd party research documents that heavily draw from the market leaders’ datasheets. We can easily identify a circular loop of information which can lead to a few problems:

1. Feature Bloat - Products are developed over time and customers need backwards compatibility. This means products accumulate features that may or may not be relevant anymore. This creates a bloated architecture with high points of failure and performance bottlenecks.
2. Solution vs. Feature - Features can often be defined in a vacuum and too much in terms of a single vendor’s implementation. Additionally, features are often a fraction of the problem they are solving and need to be holistically examined by looking at the larger goal or the solution needed.
3. Future Outlook - It’s difficult to predict the future and even more difficult to quantitatively pick a product or vendor based on future performance or features. Value often lies in how the product can be used today and incorporated into future technologies. Feature lists cannot describe the direction of the product or the focus areas for development.
4. Weighting - How do you determine what’s important? If you are new to the technology, then you might not know relative value. If you are experienced, then you might have bias towards your existing vendors’ strengths. It is important to correlate the required solutions to the cost, quality, performance and reliability of the platform.

This problem is manifested in product segments that have become commoditized in the last 5 years.  The incumbent vendors in areas like traditional virtualization have, in many cases, 20 years of backward compatible features thus creating massive product complexity and costly support structures. End users unknowingly pay licensing fees to support the software development, testing and support lifecycle of such products. As a product becomes commoditized, it starts to follow the same 80/20 rule that was popularized with desktop productivity apps, namely:

80% of the customers are using 20% of the features

Personally, I am excited about the trend in the industry towards open source, microservices, product ecosystems, hybrid platforms and API driven solutions. This trend shows a grassroots demand to develop more focused solutions that are able to free themselves from the burdens of legacy bloat. Each of these trends are designed to more easily incorporate new features from a range of sources and rapidly deliver new innovation that helps organizations bring their products to the market faster than ever.

Software Evaluation Guidelines

The below guidelines outline steps that you need to take while evaluating technology solutions that are part of an adoption process in the open innovation world.

1. Datasheets Don’t Have All the Answers
Although datasheets are a great place to start, consider them to be a part of a larger ecosystem of information. Datasheets provide a quicker way to learn about the product scope and help you to figure out if there is a match with your mental list of 5-10 must have functionality.  Just remember the 80/20 rule mentioned above and look at other available sources of information before you make your entire decision based on the content of a datasheet.

2. Focus on Solutions not Features
Focus on the challenges that you are facing and the IT goals that you have for your infrastructure. You should closely examine your pain points, problems and the benefits you are trying to realize. Answers could vary including deploying 1 product, a combination of additional products or you might need to look at a completely new way of solving challenges. You will be surprised how often “out of the box” thinking will lead to a far superior solution. Just because “that is the way we have always done it”, does not mean that is the best way to solve your challenges.

3. Don’t Try to Be Jules Verne
Unlike the science fiction writings of the famous writer Jules Verne, the future of the IT infrastructure is hard to control and predict. Making big bets on specific technologies will only create the white elephant, or years of lock-in. Therefore, the simplest way to future proof your selection is to consider how the new features and technologies will integrate with your existing solutions.  Look at APIs, plug-in architectures, and community ecosystems.

4. Try Before You Buy
We live in a “post shadow IT” world. Most enterprise vendors provide trial versions of their software. Technology adoption in the enterprise today is all about rapid prototyping solutions. When evaluating a trial version, remember it’s not just about the ease of the download and the install. It’s not about ticking the box on the UI to make sure that datasheet features work. Can this product solve your specific use case? Does the solution check off your list of requirements and help you to do your job better than you were doing before?

The short list above should help you to avoid the feature war that you often face when evaluating solutions to help you solve your challenges. As an industry, we are starting to learn that you create business value by selecting technologies that enable you to rapidly innovate through open and transparent access to products, features, and knowledge. Red Hat is a technology partner with these principles at the core of everything we do.