CNCF TAG Appデリバリー – Community Contributions

Blog: A Living Blueprint: Evolving the Platform Engineering Whitepaper and Maturity Model

Tue, 03 Mar 2026 12:00:00 +0000

A Living Blueprint: Evolving the Platform Engineering Whitepaper and Maturity Model

In Q1 2026, the CNCF Platform Engineering Technical Community Group (TCG) kicked off a refresh of two foundational community resources: the Platform as a Product Whitepaper and the Platform Engineering Maturity Model. Since their initial release, both of these documents have been crucial guidance for organisations beginning their internal developer platform journey, and now, two years later, it’s time to ensure they grow with the industry.

We launched two focused initiatives to not only make initial updates but also to define a clear, sustainable path forward. We believe these should be living documents that continuously reflect industry advancements, spawn new ideas, and serve as a durable, long-term resource for the community.

Our current initiative focuses on two main areas to meet the immediate needs of the platform engineering community and pave the way for the future. First, we are Defining Future Growth and Scope by leading a discussion to clearly articulate how both the Whitepaper and Maturity Model must evolve to meet the current and emerging needs of the cloud-native industry. This ensures a measured, strategic approach to larger future changes and includes integrating content on new essential areas, notably the secure, governed integration of Artificial Intelligence (AI) tools and prototypes into the software development lifecycle.

Second, we are pursuing Clarity and Usability Improvements through Language and Terminology Refinement, making concise, simple changes to update the core language across both documents, ensuring clarity and aligning them with established vocabulary. We are also focusing on Maturity Model Practicality by adding clearer, real-world examples and scenarios. This enhancement will empower teams to assess their current state more effectively and identify concrete next steps for advancement.

The collective goal of these initiatives is to have drafts of the Whitepaper and the Maturity Model available before KubeCon EU 2026, for formal release to the community at KubeCon! Accompanied by a feedback survey, this will provide an immediate opportunity for review, feedback, and further community contributions to steer future initiative work through 2026 and into 2027.

Get Involved Now: Your Expertise Is the Blueprint!

The success of these documents and their evolution depends on the collective expertise of the cloud-native community. We invite you to join the conversation, contribute your experience, and help us finalise this next iteration.

Connect With Us Online

Slack: Join the #platform-engineering channel on CNCF Slack. It’s the best place to ask questions, share ideas, get involved, and stay up to date on progress. A link to the drafts will be published in the channel as soon as they’re ready, and formally at Platform Engineering Day on Monday 23rd March 2026.
Website: Visit cloudnativeplatforms.com to learn more about our group and resources. The draft documents and survey will be available there.
LinkedIn: Follow our latest posts and updates on LinkedIn.
Survey: We’re launching a new version of our community survey at KubeCon Europe 2026! Your input will directly inform the final shape of the updated materials — keep an eye on the channels above for the link.

Meet Us at KubeCon EU

If you’re attending KubeCon + CloudNativeCon Europe 2026 in Amsterdam, find us! We’ll be hosting Platform Engineering Coffee meet-ups Monday-Thursday 07:00-8.30, lunchtime meet-ups 12:30-13:30, at Platform Engineering day all day Monday 23rd March. Or stop by the Platform Engineering TCG booth at the Project Pavilion on Wednesday, 25th March to chat with contributors, ask questions about the updated documents, and share your own platform engineering stories. Whether you’re just starting your platform journey or you’ve been building internal developer platforms for years, we’d love to hear from you.

We look forward to building the next chapter of these resources together.

Blog: Navigating Platform Engineering with the maturity model assessment

Mon, 15 Sep 2025 01:00:00 +0000

The CNCF Platform Engineering community has been working on an assessment to accompany the Platform Engineering Maturity Model. It’s now available as a preview for feedback, but it’s crucial to understand its purpose to know what it can do for you and what you need to put in once you get your score.

The assessment is a series of multiple-choice questions that takes around 20 minutes to complete. It runs in your browser and no data is shared. Once complete, you’ll get a report card that shows you where you sit within the Platform Engineering Maturity Model.

