90% of organisations are already using the cloud in some way and the market is predicted to grow to well over $500bn in the next three years.

Whether it’s a software package, an aspect of your infrastructure, or your entire platform, it’s almost a certainty that you will be using cloud now or at some point in the very near future.

When a business decision does seem so certain, it’s easy not to fully analyse it.

You’re building a new customer facing app, so of course you’re going to host the containerised services on an AWS EC2 instance. You need to rapidly analyse vast quantities of data, so of course you are going to use a Google Cloud data storage solution. You need a new CRM platform so of course you go to Salesforce.

But these should not be cut and dry decisions. The development of any technical solution, whether built entirely in house, white labelled and outsourced, or somewhere in between, should be guided by a strategy.

The strategy should embody a framework and set of design principles that ensures that the way in which you use cloud technology most closely aligns to your business objectives.

Take the example of a large bank that wants to promote innovation and experimentation amongst its technical teams.

The bank will want its people to have the skills and knowledge to use cloud-based tools. It will want them to be able to access these tools, in a suitable, controlled development environment at a whim. It will want them to have access to test or desensitised data. The bank may want its people to be able to trial tools and solution from external vendors.

Based on this fairly simple and very common business objective, we can identify a set of principles that need to form part of the overarching cloud strategy:

• Our existing people must be trained to, and have guidance on how to best utilise cloud tools and technologies
• The new people we hire should have experience of using certain cloud tools and technologies
• We must establish an account provisioning process that enables our development teams to access cloud development and sandbox environments
• We must establish a development pipeline that provides access to suitable instances for experimentation
• Our test data must be easily accessible and suitable for use within a development cloud environment
• Our procurement teams must allow us to easily engage with innovative technology vendors

These fairly high level principles may give birth to more detailed, specific approaches that guide the use of technology. Which providers should be used for certain scenarios? What tooling is approved by the organisation? How will the organisation manage the CI/CD pipeline?

And this isn’t just applicable to a larger, traditional organisation that might only be using the cloud in pockets, or might not have a fully-fledged, well communicated strategy.

Firms that were born within the age of the cloud and embraced a cloud-first approach from Day 1 can also benefit from determining whether the way in which they use the cloud is still aligned to their business objectives.

Monzo is a good example of this. They began life in 2015 with a small team and an approach of using familiar technologies to push them forward in the right direction. Around a year later, once the Alpha Preview had been tested by around 3,000 users, the team needed to establish a set of engineering principles that would support the next phase of growth. They held workshops, took stock and identified areas of focus that formed the basis of their strategy going forwards. By all accounts that has served them well as they now exceed 3.5 million customers.

Whatever the state or size of your business establishing or reviewing your cloud strategy will be a worthwhile exercise to ensure that the way you use technology is still supporting your current business objectives.