Owning a cloud means learning to love the business
Start a beautiful relationship
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 lot to like about the new arrangement. Service delivery becomes more efficient, deployment becomes faster, systems run better. Otherwise there is no point in adopting the private cloud model in the first place.
While effective private cloud operation enables more control, it also means more controls and potentially more bureaucracy: “Yes, of course you can have a three-server cluster for your research, just fill out these forms in quadruplicate and get them signed off by the King of Denmark.”
The enemy within
Let's face it, distrust between business departments and IT sometimes goes so far back that nobody can remember what caused it. IT managers are frequently viewed as the people who like to say "no". Anyone who has worked on a support desk knows what a thankless task that can be.
One of the benefits of private cloud is that it offers an opportunity to change the relationship between IT and the business. You need only look at best practice in the way providers deal with customers.
Think of a spectrum: at one end, commodity services delivered at the lowest cost and minimal interaction, and at the other full-fat solutions needing in-depth engagement.
All roads lead to service provisioning
The controls you need in place work across the whole spectrum, in that all roads eventually lead to service provisioning and configuration.
So, is the resulting model really that different from having business analysts conduct requirements capture and service design exercises?
The answer is, it doesn’t have to be. However, while development teams have moved to more agile models in which backlogs of requirements are catalogued and delivered on a priority basis, IT systems delivery and operations is rarely so dynamic.
So what does a good IT-to-business service relationship look like?
All present and correct
Sure, there will be systems and services that just do their thing, unchanging apart from the occasional version upgrade or maintenance tweak. Assuming performance is adequate, these need little more than reporting that all is well.
But in addition to just keeping the lights on we have new service delivery. The less time spent on one, the more will be available for the other – unless you have a particularly draconian finance director, that is, in which case you are unlikely to be taking the private cloud path in the first place.
The key is to integrate the same level of dynamism across both the service definition and delivery process.
Without boring readers with the maths, a simple service delivered quickly can generate far more business value – that is financial return – than a complex one that takes months or years to deploy. It is all to do with compound interest versus development costs.
So, yes, we do need IT-literate people engaging directly with business-literate people to decide exactly what new facilities the private cloud can deliver this month. Or even this week. It may be pie in the sky for some IT departments, but that doesn’t make it wrong.
Not my job, guv
There are plenty of hurdles, not least the common but ultimately unhelpful cry from the business that anything technology-related is "IT’s problem”. But any business today that thinks it can get away with deferring responsibility for IT decisions is living in the last century.
Technologists may also need to change. Bad experiences and the very real complexity that still lurks under the bonnet of the data centre have driven IT people further into the comfort zone of technical geekdom than is helpful.
Every organisation needs its IT crowd, those people who can read the hieroglyphs on the front of the network analyser or identify the crushed patch cable with a cursory glance.
But if private cloud offers an opportunity, it also throws down a challenge to the IT department.
It is only by speaking to the people at the coalface of the organisation in their own, non-technical language that the real opportunities for technology to make a difference can be identified.
You never know, one day the business might even thank you for it. ®
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).
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.
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