Help us out by trying out the assessment and giving us feedback.

Platform orienteering

Picture yourself at the edge of a vast forest. You know there’s a destination somewhere out there, but between you and your goal lies unfamiliar terrain filled with hills, valleys, streams, and dense woodland. This is orienteering, the sport of navigating unknown territory using only a map and compass.

You can take part in orienteering with minimal kit. If you have a map, you can work out the rest using landmarks. Perhaps you’ll spot that distinctive hill in the distance, follow the bend of a river, or use a church spire as a reference point. But it gets a whole lot easier if you have a compass to tell you which direction you’re facing.

That’s why we wanted to add an assessment tool to accompany the Platform Engineering maturity model. Just like orienteering requires both a map and a compass working together, a successful Platform Engineering transformation needs a clear picture of the landscape and a way to determine your current position.

The maturity model is the map

In orienteering, a map is your window into the landscape. It shows you the contour lines that reveal steep climbs and gentle slopes, the symbols that mark forests, clearings, and water features, and the network of paths that connect different areas. But here’s what’s crucial to understand: the map shows you the terrain as it exists, not where you are within that terrain.

The Platform Engineering maturity model works the same way. It’s a detailed map that describes the features of the Platform Engineering landscape. It has the organizational structures, the technical capabilities, the process maturity levels, and the cultural elements that define different stages of platform evolution. It shows you what “good” looks like at various levels of sophistication.

What a map doesn’t tell you is where you are right now, or where you want to go. When it comes to your destination, it’s your journey, so it’s for you to decide. We’re each heading somewhere different, and that’s as true for Platform Engineering maturity as it is for choosing whether to head to a peaceful lakeside clearing or push for the challenging summit.

Some organizations want to reach the beach: a stable, reliable platform that serves their current needs without unnecessary complexity. Others are drawn to the heady heights of mountains, pursuing cutting-edge capabilities and pushing the boundaries of what’s possible with Platform Engineering. Both destinations are valid; the map just helps you understand the terrain that lies between you and your next waypoint.

The assessment is a compass

Once you have the map and an idea of where you want to get to, the one thing standing in your way is knowing where you are right now. In orienteering, you might recognize that hill over there and that stream down below, but you can’t orient the map correctly without knowing which way is north. You could be looking at the landscape upside down for all you know.

You can’t plan a route until you know your starting point. Are you at the bottom of the valley looking up, or are you halfway up the slope? Are you even on the side of the right mountain? The difference determines everything about your next steps.

This is where the Platform Engineering assessment comes in. It functions as your compass, not the magnetic but the organizational kind. It helps you work out which way around to hold the map and where you are within the Platform Engineering landscape. The assessment asks targeted questions about your current practices, capabilities, and organizational structures, then plots your position on the maturity model map.

With both map and compass in hand, you can finally see the whole picture: here’s where you are, there’s where you want to go, and now you can begin to understand the terrain you’ll need to cross to get there.

Route planning

When we were gathering feedback on the assessment during its development, one question came up repeatedly: “This is great for showing me where I am and where I could go, but how do I actually get from here to there?”

It’s a natural question. In orienteering, once you know your position and your destination, the next step is route planning. Do you take the direct path that cuts straight across that steep hill, or do you follow the longer but easier route that curves around the valley? Should you push through the dense forest or stick to the clearer paths that might add distance but save time?

At the moment, detailed route planning isn’t part of the assessment. Think of our current tool as a reliable map and compass combination, but not a complete GPS navigation system yet. The “SatNav version” that provides turn-by-turn directions is a later evolution we’re considering.

The assessment might prompt you about your intended destination and offer some general recommendations, like suggesting that organizations aiming for advanced platform capabilities typically need to focus on developer experience metrics or that teams targeting rapid scaling should prioritize automation investments. But we deliberately don’t want to remove human expertise and judgment from the process.

