Using the platform engineering maturity model to understand the commitment required for an internal developer platform

What type of investment and commitment do internal developer platforms require? We look for answers in the CNCF platform engineering maturity model

An Internal Developer Platform is at the heart of the platform engineering movement. The movement, which continues to gain momentum, was introduced as a way to overcome many of the challenges with DevOps, namely cross-company duplication and an increasing cognitive load for developers. But while that sounds great in theory - the question is what kind of investment and commitment do you need to put into platform engineering for it to produce the right results?

While the majority of your platform engineering investment will be in the Internal Developer Platform, the Internal Developer Portal is a core part of the discipline too - and this article will aim to help you answer this question by drawing on both platform and portal examples. 

First, here are two contradicting factors that you should bear in mind with regards to platform engineering

• Most platform tools say they’re easy to use - and there’s some truth in that (Port’s quickstart doesn’t take long to complete).
• To really get to grips with the tools that developers need, you have to take a platform as a product approach, which considers how the platform will be used and how it will evolve and continuously improve over time. This takes time and requires thinking, commitment and user research.

So, what do you want to do first, and how deep do you want to go in your platform engineering journey?

This is where the CNCF’s Platform Engineering Maturity Model can help you. 

What is the CNCF Platform Engineering Maturity Model?

The CNCF's Maturity Model for Platform Engineering provides a comprehensive framework for organizations to assess and enhance their internal platform capabilities.

It outlines progressive maturity levels across key aspects of platform engineering, guiding organizations towards improved efficiency and effectiveness.

Before we go deeper into the model, it’s important to note that the model isn’t there as a judgment, rating some platforms as immature and therefore “wrong”. All platforms are immature at the outset; portal adoption needs to be worked on, new reusable developer self-service actions need to be created, standards need to be defined and enforced, and so on. Most companies begin developing the platform slowly, and even when they are very committed it’s an interactive process. Many won't know whether to begin with a platform or a portal - a chicken and egg dilemma - but the answer again is not straightforward, it depends on your organization.

What the CNCF model does is provide a roadmap, showing what a fully fledged platform would be, and what intentional work needs to be carried out for it to happen. If you’re curious, you can look at the developer portal product plan Notion board here.

The model emphasizes the importance of intentional investment and planning in platform capabilities. It makes the point that platform maturity evolves through dedicated investment, user-centric design, and continuous improvement.

What are the Key Aspects of Platform Maturity?

In other words, how do you know your platform is mature? It’s not a matter of technical achievement, if there even is such a thing with regards to the technology stack that makes up your platform.. The model lists the following aspects:

1. Investment:

At the core of platform maturity lies the allocation of resources—both financial and human—to support platform capabilities. The investment aspect of the model evaluates how organizations fund and sustain their internal platforms over time. It progresses through several stages, starting with provisional investment where capabilities are built and maintained out of necessity rather than intentional funding. 

As organizations mature, they move towards dedicating teams and resources to support platform initiatives, ultimately treating platforms as products with their own budgets and business cases. At this point of its evolution, it becomes clear that there has been a commitment to continuous improvement, meaning the organization is getting the most value from its investment in platform engineering.

This doesn’t have to read as “if you haven’t invested a lot of funds, you are not mature”. You can build lean platforms too, and there are many elegant ways that go quite far in terms of providing developer self-service. But this does mean that if you’re throwing some money at a platform tool and aren’t investing the work in driving adoption, you may not be serious enough about doing the work that will result in deep platform and portal adoption by developers.

2. Adoption:

The adoption aspect of the model focuses on how users discover, adopt, and utilize internal platform capabilities. It reflects the effectiveness of platform offerings in meeting user needs and driving value across the organization.  In many ways, adoption is the name of the game in changing developer habits and experiences, or else you may have paved a golden path for developers but they may not be using it. 

At the initial stage, adoption may be erratic, with users relying on ad hoc solutions or lacking awareness of available platform capabilities. However, as organizations mature, adoption evolves into intrinsic pull, where users are drawn to platforms due to their inherent value and utility. Ultimately, adoption becomes participatory, with users actively contributing to platform development and enhancement. This progression indicates a deeper alignment between platform capabilities and user requirements, fostering greater collaboration and engagement among stakeholders.

Platform and Portal Adoption is probably the place where platform engineering truly becomes a socio-technical challenge, and requires deep thinking not only about platform-as-a-product and portal-as-a-product but also about the dos and don'ts of what you force developers to do and what you try to gently push them into doing. For instance, do you not accept certain tickets anymore or close self-service options outside the portal?

3. Interfaces:

Interfaces are a critical component of platform maturity, as they determine how users interact with and consume platform capabilities. The interface aspect of the model evaluates the ease of use and accessibility of platform offerings for end-users. 

In the early stages, users may rely on custom processes or manual interventions to access platform capabilities, leading to inefficiencies and inconsistencies. However, as organizations mature, interfaces evolve into self-service solutions and integrated services, providing users with seamless access to platform functionality. This evolution streamlines workflows, reduces friction, and enhances user satisfaction, ultimately driving greater adoption and utilization of platform capabilities.

This, of course, is exemplified by the idea of internal developer portals, such as Port. Such interfaces can be a software catalog or self-service actions for developers, such as those shown in demo.getport.io. You can also check the practical guide to internal developer portals.

4. Operations:

Effective platform operations are essential for ensuring the reliability, scalability, and security of internal platforms. The operations aspect of the model examines how platforms and their capabilities are planned, prioritized, and maintained over time. 

