Don’t Kill the Messenger: Explaining to the Board how Planning for the Cloud will Help the Business

What we need, in our dual-roles as both technologists and business-analysts, is a sort of kit bag of tools we can use to explain in simple, low-jargon, understandable language to say, the CIO or other C-level executive of a business, how a move to the cloud will benefit the organisation.

It’s a problem more of communication than anything. They’ve all seen the latest, greatest things come and go like fashion. There’s no doubt about the debate and hubub around cloud technologies, but it’s pretty confusing.

It’s like when you take a family holiday. You get back after 2 weeks in the sun and perhaps buy a newspaper at the airport and you realise “whoa – a lot of stuff has been going on”. You come straight in to the middle of 1 or 2 big news stories and because you weren’t there at the start, it’s confusing.

That’s what I mean when I say the cloud is confusing to non-technology audiences. There’s a lot of buzz about it in business circles and even in the mainstream media. But they are coming in to the middle of the story and it’s like a news story. It’s an evolving feast. There is no definitive story. It’s not like looking up Newton’s laws of physics or Darwin’s theories of evolution. In every business-focussed cloud presentation I’ve ever seen, there’s an attempt at a definitive explanation of what the cloud is. They try to distil it in to one or two sentences. These things often end up looking like company mission statements. I’ve seen some of these mission statements that are so far up their own backsides they can see daylight at the other end. “Cloud Computing is the Egalitarianism of a Scalable IT Infrastructure”. Well, yes it is, but it’s more than just that – and does the language help somebody who has come along to find out what it really means. Hmmm – I’m doubtful. Perhaps the eyes of the CIO who has just had his budgets slashed glazed over at this point. Perhaps the CEO has no idea what a “Scalable IT Infrastructure” is or even why his car-manufacturing business needs one.

I personally think the notion of trying to reduce a description of cloud computing to the most compact statement you can create just leads to more misunderstanding.

However, when you talk to technologists like us – we can all identify with the 4 key workloads that are very suitable to cloud computing.


As technologists we can all immediately relate to these diagrams of load/time. These are not the only uses for the cloud, but they are the key uses. However, the C-level audience rapidly starts to lose interest. They have to have the stories associated with these diagrams, before they get to see the diagrams. Showing the diagrams after we’ve told the stories gives us credibility because it proves we’ve done our homework.

For example take “Predictable Bursting”. In my opinion, we avoid that language until the story has unfolded. We can say something like “I know as an online retailer, you run ad-hoc campaigns to promote certain products or services. I know some of these campaigns are massively successful and others don’t quite hit the mark. I know you have difficulty predicting which ones will be successful – you’d never run a campaign in the knowledge it would be unsuccessful. But in order to give your customers a better experience than your competitors do, it’s important that the service is there, doesn’t break down, is fast and doesn’t give an inconsistent experience. So you have to build the campaign’s IT requirements around the fact that it will be a massive run-away success”.

It’s only after we’ve articulated stories like these, in every-day language, that we can then show some slightly technical diagrams (which are also business diagrams, but they only become business diagrams after business stories have been articulated first). The technical diagrams give us credibility and put meat on the bones of the stories.

The cloud can often look simply like some new form of outsourcing. It’s not. All customers are treated the same. The contracts are, largely, non-negotiable. With Windows Azure, if you as MegaCorp buy a service, you get the same SLA as me. You’ll probably be getting a discounted price because at the Enterprise level this can be done by a licensing agreement, but the service you get will be the same as the service I get. It’s the consistency of this approach which makes the cloud so economical. A traditional outsourcer would be wanting to sell additional services – people, processes, data-centres, operations and so on. With every contract being utterly unique, the costs inevitably go up. Cloud operators sell cloud services.

So much is being said about the financial benefits of the cloud. Certainly moving from a Capex to a (much reduced) Opex model would grab the attention of any bean counter. But I believe we concentrate on that point at the expense of other points – the most important one I think, being agility.

This agility though, can be a double-edged sword. I remember, back in the early days of the PC when organisations were slowly moving away from Mainframe and Mini-computer based green-screen infrastructures to PC based client/server computing. Little islands of PCs would appear to deal with some very specific problem, usually with no involvement from the main IT function. Managers could buy a few PCs with their budgets and justify it easily with a business case that seemed to work. Of course these “deployments” were rarely thought through with the same rigour an IT department would give to such a project. When the PCs failed, the users would naturally call IT who’d say “nothing to do with me”. It was quite a disruptive time for many businesses. IT departments tried to get control of these deployments and business managers began to see IT as a blocker to doing business. There was a bigger case they were unaware of. Their actions generally had a wider impact on the entire business.

It can be a little like that with the cloud. Because complex compute services can be bought, in some cases, simply on expenses, there is a tendency to think of the cloud as a super agile platform. That is agility in the sense that from the conception of an idea to having it deployed as a service can be incredibly short. As long as it doesn’t undermine the other IT functions, cause other inconsistencies in data or applications, then that’s great.