When we add more detailed recommendations in future versions, those recommendations will remain general enough to require customization. There’s always space for the next steps to be tailored by people who understand your organization’s unique context, constraints, and goals. After all, no two orienteering courses are exactly alike, and neither are any two Platform Engineering transformations.

Prototype assessment feedback

We are open to feedback for all elements of the assessment. For example:

Are the questions and answer options clear?
Did the result match your expectation?
Are the visualizations helpful or should we try something else?

The assessment scores responses for each category in the maturity model. This information is shown in three ways in the assessment’s output.

Spider chart: Uses the average score in each category to highlight strengths and weaknesses.
Matrix: Plots answer density to show the spread within each category.
Table: Displays average scores per category.

Helping you navigate

The assessment gives you the essential foundation: a clear understanding of where you stand and the possible paths forward. From there, the art of navigation, whether through forests or platform transformations, remains a uniquely human skill.

You can help by trying the assessment and giving us feedback.

To learn more about what’s happening in the platform engineering community, join our Slack Channel and follow our LinkedIn page.

Blog: From Chaos to Clarity: Navigating Observability in the Platform Engineering Era (and a Dash of AI)

Wed, 20 Aug 2025 12:00:00 +0000

There was a great energy at KCD New York this year, and for Graziano Casto, a personal highlight was leading a roundtable on observability. It was a fascinating discussion that really got him thinking about the challenges we’re all facing in the platform engineering space. Here is Graziano’s recap of the key problems and promising ideas that came up.

Introduction

It was an absolute pleasure recently to moderate a roundtable at KCD New York, diving deep into the fascinating (and let’s be honest, sometimes frustrating) world where Platform Engineering meets Observability. As my first time moderating a roundtable, I was genuinely thrilled by the energy and candid participation from everyone in the room. A huge thank you to all the participants: Michel Murabito, Colin Lacy, Tiara Sykes, Andrew Espira, Mariia Rudenko, Aderianna Williams, Marino Wijay, and Maria Ashby whose insights made this discussion truly invaluable. We had an incredibly insightful exchange, and I walked away with some serious food for thought.

We kicked off by acknowledging a universal truth in today’s cloud-native landscape: managing a full observability stack often feels like trying to hit a moving target. The more we aim to observe, the more inherent complexity seems to creep in. We continuously pile on tools, data, and dashboards–be it metrics, traces, logs, or profiling – and suddenly, we’re swimming in a sea of cognitive load, entropy, and quite often, plain old confusion. So, instead of me listing the common headaches, I threw it open to the room: “When you think about managing a full observability stack, across logs, metrics, traces, and so on, what are your biggest pain points? If you had to name the biggest challenge your team is facing with observability right now, what would it be?”

The responses flowed freely, revealing a shared understanding that while observability promises clarity, its real-world implementation often introduces its own unique set of challenges. And, quite organically, our conversation drifted into the exciting (and slightly unsettling) realm of Generative AI, specifically discussing how Large Language Models (LLMs) can be synergistically integrated within platforms to serve as enablers in resolving some of these very challenges.

The Observability Headaches: Where Do We Feel the Pinch?

One of the loudest points of contention was the persistent struggle to correlate telemetry data with the actual services generating them, and the broader challenge of telemetry data correlation. It’s like having all the pieces of a complex puzzle but no clear idea how they fit together. You might spot a spike in CPU utilization – a metric – but then you’re left guessing which microservice is the culprit. Then begins the detective work: diving into logs to pinpoint an error, and finally tracing requests to understand the flow. The fundamental problem is that these critical data points often reside in disparate systems, use inconsistent identifiers, and demand a significant amount of manual effort and intuition to connect the dots. This fragmentation makes it incredibly difficult to quickly identify the root cause of a problem when seconds count.

Adding to this complexity is the sheer volume of alerts and the difficulty in correlating them with the actual underlying problem. We’ve all experienced it: a dozen alerts fire simultaneously, each pointing to a symptom, yet none clearly indicating the core issue. This leads to what’s known as alert fatigue, resulting in missed critical incidents, wasted time triaging false positives, and ultimately, a palpable loss of trust in the alerting system itself. The challenge isn’t merely about receiving notifications; it’s about receiving meaningful alerts that directly pinpoint the underlying problem, not just its outward manifestations.

