The following article is a Gemini translation of the CNCF Platform Whitepaper.
Original: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
Cloud Native Computing Foundation (CNCF) Platform Working Group Announcement
Version 1.0.0 | Released October 31, 2023
1. Introduction
The CNCF’s initial ‘Platform Definition Whitepaper’ describes what an internal platform for cloud computing is and the value it promises to enterprises. However, to achieve these values, organizations must reflect on and intentionally pursue impactful outcomes and practices. It’s important to remember that every organization relies on an internal platform meticulously crafted for its own needs, even if it’s merely documentation on how to use third-party services. This maturity model provides a framework for such reflection and helps all organizations identify opportunities for improvement.
2. What is platform engineering?
Inspired by the cross-functional collaboration promised by DevOps, platforms and platform engineering have emerged within enterprises as an explicit form of that collaboration. Platforms curate and present common capabilities, frameworks, and experiences. The focus of this working group and related publications is on platforms that facilitate and accelerate the work of internal users, such as product and application teams.
Platform engineering is the practice of planning and delivering these computing platforms to developers and users, encompassing all parts and capabilities of the platform (people, processes, policies, technology, and the business outcomes driving them). For a complete understanding of the context, please read the CNCF Platform Definition Whitepaper first.
3. How to use this model
As platform engineering has risen in prominence over the past few years, several patterns have become clear. By organizing these patterns and observations into a progressive maturity model, we aim to guide platform teams through the challenges they may face and the opportunities they should pursue.
Each aspect is described as a continuum, illustrating the characteristics of different teams and organizations within each level. Readers will be able to locate their position within this model and identify opportunities in adjacent levels.
Caveats:
- Higher maturity levels require more funding and personnel time. Therefore, reaching the highest level should not be an end goal in itself.
- Readers should consider whether their organization and current context can benefit from the characteristics of a given level, relative to the required investment.
- Each aspect should be evaluated and developed independently. However, they are intricately interconnected, and improving one aspect may require reaching a minimum level in others.
- Assess your organization’s current cloud-native adoption status. It is recommended to use the ‘Cloud Native Maturity Model’ for this purpose.
Martin Fowler stated: “The real outcome of a maturity model assessment is not what level you are at, but the list of things you need to work on to improve. Your current level is just an intermediate step to determine the list of skills to acquire next.”
4. Context behind this work
Intended audiences
- CTOs, VPs, Technical Directors: Leaders planning the path for digital transformation and improved developer productivity.
- Engineering Managers: Groups aiming to empower engineers to deliver value with low overhead and high efficiency.
- Enterprise Architects: Individuals seeking a value- and solution-driven perspective on technical challenges.
- Platform Engineers and Platform Product Managers: Teams striving to create the best experience for platform builders and users.
- Product Vendors and Project Maintainers: Organizations designing tools and messages to help users succeed with platforms.
- Application and Product Developers: Users seeking a detailed understanding of what to expect from internal platforms.
Understanding the levels
This model is not intended to categorize an organization entirely as “Level 1” or “Level 4.” Each aspect should be considered independently. Lower-numbered levels consist of more tactical solutions, while higher-numbered levels are more strategic. This is similar to a typical digital product development process: Problem Recognition → MVP Development → Iteration and Fit Confirmation → Scaling and Optimization.
5. Model table
| Aspect | Level 1: Provisional | Level 2: Operational | Level 3: Scalable | Level 4: Optimizing |
| — | — | — | — | — |
| Investment | Voluntary or Temporary | Dedicated Team | Managed as a Product | Enabled Ecosystem |
| Adoption | Irregular | External Pressure (Push) | Internal Attraction (Pull) | Participatory |
| Interfaces | Custom Processes | Standardized Tooling | Self-Service Solutions | Integrated Services |
| Operations & Measurement | On-demand / Ad hoc | Centralized Tracking / Consistent Collection | Centralized Enablement / Insight Generation | Managed Services / Quantitative & Qualitative Measurement |
## 6. Model Detail
6.1 Investment
How are staff and funds allocated to platform capabilities?
- Level 1, Provisional – Voluntary or Temporary: Capabilities are built as needed without planned or intentional funding. Maintained by temporarily assigned personnel or volunteers, relying on immediate tactical user needs.
- Characteristics: “Tiger teams” operate for urgent requirements, improvement efforts are considered “nice-to-haves.” Staff report burnout due to workload beyond their primary duties.
- Level 2, Operational – Dedicated Team: Budget and personnel are allocated for continuous support. Tasked with providing common capabilities to accelerate software delivery. Primarily focused on reactive technical requirements, treated as a cost center, with no measurement of impact on value streams.
- Characteristics: Composed of general technical experts, infrastructure costs included in team budget, making it central to budget discussions. Lacks time or experience to conduct user research.
- Level 3, Scalable – As a Product: Investment in the platform as if it were an externally sold product. Explicit investment in Product Management (PM) and User Experience (UX), allocating resources using data-driven metrics and feedback loops.
- Characteristics: Roles like PM, UX, not traditionally found in technical teams, are introduced; internal roadmaps are public. Feature removal also becomes a significant topic of discussion.
- Level 4, Optimizing – Enabled Ecosystem: Platform teams look beyond basic capabilities to maximize overall organizational efficiency. Core maintainers focus on enabling security and performance experts to directly contribute to the platform framework, extending its functionality.
6.2 Adoption
Why and how do users discover and use internal platforms?
- Level 1, Provisional – Irregular: Shared platform adoption is sporadic and inconsistent. There is no organization-wide strategy, and teams believe external tools are more effective than internal ones.
- Characteristics: Proliferation of one-off tools, cloud services used haphazardly without standard policies, tool discovery relies on word-of-mouth.
- Level 2, Operational – External Pressure (Push): The organization recognizes the value of shared platforms and encourages adoption. External directives, such as performance reviews or funding conditions, mandate or incentivize usage.
- Characteristics: Fragmented capability utilization, users have low motivation to learn the platform and heavily rely on the help desk.
- Level 3, Scalable – Internal Attraction (Pull): Users choose the platform themselves due to clear value in reduced cognitive load and high quality.
- Characteristics: Adoption occurs organically, users satisfied with one capability seek out others. Golden path templates and self-service portals enable rapid usage.
- Level 4, Optimizing – Participatory: Users join the platform ecosystem and contribute directly. They modify existing features or add new ones for new use cases.
- Characteristics: Asynchronous feature enhancement via issue boards or PRs, developer evangelists support the internal community.
6.3 Interfaces
How do users interact with and consume platform capabilities?
- Level 1, Provisional – Custom Processes: Various inconsistent processes exist, relying on manual intervention. Knowledge is shared verbally among individuals, lacking standardization.
- Level 2, Operational – Standardized Tooling: Consistent standard interfaces exist to meet broad requirements. “Paved roads” or “golden paths” are provided in the form of documentation and templates.
- Level 3, Scalable – Self-Service Solutions: Users can operate autonomously without maintainer support. Provides “one-click” implementations that abstract complexity through guided internal languages.
- Level 4, Optimizing – Managed Services: Platform capabilities are transparently integrated into the tools and processes teams already use. Observability or ID management is automatically provisioned upon deployment. Provided as customizable building blocks for deep customization as needed.
6.4 Operations
How are platform capabilities planned, prioritized, developed, and maintained?
- Level 1, Provisional – On-demand Processing: Developed reactively based on sporadic requests from product teams. Focus is solely on initial delivery, lacking plans for continuous maintenance or security patches.
- Level 2, Operational – Centralized Tracking: Capabilities are centrally documented and discoverable. Service-specific ownership is explicit, and a central team manages the backlog to track maintenance status.
- Level 3, Scalable – Centralized Enablement: The platform team understands and prioritizes the broad needs of the organization. Standard processes exist for anyone to contribute solutions, and updates are deployed via Continuous Delivery (CD).
- Level 4, Optimizing – Managed Services: The lifecycle of all capabilities is managed in a standardized and automated manner. Updates are continuously delivered without user impact, and a clear ‘shared responsibility model’ exists.
6.5 Measurement
What are the processes for collecting and incorporating feedback and learning?
7. Conclusion
Platforms and their maintainers provide the foundation for agile digital product development. They offer a consistent set of capabilities that enable efficient software development and improvement. This maturity model will serve as a map for your platform engineering journey.
Leave a Reply