In this chapter, we will focus on what an architect's role entails and explain the various cloud service models that are made available by the Microsoft Azure platform. We will describe how the numerous maps in this book are built, what they intend to demonstrate, and how to make sense of them.

More specifically, in this chapter, we will cover the following topics:

• Getting to know architectural duties
• Getting started with the essential cloud vocabulary
• Introducing Azure architecture maps
• Understanding the key factors of a successful cloud journey

Our purpose is to help you learn the required vocabulary that is used across the book. You will also understand the duties of an Azure architect. We will explain the most frequently used service models and their typical associated use cases, which every Azure architect should know. We start smoothly, but beware that the level of complexity will increase as we go. Let's start by getting acquainted with the definition of an architect.

The Maps provided in this chapter are available at https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapbook/tree/master/Chapter01.

Before we define what an Azure architect is, let's first define what an architect's role is and how our maps specialize to reflect these different profiles. The word architect is used everywhere on the IT planet. Many organizations have their own expectations when it comes to defining the tasks and duties of an architect. Let's share our own definitions as well as some illustrative diagrams.

Enterprise architects

Enterprise architects oversee the IT and business strategies, and they make sure that every IT initiative is in line with the enterprise business goals. They are directly reporting to the IT leadership and are sometimes scattered across business lines. They are also the guardians of building coherent and consistent overall IT landscapes for their respective companies. Given their broad role, enterprise architects have a helicopter view of the IT landscape, and they are not directly dealing with deep-dive technical topics, nor are they looking in detail at specific solutions or platforms, such as Azure, unless a company would put all its assets in Azure. In terms of modeling, they often rely on the TOGAF (short for The Open Group Architecture Framework) modeling framework and ArchiMate. The typical type of diagrams they deal with looks like the following:

Figure 1.1 – Capability viewpoint: ArchiMate

As you can see, this is very high level and not directly related to any technology or platform. Therefore, this book focusing on Azure is not intended for enterprise architects, but they are, of course, still welcome to read it!

Domain architects

Domain architects own a single domain, such as the cloud. In this case, the cloud is broader than just Azure, as it would probably encompass both public and private cloud providers. Domain architects are tech-savvy, and they define their domain roadmaps while supervising domain-related initiatives. Compared to enterprise architects, their scope is more limited, but it is still too broad to master the bits and bytes of an entire domain. This book, and more particularly our generic maps, will certainly be of great interest for cloud domain architects. Diagram-wise, the domain architects will also rely on TOGAF and other architecture frameworks, but scoped to their domain.

Solution architects

