Cloud Adoption Framework | Aidan Finn, IT Pro

Interpretation of The Azure Cloud Adoption Framework

In this post, I will explain how I have interpreted the Cloud Adoption Framework for Microsoft Azure and how I apply it with my company, Cloud Mechanix.

Taking Theory Into Practice

In my last post, I explained two things:

The value of the Cloud Adoption Framework (CAF)
It is never too late to apply the CAF

I strongly believe in the value of the CAF, mostly because:

I’ve seen what happens when an organisation rushes into an IT-driven cloud migration project.
The CAF provides a process to avoid the issues caused by that rush.

The CAF does have an issue – it is not opinionated. The CAF has lots of discussion, but can be light on direction. That’s why I have slightly tweaked the CAF to:

Take into account what I believe an organisation should do.
Include the deliverables of each phase.
Indicate the dependencies and flow between the phases.
Highlight where there will be continuous improvement after the adoption project is complete.

The Cloud Mechanix CAF

Here is a diagram of the Cloud Mechanix version of the Azure Cloud Adoption Framework:

Cloud Mechanix Azure Cloud Adoption Framework

There are two methodologies:

Foundational
Operational

Foundational Methodology

There are four phases in the Foundational Methodology:

Strategy
Plan
Ready
Adopt

Strategy

The Strategy phase is the key to making the necessary changes in the organisation. When an IT (infrastructure) manager starts a migration project:

They have little to no knowledge of the organisation-wide needs of IT services.
No influence outside their department – particularly with other departments/divisions/teams – to make changes.
Possibly have little interest in any process/organisational/tool changes to how IT services are delivered.

The process will run sequentially as follows:

Task	Description	Deliverable
Define Strategy Team	Select the members who will participate in this phase. They should know the organisational needs/strategy. They must have authority to speak for the organisation.	A team that will review and publish the Cloud Strategy.
Determine Motivations, Mission, and Objectives	Identify and rank the organisation’s reasons to adopt the cloud. Create a mission statement to summarise the project. Define objectives to accomplish the mission statement/motivations and assign “definitions of success”.	Ranked motivations. A mission statement. Objectives with KPIs.
Assess Cloud Adoption Strategy	Review the existing cloud adoption strategy, if one exists.	A review of the cloud strategy, contrasting it with the identified motivations, mission statement, and objectives.
Write Cloud Strategy	A cloud strategy document will be created using the gathered information. This will record the information and provide a high-level plan, with timelines for the rest of the cloud adoption project.	A non-technical document that can be read and understood by members of the organisation.
Inform Strategy	The Cloud Strategy will be published. A clear communication from the Strategy Team will inform all staff of the mission statement and objectives, authorising the necessary changes.	A clear communication that will be understood by all staff. Note that the steps to produce and publish this strategy will be repeated on a regular basis to keep the cloud strategy up-to-date.
Assemble Operations Teams	The leadership of the Operational Framework tracks will be selected and authorised to perform their project duties.	The team leaders will initiate their tracks, based on instructions from the Cloud Strategy.

The Cloud Strategy is the primary parameter for the tracks in the Operational Framework and the Plan phase of the Foundational Framework.

Plan

The Plan phase is primarily focused on designing the organisational changes to how holistic IT services (not just IT infrastructure) are delivered.

Task	Description	Deliverable
Azure Foundational Training	The entry level of Azure training should be delivered to any staff participating in the Plan/Ready phases of the project.	The AZ-900 equivalent of knowledge should be learned by the staff members.
Plan Migration	An assessment of workloads should begin for any workloads that are candidates for migration to the cloud. This is optional, depending on the Cloud Strategy.	A detailed migration plan for each workload.
Define Operating Model	Define the new way that IT services (not just infrastructure) will be delivered.	An authorised plan for how IT services will be delivered in Azure. The operating model will be a parameter for the Design task in the Govern/Secure/Manage tracks in the Foundational Methodology.
Cloud Centre of Excellence	A “special forces” team will be created to be the early adopters of Azure. They will be the first learners/users and will empower/teach other users over time.	A list of cross-functional IT staff with the necessary roles to deliver the operational model.
Process, Tools, People, and Skills	The processes for delivering the new operational model will be defined. The tools that will be used for the operational model will be tested, selected, and acquired. People will be identified for roles and reorganised (actually or virtually) as required. Skills gaps will be identified and resolved through training/acquisition.	The necessary changes to deliver the operational model will be planned and documented. Skills will be put in place to deliver the operational model.
Document Adoption Plan	A plan will be created to: 1. Deploy the new tools 2. Build platform landing zones 3. Prepare for Adopt	An adoption plan is created and published to the agreed scope.