I think we can therefore say that cloud affects not only IT, but many other stakeholders in the business. Indeed, in many (most?) cases, it will be these stakeholders that experience cloud computing before IT departments do.

So what are the things that business managers complain about? I think a scenario will paint a picture we can dissect:

Let’s say a product sales group has just been given what seems like an unachievable revenue target and a really tough scorecard for business performance. They’re in a flat spin, panicking about how they are going to achieve this. In a hastily convened meeting they brainstorm ideas. One of them is completely crazy, but hey – you know what? it will probably work. Remember these guys are panicking. They don’t do the usual due diligence on a business idea because they have such a short time to reach these new goals. They know they’ll have failed if they go through the normal process.

They need an application. It needs to be Internet facing and because of the size of the problem they are making the offers so compelling that millions of customers will be visiting. If you are a salesperson in this situation, it all seems logical and ever so slightly exciting. Until you outline your ideas to IT. Even though the business unit has budget for the development, it doesn’t stop there.IT say the procurement process just to get the hardware is 4 months. There’s no way they can turn this around in 4 weeks. They have to develop the service, find space in the data-centre, provision the hardware and software, build support in to their maintenance plans, add hardware if the service is as successful as you say it is. IT come up with all these problems that slow you down. The conversations among yourselves are “…do these guys not realise that sales is the lifeblood of this company? If we don’t sell anything they won’t have jobs. Why are they putting so many barriers in the way of this great idea"?”.

If the cloud is not already an integral part of the IT strategy, the sale team will probably eventually discover it themselves and bypass IT completely. In fact they probably won’t want IT to have any idea they are doing it, because, as far as they are concerned, IT is there to stop business, not promote it. The less IT know the better. So with a combination of local business budgets, expenses and other sources of money, they get the service they want. Agility. Great – it all worked fantastically without IT and let’s bear that in mind for the future.

Let’s now wind forward 2 years. The whole thing has been a runaway success and the CEO wants everything to be integrated in to the main business. There are lots of niggles. Customers have to have 2 ids. One for the main systems and one for this cloud app which was developed “free of IT interference”. Customers don’t like that every time they visit the site, they aren’t quite sure which id they should use. The format of the data in the cloud app and in the internal databases is different. To get consolidated reporting is now a big problem. A database specialist has had to be hired to try to create compound reports from all the data that is gradually being spread to more and more small cloud apps without the benefit of an IT orchestrated model for data.

If IT had been prepared for the onslaught, this model would be different. If IT had already thought about the cloud as a model for delivering these kinds of services – services that fit in to those service appetite diagrams above – only to have been done with the enterprise architecture of the entire system, on-premise and cloud, in mind – the story would be very different.

What are the questions that arise from this scenario (and this is only one scenario):

  • Can IT respond in a timely manner to the business?
  • Do projects over run and under-deliver?
  • Are projects delayed because of infrastructure complexity?
  • Are projects delayed because of procurement complexity?
  • Are business managers demanding that IT change faster than it is capable of changing?
  • Does the business generate problems with mergers, acquisitions, divestitures?
  • Does IT make the best use of the resources it already owns in its data-centres?
  • Does the business move at an ever increasing pace, making greater and greater demands for flexibility and agility on IT?

Organisations do want to change these problems. They want a lower cost base with more predictable and manageable costs. They only want to pay for the resources they use (some estimates say that between 70% and 90% of compute resources in most data-centres are unused (but still paid for)). The cost of risk is too high, business want to shield themselves financially against risk. They want to provide a platform that allows for business innovation, but they need to do it at a cost they can afford. They definitely want to be more agile and more able to respond quickly to competitive threats.

These are the sorts of things the cloud brings. Not to every business problem. But to many.

Most businesses (and governments come to that) have a 5-year time horizon. There’s always a “5 year plan”. I’d say this is the best time period to make the comparisons between the “what we’ll have if we don’t embrace the cloud” and the “what we’ll have if we do embrace the cloud”. Financially, this needs to cover the migration costs.

Having a reasonable time period, like 5 years, allows an organisation to build other factors in – for example a refresh cycle that would normally happen at say the 4 year point, could be delayed (or brought forward), if appropriate and the service moved to the cloud as part of the refresh planning. For example the organisation might be thinking of upgrading the CRM system at the 4-year point, when in fact, because moving to a cloud-based version of the same system might be cheaper, it would give them the option of bringing that “migration” forward (or moving it backward). Bringing it forward would give the benefits of the system earlier to help make the business more successful. Moving it back might help if the organisation is on a cost-drive (perhaps, as is often the case, simply to prove to the market they are taking costs seriously).

Overall, those organisations that have thought about the cloud as a strategic platform and as part of their overall enterprise architecture stand to benefit the most from an architecture that allows for integration and economies of scale. Organisations that neglect this planning will suffer the problems created by independent business units for many years to come.

I believe human stories, combined with technical data, evidence etc (in that order) is the way this can be most optimally achieved.


Planky – GBR-257

Comments (0)

Skip to main content