Changelog
2023-10
We updated Privileged Access Management and also changed its journey stage from “Recommended” to “Essential”. While we realize many cloud foundation teams in the beginning of their cloud journey will not be able to implement a sophisticated solution for this capability at the start of their journey, this is better tracked as an implementation maturity rather than putting the capability on the shelf for later. This is especially critical on platforms like AWS where root account user credentials need to be protected.
We update Virtual Network Service to describe the most common implementation mechanisms and cloud services for AWS, GCP and Azure
Changed Centralized audit logs scope to to “Platform”. It was tagged as “Landing Zone” scope before but is more commonly implemented centrally for the entire cloud platform.
2023-06
We added a new building block for Quota Management.
We expanded a couple of building blocks like Centralized audit logs and Service and Location Restrictions with short “How to implement” sections.
2022-12
We aligned terminology in the model. We will from now on consistently refer to “application teams” when describing the consumers of a landing zone. From our experience this term more accurately reflects the different kind of teams that can consume a landing zone like development teams running their own workloads (DevOps Teams, Developer Teams) or teams running third party vendor software. The term is also more specific than “internal cloud customer” used before.
Added a new building block for a Data Science Landing Zone describing a landing zone for use by data scientists to develop AI or ML workloads.
Added a Virtual Machine Service which can be an essential component of a Lift & Shift Landing Zone but is also useful for other Landing Zones.
We removed the Cloud Zones building block. The central idea behind Cloud Zones was finding commonalities between Use-Cases that allow you to build Landing Zones. To describe this idea we introduced the concept of “use-case requirements” in several building block pages. We found that Cloud Zones was not describing a separate capability cloud foundation teams are building up. We expanded Shared Responsibility Model Alignment, Guided Cloud Onboarding and Control Access to Landing Zones to reflect what was previously described in the Cloud Zones building block.
We renamed the building block “Control access to Cloud Platform and Landing Zones” to Control Access to Landing Zones. This reflects that Landing Zones delivery is the central function of a cloud foundation team.
2022-11
The Cloud Foundation Maturity model now offers more interactive controls to explore the model. Here’s what we added
Filters for filtering blocks by scopes and journey stage
Interactive highlighting of block relations with color-coded relationships
Expert tools to allow manual block filtering as well as unfolding all block descriptions
A legend explains important CFMM concepts
Added a new group of building blocks for use-case-specific Landing Zones to the Tenant Management Pillar
Cloud-native Landing Zone offers cloud-native tenants for sophisticated internal customers building directly on the cloud
Lift & Shift Landing Zone provides an optimized cloud environment for re-hosting or re-platforming VM based workloads.
Container Platform Landing Zone offers a developer-centric experience for building and running container-based applications on the cloud.
Removed the “Monolithic Landing Zone” building block. We documented this as an anti-pattern but feel it makes more sense to include in the motivation for Modular Landing Zones.
Several key building blocks were refactored to describe the capability they represent instead of an implementation artifact or concept. This refactoring improves the consistency of the model and makes assessing implementation maturity of each block more consistent as well.
"Identity and Access Management Concept” was renamed to Identity and Access Management Alignment. It was also re-focused on establishing aligned processes for governing identities and access permissions across cloud platforms.
"Shared Responsibility Model” was renamed to Shared Responsibility Model Alignment and considerably revised to describe useful strategies for aligning responsibilities between different stakeholders.
“Authorization Concept” was renamed to Resource Authorization Management. We now also see this capability on the Landing Zone scope instead of the platform scope as landing zone’s built for different use cases can require different approaches to managing resource authorization.
The Resource Hierarchy block summary now also highlights the importance of maintaining the integrity of the hierarchy to ensure other capabilities built atop of it remain effective.
Merged the “Multi-Cloud Tenant Database” block into the existing Self-Service Multi-Cloud Tenant Database block. Most teams that we have been advising on their cloud journeys have found little value in the distinction at Journey Stage one between the core-scope “Multi-Cloud Tenant Database” and the platform-scope Cloud Tenant Database block. In practice, the need to establish a multi-cloud tenant database coincides with increased scoped for the cloud foundation team (more customers, more platforms) so merging this makes the model a little leaner and provides better distinction between these capabilities.
We renamed the “Resource Policies - Blacklisting” building block to Service and Location Restrictions. Cloud foundation teams can establish policies for allowed cloud services and regions via both blacklisting and whitelisting resources and we think the new name better captures this.
We added Resource Configuration Policies as a journey stage 2 capability. Albeit often using the same implementation techniques as Service and Location Restrictions, we see this as a differentiated capability leveraged by cloud foundation teams building bespoke landing zones for self-service application teams.
Provided a first version of the Resource Configuration Scanning block, which was previously named “Automated Security Scanning”
We recently change the scope of the Tenant Provisioning capability from “Platform” to “Landing Zone”. Consequentially the Tenant Deprovisioning / Decommissioning block was re-scoped to Landing Zone as well
2022-10
Change scope of the Tenant Provisioning capability from “Platform” to “Landing Zone”. This change reflects that the “tenant” concept can be different for different landing zones (e.g. a Lift & Shift landing zone may provision an Azure Resource Group, a container landing zone provisions a K8s namespace on a shared cluster)
Most cloud foundation teams take a structured approach to offering services in the service ecosystem pillar. We split up the Internal Service Marketplace block to better segregate the evolution of this capability along typical cloud journeys.
An Individual Service Provisioning process helps cloud foundation teams support early adopters while foundation services are not highly standardized yet
A Foundation Service Platform brings standardization to services and how they are made available to customers
Larger organizations can evolve this into an Internal Service Marketplace, an advanced capability that enables “peer to peer” services between different teams
Added Managed DNS Services and Managed SSL Certificates blocks, capturing services that we often see cloud foundation teams offer for cloud-native workloads