Understanding the key factors of a successful cloud journey

The role of the Azure architect is to help enterprises leverage the cloud to achieve their goals. This implies that there is some preparation work up front, as there is no such thing as a one-size-fits-all cloud strategy. As we have just seen, the various cloud service models do not respond to the same needs and do not serve similar purposes. It is, therefore, very important to first define a vision that reflects which business and/or IT goals are pursued by your company before you start anything with the cloud.

As an example, typical transversal drivers (when moving to the cloud) are cost optimization and a faster time to market. Cost optimization can be achieved by leveraging the economies of scale from multi-tenant infrastructures. A faster time to market is conceived by maximizing outsourcing from the cloud provider. Should you have these two drivers in mind, rushing to a pure IaaS strategy would be an anti-pattern. Whatever your drivers, a possible recipe of success is the following: Define Vision è Define Strategy è Start Implementation. Let's now go through a few key aspects and start with the vision.

Defining the vision with the right stakeholders

Write a vision paper to identify what you are trying to solve with the cloud. Here are a few example questions for problems you might want to solve:

• Do you have pain points on-premises?
• Do you want to make data monetization through APIs?
• Do you want to outsource?
• Is the hardware in your data center at its end of life?
• Are you about to launch new digital services to a B2C audience?
• Do you have several of these issues?
• Are your competitors faster than you to launch new services to consumers, making you lose some market shares?

The vision paper helps you identify the business and IT drivers that serve as an input for your strategy.

Business drivers should come from the company's board of directors (or other corporate leaders). IT drivers should come from the IT leadership. Enterprise architecture may play a role in identifying both the IT and business drivers. Once the vision is clear for everyone, the main business and IT drivers should emerge and be the core of our strategy.

Defining the strategy with the right stakeholders

In order to achieve the vision, the strategy should be structured and organized around the vision. To ensure that you do not deviate from the vision, the strategy should include a cloud roadmap, cloud principles, and cloud governance. You should conduct a careful selection of candidate assets (greenfield, brownfield, and so on). Keep in mind that this will be a learning exercise too, so start small and grow over time, before you reach your cruising speed.

You should conduct a serious financial capability analysis. Most of the time, the cloud makes companies transition from CAPEX to OPEX, which is not always easy. You should see the cloud as a new platform. Some transversal budgets must be made available, to not be too tightly coupled to a single business project. Lastly, do not underestimate the organizational changes, as well as the impact of company culture on the cloud journey. Make sure that you integrate a change management practice as part of your strategy.

In terms of stakeholders, the extent to which the executive committee is involved should depend on the balance between business drivers and pure IT drivers. In order to be empowered to manage the different layers, the bare minimum requirement is to at least leverage a strong business sponsor. You should also involve the Chief Information Officer, or, even better, the Chief Digital Officer.

Starting implementation with the right stakeholders

This phase is the actual implementation of the strategy. Depending on the use case (such as a group platform), the implementation often starts with a scaffolding exercise. This consists of setting up the technical foundations (such as connectivity, identity, and so on). It is often a good idea to have a separate sandbox environment, to let teams experiment with the cloud. Do not default to your old habits, to using products you already use on-premises. Do your homework and analyze Azure's built-in capabilities. Only fall back to your usual tools after having assessed the cloud-native solutions. Stick to the strategy and the principles that were defined up front.

In terms of stakeholders, make sure you involve your application, security, and infrastructure architects (all together) from the start. Usually, the Azure journey starts by synchronizing Active Directory with Azure Active Directory for Office 365, which is performed by infrastructure teams. Since they start the cloud journey, infrastructure teams often tend to work on their own, and look at the cloud with infrastructure eyes only, without consulting the other stakeholders. Most of the time, this results in a clash between the different teams, which creates a lot of rework. Make sure that all the parties using the cloud are involved from the ground up, to avoid having a single perspective when designing your cloud platform.

