[My main title is inspired by my current reading – the God Delusion by Richard Dawkins]

I recently took a trip to Palo Alto to VMware’s Corporate Head Office. It was chance for my team to get together, looking back on last year and look forward to the new one. It was such a treat to put faces to names that I’ve heard on the end of concall for the last 12 months. On our second day we had a bunch of people from across VMware present to us. And in one of those sessions I had one of those “light bulb” moments. Like all light bulb moments, or moments of epiphany – the insight I had feels like it has always been there. In truth I’ve had this blogpost in my draft folder for more than a year – but it took the presentation last week to crystalize it for me.  The talk was about how products are selected by large corporates, and the dynamics that fuel the process of implementing a C-Class executive initiative.

The process begins with C-Class starts an Executive Initiative identifying a business need – this will hopefully result increased profits by increasing revenue; decreasing cost or decreasing risk. In the best of all possible worlds (to quote Voltaire for a moment) you would hope to achieve all three. The likelihood is the executive team have balance risks against rewards. Further down the management chain these Executive Initiatives trigger the creation of programs, and then projects – which ultimately lead to tasks being carried out by the “doers” in the organization. Budgets are aligned from the Executive Initiative to various Programs and Projects. So even if a particular Executive Initiative comes with million dollars worth of budget, by the time it is diced and spliced, and trickled down to the Project Team it has been shared out amongst a number of Projects competing for funding. It’s from this that the pressure to save money is driven – either keep on budget or qualify for a bonus by bringing the Project in on time and on budget. And this precisely why and where the “good enough” delusion starts to rear its ugly head.

The term “Good Enough” is often used to describe a technology or process that’s adopted because it meets the perceived bare minimum requirements for the problem or task at hand. Quite often there is a much more functional, flexible and more advanced technology available. The trouble is that superior product is sometimes slightly more expensive than the “good enough” solution. This was something I used to see a lot of back in the previous decade. Customers would complain about the cost of VMware or the cost of Microsoft SQL licenses for vCenter. But when looked at in a broader picture their virtualization initiative the customer was spending four times as much on the acquisition of storage. I’m sure you’ve heard of the adage that for every $1 spent on VMware; $4 is spent on storage.

Sadly, that appeal to look at costs with the wider context of a massive Executive Initiative often fell on deaf ears. Despite the fact the technology might contribute just 1% of the overall initiatives budget, by the time the folks who are running the Project are given their stipend, its now become 25% of their budget. The issue is often distorted by the way budgets are aligned to various silos within the organization. Where the cost of a technology isn’t seen because it doesn’t come out of that business units cost center. This contributes to resources being “free” because the burden of paying from them falls on someone else balance sheet. Increasingly, I feel our IT structures or silos (InFRUSTuctures as I like to call them) create a dysfunctional culture in many organizations. To the server team – I’ve often seen/heard that the network and storage is “free” because that “spend” comes out of someone else’s budget. I know this is an over-simplification, but bear with me.

It’s within this context that the “Good Enough Delusion” evolves. I can see the seductive appeal of the “Good Enough Delusion”. In fairness on paper the “Good Enough” delusion is totally understandable and logical response to these business pressures to bear down on costs – and I have every sympathy for those who are convinced by its seductive message. Especially as In my career if often witness customers being “over sold” on a technology. In other words they have been sold a product that’s far in excess of there needs and requirements. I’ve sometimes used the metaphor of the car sales man selling a little old lady a Bugatti Veyron to take her to the shops and back, and to see her grand-daughter on a Sunday. The causes of this can be merely the salesman miss selling a product in order to fuel their short-term commission. Perhaps less provocative reasons is the engineer over-engineering a solution to both cover their own back (called CYA in the trade!), but also to protect the customers from blowback. In this context the “Good Enough Delusion” is an attractive strategy to protect the business. The “Good Enough Delusion” drives down costs, and keeps your budget on track. So long as you spend time carrying out due diligence testing to make 100% sure that your needs are being met by the solution. Right?

Wrong. The problem with “Good Enough” lies in those very words. You can soft-soap it and couch in terms of “but it meets our needs and requirements”. But to admit something is “good enough” is to tacitly admit that you have selected a less than “ideal” solution, when something superior was available. That’s what is the hidden kernel truth at the heart of the phrase. And it’s for this reason you often see “good enough” solutions deployed in scenarios of low-risk, as a tactical play rather than a strategic one.  The classic example of this is using a “Good Enough” technology in Test/Dev and “Best of Breed” in production. I think a good way to undermine this bifurcation is to ask this simple question. You know that “Good Enough” solution you’re using in Test/Dev – would you trust it in production? Would you risk your organizations operations or stake your career or the success of the overall initiative by using a “Good Enough” technology in a production scenario. Nine times out of ten, the answer that comes back is NO!  At this point we are admitting that good enough just isn’t good enough.

In our community there’s been a lot of chatter about the adoption of a “multi-hypervisor” strategy. Personally, I hate this phrase because in our current period the game has nothing to do with the hypervisor – and everything to do with the comprehensive platform include a control plane of management technologies that cluster around the hypervisor – and the VM. Customers often flag up not wanting avoid “vendor lock in” – which is always pretty laughable considering how overcommitted and “in bed” they are with other dominant vendors (Cisco, HP, IBM, Microsoft, etc…).   For me the multi-hypervisor strategy just increases cost and complexity by having to have multiple management systems, and staff capable of driving both systems. Many of us as spent years developing automation and business process around VMware technologies – are we going to jump into the TARDIS and redo all that work again? Additionally, I perceive a very strong risk associated with running test/dev one system, and production on another. This is particularly true if that test/dev environment serves as sandbox for QA testing, and staging up solutions ready for production use. Ever since I was SysAdmin in the 90’s the adage of “reduce your differences in your environment” is one I’ve held to – it reduce complexity, costs and risks.  For me the “Good Enough” approach in test/dev introduces the unnecessary risk of undermining the overall such of the CEO initiative.  It drives up complexity and cost maintaining multiple systems that duplicate each others functionality under some false notion that it will save money especially as such a business critical layer – The Good Enough Delusion.

