Project 2012: Day 125
This is the final in our look at the economics of adopting cloud computing in the enterprise. To date we’ve covered:
In today’s post we’re going to discuss considering when it’s most appropriate to move a particular workload to the cloud.
Note: I’m using the term workload, rather than application, to identify a business process that may be provided by part of, one or many applications.
E.g. a Business Intelligence workload may include multiple, interdependent applications such as: Cognos, SQL Server, Crystal Reports etc. equally, a database workload may support a number of capabilities such as: Data Warehouse, CRM, ITSM Monitoring etc.
The first thing you’ll want to consider are the dependencies for a given workload.
So when considering moving a workload to the cloud, whether transitioning the workload onto IaaS, transforming it to depend on PaaS, or replacing it entirely with SaaS, the first economic consideration are the dependencies.
That includes the dependencies the workload has, e.g. authentication systems, operating systems, infrastructure etc.; as well as the dependencies the workload supports, e.g. other applications.
An analysis of the dependencies will highlight whether the standardised environment of the cloud will provide critical functionality that the workload depends upon, boundaries that the workload will now have to traverse, inter-connections needed, and the cost of downtime.
One of the first workloads many firms opt to put in the cloud is Messaging. This makes sense because the cost of running an on-premise messaging system is significantly higher than subscribing to a cloud service. Messaging is network aware by definition, tends to have few dependencies within most organisations, and is a very mature service that has been provided by Service providers for many years. This predates even the commercial Internet, with providers such as CompuServe, and America Online.
I was intrigued to hear of a European based bank that transformed from on-premise email to GMail, and their migration strategy was to run the two systems for a month, giving their users 30 days to copy across emails they believe they needed to keep. In other words, they were not maintaining any of the dependencies of the legacy messaging system, not even for migration of users and data.*
So you’ve decided your HR system is better in the cloud. Except that you have $3m worth of hardware less than a year old.
Clearly there is a lost cost of capitalised assets that were purchased to run the workload. These include facilities, infrastructure, and one that is oft overlooked, software licences.
There are three opportunities to deal with these assets if you were to transform:
- Vendor buy back. Many vendors, such as HP, will offer to “buy back” hw assets replaced. Although this will offset a depreciation, generally speaking the buy back figure will be less than the unrealised depreciation.
- Re-purpose. This is often a viable opportunity for newer assets. Servers can be cycled into infrastructure farms, or used to provide new services.
- Sell. There is always an opportunity to sell the assets to other organisations, or to auction them off through sites such as Greys Auctions.
However, if the return on these assets is significantly less than the depreciation, this may influence the point of commitment for this particular workload.
Remember to calculate the operational costs to running the workload for the period of depreciation left on the assets. These operational costs need to include:
- Running costs
- Support and maintenance
- Licence refreshes
Finally there’s opportunity cost. This is the cost of the lost revenue because of not moving to the cloud. This can be particularly hard to quantify, but the benefits of cloud, such as agility, rapid time to market, or elasticity can be described in financial terms and used for analysis.
Point of Commit
Once you have detailed these costs, you can extrapolate these over a number of years. Then do a similar exercise with transformation and OpEx of the same workload in the cloud.
At some point, it will make financial sense to commit a particular workload to the cloud. This then informs your strategic cloud roadmap.
Of course every workload will have a different ideal point of commitment. Some workloads you may determine to move early, or late, because of the dependent systems ideal point of commitment.
A Final Word
As demonstrated, adopting cloud computing, whether private, virtual private, or public; and whether IaaS, PaaS, or SaaS; has a significant impact in the enterprise. It’s important enough to appoint someone to be responsible for your cloud strategy and roadmap, and to look at all aspects of the economics of transforming your information systems over time.
Next week we’ll begin the next part in this series, looking at Agility as a Business Enabler.
As ever, feel free to comment, discuss, or share. If you have any questions please do contact me.