Blog: Making the Case for Good Enough in Modern Technology Selection

Welcome to the Think Tank with Frank Kenney

With decades of analyst and integration industry experience, Frank Kenney is a fountain of knowledge on all things tech. Now, he aims to share that awareness with you. Come back every other Thursday for your biweekly dose of thought leadership in this blog from one of technology's most insightful thinkers and gain perspective on a variety of topics ranging from what's happening in integration today to what's on the horizon, poised to disrupt the integration space going forward.

***

I used to have these long drawn out debates with my colleagues about the importance of technology. (If you've been keeping up with my other posts, you may recognize this as a recurrent theme.) They argued that an independent software vendor (ISV) had a responsibility to build high-performance, incredibly resilient, and innovative technology, with a firmly held belief that if an engineering team could achieve all three, an ISV would be best positioned to capture a market (with everything else like marketing and sales being equal).

I took the opposing stance. I felt that even the most innovative technology, the solutions that over-perform and never experience any downtime will have a hard time competing with technology that's just good enough. Every so often I still have this conversation with my current product team, who I consider one of the best I've ever seen.

The Principle of Good Enough

The principle of good enough is a long-standing IT concept that is often used by the procurement team to help whittle down the list of potential vendors. As you can imagine what defines good enough is particular to the type of technology and the applicable use case. Furthermore, good enough is not about parity it doesn't mean that all vendor offerings are equal in terms of features, functionality, or capabilities. Rather, it simply points to the fact that a specific technology or service is just good enough to meet the intended requirements of a project or initiative.

Determining the Stakes of a Project

The designs that I made for my newest custom Lego project (yes, that is the thing for me) fits the good enough principle in that it is good enough for me. However, the standard by which what I determine good enough as it applies to a personal Lego set would never cut it in the field of aeronautical engineering. If one of the buildings in my Lego city isn't stable, not much is at stake beyond my pride. On the other hand, what is the cost of not being good enough when designing an airplane that will eventually fly at 600 miles an hour, 36,000 feet above the face of the earth?

Due to the importance of application and business data to lines of revenue, operations, and trading partner and customer relationships, selecting new integration technology is high stakes. Therefore, it is the responsibility of the procurement team to work above the demarcation line of good enough. That said, where that line falls is sometimes hard to determine.

Good Enough vs Differentiated

Let's consider the current integration platform as a service (iPaaS) market. Gartner is tracking over 100 different vendors at this point. Take a minute to let that number sink in. Across such a large field, the differences become harder and harder to spot. While most iPaaS offerings will be good enough, it is the differences that make individual offerings stand out.

On this note, the advice that I would give any product team is to make sure to understand where to provide technology that's good enough  to solve a variety of common issues, and where to spend the remainder of their intellectual acumen, domain expertise, and creative prowess to strengthen and deepen the places where they differ.

And that's what I found in the tens of thousands of IT users I've talked to over the last two decades. They care most about the deltas. Even when their RFIs and RFPs have hundreds of line items, most of those stated requirements describe what's good enough.

I'm often asked to look at some specific functionalities of cloud integration platforms. How well-defined are the interfaces? How much customization and nuance does the transformation engine allow? How minute or precise can we get with the business process modeler? These questions are important and help zero in on common table stakes. But, after I've answered all of these, I ask a series of my own questions:

• How much of the stuff do you need?
• How well does it have to be?
• What is just good enough?

If you consider the last question essential in determining the viability of a cloud integration platform, I would argue that the principle of good enough is an axis that should be measured, and ultimately used in technology selection.

Technology Comparisons and Mapping Good Enough

Let me propose an alternate way of looking at the various graphical comparisons that different market analyst firms provide that attempt to rank and contextualize the top performers in a market.

Let's say for instance I decided to come up with the "Frank Kenney Line of Power."

In actuality, it's just a simple line with a few points plotted out linearly. Now, let's say I can use this line to rank different vendors on their relative "power in a market." I'm not sure what power means in this case, or even if it matters for the purposes of this exercise, but feel free to play along.

Now, pretend you need to buy technology from a vendor in whatever market this is. Looking at the line of power, you would be drawn to the vendors far out to the right. In other words, a vendor that's closer to a 10 on a scale of 10 certain appears better than a vendor that falls closer to zero.

But what if I told you that after doing extensive market analysis (again for this example I'm not looking at any given market), I have determined that there was a point of good enough? That any vendor to the right of this specific line is going to have technology that is good enough to meet 80% of the required use cases.

As you can see vendor C is ranked better than vendor D. However, vendor C falls short in comparison to vendors A or B.

I could be even more dramatic I can tell you that there are two additional intersection points that matter. They involve risk and cost.

Any vendor that is plotted on my line outside of "the zone of goodness" will likely increase the risk of failure of the implementation and will also likely be very costly.

Market Axes

These axes exist in every market. They also exist in any market infographic. They may be implicit, but they're there. In most cases, you have to ask the author of the report where they would draw the line for "just good enough."

Hopefully, I've made you think differently about how to evaluate and procure your next technology investment.

***