« Doing More With Less: VCE Vblocks and EMC UIM | Main | A Transformational Gathering of IT Leaders »

October 18, 2011


Martin G

The biggest mistake is believing that you need a large team to make this happen. You don't; you can start small and with commodity; you can build a cloud to support testing environments which can be brought up quickly and easily for example. You can learn a lot from this approach; you may still decide to go down the VCE route but you won't waste a huge amount of time either. This is not rocket science!

You can make this as complicated as you like I guess but as soon as it gets complicated; you've probably gone wrong. My advice for most people, start small and don't try to boil the ocean.

If you or your teams can't build a commodity cloud in less than month; you've employed the wrong people. Harsh, I know!

Chuck Hollis

Hi Martin

I do agree -- quick, low-cost "experiments" have a role in any new approach to technology, and that includes cloud-building. If you can afford to have something fail, you're in good territory. And there's lots to be learned about the second-order challenges in the process.

But that's not what I'm seeing. We're talking big projects with big budgets and big outcomes at stake.

And that's really scary when you see it.

-- Chuck

Martin G

That's because people are being told 'We must have Cloud...*NOW*' often; these might be either external or internal pressures. How many people go into these big projects with little idea of what the outcome should be? Just wanting to build a Cloud; that's not an outcome...that's playing with technology for technology's sake.

There's a lot of confused people wandering around technology departments at the moment; flustered and flapping, threatened by Cloud but not knowing why. Which is pretty much a perfect scenario for vendors...

Mike Foley

I suppose if I was told I had to drive from here to the West Coast for an important business meeting I could buy a bunch of parts and put together a car that beats a Honda. Or, I could just go buy or rent a Honda and get on with the trip. (which is what my boss asked me to do!)

I'm hearing similar stories. I ask "How frequently do you build cars?"

Jo Maitland


Interesting post. I imagine you have considered that when you have these conversations with customers, they:

a) keep both hands firmly in their pockets holding on to their wallet
b) are not under a big time crunch to build a cloud NOW
c) do not get opportunity cost(IT dept is rarely made aware of how integral they are or could be to the business as the business side doesn't trust them and or has low expectations of them)
d) think your product automates away their job
e) keep both hands firmly in their pockets holding on to their wallet.

That's my experience in talking with your customers.


jamal k

@Jo, you forgot f) are petulant assholes with an axe to grind.

Wesley W

Oh the anti-engineer tone of this post and some of the comments is disturbing. Lets turn this negativity around: You want to sell VBlock and the biggest obstacle is the technical staff. So you make a blog post from your perspective as a manager/sales person: technical folks are basically self-serving Dr. Frankensteins and if only you could just bypass them and get a business person to pull the trigger on a VBlock sale...

I know that isn't true. Look, Cloud is a cluster*&#! right now. I'm not even sure what it means anymore. I'm being sold by Cisco network virtualization solutions "that are not VLAN based" because VLANs are not secure. My security folks and our auditors tell us VLANs are not secure. But VCE produces a secure multi-tenant document that says VLANs *are* secure. The "C" in VCE stands for Cisco, no?

And yes, Vendor lock-in is an issue. Its clear VMWare and Cisco want to rule the world. However in recent years we've discovered that other vendors have competing products that are sometimes better. We can negotiate prices down with vendors by being multi-vendor. The results speak for themselves. VMWare and Cisco loathe this greatly and engage in shady sales tactics to get their way. They hijack standards bodies and they refuse to integrate with existing virtualized platforms. Just ask the Service-Providers. The IETF is just now coming around to addressing some of the shortcomings of VM/network integration.

So why should I dole out a pile of cash? Oppurtunity cost? An intangible and largely made-up percentage that I can't quantify that passes me by with 40 other percentages on someone's sales deck?

We're profitable now. Our customers are happy. I think I'd rather wait for the dust to settle. In the meantime, we can address the shortcomings with enhancements to our existing infrastructure/product portfolio using commodity and open source solutions.

Chuck Hollis

Hi Wesley -- thanks for the thoughts.

My intent was not to be anti-engineer, or to endorse any one vendor's approach over another.

The decision to invest in a robust engineering function to create a home-grown environment is an important decision. Since there are now alternatives, those must be considered now?