The Adoption Plan will be the primary parameter for the Ready phase.

Ready

The purpose of Ready is to:

Get the tooling in place.
Prepare the platform landing zones to enable application landing zones.

There is a co-dependency between Ready and the Operational Methodology. The Operational Methodology will:

Require the tooling to deploy the governance, security and management features, especially if an infrastructure-as-code approach will be used.
Provide the governance, security, and management systems that will be required for the platform landing zones.

This means that there is a required ordering:

Governance, Secure, and Manage must design their features.
Ready must prepare the tooling.
Governance, Secure, and Manage will deploy their features.
Ready can continue.

Task	Description	Deliverable
Deploy Process & Tools	The tools and processes for the operating model will be deployed and made ready.	This is required to enable Govern, Secure, and Manage to deploy their features.
Deploy Platform Landing Zones	Landing zones for features such as hubs, domain controllers, DNS, shared Web Application Firewalls, and so on, will be deployed.	The infrastructure features that are required by application landing zones will be prepared.
Operate Platform Landing Zones	Each platform landing zone is operated in accordance with the Well-Architected Framework.	Continuous improvement for performance, reliability, cost, management, and functionality.

The platform landing zones are a technical delivery parameter for the Adopt phase.

Adopt

The nature of Adopt will be shaped by the cloud strategy. For example, an organisation might choose to do a simple migration because of a technical motivation. Another organisation might decide to build new applications in The Cloud, while keeping old ones in on-premises hosting. Another might choose to focus entirely on market disruption by innovating new services. No one strategy is right, and a blend may be used. All of this is dictated by the mission statement and objectives that are defined during Strategy.

Task	Description	Deliverable
Migrate	A structured process will migrate the applications based on the migration plan generated during Plan.	An application landing zone for each migrated application.
Modernise	Applications are rearchitected/rebuilt based on the migration plan generated during Plan.	An application landing zone for each migrated application.
Build	New applications are built in Azure.	An application landing zone is created for each workload.
Innovate	New services to disrupt the market are researched, developed, and put into production.	An innovation process will eventually generate an application landing zone for each new service.
Operate Application Landing Zones	Each application landing zone is operated in accordance with the Well-Architected Framework.	Continuous improvement for performance, reliability, cost, management, and functionality.

Operational Methodology

The Operational Methodology must not be overlooked; this is because the three tracks, running in parallel with the Foundational Methodology, will perform necessary functions to design and continuously operate/improve systems to protect the organisation.

The three tracks, each with identical tasks, are:

Govern: Build, maintain, and improve governance systems.
Secure: Build, maintain, and improve security systems.
Manage: Build, maintain, and improve systems guidelines and management systems.

This approach assigns ownership of the Well-Architected Framework pillars to the three tracks.

Govern: Cost optimisation
Secure: Security
Manage: Reliability, operational excellence, and performance efficiency

Each track has a separate team with:

A leader
Stakeholders
Architect
Implementors

Each is a separate track, but there is much crossover. For example, Azure Policy is perceived as a governance solution. However, Azure Policy might be used:

By Govern to apply compliance requirements.
By Secure to harden the Azure resources.
By Manage to automate desired systems configurations.

The inheritance model for Azure Policy is Management Groups, so all three tracks will need to collaborate to design a governance architecture. For this reason, the architect should reside in each team. The implementors may also be common.

Task	Description	Deliverable
Assess	Perform an assessment of the current/future requirements, risks, and requirements.	A risk assessment with a statement of measurable objectives.
Author Policy	A new policy is written, or an existing policy is updated to enforce the objectives from the assessment.	A policy document is written and published.
Design	A solution to implement the policy is designed. The goal is to automate as much of the policy as possible. Remaining exceptions should be clearly documented and communicated with guidelines.	High-level and low-level design documentation for the technical implementation. Clearly written and communicated guidelines for other requirements.
Deploy	This depends on Deploy Process & Tools from Ready. Deploy the technical solution.	The technical Azure (platform landing zones) and any third-party resources are deployed to implement governance, security, and management based on the published policies.
Operate	The systems are run and maintained.	Continuous improvement for performance, reliability, cost, management, and functionality. The Deploy Platform Landing Zone(s) in Ready can proceed.

