Tuesday, September 22, 2009

Is the enterprise ready for the cloud?

There are many known risks associated with the cloud, some are transitional in nature (i.e. related to the transformation of an industry from a product to a service based economy) whilst others are general to the outsourcing of any activity. These always have to be balanced against the risk of doing nothing and the loss of competitive effectiveness and/or efficiency.

You'll find discussion of these risks in various posts and presentations I've made over the years. The forces behind this change are not specific to I.T. but generic and have (and will) effect many industries.

In this post, I want to turn the clock back and discuss again the organisational pressures that cloud creates because for some reason it doesn't get mentioned enough.

The tactics and methodologies needed to be used with any activity depend not upon the type of activity but it's lifecycle. For example, there is no project management method applicable to all types of activities despite the desire of many organisations to try and simplify this complex problem to a unified approach. Using agile everywhere is about as daft as using prince 2 everywhere, single policies simply aren't effective.

The shift towards cloud and the further commoditisation of I.T. will actually exacerbate this problem of single policies by highlighting the extremes and differences between managing an innovation and a commodity. Many organisations are simply not geared upto dealing with the realisation that they are complex adaptive systems rather than linear like machines.

People often ask the question whether "the cloud is ready for the enterprise" but the bigger question which is missed is whether "the enterprise is ready for the cloud". In many cases, the answer is no.

An example of the problems that the cloud can create is the shift to a variable model of charging and the move away from capital expenditure. Whilst it makes intuitive and obvious sense to pay for what you use, I'll use the example of worth based development to show where it goes wrong.

Back in 2003, I was extensively using agile development techniques for new projects to overcome the normal conflict between the client and the developers over what was in or not in the specification. It should never be forgotten that the process of developing a new project is also a process of discovery for the client. Requirements change continuously as more is discovered and agile is specifically designed to cope with a dynamic environment. However, it does have a weakness.

Whilst the client gets more involved in the project, the cost of change reduces (due to test driven development) and the client gets more of what they wanted, the weakness is that in most cases the client has little or no understanding of what the value of the system is going to be other than the amount they have to spend on it. In response to this, I introduced a concept known as worth based development.

The first step was to sit down with the client and work out a measure of worth for the system (i.e. machines sold, leads created, new customers found, improved forecasting etc). Once we had an agreed measure of worth, we used models to calculate the likely range of potential values that such a system would create.

If we calculated that the potential was high enough and the risks acceptable then we would offer to build and operate the system in return for an element of the measurable value created. This was a no-win, no-fee mechanism of development and goes far beyond "pay for what you use" and into "pay a fraction of what you get out".

The effect of this approach was several fold :-

  1. If we didn't believe the project was likely to succeed then we wouldn't work on this basis and instead charge on a more traditional model (hours billed etc). This told the client valuable information about their project.

  2. If we both agreed then immediately both parties were now focused on maximising the value of system rather than developing an arbritary set of capabilities. If an opportunity arose that could maximise value, then it was easy for both parties to accept it.

Charging based upon a measure of the value created sounds obvious but it was a spectacular fail.

In one case, we built a system which created leads for highly expensive equipment. The measure of value here was leads (i.e we didn't control the sales process which was entirely separate). We worked with the client, built the system and switched it on - it was a massive success.

In a few months, we had created tens of thousands of leads. Our charge was around 10 euros per lead and the client had racked up a sizeable bill. At this point I received a phone call.

The client asked me to switch the service off. I asked why and whether they were happy with all the leads. The answer came back that they were delighted with the leads, lots of which were turning into sales but could we still switch the system off because they had run out of budget.

Now this perplexed me because a single unit of the equipment sold for thousands of euros and the client was selling to a good percentage of the leads (often with multiple units). Working with the client, we quickly showed them how the additional revenue vastly outstripped the cost, the system was simply generating profit and we had the figures to prove it.

The problem however wasn't profit, they could see it was creating it. The problem was that the cost had exceeded the allocated budget and the client would have to go through either another planning cycle or an approval board to get more funds. Both options would take months.

I was stunned, the client was asking me switch off a profit making system because it had been too successful and the cost had surpassed some arbritary budget figure. They answered "yes" and stated that they had no choice.

Even in a case where direct additional revenue and profit could be proved, the budgetary mechanisms of the organisation were not capable of dealing with variable costs because they'd never been designed that way. The situation is worse in the case of the utility charging model of cloud providers because a direct measure of worth cannot always be shown. This problem of variable costs vs fixed budgeting & long planning cycles is going to re-occur for some organisations.

Not all enterprise are ready for the cloud.


Ian Krieger said...

Have hit that very same issue a number of times. The other common struggle I see is internal Business Units within a customer claiming ownership of said kit/software and each BU needs to go ge their own, on top of this fixed budgeting model. There needs to be a mindset change before cloud is even an option in a lot of places.

swardley said...

I mentioned this example to demonstrate a basic problem that many management processes are not designed to deal with the variability inherent in the cloud. There are many other examples as you allude to.

Another problem is for example, the situation that by actually associating cost with the consumption of an activity (rather than a sunk cost), business units will increasingly find themselves needing to justify the worth that such consumption creates.

Historically, businesses have been fairly atrocious at identifying actual worth and often the process is backwards.

The most farcical form of this, is the old chestnut of first determining the cost of a system, then applying some ROI calculation to determine how much value the system needs to create and then building some form of revenue model which supports this argument.

I have seen this more times than I care to mention.

Unknown said...

To be quite frank I believe Darwin had something to say about entities that behave in that manner.

Sadly for some reason however in terms of companies a lot of the dead wood seems to stay around longer than it should :(

swardley said...

Of course companies are in competition with each other and as long as everyone else is as bad as each other in managing this stuff, then no advantage is gained.

Derik Pereira (derik66@twitter) said...

I agree, most (large) enterprises are not really ready for the cloud. At a line of business, the readiness tends to be less of a problem. Thus, cloud is (should) me marketed to the lob. At least, that is what I did during my grid computing days. All the same, here is my process (albeit, abstract for my bread and butter) ... abstract I use. One component being "readiness". Invariably, lob apps are usually what goes on a cloud, initially. Later phases have less resistance after proofing the concept to the enterprise.

Ryan Nichols said...

Love your point that the question is no longer "is the cloud ready for the enterprise," but rather "is the enterprise ready for the cloud?" It inspired a blog post here.

This is certainly what we've seen in Appirio's work accelerating enterprise adoption of cloud computing-- making the most of cloud computing requires a fundamental changes in how companies interact with their internal staff, their partners, and their technology vendors.

Read more here....

Char said...

This sounds straight out of Eli Goldratt (e.g. The Goal). Jonah would be reading the riot act to the company's sr. leadership. What is the *purpose* of your company???

for ict 99 said...

Great Article. Thank you for sharing! Really an awesome post for every one.

Final Year Projects for CSE

JavaScript Training in Chennai

Project Centers in Chennai For CSE

JavaScript Training in Chennai

Huongkv said...

Mua vé máy bay tại Aivivu, tham khảo ngay

gia ve may bay tet 2021

ve may bay di my gia re

ve may bay di Phap

giá 1 vé máy bay đi hàn quốc

vé máy bay đi nhật là bao nhiêu

vé máy bay giá rẻ đi Anh

vé máy bay rẻ

Huongkv said...

Mua vé máy bay tại Aivivu, tham khảo

Vé máy bay đi Mỹ

vé máy bay từ mỹ đi việt nam

các chuyến bay từ anh về việt nam

máy bay từ pháp về việt nam