There’s many difference ways of taking this rather abstract argument and translating that into something an ordinary human can understand. I often begin with famous quotes that in a pithy way wrap up the idea with neat bow. Try these on for size:

Penny wise, Pound foolish From the ‘The Historie of Foure-footed Beastes’ by Edward Topsell Robbing Peter to pay Paul Biblical in origin, first quoted by John Haywood, 1546. One ounce of prevention, is worth a pound of cure Ben Franklin, 1736

All three of these quotes essentially make the same vital point. Trying to save money in the short-term can cost you money in the long term. A more academic way of expressing this is the term “a false economy” where a perceived cost saving actually results in greater spending later on. By overly focusing on nominal savings and squeezing the pips on those – you loose sight of the bigger picture, the bigger Executive Initiative. It’s like my customers belly-aching about the cost of Microsoft SQL license for the vCenter database – whilst simultaneously writing an enormous cheque with lots of zeros to their storage vendor. To use a more American reference, I’ve seen plenty of solutions undermined by people “nickel-and-dime” their customers.

For me, another way of illustrating the limitations of “Good Enough” delusion is to think back in my career looking for cases where it was used. In the 90’s the company I worked for needed disk imaging solution for rolling out a large number of PCs. The market and technical leader was Symantec Ghost. The company didn’t buy it. Instead they bought a competing product that was cheaper. Everyone in the company knew that Symantec Ghost was the more reliable, and performing technology. Instead the decision was made to acquire a product almost no one had heard of [I’m protecting the guilty by not mentioning it by name!]. Sure enough, the “good enough” technology was okay. But every 2 out 10 operations would fail. This meant the SysAdmin had babysit and nanny the “Good Enough” solution because it could be relied to failed every 2 clones. This meant many long hours staying behind after business hours, and coming in at the weekend to mop-up the failed jobs. This time could have been better spent doing some real productive work, rather than nursing maiding this technology. The situation got so bad, that many employees bought a personal license for Symantec Ghost and used it without senior managements knowledge. Of course now we would call this “Shadow IT”….

Another way at looking at the “Good Enough Delusion” is to be honest about how we behave as consumers and as employees in the economy. I’m going to be changing my car in the next couple of weeks. I’m currently driving a rear-wheeled power two-seat roadster. I bought it 2007 as a “pre-middle life crisis” car. That was my joke with the wife. I needed this totally impractical car to pre-empt a fully blown mid-life crisis that is usually accompanied by dyeing ones hair, buying a red Ferrari – and acquiring 18-year-old girlfriend. Where I live now this car is totally impractical, when the snow sets in I won’t be able to get through the country roads and hills. So I’m switching to SUV – I’m looking for combination of good fuel consumption; engine size; and reliability. The way I see it I have series of attributes – just like we would have with an IT purchase such security, stability, availability and performance.  I’m going to work my butt of get the best vehicle with the all the features – at the price point I can reasonably afford. I won’t be settling for good enough solution to save myself money – only to discover that when get up in the morning in the ice and cold – to find the SUV won’t start.  Similarly, when I turn up for work – do I aspire to be just a “Good Enough” employee – or do I try to exceed expectations and deliver a quality of service – above and beyond clocking in and off at the end of the day. If good enough is not good enough for my personal purchases or the services I deliver to my company – why is “Good Enough” approach for enterprise technologies that provide mission critical applications to thousands of users?

Here’s where I see the gaps in “good enough”

Superior Solution	Good Enough Solution	Risk
Proven technology / application in “real world” environments	The vendor only says its proven or good enough	loss productivity to deal with unforeseen shortfalls
Established skilled workforce	Training to include another solution	Cost of training and exploring the “unknowns”
Proven in production	Good enough for test/dev	Cost of migrating workloads / buying addition tools – more skillset required. Reinventing the wheel in operations…
Managed workloads as part of the platform	Incomplete management	Increased cost & complexity

For me the whole problem with the “Good Enough Delusion is that it just not Aspirational Enough. It’s admission that the design is a subpar configuration of cobbled together technologies that could well undermine the overall success of the solution, and a consequence the initiative itself. We should be striving to make things better – exceeding business expectations whilst remaining on time, and on budget. Instead of nickel and diming the businesses investment in its infrastructure. Without a proper investment in our physical and virtual infrastructure we run the risk of the levees breaking….

Now, of course that doesn’t mean we at VMware are complacent about cost. It should be of no surprises to you that a company who drove massive efficiencies and costs savings in the Virtualization 1.0 era – is still focused on driving as greater efficiencies beyond the compute layer. Remember its VMware who first brought that innovation to the mainstream x86 market places, not the also-ran vendors who were content to allow the status quo to prop-up their revenue streams. That’s the message at the heart of the SDDC message – the efficiencies and cost savings VMware brought to the computer layer – now need to be extended to the network, storage and administration. vSphere isn’t the end of the story – we have only just begun…