Note that Govern, Secure and Manage should never finish. They should deliver a minimal viable product (MVP) to quickly enable Ready with a baseline of governance, security, and management best practices, as defined by the organisation. A regular review process will assess the policy versus new risks/requirements/experience. This will start a new cycle of continuous improvement.

This approach should be the method used for continuous risk assessment in IT Security or compliance. If this is true, then the new Azure process can be blended with those processes.

Final Thoughts

The partners of a 3-or 4-letter consulting franchise do not have to get rich from your cloud journey. The Cloud Adoption Framework does not have to be a process that generates tens of thousands of pages of reports that will never be read. The focus of this approach is to:

Enable cloud adoption.
Use a rapid light-touch approach that avoids change friction.

For example, a Cloud Strategy workshop can be completed in 1.5 days. A high-level design for a minimum viable security policy can be discussed in under 1 day. The Cloud Strategy will, and should, evolve. The IT Security policy will evolve with regular (risk) assessments.

If You Like This Approach …

As I stated, this is the approach that I use with Cloud Mechanix. The focus is on results, including speed and correct delivery. This process can be done during the cloud journey, or it can be done afterwards if you realise that the cloud is not working for your organisation. Contact Cloud Mechanix if you would like to learn how I can facilitate your experience of the Cloud Adoption Framework.

It’s Never Too Late For The Cloud Adoption Framework

I’m going to explain why the Cloud Adoption Framework can offer answers to Azure – even for organisations that have been in The Cloud for years.

Let Me Tell You Some Stories

As someone who started his professional career in IT back before Google was a thing, I have a few stories to tell.

The central IT department in a decentralised organisation spends months deploying an Azure infrastructure. Years later, they are puzzled as to why none of the other departments will use the cloud platform.

Another organisation spends a lot of money building a secure/flexible platform in Azure. 24 months later, the developers are still refusing to use this platform. They even seek out other ways to use Azure.

A very large organisation starts their cloud journey. A consultant asks them, “Have you done any preparation for the organisation?” The response is “We did that last week. Just get on with deploying stuff!”

These stories are based on truth. They are common stories – I know that anecdotally. Let’s figure out:

What went wrong?
How do we prevent it?
What can you do if the above stories are similar to what you are experiencing?

Cloud Migration

Before big data, then IoT, and then AI, stole Microsoft’s focus, the corporation used to repeat this line:

Cloud is not where you work. Cloud is how you work.

Looking back on it, that oft-repeated marketing phrase genuinely had meaning, and it succinctly defines the problem.

Just about every (I’m being cautious, because I think it is every) cloud journey project that I was sent to work on as a consultant started this way:

An IT manager ran the project.
The reasoning was “get off of X, get out of Y” or some other technical reason that made sense to the IT manager.
The project was contracted as (1) build the platform, (2) migrate the applications, and (3) do a handover to the IT department.

This is what I call a “cloud migration”. Why is that? The IT department is leaving a hosting facility, a computer room, old hardware, VMware/Nutanix/etc. They are lifting & shifting the VMs to Azure. Some new tooling will be used, but no processes will change.

The IT department will then tell the devs, “We are in the cloud! Come use the company-approved cloud.” The devs get some level of access and here’s their first experience when the business assigns a new project:

They design the application without interaction with IT/IT Security, as usual.
They attempt to deploy the application in Azure, but they have no rights.
After a helpdesk ticket, some resource groups will be set up with assigned rights.
The developers start to work, seek out some assistance, and are told that the design is unsuitable for compliance/security reasons. They must start over again.
The new design requires some networking features. The developer has no rights to Azure networks, so this requires several helpdesk tickets to eventually resolve.
Weeks later, the application is nowhere near ready. The business is impatient. The developer is frustrated.

This is not the story of one organisation. This has happened and is happening worldwide. The reason for this is that the IT department moved the applications to a new location. Nothing else changed.

Cloud Adoption

The cloud adoption journey is one of change. Typically sponsored by the business, A strategy is defined and clearly communicated:

We are changing how we deliver IT services for the business
Old organisational structures will be broken down to create a cooperative process. This will involve new tools and training before we put everything into action.
A new method of working will empower on-demand self-service.
Guardrails will be put in place to protect the organisation, its customers/suppliers/partners, and ensure operational excellence.

As you can see, there is a lot more going on here than “let’s use Veaam or Azure Migrate to shove some VMs into The Cloud.”

Some questions should arise now:

Is there a canned process for doing this?
How long is all this going to take?
Is some 3-letter or 4-letter global consulting company going to be handing out ivory back scratchers as annual bonuses to their consultants at the end of this?