Furthermore, a significant unspoken burden that often comes with observability is the cost of both creating and maintaining the entire observability stack. From licensing fees for proprietary tools to the infrastructure costs of storing massive volumes of telemetry data and the operational overhead of managing these complex systems, the financial outlay can be substantial. This constant investment of resources, both human and monetary, can become a major pain point, often weighing heavily on budget decisions and resource allocation.

Then there’s the pervasive issue of making insights accessible and visualizing them in a way that provides the right insight to the right person. Raw telemetry data, in its unadulterated form, is overwhelming. Different roles within an organization – SREs, developers, product managers – need distinct views and varying levels of detail. A developer might require granular trace data, while a product manager needs high-level business metrics. The constant battle involves creating and maintaining these tailored dashboards and ensuring everyone knows where to find what they need. This often leads to information silos and missed opportunities for proactive improvement.

A recurring theme throughout our discussion was the persistent problem of siloed teams and the resulting lack of standardization. When different teams adopt disparate observability tools, inconsistent naming conventions, or even varied logging formats, it inevitably creates a fragmented and chaotic landscape. This makes it incredibly challenging to gain a holistic view of the system, collaborate effectively during incidents, and leverage best practices across the entire organization. It’s a classic case of “everyone doing their own thing”, leading to pervasive inefficiencies and increased complexity.

Finally, a crucial point that resonated deeply was the importance of developer education. Observability isn’t merely about deploying tools; it’s about cultivating a specific mindset. Developers need to grasp why observability is vital, how to effectively instrument their code, how to interpret telemetry data, and critically, how to leverage observability tools to troubleshoot their applications. This knowledge gap can lead to poorly instrumented services, ignored alerts, and a general underutilization of the powerful observability stacks organizations invest heavily in.

Internal Developer Platforms: The Unified Solution

So, with these common headaches laid out, how do we begin to alleviate them? This is precisely where the concept of an Internal Developer Platform (IDP) steps in as a truly powerful solution, providing a cohesive answer to many of these challenges.

An IDP, at its core, inherently solves the problem of standardization. By providing clear standards and abstractions through “golden paths” for building and deploying applications, it ensures consistency across the organization. However, it’s crucial that these golden paths don’t become “golden cages”. A well-designed IDP empowers developers with the necessary autonomy to cover edge cases, allowing them to step outside the perimeter of the provided golden paths when needed for specific requirements. This balance is vital for both consistency and innovation.

Moving beyond standardization, IDPs also play a crucial role in addressing the challenges faced by siloed teams that might be working on different components of the same system and often lack a shared performance baseline. During our discussion, we introduced the concept of leveraging generative models within these platforms. Specifically, the role of Generative AI, particularly Large Language Models (LLMs), in the observability space emerged as a truly futuristic and exciting prospect. The idea is that LLMs can help close the gap between users and telemetry data. Imagine being able to ask natural language questions like, “Why is our checkout service slow right now?” and have an LLM sift through mountains of metrics, logs, and traces to provide a concise, actionable answer. Or, “What were the top 3 errors in our authentication service last night?” and get a summary, perhaps even with links to relevant log lines. These models can also be instrumental in enabling teams to define and compare their telemetry data against customized thresholds, ensuring that the entire system is monitored according to a collectively defined baseline, fostering a shared understanding of system health.

From here, we delved into how these models further enhance the transparency and clarity of insights. LLMs, integrated within the IDP, can analyze vast amounts of telemetry data and provide various stakeholders with personalized insights and alerts. This capability opens the door to entirely new interfaces beyond the traditional dashboards, making complex operational data more accessible and actionable for different roles. Unfortunately, we didn’t have the opportunity to delve deeper into the intricate topic of telemetry data correlation during the roundtable, but I have written an article that explores this topic further, which you can find here.