Solution architects help different teams to build solutions. They have T-shaped skills, which means that they are specialists in a given field (the base of the T), but they can also collaborate across disciplines with the other experts (the top of the T). Solution architects are usually in charge of designing solution diagrams, and they tackle non-functional requirements, such as security, performance, and scalability. Their preferred readings will be our chapter dedicated to solution architecture, as well as some reference architectures. Solution architects may build both high-level technology-agnostic, and platform-specific diagrams. Azure solution architects may build reference architectures, such as, for instance, one that we can find on the Azure Architecture Center (https://docs.microsoft.com/en-us/azure/architecture/):

Figure 1.2 – AI at the edge with Azure Stack

The preceding diagram illustrates how to leverage both Azure Stack and Azure, together with artificial intelligence services. Such architectures can be instantiated per asset, but still remain rather high-level. They depict the components and their interactions, and must be completed by the non-functional requirements. We will explore this in more detail in the next chapter.

Data architects

Data architects oversee the entire data landscape. They mostly focus on designing data platforms, for storage, insights, and advanced analytics. They deal with data modeling, data quality, and business intelligence, which consists of extracting valuable insights from the data, in order to realize substantial business benefits. A well-organized data architecture should ultimately deliver the DIKW (Data, Information, Knowledge, Wisdom) pyramid as shown in Figure 1.3:

Figure 1.3 – DIKW pyramid

Organizations have a lot of data, from which they try to extract valuable information, knowledge, and wisdom over time. The more you climb the pyramid, the higher the value. Consider the following scenario to understand the DIKW pyramid:

Figure 1.4 – DIKW pyramid example

Figure 1.4 shows that we start with raw data, which does not really make sense without context. These are just numbers. At the information stage, we understand that 31 stands for a day, 3 is March, and 3,000 is the number of visits. Now, these numbers mean something. The knowledge block is self-explanatory. We have analyzed our data and noticed that year after year, March 31 is a busy day. Thanks to this valuable insight, we can take the wise decision to restock our warehouses up front to make sure we do not run short on goods.

That is, among other things, the work of a data architect to help organizations learn from their data.

Data is the new gold rush, and Azure has a ton of data services as part of its catalog, which we will cover in Chapter 6, Data Architecture.

Technical architects

Technical architects have a deep vertical knowledge of a platform or technology stack, and they have hands-on practical experience. They usually coach developers, IT professionals, and DevOps engineers in the day-to-day implementation of a solution. They contribute to reference architectures by zooming inside some of the high-level components. For instance, if a reference architecture, designed by a solution architect, uses Azure Kubernetes Services (AKS) as part of the diagram, the technical architect might zoom inside the AKS cluster, to bring extra information on the cluster internals and some specific technologies. To illustrate this, Figure 1.5 shows a high-level diagram a solution architect might have done:

Figure 1.5 – Reference architecture example

Figure 1.6 shows the extra contribution of a technical architect:

Figure 1.6 – Reference architecture refined by a technical architect

We see that the reviewed diagram contains precise technologies, such as KEDA (Kubernetes-based Event Driven Autoscaling), and Dapr (Distributed Application Runtime), for both autoscaling and interactions with event and data stores.

The technical architect will mostly be interested in our detailed maps.

Security architects

In this hyper-connected world, the importance of security architecture has grown a lot. Security architects have a vertical knowledge of the security field. They usually deal with regulatory or in-house compliance requirements. The cloud and, more particularly, the public cloud, often emphasizes security concerns (much more than for equivalent on-premises systems and applications). With regard to diagrams, security architects will add a security view (or request one) to the reference solution architectures, such as the following:

Figure 1.7 – Simplified security view example

In the preceding example, the focus is set on pure security concerns: encryption in transit (TLS 1.2) between the browser and the web application firewall (WAF). The WAF enforces a security ruleset to protect against the Open Web Application Security Project (OWASP) top 10 vulnerabilities. The API gateway acts as a policy enforcement point before it forwards the request to the backend service. The backend authenticates to the database using managed service identity (MSI), and the database is encrypted at REST with customer-managed keys. Figure 1.7 clearly emphasizes what security architects are interested in.

However, as we will explore further in Chapter 7, Security Architecture, mastering cloud and cloud-native security is a tough challenge for a traditional (on-premises) security architect. Cloud native's defense in depth primarily relies on identity, while traditional defense in depth relies heavily on the network perimeter. This gap is often a source of tension between the cloud and non-cloud worlds.

Infrastructure architects

Infrastructure architects focus on building IT systems that host applications, or systems that are sometimes shared across workloads. They play a prominent role in setting up hybrid infrastructures, which bridge both the cloud and the on-premises world. Their diagrams reflect an infrastructure-only view, often related to the concept of a landing zone, which consists of defining how and where business assets will be hosted. A typical infrastructure diagram that comes to mind for a hybrid setup is the Hub & Spoke architecture (https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke):

Figure 1.8 – Hub and spoke architecture

Figure 1.8 is a simplified view of the hub and spoke, which, in reality, is much more complex than this. We will explore this further in Chapter 3, Infrastructure Design. We will also stress some important aspects related to legacy processes, so as to maximize the chances of a successful cloud journey.

Application architects

Application architects focus on building features that are requested by the business. Unlike other architects, they are not primarily concerned by non-functional requirements. Their role is to enforce industry best practices and coding patterns in order to make maintainable and readable applications. Their primary concerns are to integrate with the various Azure services and SDKs, as well as leverage cloud and cloud-native design patterns that are immensely different from traditional systems. Beyond this book, a good source of information for them is the Microsoft documentation on cloud design patterns (https://docs.microsoft.com/en-us/azure/architecture/patterns/).

What is challenging for application architects is to correctly understand the ecosystem in which the application runs. Today, there is a clear trend that entails breaking the monolith. In other words, we slice the architecture into multiple decoupled pieces, and we end up with a very distributed architecture. In most modern applications, a lot of common duties are offloaded to specialized services, often not so well known by old school application architects. For instance, an API gateway already has built-in policies for API throttling, token validation, and caching. Instead of writing your own plumbing in code to handle this, it is better to offload it. Another attention point for application architects is the horizontal scaling story of the cloud, meaning that applications/services must be multi-instance aware, which is rarely the case with monoliths. We will explore these concerns further in Chapter 5, Application Architecture.

Azure architects

From the top to the bottom of our enumeration, the IT landscape shrinks, from the broadest to the narrowest scope. It would be very surprising to ever meet an Azure enterprise architect. Similarly, it is unlikely that we will stumble upon an Azure domain architect, since the parent domain would rather be the cloud (which is much broader than just Azure).

However, it makes sense to have Azure-focused solution architects, technical architects, and data architects, because they get closer to the actual implementation of a solution or platform. Depending on your interest and background, you might specialize in one or more service models, which are depicted in the following section. Thus, some Azure architects will be interested in specialized maps, and some simply won't be interested, although it is always highly recommended to look at the broader picture.

Architects versus engineers

Before we move on, we need to address the engineer that we all have inside of us! What differentiates architects from engineers is probably the fact that most architects have to deal with the non-functional requirements piece. In contrast, engineers, such as developers and IT professionals, are focused on delivering and maintaining the features and systems requested by the business, which makes them very close to the final solution. Nevertheless, this book also contains some sections that are likely to help engineers build effective solutions.

Now that we are clear with what the role of an architect is all about, it is time to get started with the different service models and acquire the essential vocabulary that every Azure architect should know.

In this section, we will cover the essential basic skills every Azure architect should have. The cloud has different service models, which all serve different purposes. It is very important to understand the advantages and inconveniences of each model, and to get acquainted with the jargon relating to the cloud.

Cloud service models map

Figure 1.9 demonstrates our first map (not counting our sample map), which depicts the different cloud service models and introduces some vocabulary. This map features two additional dimensions (costs and ops) to each service model, as well as some typical use cases:

Figure 1.9 – Cloud service models

In terms of cost models, we see two big trends: consumption and pre-paid compute/plans. The consumption billing model is based on the actual consumption of dynamically allocated resources. Pre-paid plans guarantee a certain compute capacity that is immediately made available to the cloud consumer. In terms of operations, the map highlights what is done by the cloud provider, and what you still have to do yourself. For instance, very low means that you have almost nothing to do yourself. We will now walk through each service model.

IaaS (Infrastructure as a Service)

IaaS is probably the least disruptive model. It is basically the process of renting a data center from a cloud provider. It is business as usual (the most common scenario) in the cloud. IaaS is not the service model of choice to accomplish a digital transformation, but there are a number of scenarios that we can tackle with IaaS:

• The lift-and-shift of existing workloads to the cloud.
• IaaS is a good alternative for smaller companies that do not want to invest in their own data center.
• In the context of a disaster recovery strategy, when adding a cloud-based data center to your existing on-premises servers.
• When you are short on compute in your own data center(s).
• When launching a new geography (for which you do not already have a data center), and to inherit the cloud provider's compatibility with local regulations.
• To speed up the time to market, providing some legacy practices and processes were adjusted upfront to align with the cloud delivery model.

With regard to costs and operations, they are almost equivalent to on-premises, although it is very hard to compare the total cost of ownership (TCO) of IaaS versus on-premises.

Of course, facilities, physical access to the data center, and more are all managed by the cloud provider. It is no longer necessary to buy and manage the hardware and infrastructure software by yourself. However, you should be aware that most companies today have a hybrid strategy, which consists of keeping a certain number of assets on-premises, while gradually expanding their cloud footprint. In this context, IaaS is a required model to some extent, in order to bridge the on-premises and cloud worlds.

PaaS (Platform as a Service)

PaaS is a fully managed service model that helps you build new solutions (or refactor existing ones) much faster. PaaS reuses off-the-shelves services that already come with built-in functionalities and whose underlying infrastructure is fully outsourced to the cloud provider. PaaS is quite disruptive with regard to legacy systems and practices.

Unlike IaaS, in order to make a successful cloud journey, PaaS requires a heavy involvement from all the layers of the company and a top sponsor from the company's leadership. Make no mistake: this is a journey. With PaaS, much of the infrastructure and most operations are delegated to the cloud provider. The multi-tenant offerings are cost-friendly, and you can easily leverage the economies of scale, providing you adopt the PaaS model. PaaS is suitable for many scenarios:

• Green-field projects
• Internet-facing workloads
• The modernization of existing workloads
• API-driven architectures
• A mobile-first user experience
• An anytime-anywhere scenario, and on any device

The preceding list of use cases is not exhaustive, but it should give you an idea of what this service model's value proposition is.

FaaS (Function as a Service)

FaaS is also known as serverless. It emerged rather recently; it started with stateless functions that were executed on shared multi-tenant infrastructures. Nowadays, FaaS expanded to much more than just functions, and it is the most elastic flavor of cloud computing. While the infrastructure is also completely outsourced to the cloud provider, the associated costs are calculated based on the actual resource consumption (unlike PaaS, where the cloud consumer pre-pays a monthly fee based on a pricing tier). FaaS is ideal in numerous scenarios:

• Event-driven architectures: Receive event notifications and trigger activities accordingly. For example, having an Azure function being triggered by the arrival of a blob on Azure Blob Storage, parsing it, and notifying other processes about the current status of activities.
• Messaging: Azure Functions, Logic Apps, and even Event Grid can all be hooked to Azure Service Bus, handle upcoming messages, and, in turn, push their outcomes back to the bus.
• Batch jobs: You might trigger Azure Logic Apps or schedule Azure Functions to perform some jobs.
• Asynchronous scenarios of all kinds
• Unpredictable system resource growth: When you do not know in advance what the usage of your application is, but you do not want to invest too much in the underlying infrastructure, FaaS may help to absorb this sudden resource growth in a costly fashion.

FaaS allows cloud consumers to focus on building their applications without having to worry about system capacity, while still keeping an eye on costs. The price to pay for the flexibility and elasticity of FaaS is usually a little performance overhead that is caused by the dynamic allocation of system resources when needed, as well as less control over the network perimeter. This leads to some headaches for an internal Security Operations Center (SOC), which is the reason why FaaS cannot be used for everything.

CaaS (Containers as a Service)

CaaS is between PaaS and IaaS. Containerization has become mainstream, and cloud providers could not miss that train. CaaS often involves more operations than PaaS. For example, Azure Kubernetes Service (AKS) involves frequent upgrades of the Kubernetes version on both the control plane and the worker nodes. Rebooting OS-patched worker nodes remains the duty of the cloud consumer. We could say that AKS is a semi-managed service as it is less managed than a PaaS or FaaS one, but it is much more managed than a regular IaaS virtual machine.

On the other hand, Web App for Containers is a fully managed service that sits between PaaS and CaaS, from a feature standpoint. Azure Container Instances (ACI) is also fully managed and sits between serverless (the consumption-pricing model) and CaaS. Admittedly, CaaS is probably the hardest model when it comes to evaluating both costs and the level of operations. It is, nevertheless, suitable for the following scenarios:

• Lift-and-shift: During a transition to the cloud, a company might want to simply lift and shift its assets, which means migrating them as containers. Most assets can be packaged as containers without the need to refactor them entirely.
• Cloud-native workloads: By leveraging the latest cutting-edge and top-notch Kubernetes features and add-ons.
• Batch, asynchronous, or compute-intensive tasks through ACIs.
• Portability: CaaS offers a greater portability, and helps to reduce the vendor lock-in risk to some extent.
• Service meshes: Most microservice architectures rely on service meshes. We will cover them in Chapter 3, Infrastructure Design.
• Modern deployment: CaaS uses modern deployment techniques, such as A/B testing, canary releases, and blue-green deployment. These techniques prevent and reduce downtime in general, through self-healing orchestrated containers.

We will explore the CaaS world in Chapter 2, Solution Architecture, and AKS in Chapter 3, Infrastructure Design.

DBaaS (Database as a Service)

DBaaS is a fully managed service model that exposes storage capabilities. Data stores, such as Azure SQL, Cosmos DB, and Storage Accounts, significantly reduce operations, while offering strong high availability and disaster recovery options. Other services, such as Databricks and Data Factory, do not strictly belong to the DBaaS category, but we will combine them for the sake of simplicity. Until very recently, Azure DBaaS was mostly based on pre-paid resource allocation, but Microsoft introduced the serverless model in order to have more elastic databases. DBaaS brings the following benefits:

• A reduced number of operations, since backups are automatically taken by the cloud provider
• Fast processing with Table Storage
• Potentially infinite scalability with Cosmos DB, providing that the proper engineering practices were taken up front
• Cost optimization, when the pricing model is well chosen and fits the scenario

We will explore DBaaS in Chapter 6, Data Architecture.

XaaS or *aaS (Anything as a Service)

Other service models exist, such as IDaaS (Identity as a Service), to such an extent that the acronym XaaS, or *aaS, was born around 2016, to designate all the possible service models. It is important for an Azure architect to grasp these different models, as they serve different purposes, require different skills, and directly impact the cloud journey of a company.

Important note

We do not cover Software as a Service (SaaS) in this book. SaaS is a fully managed business suite of software that often relies on a cloud platform for its underlying infrastructure. SaaS examples include Salesforce and Adobe Creative Cloud, as well as Microsoft's own Office 365, Power BI, and Dynamics 365 (among others).

Now that we reviewed the most important service models, let's dive a little more into the rationale behind our maps.

Although we have already presented a small map, let's explain how Azure architecture maps were born and how to make sense of them. However rich the official Microsoft documentation might be, most of it is textual and straight to the point, with walk-throughs and some reference architectures. While this type of information is necessary, it is quite hard to grasp the broader picture. An exception to this is the Azure Machine Learning Algorithm Cheat Sheet (https://docs.microsoft.com/en-us/azure/machine-learning/algorithm-cheat-sheet), which depicts, in a concise way, the different algorithms and their associated use cases. Unfortunately, Microsoft did not create cheat sheets for everything, nor is there any other real visual representation of the impressive Azure service catalog and its ecosystem. That gap leaves room for some creativity on the matter…and that is how Azure architecture maps were born. The primary purpose of Azure architecture maps is to help architects find their way in Azure, and to grasp, in the blink of an eye, the following:

• Available services and components: Since there are so many services and products out there, our primary purpose is to classify them and associate them with the most common customer concerns and use cases. However, keep in mind that Azure is a moving target! We will try to be as comprehensive as possible, but we can never guarantee exhaustive or complete coverage. It simply isn't possible.
• Possible solutions: These architecture maps are like a tree with multiple branches and sub-branches, and finally the branches end with flourishing leaves. On many occasions, there are multiple ways to tackle a single situation. That is why we will map alternative use cases, based on real-world experiences. However, we strongly encourage you to form your own opinion. You need to exercise your critical reflection on every topic, as to not blindly apply the map recommendations. The unique particularities of your own use case will often require a different solution (or at least a modified solution).
• Sensitivity and trade-off points: Architecting a solution is sometimes about choosing the lesser of two evils. Some of your choices or non-functional requirements might affect your final solution, or they might lead you to face some additional challenges. We will highlight sensitive trade-off points with specific marks on the maps.

Given the size of the Azure service catalog, a single map would not suffice. Hence, we created specialized maps. They are not restricted to Microsoft services and, when applicable, may also refer to marketplace and third-party solutions. Let's jump to the next section, which explains how to read and make sense of the maps.

How to read a map

The maps proposed in this book will be your Azure compass. It is therefore important to understand the fundamentals of how to read them. We will therefore go through a sample map to explain the semantics and its workings. Figure 1.10 presents a very tiny, sample map:

Figure 1.10 – A sample map

The central point that the diagram depicts is the Master Domain (MD), the central topic of the map. Each branch represents a different area belonging to the MD. Under the sub domains, you can find the different concerns. Directly underneath the concerns, the different options (the tree's leaves) might help you address the concerns (see POSSIBLE OPTION in Figure 1.10). There might be more than one option to address for a given concern. For example, CONCERN 2 in the diagram offers two options: ALTERNATIVE 1 and ALTERNATIVE 2.

From time to time, dotted connections are established between concerns or options that belong to different areas, which indicates a close relationship. In the preceding example, we see that the ALTERNATIVE 2 option connects down to the SUB DOMAIN 2 concern. To give a concrete example of such a connection, we might find a Dapr leaf under the microservice architecture concern that is connected (by a dotted line) to a Logic Apps leaf under the integration concern. The rationale of this connection is because Dapr has a wrapper for self-hosted Logic Apps workflows. Let's now see how, as an architect, you can get started with your 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.

In this chapter, we reviewed the architecture landscape and the different types of architects we may be working with in our day-to-day Azure architecture practice. Knowing the different profiles, being able to speak to each of them, as well as satisfying their own interests and preoccupations, is what every Azure architect should do.

In this chapter, we also explained the value proposal of the maps and how to read a map, which will be very useful for the next chapters. We shed some light on the various service models that exist in the cloud, and those that serve different purposes. We also tried to grasp the important differences that exist across them, in terms of functionalities, operations, and costs. All these models constitute the cornerstone of Azure, and should be wholly mastered by the Azure architect as they represent the minimal, vital must-have skills. Finally, we have understood the key success factors of a cloud journey from real-world observations and through a fictitious enterprise scenario.

In the next chapter, we will start to get closer to the actual implementation of an Azure-based solution.