Don't just take your apps to the Cloud: take your teams too

I was recently reading a graphic novel version of The Goal, the classic business novel by Eliyahu Goldratt. The book has been translated into many languages and inspired the equally essential DevOps book, The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford. It’s always worth engaging with the ideas these books contain, and the graphic novel form is an accessible and entertaining way of getting to grips with them.

On this reading, though, I was struck by one thing in particular. The guru to whom the protagonist turns for advice provides guidance which changes the fortunes of the fictional business. But he doesn’t give the protagonist every answer at the beginning of the book: he keeps telling him that he must figure things out for himself, and must apply each lesson in practice before being ready for the next revelation.

This may partly be a literary device: the novel form wouldn’t work if all it comprised was one character explaining the theory. But I think it is more important than that: I think it is a reminder that, in business and in software development, as in other human activities, learning requires experience.

I also think that this is particularly true for fundamental technology transformations, such as the move to Cloud. As I argued in a previous article, you need to walk onto the Cloud with both feet, mastering essential foundations such as control and security, but balancing these foundations with real experience learned from real migrations and deployments. Once we recognise that the route to mastery lies through a combination of theory, training and practical experience, we can use this recognition to change the way we plan and measure Cloud adoption.

Cloud adoption is often planned and measured in terms of technical assets: we figure out how many applications we have, we decide which of those will move to the Cloud and when, and then we measure progress against that plan. Or we may work at an even more basic level: we may measure our progress in terms of numbers of servers, or petabytes of storage.

Most companies also realise that they must pay attention to people and skills, and build training schedules into their adoption plans, measuring success in terms of training courses completed and certifications attained.

Isn’t this enough? It sounds entirely rational that, if we are changing the platform on which we run our applications and host our data, we build a plan centred on applications and data, the infrastructure they run on, and the skills of the people that look after them. Many companies have such plans, and they often run well enough to deliver satisfactory results.?

However, I think that if we want spectacular, sustained results (and, if you read The Goal and The Phoenix Project, they are about achieving such results), then we need to think differently and think harder.

Plans which focus on applications, infrastructure and skills adopt a static perception of technology architecture. They see applications, infrastructure and, to a large extent, people, as assets to be managed: fixed things with fixed costs and fixed capabilities. From this static perspective, a Cloud adoption programme is like moving boxes from warehouse A to warehouse B: we have the same boxes at the end, but they are in a different place.

But, applying further lessons from The Goal and The Phoenix Project, we should know by now that our technology architectures are not static, and neither are the components that make them up. They are dynamic systems which should be in a state of constant change. Once we adopt this perspective, we realise than ‘an application’ is not just a bunch of code that could live on one virtual machine or another virtual machine, or on one container or another container, but a living ecosystem which includes all the tools used to manage it, the data it produces, and, most importantly, the team that owns it.

From this perspective, it’s clear that technical training and accreditations, important though they are, are not enough. Our Cloud adoption plans must ensure that teams have opportunities to learn in practice, to become confident, competent and capable on the technology platform where they now live. Cloud migration may be more like moving house than moving boxes between warehouses.

What does this mean in practical terms for companies building Cloud adoption plans? I don’t think it means that you should scrap your application and infrastructure based analysis, and I definitely don’t think that you should compromise your technical training plans (however much training you are doing, you can always do more). But I do think that you should make sure that your adoption plan is team-centric. Your plan should not just show how you are progressing with application and data migration, but how you are progressing with team enablement. How many teams are confident, competent and capable on your chosen Cloud platform? How many of them have not just migrated their apps, but have a robust and proven ability to deliver code to production with speed and reliability? And are you orienting the resources at your disposal to maximise team enablement?

And remember that the resources at your disposal aren’t limited to money, time, help from partners and support from Cloud providers. Every activity in your plan is a resource too: every action is a chance to learn. If you adopt a team-centric approach to Cloud adoption, then you will recognise that app migrations don’t just get an app from one place to another: they advance the understanding and capabilities of your teams too.

Books like The Goal and The Phoenix Project give us new ideas. But they remind us that we will only truly understand these ideas when we put them into practice. Your Cloud programme should be about practice as much as it is about migration.

(Views in this article are my own.)