Today, most companies have at least some workloads in the Cloud but sometimes at the cost of a long and tortuous journey. Here are some guiding principles that I think are important for a successful or at least, less painful journey. The below sequence is more or less logical but activities relating to different principles could be executed in parallel.
1. Understand well your business drivers.
It might sound obvious but there is no such “a good Cloud strategy”, the good strategy will be the one that serves best your business drivers, providing you know what they are. My observations is that for B2C kind of activities, time to market (TTM) and innovation are critical, especially if you have many competitors. Channels to customers are a first class citizen in a business model canvas. When TTM is the most important driver, adopting agile methodologies and leveraging Serverless and PaaS while revamping your internal processes, is certainly the way forward, but this will have for sure a huge impact on the internal Enterprise culture (startups aside of course).
In a B2B kind of business, TTM is often not the main success factor as one may envision longer-term relationship to build strong partnership, unless this B2B partnership is aimed at delivering B2C services :).
In a B2E context, you could be in a situation where the hardware reaches end of life and you’d like to envision a complete or partial relocation of your datacenter which will lead to a total different strategy, since a lift and shift of your infrastructure to the Cloud might be the way to go, while reusing very similar processes, thus with very little impact on the culture and a minimal disruption. In such a case, your driver is more an IT one than a business one and it’s all fine, IT will be both the customer & the cost center. You might as well be in a situation where Traditional IT is overwhelmed by the rising demand from the business while not being able to deliver anymore. Will the Cloud be the solution? Perhaps but nothing could be less certain.
Understanding your business drivers is really key as they will drive your strategy and might also already help you choosing your service model(s) (IaaS, PaaS, SaaS, CaaS, FPaaS), your deployment model(s) (Public/Private off premises/Private on-premises/Hybrid) and even your provider(s).
2. Perform a gap assessment prior to start your Cloud journey
Once you understood your drivers, whether your start from pain-points or with a real ambition to grow your business and find new niches, you should see how far the “as is” situation is from the “to be” one. There is no such “a legacy”, for some companies, the Cloud Journey might just be an extra mile away because they already work with modern technologies and agile methodologies internally, and their technical debt might be very limited. For some others, the extra mile looks more like climbing the Mount Everest as they are light years away from the “to be”. This gap assessment effort should shed some light on the feasibility aspects as well as budgetary ones and should also help clarifying the requirements for guiding principle #7 below.
3. Aim at multi-cloud but start with one
This one is not from me, it’s from Gartner but I strongly adhere. Even for companies that only have to make an extra mile, the Cloud is kind of disruptive so you’d better walk before you can run. Starting directly with multi-cloud providers and/or models (private and public) will dramatically increase complexity and the risk of effort dilution. However, on the longer run, aiming at multi-cloud should help preventing vendor locking although this sound a bit like a farce to me as I find most companies are already totally locked. Besides locking, you might also choose the best Cloud provider for a given workload but this requires a certain level of maturity. So, starting with one CSP is, in my humble opinion, the best way to get started even if it might lead to some re-work/friction along the way when on-boarding extra CSPs.
4. Best of suite over best of breed or Cloud Native vs In-House
The Cloud is a brownfield ecosystem, not an empty greenfield landscape. You should first try to respect this well-balanced ecosystem, where services were “by design” conceived to integrate well with each-others, and avoid bringing in-house solutions that you have been using for decades into this ecosystem. My recommendation here is you should first try to use the built-in tools, and only if they do not seriously satisfy your internal standards (for compliance reasons for instance), envision third-party and/or in-house solutions. There must be a mindset shift and I know this makes people uncomfortable because they have to go out of their comfort zone but trust me, bringing in-house solutions into that ecosystem will harm it a lot and might even destroy your initial business drivers. Deviating from this principle leads in all cases to 1) break the “as a service” offering. 2) costs increase 3) Time to market impact. In my opinion, non-Cloud Native tools or rather Cloud-Neutral tools should be envisioned once you reach the stage of going multi-cloud. Also, with most Cloud Providers, the vendor locking maybe partly mitigated with some rational thinking. For instance, using terraform to deploy resources, opting for .NET Core or Node to be cross-platforms, opting for containerized app services, opting for the Mongo API when using Cosmos, etc. plenty of guidelines to mitigate the locking effect.
Having said that, if you understand the consequences of your choices and their impact on the business drivers which might be negligible for the datacenter example I gave earlier, it’s all fine.
5. Dedicated budget and holistic approach
Although the Cloud comes with a predefined ecosystem, starting to use it requires global technical foundations such as connectivity (ie: Azure Expressroute), identity, skills, etc. as well as non functional requirements (NFR) such as compliance, security etc. Depending on the industry you are in, the NFR might be a long and tedious process. I recommend having a holistic approach and tackle this in a transversal manner. Trying to enable these global capabilities through business projects leads to an increased risk of dilution, ad-hoc solutions, redundant efforts etc. and it is really not a good idea to bind transversal capabilities to project specific deadlines. Your business case must be strong enough to support this holistic approach principle. However, this does not prevent from running this global enablement in conjunction with specific use cases but a clear line should be drawed between what is ad-hoc and what is transversal. Therefore, a dedicated budget and organization should be defined (more on this in #8).
6. Holistic but agile approach
The Cloud is a moving target and is not only disruptive in terms of technologies, it is also disruptive in terms of architecture. Predicting what the Cloud will be in a 5 years roadmap is an hazardous activity. I’d recommend working on shorter roadmaps (max 2 years) to diminish the risk of being confronted to a new paradigm once your plans come true. Moreover, this disruptive nature but must addressed by your NFR activities.
7. Get endorsed by top business sponsors
Whatever you might have in mind, you need a mandate and you’d better get one from the business, not from IT. The chain of command being Board ==> CEO ==> CIO/C…, trying to get sponsored by the business is much better because if the sponsor is strong enough, the IT Csuite will follow blindly. As stated already, for every company, the Cloud is disruptive and disruption means “change”. From my personal experience, the biggest impediments relate to the people’s culture. Without a strong mandate, you’re likely to fail miserably. You might know the Kübler-Ross model about change management, describing in short the five stages of grief (denial, anger, bargaining, depression, acceptance) people go through when important changes impact their job. I can tell you that this turns to apply very well to a Cloud journey and you will face hard resistance from many IT sub-departments. Having a strong mandate to make people understand that they should transition faster to the “acceptance” stage is absolutely necessary.
8. Use a governance framework
Once you got endorsed on the what, it’s time to define the how and to setup a governance around organizational aspects, project candidates, etc. I recommend using a framework and I think Cobit may be used as a source of inspiration to formalize the way to work in a tangible manner. The governance will tackle the processes and once they are made clear, you might want to include your Cloud journey into your Enterprise Architecture practice as well using your preferred framework.
9. Engage with your stakeholders, avoid Ivory Tower Architecture
This principle is of course linked to the previous one but I recommend engaging with your stakeholders early enough but already with a value proposition that will be likely subject to changes. Some stakeholders are more critical than others when it comes to the Cloud, especially for the Public Cloud. Engaging with Legal/Risk & Compliance/Security early enough is key, even more if you are in a highly regulated industry.
10. Revisit the 9 previous principles regularly, remain open and rational
Whatever your other principles are (mine are here above), review them regularly, address business changes as this will probably lead to reflect on your current strategy. Make sure you do not miss opportunities by blindly applying your principles & policies. They should drive the strategy, give the direction but should not become a limiting factor. While working on your strategy, try to avoid emotional discussions, parochial politics (wishful thinking here I know) and be rational.
As a conclusion, I think that the guiding principle #1 is by far the most critical since all the others should only support and enable the business case.