Owning a cloud means learning to love the business

One of the problems with trying to improve things is that not everyone appreciates it. Deploying a private cloud is tantamount to saying that the IT department needs to become a service provider, at least in part. But it also means that the business needs to start acting more like a service consumer. In principle, there is a …

[jake]

Blah, blah, blah, blah.

I have a double-handful of clients with usable corporate computer systems spread across most of the continents on this dampish, muddy rock that we call "The Earth". Several are Fortune 500s.

Not a single one of my solutions contains the word "cloud".

"Distributed", yes. "Cluster", yes. "Grid", yes (one legacy system). "Centralized", yes. Even "Peer-peer" and "stand alone workstation with network availability on demand". Etc. But no "cloud", not anywhere.

IMO, "Cloud" is a reference to the old ISO OSI-model textbooks that used a "cloud" image to try to hide the actual networking layers below the so-called "presentation layer".

Enough non-technically-inclined managers "took a course" with outdated textbooks that this "cloud" nonsense entered the corporate vernacular when said managers moved into marketing (hint: If your school is teaching the OSI model, you're obsolete before you paid the course fee).

[Anonymous Coward]

But it's all about the marketing, you know

The "cloud" is now just another marketing buzzword that tries to package many different technologies and methods, some sort of new and some relatively ancient.

Here are just a few concepts and terms that currently nest under the mantle of "cloud" technology.: "virtualization", "hardware-abstraction", "dynamic resource allocation" and "elasticity". Most of these concepts are a bit too complex for mere mortals to grasp. A simpler code word was needed, and so the term "cloud" was re-incarnated and now everything has become cloudy.

The best definition I have ever heard for cloud computing was that "it is a better way of doing things". But so were (are) grid computing, centralized data centers, client server systems, peer-to-peer and many other bla-bla terms, all quite good when fully understood, suited for purpose and deployed correctly.

At the end of the day, we should only use the solutions that work best or are the most afforable and profitable for a customer at the time. Calling solutions "cloud computing" is not enough, they must also provide value. The cloud will be what you make it, nothing more, nothing less. But try to explain that to a PHB..... you'll have better luck explaining it to the CFO.

[boony]

Re: Blah, blah, blah, blah.

Total agree with you Jake.

I work in technical pre sales for a large telco and have had to face "training" on how to market what is basically a comforting term for distributed, cluster, mobility, lower capex/higher opex etc

I hate to use the term "cloud" in my decks and won't when talking with my customers techies as they understand that it is all about the network, security etc. However, as procurement directors are usually project sponsors, you have to dumb down somewhat and say the word through gritted teeth. Cloud is merely a way of saying something simple about something quite complex to an audience that is only interested in bottom line.

I did get some nice goody bags from Cisco and HP though - including a mug that glows when it has hot water in it and a pen with a laser pointer - you can't say fairer than that for £2,250 per delegate

[zanshin]

I agree!

Buzzwords aside, there are some very good observations here. Whether one lays it at the feet of "the cloud" or what-have-you, the combination of greater compute power (faster CPUs, network, more memory, etc.) and improving IT efficiencies in deployment of that power (increased automation, virtualization, etc.) mean that IT departments need to be delivering more "oomph" in the same timeframe, or there's no return on investment in actually having all those new capabilities. And my experience does agree that taking advantage of this is going to usually be disruptive of existing IT culture, all the way up the IT delivery chain from VMs and network to middleware stack to the main application developers.

One thing, though, doesn't change - the need for quality requirements. All the fancy IT infrastructure in the world is only going to let someone with poor requirements deliver the wrong product faster. That may seem like a good thing, but if your business customer is choosing between you and another provider (internal or external) and they too share your turn-around speed (and eventually, someone will), then the best investment for the customer is the IT delivery organization that gives them the product they need (or at least want), and not the one with the coolest IT toys.