The Open Question: Balancing Trust and Cost with Benefits in the LLM Era

However, as with any powerful new technology, the discussion around LLMs quickly led to a critical open question for the community:

How do we effectively balance the significant benefits that LLMs bring – such as improved automation and deeper insights – against the inherent costs? These costs include not only the economic investment required for these models but also the crucial aspect of trust, both in the accuracy of the results and in entrusting our sensitive data to an LLM, particularly when utilized as a service.

This is a conversation that needs to continue. As we push the boundaries of what’s possible with AI in operations, we must collectively figure out how to build systems that are not only efficient and intelligent but also fundamentally secure, trustworthy, and cost-effective.

Wrapping Up

My first moderating experience at KCD New York was an absolute blast, and the insights from the roundtable on Platform Engineering and Observability were truly invaluable. It’s clear that while observability brings its own set of complexities, Internal Developer Platforms offer a robust framework for overcoming these challenges by promoting standardization, providing contextualized insights, and empowering developers. And looking ahead, the potential of LLMs to revolutionize how we interact with our telemetry data is incredibly exciting, even if it comes with some important questions we need to answer as a community.

What are your thoughts on these challenges and solutions? And how do you see the role of LLMs evolving in the observability space, especially concerning the trust and cost trade-offs? Let’s keep the conversation going!

Blog: Demystifying Composability on Platforms: extending Platforms to business needs

Wed, 29 Jan 2025 12:00:00 +0000

Introduction

Let’s start with what’s a Platform, according to the CNCF Platforms White Paper, “A platform for cloud-native computing is an integrated collection of capabilities defined and presented according to the needs of the platform’s users. The specific set of capabilities and scenarios supported by a platform should be determined by the needs of stakeholders and users. And while platforms provide these required capabilities, it’s critical to note that platform teams should not always implement them themselves.”

Composable platforms promote flexibility and adaptability in the configuration and setup of the Platform. These individual solutions are then combined to form a larger, more feature-rich Platform. This allows configuring different components to achieve various technical and business needs by providing specific components or allowing setup of this component. When looking for a platform, understanding the end goal – bringing value to the business – is critical for ensuring the right capabilities meet the organization’s needs.

Composability, then, is the characteristic of a platform that, through different user experiences and a broad range of components, expands to fulfill technical needs at the end, supporting business value and increasing competitiveness advantage.

As the platform supports and enables different personas, each persona will have distinct needs and usage of the platform and, accordingly, differing requirements and perspectives on what composable means. Platform consumers may leverage some or all of the composable capabilities, depending on their needs. For example, while one development team may choose to only make use of the platform’s full capabilities to build, test, scan, and store artifacts; another team may opt into the build and scan capabilities only, storing their artifacts in a different repository from the one provided by the platform team. The flexibility to consume only the parts that provide business value based on a team’s specific business deliverable, as opposed to an all-or-nothing approach, is a hallmark of composable platforms.

Fig 1. Platform Capabilities

It’s worth noting that this loose coupling does not preclude the benefits of interoperable components. While capabilities such as build and test, as well as artifact storage may be consumed separately, a composable platform can still provide benefits for those consumers who wish to use the two together, such as automatic image signing and SBOM generation.

A key concept in building platforms is the persona. We refer to a persona as a group of stakeholders within a platform. Note that a persona is not the same as a role, and is intended to apply to different roles in team topologies. Some individuals will fit into one or more persona - especially in smaller organizations where team members are expected to wear multiple hats.

Characteristics of a Composable Platform according to the personas

Builders (focus on platform and beneficiary experience): From being extensible and configurable, the platform should support a variety of underlying infrastructure on which the platform will run, from on-premise to cloud.
Enablers (focus on end-users and application capabilities): Provide availability to access different installation methods and configure the platform by allowing the custom configurations, extend the platform to additional infrastructure. Increase platform capabilities to either of the following two roles- Developers and Business Customers
Consumers - Platform Customers (Developers) components are the tools that add application capabilities, such as database, observability, and application log management to accomplish business goals. Decreasing lead time in development will increase developer productivity.
End-users (customers) - End users don’t interact directly with the platform but benefit from the increased productivity of the platform consumers, which reduces the time to market. Platform capabilities and application features will contribute to business use cases and add customer value. Customers can also measure the value of a strong platform through enhanced reliability and availability, building trust over time. Furthermore, the ability to support a variety of workloads helps the platform meet business requirements and provide value to the end users.