The Microsoft Azure Cloud Adoption Framework

The Microsoft Cloud Adoption Framework – let’s save my fingers and call it “the CAF” – was created and continues to be curated by Microsoft. The legend goes that Microsoft observed these issues and worked with Microsoft partners to create the CAF. The CAF contains a lot of information:

How to build things in Azure
How to operate Azure
But most importantly, how to do the cloud adoption journey:

The CAF has evolved gradually since the first release, but the substance remains the same:

There are two methodologies:

Core methodology: The core phases for a successful cloud adoption.
Operational methodology: Building and continuously improving the guardrails.

In summary, the core methodology has 4 phases:

Strategy: Understand why the organisation’s leadership wants to start the cloud adoption journey. Translate those motivations into measurable objectives and a mission statement. Write and clearly communicate a cloud strategy for the entire organisation.
Plan: Any migration assessments (see objectives) will be started now because they will take time. However, the main work is defining the new IT operations model, preparing the organisational changes, identifying the required tools, and filling skills gaps through training/acquisition.
Ready: The technical work begins! The tooling is readied. The first platform landing zones (shared infrastructure such as hubs) are built. The goal is to be ready for the first application landing zones.
Adopt: The organisation finally gets the new/old applications in the cloud through migration, new builds, and innovation (this last one is quite important to business leaders).

The operational methodology will have three parallel tracks, starting after the cloud strategy is communicated, and aiming to have their minimal viable products available before Ready starts:

Govern: Protections for the business are created, covering cost management/optimisation, compliance, and so on. This will be impacted, for technology reasons by Security and Manage.
Secure: This is where modern IT security processes should be in action. A cloud security policy is created, dictating the technical security build, putting in the processes, and regularly doing risk assessments to improve the holistic posture.
Manage: The more practical elements of running Azure are dealt with, including (but not limited to): disaster recovery, backup, patching, monitoring, alerting, and so on.

Each track will have a team with stakeholders (compliance officers, IT security, and so on) and technical staff that can architect and deploy the features. There will be a lot of crossover. For example, Azure Policy (seen as a governance product) can automate:

Governance features
Security audits/enforcements
Operational excellence.

Aidan, what about the Well-Architected Framework (WAF)? Good question, if I do say so myself. The WAF contains several pillars that guide you to good design and good management. If you look at the pillars, it is easy to see that each can be owned by either Govern, Secure, or Manage.

Not Just For New Azure Customers

The CAF is not just for customers who are starting their Cloud adoption journey. As I’ve made clear, many organisations have embarked on a migration to Azure without making organisational/process/tools changes. They can’t ignore the resulting problems forever. It makes sense that those organisations take the time to figure out what changes to make. The CAF shows them the methodologies to make that happen.

Those same phases, tracks and steps can be applied to correct the course and make the necessary changes. I have started working with some clients on this very process.

Cloud Mechanix

I am a big fan of the Cloud Adoption Framework (CAF) but it is not perfect. The CAF has a process, but a lot of the content is “you could do this, you could do that” without practical opinion. With Cloud Mechanix, I deliver a streamlined and opinionated version of the CAF, focused on results. This delivery can be for new cloud adoption journeys and for those who are struggling to get their business to adopt an existing Azure environment. You can learn more about Cloud Mechanix here.

DevSecOps Resolving IT Friction In The Cloud

In this post, I’m going to discuss how to solve an age-old problem that still hurts us in The Cloud with DevSecOps: the on-going friction between devs and ops and how the adoption of the cloud is making this worse.

Us Versus Them

Let me say this first: when I worked as a sys admin, I was a “b*st*rd operator from hell”. I locked things down as tight as I could for security and to control supportability. And as you can imagine, I had lots of fans in the development teams – not!

Ops and devs have traditionally disliked each other. Ops build the servers perfectly. Devs write awesome code. But when something goes wrong:

Their servers are too slow
Their architecture/code is rubbish

Along Came a Cloud

The cloud was meant to change things. And in some ways, it did. In the early days, when AWS was “the cloud”, devs got a credit card from somewhere and started building. The rush of freedom and bottomless resources oxygenated their creativity and they build and deployed like they were locked in a Lego shop for the weekend.

Eventually, the sober-minded Ops, Security, and Compliance folks observed what was happening and decided to pull the reigns back. A “landing zone” was built in The Cloud (now Azure and others are in play) and governance was put in place.

