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 :-
- 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.
- 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.