Learn more about the personas: https://tag-app-delivery.cncf.io/blog/paap-personas/

How do the different personas view a platform?

The following diagrams help us explore how a platform looks from the differing perspective of each persona and how the platform evolves with the new components.

From Builders:

The underlying infrastructure may not necessarily be part of the platform. However, the platform takes advantage of the underlying hardware resources and services. The following diagram shows an example of how a composable platform expands its components according to the organization’s setup and configuration requirements.

Once the infrastructure is defined, the platform can be set up; as a platform expanded using different configurations from networking and security configuration. Once the platform is up and running and accessible it can be handed over to the next team.

Fig 2. Platform Expands within an infrastructure

Once the infrastructure is defined, the platform can be set up as a platform expanded using different configurations from networking and security until the platform is running and accessible for the next team.

From Platform Enablers:

Growing a Platform by increasing platform and application capabilities, taking advantage of the platform components or new components selected by the organization.

Fig 3. Platform Expands within platform and application capabilities

After cluster installation and setup typically with a Kubernetes distribution, platform engineers embarked on Day 2 operation activities, ensuring relevant governance and security are in place. Next, the teams will work to ensure an efficient onboarding experience and a great user experience, allowing teams to access the platform directly or indirectly and bringing application capabilities closer to developer teams. It’s critical to meet the business’s scalability, resilience, and high availability needs before moving forward with production workloads.

From Developers (platform end-users):

The platform expands with each component, building out CI/CD pipelines, then moving on to tune resources to meet requirements, and ensuring the availability to run multiple and diverse workloads. The platform can be extensible enough to support different third-party tools for application and user needs, such as databases, interconnectivity, and security tools.

Fig 4. Platform Expands within new workloads, tools and resources.

End users of the platform, such as Developers, MLOps, and Software Engineers, will benefit from the platform’s readiness to start bringing new workloads and promoting best practices from CI/CD, accessing more resources, and setting up third-party tools to fulfill business needs.

From Customers (platform end-users):

As the platform expands to fulfill technical and user needs, each expansion means new components that make the platform composable. A composable platform will bring value to the business by providing scalability and flexibility to different personas to achieve business goals. Examples of this might be increased trust, speedy service, or cost efficiency for those funding the service. While this persona will receive an indirect benefit from platform composability, they have a sizable role in driving the priority of composable capabilities and components, as facilitating their evolving needs helps determine the necessary platform capabilities for increasing business value.

Conclusion

Composability allows the different personas in an organization to get what they need from a platform without undue investment by stakeholders in areas that are of secondary importance, allowing for flexibility and more efficient onboarding. We discussed what composable platforms are, and how they can help a business to succeed in their goal of deriving the most business value from their investment in cloud native technology.

Blog: Platform as a Product: Understanding the Personas

Thu, 16 Jan 2025 12:00:00 +0000

Platform as a Product Overview

Platform as a Product is a critical topic in the industry because it helps teams to work agile in our forever changing organizations and market. Platform as a Product is key to helping us move quickly and be ready for new technology in a standardized way. According to the CNCF Platforms White Paper, Platform as a product is defined as:

Platform as a product: A platform exists to serve the requirements of its users and it should be designed and evolved based on those requirements, similar to any other software products. Platforms should provide the necessary capabilities to support the most common use cases across product teams and prioritize those over more specific capabilities that are only used by a single team to maximize the value delivered.

Understanding the personas

When considering its users, we need to identify the different personas such as: Developers, ML Engineers, Data Scientists, Platform Engineers, and others.

The personas would focus on different aspects of the platform, and these could be represented in different organizations on one or multiple roles and teams.