What was delivered in that landing zone? A representation of the on-premises data center that the devs were trying to escape from. Now they are told to work in this locked-down environment and the devs are suddenly slowed down and restricted. Change control, support tickets, and a default answer from Ops of “no” means that agility and innovation die.

But here’s the thing – the technology was a restricting factor when working on-premises: physical hardware means and 100% IaaS means that Ops need to deliver every part of the platform. In the cloud, technology wasn’t the cause of the issue. The Cloud started with self-service, all-you-can-eat capacity, and agility. And then traditional lockdowns were put in place.

Business Dissatisfaction

A good salesperson might have said that there can be cost optimisations but cost savings should not be a primary motivation to go with the cloud. Real rewards come from agility, which leads to innovation. The ability to build fast, see if it works, develop it if it does, dump it if it doesn’t, and not commit huge budgets to failed efforts is huge to a business. When Ops locks down The Cloud, some of the best features of The Cloud are lost. And then the business is unhappy – there were costly migration projects, actual IT spend might have increased, and they didn’t get what they wanted – IT failed again.

By the way, this is something we (me and my colleagues at work) have started to see as a trend with mid-large organisations that have made the move to Azure. The technology isn’t failing them – people and processes are.

People & Processes

Technology has a role to play but we can probably guesstimate that it’s about 20% of the solution. People and processes must evolve to use The Cloud effectively. But those things are overlooked.

Microsoft’s Cloud Adoption Framework (CAF) recognises this – the first half of the CAF is all about the soft side of things:

The CAF starts out by analysing the business wants from The Cloud. You cannot shape anything IT-wise without instruction from above. What does the business want? Do you know who you should not ask? The IT Manager – they want what IT wants. To complete the strategy definition, you need to get to the owners/C-level folks in the business – getting time with them is hard! Once you have a vision from the business you can start looking at how to organise the people and set up the processes.

Organisational Failure

Think about the structure of IT. There is an Ops team/department with a lead. That group of people has pillars of expertise in a mid-large organisation:

The Windows team
Linux
Networking
SAN
And so on

Even those people don’t work well in collaboration. There is also a Dev department that is made up of many teams (workloads) that may even have their own pillars of expertise – some/many of those are externals. There is no alignment or collaboration between all the parties involved in building, running, and continuously improving a workload.

DevOps

DevOps is a methodology that brings Ops and Devs together in actual or virtual teams for each workload. For example, let’s say that a workload requires the following skills from many teams/departments:

.NET developers
Application architect
Infrastructure architect
Azure operators

That might be skills from 4 teams. But in DevSecOps, the workload defines a virtual or actual team of people that will work on that application and its underlying infrastructure together. The application and infrastructure architects will design together. The devs and ops skills will work together to produce the code that will create the underlying platform (PaaS and/or IaaS) that will be continuously developed/improved/deployed using GitHub/DevOps actions/pipelines.

Agile methodologies will be brought into plan:

Work through epics, user stories, features and tasks (backlog)
That are scheduled to sprints (kanban board)
And are assigned to/pulled by members of the DevOps team (resource planning)

What has been accomplished? Now a team works together. They have a single vision through a united team. They share a plan and communicate through daily standup meetings and modern tooling such as Teams. By working as one, they can produce code fast. And that means they can fail fast:

Produce a minimally viable product
Test if it works
If it does, improve on it in sprints
If it doesn’t, tear it down quickly with minimal money lost

DevSecOps

In The Cloud, modern workloads are presented to clients over the Internet using TLS. The edge means that there is a security role. And in a good design, micro-segmentation is required, which means an expanded security role. And considering the nature of threats today, the security role should have some developer skills to analyse code and runtimes for security vulnerabilities.

If we don’t change how the security role is done then it can undo everything that DevOps accomplishes – all of a sudden a default “no” appears, halting all the progress towards agility and innovation.

DevSecOps adds the security role to DevOps. Now security personnel is a part of the workload’s team. They will be a part of the design process. They will be the ones that either implement in code and/or review firewall rules in the pull request. Elements of security are moved from a central location out to the repos for the workloads – the result is that the what and who don’t change; all that changes is the where.

Influence

Introducing the sort of changes that DevSecOps will require is not going to be easy or quick. We can do the tech pieces in Azure pretty easily, actually, but the people might resist and the processes won’t exist in the organising. Introducing change will be hard and it will be resisted. That’s why the process must be lead from the C-level.

Got Something To Add?

What do you think? Please comment below.