Application programming interfaces or APIs form the fabric of the modern internet. According to The State of API Security in 2024 Report from Imperva, a Thales company, API calls made up 71% of all web traffic in 2023. Moreover, a typical enterprise site saw an average of 1.5 billion API calls in 2023. Needless to say, developing and managing APIs have become paramount for organisations striving to stay ahead in the technology race.
However, building production-grade APIs and API products has its challenges. From an implementation standpoint, you need to consider security requirements, enforce governance standards, implement access control, ensure stability and reliability, capture logs and metrics to access the health of your services and to troubleshoot them quickly when things go wrong. Adding distributed teams, evolving business requirements, and an expanding tool stack make it a task that could soon go awry and fast!
This is where the platform engineering and API platforms come to the fore, especially considering the platform-as-a-product approach.
The API platform maturity model
This still leaves organisations with an important question – how do you assess the maturity of your API platform and chart a roadmap for the future? Enter the API platform maturity model, a holistic and open framework designed to empower teams and organisations towards excellent API experiences.
We’ve always believed in the power of community-driven initiatives, and the API platform maturity model is no exception. While this has been developed and facilitated by Tyk, this model isn’t just another set of guidelines; it’s a living, breathing testament to the collective wisdom and experiences of platform engineers, product managers, developers, and leaders like you.
Understanding the API platform maturity model
Let’s rewind a bit first. Why is this model such a game-changer? Well, imagine having an intricate yet intuitive roadmap that helps you assess your team’s current maturity level, envision where you want to be, and chart a course to get there. That’s precisely what the API platform maturity model offers – a strategic compass tailor-made for organisations aspiring to API excellence.
At its core, the API platform maturity model has four key objectives:
- Assessing the current maturity of your API platform team
- Defining where you want your maturity to be in the next 6 to 12 months
- Allocating resources strategically to bridge the gap between the two
- Fostering a culture of collaboration among different teams, united by a common objective.
This model builds upon the groundwork laid by the CNCF Platform Engineering Maturity Model, extending its scope in 2 specific ways:
- Tailoring the model to API-first platform engineering teams
- Splitting the CNCF model into two by factoring in the decision-makers and implementers of API platforms.
By doing so, it addresses the unique challenges and opportunities inherent in the API ecosystem.
Who is this model for?
The beauty of the API platform maturity model lies in its versatility. It caters to a diverse audience, each with its unique set of motivations:
Decision-makers
- CTOs, VPs, and directors of technology: Leaders seeking to navigate the path of digital transformation or innovation, and enhance developer productivity within their organisations through widespread adoption of APIs.
- Engineering or product managers: Individuals aiming to empower their development teams to measure and optimise the growth of APIs they own or consume, along with improvements to time to market, performance or utility they need to provide.
Implementers
- Platform engineers and operations managers: Teams and individuals striving to deliver exceptional experiences for both API platform maintainers and users, thereby fostering collaboration and efficiency for the wider teams they serve.
- Application and API product developers: Those who contribute APIs to the platform or consume them most regularly as part of their day-to-day role, seeking to both deliver and integrate APIs that add value.
Navigating the API platform maturity model
The API platform maturity model consists of two distinct yet interconnected parts, each tailored to cater to different stakeholders within the organisation:
- Platform managers and decision-makers
- Platform engineers and implementers
There are a few things to consider when using this maturity model:
- For each part, the model comprises five maturity pillars, with corresponding maturity questions, all representing a critical aspect of platform maturity.
- Each pillar should be considered independently, understood and assessed for relevance to your organisation’s goals. These pillars may influence each other but the assessment should be done independently.
- There are four maturity levels mirroring the approach established by the CNCF platform engineering maturity model. The evolution from level 1 to level 4 takes platform teams from an ad-hoc, individual-driven approach to a fully integrated, self-service platform with robust processes in place.
Part 1: For platform managers and decision-makers
|
Maturity pillar
|
Maturity questions
|
Level 1 (provisional)
|
Level 2 (operational)
|
Level 3
(scalable)
|
Level 4
(optimising)
|
|
Investment
|
How are resources/ funds being allocated in the development of the API platform and platform team?
|
Temporary project basis/ ad-hoc.
|
Dedicated resources/ project based.
|
API platform as a product for 80% of use cases.
|
Platform extended to enable innovation of latest API standards or widened to incorporate bespoke edge cases.
|
|
People & team
|
Who maintains/ is responsible for the API platform, and who has access?
|
Voluntary/ individuals dotted across the organisation.
|
Small central tech, architecture or ops team.
|
Dedicated platform team overseeing federated/ distributed dev teams.
|
Dedicated platform product managers and API specialists continuously iterating on priority API platform improvements.
|
|
Tooling & interfaces
|
How are APIs within the platform surfaced to consumers?
|
Shareable API documentation (if at all).
|
Thinnest viable platform e.g. API wiki.
|
Mature API catalogs as part of an IDP/ external portal.
|
APIs deeply integrated into products and accessible on granular user permissions.
|
|
Process & operations
|
How are API platforms and their capabilities planned, prioritised, developed and maintained?
|
On individual requests / ad-hoc sharing basis.
|
Manual submission to the central resource.
|
Central team enablement & automated service deployment and operations.
|
Further bespoke workflows and distributed developer experience tooling to drive further efficiencies.
|
|
Measurement & reporting
|
How do you measure and report successes and learnings?
|
Basic metrics with ad-hoc reporting.
|
Dedicated KPIs collected and reported frequently.
|
Focused KPIs reported along with insights and analysis, available on a central portal.
|
Self-service KPI reporting dashboards targeted at technical and non-technical audiences.
|
Part 2: For platform engineers and implementers
This part is designed for platform implementers and focuses on the outcomes that the API platform would drive at different levels of maturity.
|
Maturity pillar
|
Maturity questions
|
Level 1
(provisional)
|
Level 2
(operational)
|
Level 3
(scalable)
|
Level 4
(optimising)
|
|
API governance
|
How do you manage and apply API governance policies and standard practices across your organisation? |
Developers run API development tasks on an ad-hoc basis.
|
Central API platform team with API ops still owned by distributed API dev teams, basic API ownership enforced. | Templated API development and operations golden paths standardised across the organisation, personalised ‘API team’ views. | Continued investment to support latest API standards and drive further innovation and efficiencies. End-to-end visibility of APIs. Development of platform APIs to add further value. |
|
API security
|
What organisation- wide API security standards do you have in place? | Basic per API rate limiting, token-based authorisation applied by individuals. | Standardised API rate limiting and token-based API authentication and authorisation advised by central platform team. | Global API security enforced inc. rate limits, central trust using claims to further token- based API authorisation and authentication. | Continual API security, pen testing and audits. Robust compliance to sector-specific or global regulations regularly achieved. |
|
API consumer experience
(API discoverability)
|
How are APIs documented, discovered, accessed, and supported? | Internal word docs shared, API access granted via manual requests e.g. email. Individual adoption. | Internal API catalogs emerging (e.g. API documentation wikis), access granted through formal API requests to central owners. API adoption by multiple teams. | Self-service API catalogs with documentation standards adhered to and access granted on an a permissions basis. API SLAs in place. | Context specific API interfaces, with granular permissions and automated role or subscription based access control baked in. SLAs continually met. API adoption by non techs. |
|
API developer experience
(APIOps)
|
What does your end-to-end API development and deployment workflow / SDLC look like? What best practices are followed? |
Click ops or manual process to move APIs between environments. Ad-hoc API design and development workflows.
|
GitHub actions, config scripts and basic GitOps or CI/CD deployment pipeline best practice for APIs achieved. | Native technologies in use (CI/CD ops tools), automated API creation, testing and deployment achieved. | Consistent API development tooling in use at all stages of the API SDLC e.g. API design, linting, SDKs or IDEs. Seamless collaboration within teams. |
|
API observability
|
What level of insights do you have across your API platform stack? | Basic API telemetry used to analyse API stability, error rates and traffic levels. | Comprehensive API analytics summary dashboards, accessible for API platform management and API development. | Granular API tracing, API telemetry exported and viewed within central observability platform. | Mature API observability dashboards for variety of BAU (alerting and monitoring) and strategic platform KPI / value reporting. |
It’s important to note that advancing through the maturity levels requires intentional and collaborative efforts across all pillars. There’s no one-size-fits-all solution. Instead, it’s about finding the right combination of strategies tailored to your organisation’s context and goals.
It’s also crucial to recognise that the model does not have an inherent good or bad level. Instead, each level is contextual and aligns with your team’s specific objectives and aspirations. So, as you engage with the model, consider your organisation’s goals, challenges, and growth opportunities. Use it to assess your current maturity level, define future aspirations, and allocate resources effectively.
Remember, the model is a tool – a means to an end. The real value lies in applying it to drive meaningful progress and innovation within your organisation.
Next steps
The API platform maturity model represents a transformative tool for organisations navigating the complexities of modern-day API ecosystems. But here’s the thing: we’re not done yet. We’ve just returned from launching the model at the Austin API Summit by NordicAPIs, and the response has been phenomenal. But it is not set in stone; it will evolve with the community’s input and experiences.
By sharing insights and lessons learned, we can collectively refine the model and empower organisations worldwide to make informed decisions and drive meaningful progress. So, we want to hear from you. Your feedback is what fuels our innovation. What do you think? Share your thoughts, insights, and suggestions with us.
Let’s collaborate and shape the future of API excellence together, one level at a time!