You (and your co-workers) are not free. Nor will be the technical folks who end up supporting whatever it is you create.

Opportunity cost is difficult to measure at the IT level -- that's a business discussion. However, the ability for IT professionals to coldly tick off bounded alternatives for achieving said business goal (pros *and* cons) is useful, and -- it seems -- very rare indeed.

Your vendor rant is understandable. Vendors are vendors. Engineers are engineers. The interests between the two groups are not always aligned.

You didn't mention anything about your organization and what it does -- enterprise IT, service provider, something else. It'd be easier to have a more nuanced discussion with specific context.

Thanks for writing

-- Chuck


This project is suffering from a lack of executive leadership/sponorship. Have seen this many times in the past, as soon as the bravado of open source and commodity HW appears, you can bet with almost complete certainty that there is little connection between the science project and the business itself. The reality that this teams fails to realize is that if this is truly a best use of the firm's scarce resources, then every day the project is not funcitonal represents opportunity costs to the owners of the business. It is very frustrating when you see a train getting ready to go off a cliff and all you hear is that the costs are low and that there is no vendor lock. Really? Is that this project's value to the firm or is the value better, more agile, optimmally aligned I/T services. I wonder which is more important to the executive suite?


Not so long ago, rich people bought cars on the basis of how they looked, how they enhanced their prestige and then hired a chauffeur to clean, maintain and drive it. You would have never tried to sell a horseless carriage to the chauffeur.

Taken another way, the majority of folks in IT are there for the technology. Had they been more interested in business they would have gone down that path and probably be earning more money as well.

With outsourcing and solution oriented vendors, the IT folks feel threatened. To the management they are a fungible resource which leads to job hopping and with that their primary investment will be in their technical proficiency.

Judging how the motor vehicles all but drive themselves to a voice given destination, the best technology focused folks will either end up working for a vendor or outsourcer or go the way of the horse buggy whip makers.

Ken Carroll

Having experienced and fought against this issue on many occassions, I think you have absolutely hit the nail on the head with this post. I believe you have also pinpointed the solution, which is for IT companies to forge relationships with business management.

The challenge is that IT people are naturally interested in developing IT things - it is FAR more interesting and self-satisfying to create your own framework for X than it is to simply use one (commercial or open source). However, if your employer is, as cited in your example above, a financial services company then their real & primary interest is in servicing their customers. Customers don't care if you create the circuit boards, write the O/S and extrude the CAT5 cables too - all they want is good service. If IT people in a non-IT company spend a lot of time on infrastructure creation & maintenance then they are wasting time as they are not contributing to producing customer perceived value.

Not all IT people are like this but unfortunately there are enough smart & capable IT people in non-IT companies who act as if they are working for IT companies and so they concoct justifications for allowing them to create infrastructure solutions. It is very interesting and challenging work, for sure, but absolutely a complete waste of time to do in an non-IT company.

What is often forgotten is that creating something, e.g. software, also creates mistakes/bugs and only extensive usage in many different contexts will rustle out those mistakes/bugs in a reasonable timeframe. Creating your own homegrown solution limits the amount of usage and context variations such that mistakes/errors/bugs live on for a long time and result in many outages & problems popping up. Using, instead, widely used commercial or open source solutions is extremely effective in overcoming this issue. Everyone I've encountered who reinvents the wheel has a tendency to turn a blind eye to this and I've seen it cause SEV-1 outages as a consequence.

The challenge is that with very smart IT people leading other smart IT people, they somehow seem to get enticed into continuing to do interesting IT things. This tendency permeates up & down the full hierarchy of IT staff, from the top leadership on down. I have seen it repeated so much that it just seems to be a basic human condition - smart IT people have a tendency to want to do 'smart' IT things such as reinvent this & that.

The only solution, I think, is for IT vendors to forge strong relationships with the business management to whom IT is accountable. These should be considered peer customers of your IT management in a company. It is difficult to see any other way to ensure that the checks & balances helping enforce accountability are in effect.

The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    Chief Strategist, VMware Storage and Availability Business Unit

    Chuck works for VMware, and is deeply embroiled in all things software-defined storage these days.

    Previously, he was with EMC for 18 years, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Holliston, MA with his wife, three kids and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not buy him a drink when there is a piano nearby.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!