The preceding advice is useful when building a cloud platform for a company. However, these factors are also often important to know for third-party suppliers, who would be engaged on a smaller Request for Proposal (RFP). To deliver their solution, they might have to adhere to the broader platform design, and the sooner they know, the better.

Practical scenario

As stated in the previous sections, crafting a few principles that are signed off by the top management may represent a solid architecture artifact when engaging with various stakeholders in the company. Let's now go through a business scenario for which we will try to create an embryonic strategy:

Contoso is currently not using the cloud. They have all their assets hosted on-premises and these are managed in a traditional-IT way. The overall quality of their system is fine, but their consumer market (B2C) has drastically changed over the past 5 years. They used to be one of the market leaders, but competitors are now showing up and are acquiring a substantial market share year after year. Contoso's competitors are digital natives and do not have to deal with legacy systems and practices, which enables them to launch new products faster than Contoso, responding faster to consumer needs. Young households mostly use mobile channels and modern digital platforms, which is lacking in the Contoso offering. On top of this, Contoso would like to leverage artificial intelligence as a way to anticipate consumer behavior and develop tailor-made services that propose a unique customer experience by providing digital personal assistants to end users. However, while the business has some serious ambitions, IT is not able to deliver in a timely fashion. The business asked the IT department to conduct both an internal and external audit so as to understand the pain points and where they can improve.

Some facts emerging from the reports include (but are not limited to) the following:

• The adoption of modern technologies is very slow within Contoso.
• Infrastructure management relies entirely on the ITIL framework, but the existing processes and SLAs have not been reviewed for the past 5 years. They are no longer in line with the new requirements.
• The TCO is rather high at Contoso. The operational team headcount grows exponentially, while some highly qualified engineers leave the company to work in more modern environments.
• Some historical tools and platforms used by Contoso have reached end of life and are discontinued by vendors in favor of their corresponding cloud counterpart, which made Contoso opt for different on-premises solutions, leading to integration challenges with the existing landscape.

As a potential solution, the auditors proposed a magical recipe: the cloud (Azure in our case)! Now, it's up to you, the Azure architect, to manage expectations and advise Contoso on the next steps. We will see an example of this work in the next sections.

The drivers

Some drivers emerge rather quickly out of this business scenario. The business wants to launch products faster, so time to market is critical. Costs are never mentioned by the business, but the audit reveals a TCO increase due to growing operational teams. So, costs are not a strong focus, but we should keep an eye on it. The features the business want to expose as part of their services rely on top-notch technologies, which are hard to make available on-premises. So, technology could be a business enabler for Contoso. In summary, the drivers that emerge are time to market, new capabilities (enabled by top-notch technologies), and, to a lesser extent, cost optimization.

Strategy

