Getting your head in (the) Cloud
The revolution in cloud computing is designed to free us from the barriers and constraints of the ‘old ways of working’. On demand, elastic and reliable technology that can be spun up on a self service basis. It’s what the democratisation of technology is all about.
What’s not to like? Not a huge amount. The organsiations that have mastered their understanding and utilisation of cloud are flying. More power to their elbows. There are, however, those that are still weighed down by the burdens of old school thinking and traditional ways of working, even after completing the often arduous and complex work involved in a cloud migration.
In the rush to get onto cloud, many organisations have lost sight of the reasons for which they originally decided to migrate in the first place. Let’s take a real world example of an organisation embarking on a post cloud migration, value stream / programme of work.
Our business is creating a new customer facing application, in an organisation that migrated to cloud some years ago. Our internal foundations and enablers are in place and we’re good to go…or at least we think we are. Let’s get our initial infrastructure requirements together, costed and our development, test and production environments spun up. This should be a quick exercise using cloud technology and a lean Operating Model.
Our first challenge occurs with being able to proactively view and cost our infrastructure requirements. We find that we do not have the ability to do this ourselves using a TCO (Total Cost of Ownership tool). This work takes place within a funneled and prioritised workflow process, managed by a centralised team. More precisely, the same process and team that managed infrastructure requests, before we migrated to cloud. We now find ourselves firmly ensconced in one of the old ways of working. The expected benefits of transparent, on demand and self-service technology effectively blocked by a legacy process and subject to the bottlenecks and knock-on impact of those requests prioritised above our own.
Our second issue materialises itself in the form of cost. We require a platform that can scale up and down to manage volatile and unpredictable demand. We’d like to pay for resource to manage this as and when we use it. Unfortunately, our cloud solution does not provide elasticity so we’re tied to paying up front (without discount), for the maximum resource we estimate (plus headroom) that will be required. This represents a big increase in our costs and a risk to the service we intend to offer on the platform.
We move on to storage costs. We have a requirement to keep customer data for 7 years. We know that data older than 1 year is rarely accessed. We also know that we can take advantage of different storage classes that cloud offers to minimise costs here, by automatically moving data older than 1 year to a cheaper tier of storage for infrequently accessed data. Our request to configure rules to automatically move data between storage tiers, to lock these savings in, is functionality that currently appears to be unavailable with our cloud provider. This has to be managed as part of a manual process.
Somewhere along the way we appear to have lost the ability to do most of the things cloud should empower us to do. Should we be downhearted? In short, no. We’ve learnt a lot on our journey.
Firstly, we know we can progress with work in our newly created value stream, albeit at a greater cost and with extended timelines to that we originally expected. Let’s put a tick in this box.
Secondly, we have identified an Operating Model, Organisational Design and Service Contract that appears to be preventing the organisation from reaping the true benefits of cloud. We know what the problems are here and we know how to fix them. Let’s feed this into our development value stream so that we can work together and bring the fruit of the hard work already completed on cloud, to bear.
Thirdly, we have learnt that large scale programmes can get lost in the rush to catch up with or usher in new technology. We need to focus on the high level objectives and criteria for success and follow through on these. We can address this for our next big delivery (or indeed any delivery) or if we’re going to do this properly, as part of an ongoing and fully funded development value stream.
Let’s keep our heads in (the) cloud by getting our heads out of the clouds.
For more help and information on this article and the services we offer, contact us at info@verander.co.uk
