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

Did this page help you?