Builders (focus on platform and beneficiary experience):
- Enabling Day2 Platform Operations
- Setting up the platform
- Setting up security
- Platform Capabilities for AI
- Platform capabilities for HPC workloads
Enablers (focus on end-users and application capabilities):
- Enabling cloud-native and legacy workloads with best practices such as CI/CD and security guardrails.
- Enabling user experience and self-service capabilities
- Build automation practices to simplify onboarding experiences for end users.
- Configuration integrations and third-party tools
Consumers - Platform Customers (Developers):
- Access the platform to maintain and build applications
- Build any applications from legacy systems, cloud-native, AI
- Might not interact with the platform directly.
End-Users (customers):
- Customers who are the end-users of the applications and systems running on top of the platform.
- Might not interact with the platform directly.
Service Providers:
- Organizations who provide a Platform on top of Kubernetes.
- Consulting organizations that help teams drive implementations and adoption around the platform

Personas interactions

The Platform Builders are those who are installing the platform and configuring the platform in an organization. These are the teams who are responsible for the platform itself. These personas can be a group of teams dedicated to diverse aspects of the platform, networking teams, security, and Platform Engineers, whether they are internal teams to the organization or work with service providers to provide the platform and build configurations on top of it.

The Platform Enablers could be composed of DevOps, Middleware teams, and Migration teams, who are mostly dedicated to building application capabilities and user experience with best practices on top of the platform and work directly with Developers and data Scientists. These personas will also interact with Platform Builders to ensure the platform foundation is ready for the capabilities required. They can be internal teams, external consulting teams, or a mix of both.

The Platform Consumers could be composed of Developers, Software Engineers. They are the personas who build and enrich applications from legacy systems, AI workloads, microservices or any workload that will run on top of the Platform to serve a business needs. They usually are in the Line of Business, and work might work directly with Platform Enables to ensure application capabilities are in place and access self-service and user experience. They can be internal teams, external consulting teams, or a mix of both.

The Platform End-Users, these personas are an organization customer. They are the main reason why the platform exists and what drives the organization’s business. They might interact or not directly with the platform by accessing a UI, service, AI, or any other workload. They will often work with teams closer to the platform consumers.
The Service Providers provide platforms, toolings, and services to help organizations move faster into the cloud native ecosystem. These organizations are focused on resolving common problems that the industry faces and provide diverse tools and frameworks to resolve them. They can be internal teams, external consulting teams, or a mix of both.

Blog: Practical Paths to Platform Maturity: Insights from KubeCon Paris

Wed, 27 Mar 2024 12:00:00 +0000

If you were lucky enough to be at KubeCon in Paris last week, you might have heard Nicki Watt from OpenCredo give a practical walkthrough of the CNCF’s Platform Maturity Model. Nicki was an early contributor to the development of the model, and she spoke about her experience using it with client organizations.

Some of the topics that Nicki covers include:

Understanding Starting Points and Goals: how to assess an organization’s current position within the CNCF Platform Maturity Model aspects, and then how to identify opportunities. This involves surveying existing capabilities and identifying the steps required to meet business needs.
Tailoring Strategies to Context: ways to adapt the maturity model to an organization’s unique context. Instead of aiming for higher levels of maturity for their own sake, Nicki advocates for work that is appropriate to the organization’s specific goals, constraints, and current state.
Center of Excellence Challenges: insights on overcoming obstacles in advancing the maturity of a platform engineering center of excellence. This includes knowing organizational goals, understanding the current landscape of people, processes, and technology, and ensuring that any tools or systems adopted are API-driven to facilitate integration and flexibility.
Practical Application of the Maturity Model: Through examples from her experience, Nicki illustrates how the maturity model can guide organizations in enhancing their platform engineering practices. This involves plotting out paths and options that align with achieving business outcomes, based on the model’s framework.

If you are looking for fresh ideas about how to improve your platform initiative, this talk is full of practical strategies and insights for using the Platform Maturity Model effectively.