At the initial stage, operations may be ad hoc, with capabilities being developed and managed on a reactive basis. However, as organizations mature, operations become more centralized and systematic, with dedicated teams responsible for tracking and managing platform capabilities. 

Ultimately, operations evolve into managed services, where platforms are treated as products with well-defined SLAs, monitoring, and support mechanisms. This evolution enhances platform reliability, accelerates issue resolution, and enables organizations to scale their platform capabilities more effectively.

Most of the focus on developer self-service is usually around scaffolding new microservices, but in fact, the real needs over time are with regards to day-2 operations. This is where much of the focus around maturing platforms should be.

5. Measurement:

The measurement aspect of the model focuses on how organizations gather feedback and incorporate learning to drive continuous improvement in platform capabilities. At the initial stage, feedback gathering may be ad hoc, with limited mechanisms in place to collect and analyze user input. 

However, as organizations mature, measurement becomes more systematic and insights-driven, with established processes for gathering, analyzing, and acting upon feedback. This evolution enables organizations to identify areas for improvement, prioritize initiatives, and drive iterative enhancements to platform capabilities. Ultimately, measurement becomes quantitative and qualitative, with organizations leveraging data-driven insights to optimize platform performance, enhance user satisfaction, and drive business value.

This ties into the understanding that if something is made to fix the developer experience and grow developer productivity, you first need to measure the developer experience, which requires both quantitative and qualitative approaches. Similarly, you’ll need to measure platform use - as in how often people avail themselves of the features and capabilities offered by the platform.

What are the different levels of maturity in the CNCF Platform Engineering Maturity Model?

The model delineates four distinct levels of maturity, each representing a progression in the sophistication and effectiveness of internal platform capabilities. Obviously, they are correlated to the maturity aspects listed in the section above.

These levels offer organizations a roadmap for advancing their platform engineering practices and driving greater value from their investments. Let's delve into each level to understand its characteristics and implications:

1. Provisional:

At the Provisional level, organizations exhibit ad hoc or provisional approaches to platform engineering. Platform capabilities may exist, but they are often developed and maintained out of necessity rather than through deliberate planning and investment. Key characteristics of this level include:

- Voluntary or temporary investment: Platform capabilities are built and maintained by individuals or teams on an as-needed basis, without dedicated funding or resources.

- Tactical solutions: Platform initiatives are driven by immediate needs or urgent requirements, leading to short-term fixes or workarounds.

- Limited scalability: Platform capabilities may lack scalability and sustainability, as they are primarily focused on addressing immediate challenges rather than long-term objectives.

Starting with a provisional platform isn’t all that bad. In many cases, creating a fully fledged platform is a difficult task that may create some level of paralysis. Usually we see organizations evolving the platform over time - and therefore beginning with a simple interface to several key self-service actions, as an example. A provisional platform can also be a nice MVP that allows proving the value of the platform in a controlled manner. Just remember that over time needs will change and the platform will need to evolve.

2. Operationalized:

The Operationalized level represents a maturation in platform engineering practices, with organizations establishing dedicated teams and processes to support platform capabilities. Key characteristics of this level include:

- Dedicated team: Organizations allocate resources and staffing to support platform initiatives, with dedicated teams responsible for developing, maintaining, and supporting platform capabilities.

- Centralized management: Platform operations are centralized and tracked, with established processes for prioritizing and managing platform initiatives.

- Incremental improvements: Platform teams focus on addressing immediate needs and operational challenges, with a growing emphasis on continuous improvement and optimization.

3. Scalable:

At the Scalable level, organizations treat platform capabilities as products, with dedicated investment, strategic planning, and user-centric design. Key characteristics of this level include:

- Product-centric approach: Organizations treat platforms as products, with dedicated budgets, roadmaps, and user experience design.

- Self-service solutions: Platform capabilities are designed to be self-service, enabling users to access and consume platform functionality with minimal manual intervention.

- Continuous optimization: Platform teams focus on iterative enhancements and optimization, leveraging user feedback and data-driven insights to drive continuous improvement.

The way we think at Port actually differs from the approach presented by the CNCF, since we think that self-service elements should exist in the provisional platform too.

4. Optimizing:

The Optimizing level represents the pinnacle of platform maturity, with organizations optimizing platform capabilities to drive organizational efficiency, innovation, and competitiveness. Key characteristics of this level include:

- Ecosystem enablement: Platform capabilities enable ecosystem-wide efficiency and effectiveness, with a focus on accelerating time-to-market, reducing costs, and enabling innovation.

- Specialized capabilities: Organizations leverage specialized capabilities and expertise to enhance platform offerings, with a focus on advanced features, such as security, performance, and quality.

- Strategic alignment: Platform initiatives are closely aligned with organizational goals and priorities, driving tangible business outcomes and competitive advantage.

Good examples of mature platforms that were built in-house are:

• Using an internal developer portal to make developers 10X and break Conway’s law
• Letting developers create microservices quickly: Monday’s internal developer portal

Maturity Requires Patience 

The CNCF Platform Engineering Maturity Model provides organizations with a structured approach to advancing their internal platform capabilities. By understanding and embracing the characteristics of each level, organizations can chart a path towards enhanced platform maturity, driving greater efficiency, innovation, and competitiveness in the digital era.

As the model states, platform maturity evolves through intentional investment, user-centric design, streamlined operations, and continuous measurement and improvement.

Higher levels of platform maturity are characterized by deeper alignment with user needs, greater efficiency in operations, and a stronger focus on driving business value.

What we really need is the patience to go through the different stages.