We could write an entire book on how to conduct a proper strategy, so we will simplify the exercise and give you some keys to get started with your strategy. To understand all the aspects that you have to keep an eye on, you can look at the Microsoft Cloud Adoption Framework (https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/). This is a very good source of information, since it depicts all the aspects to consider when building an Azure cloud platform. To structure and formalize your strategy, you could also leverage governance frameworks such as Control Objectives for Information and Related Technologies (COBIT) (https://www.isaca.org/resources/cobit). This helps transform verbal intentions into a well-documented strategy, and to consolidate the different aspects so as to present them in front of executive people. It also connects the dots between the business goals and the IT goals in a tangible fashion. One of the key COBIT artifacts is what they call the seven enablers, which are applicable to any governance/strategy plan:

Figure 1.11 – Cobit's seven enablers

The diagram offers a short definition of each, and their relative impact on the journey. You can easily map them to the dimensions you see in the CAF:

1. Principles, Policies, and Frameworks: This could be summarized as such: what is clearly thought is clearly expressed. You should identify your core principles and policies that are in line with the business drivers. These will be later shared and reused by all involved parties. Writing a mission statement is also something that may help everyone to understand the big picture.
2. Processes: The actual means to executing policies and transforming the principles into tangible outcomes.
3. Organizational Structures: A key enabler to putting the organization in motion toward the business and IT goals. This is where management and sponsorship play an important role. Defining a team (or virtual cloud team), a stakeholder map, and, first and foremost, a platform owner, accountable for everything that happens in the cloud, who can steer activities.
4. Culture, Ethics, and Behavior: This is the DNA of the company. Is it a risk-adverse company? Are they early adopters? The mindset of people working in the company has a serious impact on the journey. Sometimes, the DNA is even inherited from the industry (banking, military, and so on) that the company operates in. With a bit of experience, it is easy to anticipate most of the obstacles you will be facing just by knowing the industry practices.
5. Information: This enabler leverages information practices as a way to spread new practices in a more efficient way.
6. Services, Infrastructure, and Applications: Designing and defining services is not an easy thing. It is important to re-think your processes and services to be more cloud-native, and not just lift and shift them as is.
7. People, Skills, and Competencies: Skills are always a problem when you start a cloud journey. You might rely on different sourcing strategies: in-staffing, outsourcing, …, but overall, you should always try to answer the question everyone is asking themselves: what's in it for me in that cloud journey? In large organizations, a real change management program is required to accompany people on that journey.

Developing a strategy around all these enablers is beyond the scope of this book. From our real-world experience, we can say that you should work on all of them, and you should not underestimate the organizational impacts and the cultural aspects, as they can be key enablers or disablers should you neglect them. A cloud journey is not only about technology; that's probably even the easiest aspect.

To develop our strategy a little further, let's start with some principles that should help meet the business drivers expressed by Contoso, for whom time to market is the most important one:

• SaaS over FaaS over PaaS over CaaS over IaaS: In a nutshell, this principle means that we should buy instead of building first, since it is usually faster to buy than build. If we build, we should start from the most provider-managed service model to the most self-managed flavor. Here again, the idea is to gain time by delegating most of the infrastructure and operational burden to the provider, which does not mean that there is nothing left to do as a cloud consumer. This should help address both the time-to-market driver, as well as the exponential growth of the operational teams. From left to right, the service models are also ordered from the most to the least cloud-native. CaaS is an exception to this, but the level of operational work remains quite important, which could play against our main driver here.
• Best of suite versus best of breed: This principle aims at forcing people to first check what is native to the platform before bringing their own solutions. Bringing on-premises solutions to the cloud inevitably impacts time. Best of suite ensures a higher compatibility and integration with the rest of the ecosystem. Following this principle will surely lock you in more to the cloud provider, but leveraging built-in solutions is more cost- and time-efficient.
• Aim at multi-cloud but start with one: In the longer run, aim at multi-cloud to avoid vendor locking. However, start with one cloud. The journey will already be difficult, so it's important to concentrate the efforts and stay focused on the objectives. In the short term, try to make smart choices that do not impact cost and time: do not miss low hanging fruit.
• Design with security in mind: This principle should always be applied, even on-premises, but the cloud makes it a primary concern. With this principle, you should make sure to involve all the security stakeholders from the start, so as to avoid any unpleasant surprises.
• Leverage automation: Launching faster means having an efficient CI/CD toolchain. The cloud offers unique infrastructure-as-code capabilities that help deploy faster.
• Multi-tenant over privatization: While privatization might give you more control, it also means a risk of reintroducing your on-premises practices to the cloud. Given the audit reports we had, we see that this might not be a good idea. Leveraging multi-tenant PaaS services that have been designed for millions of organizations worldwide is a better response to the business drivers.

This is not necessarily where the list ends. Other principles could be created.

Having different drivers would give us different principles. The most important thing is to have concise, self-explicit, and straightforward principles. Now that you have this first piece done, you can build on it to further develop your policies and the rest of your strategy. This will not be covered in this book, but you had a glimpse of what a cloud strategy looks like. So, do work on this in your own time. The time has now come to recap this chapter.