Many companies have high hopes for API platforms, expecting them to facilitate integrations, promote reuse and future-proof the company technologically. Initially, a lot of things seem to go well: the platform is established, the first projects have been successfully implemented and the team around the API platform builds knowledge. However, over time, a recurring pattern emerges. The demand for new APIs declines, existing APIs are rarely reused, and the API team is increasingly perceived as a bottleneck. APIs are usually only created when needed for a project – often under time pressure and without a long-term strategy.
In this blog post, we use the terms integration and API and define them as follows:
Integration: refers to the linking of different systems or applications to enable seamless data exchange for automated processes.
API: is a defined interface that allows applications to communicate with each other.
The API team recognises these challenges and actively works to counteract them. They organise workshops, define best practices and initiate platform optimisations, such as developing self-service functionalities. However, addressing structural problems proves difficult with these efforts alone. As long as integrations are handled in isolation within individual projects and there is no overarching API strategy, the platform’s effectiveness remains limited. APIs are created and discarded without delivering long-term value.
Why simply providing APIs doesn't guarantee their effective utilisation
Many organisations underestimate that building an API platform is just the first step. The real added value only comes when APIs are not only provided, but also actively used and further developed. However, many organisations fail at this stage. The reasons are numerous: often, they lack an overarching API strategy that promotes a consistent and reusable API landscape.
A key problem is that many view APIs as merely a technical necessity rather than a business enabler. When developed solely to meet immediate interface needs, they lack a strategic component. Often, APIs are created reactively within specific projects to quickly establish integrations. This approach overlooks whether an API could serve other use cases and be reusable, whether it can be extended long-term, or whether it provides sustainable value for the company.
This project-driven development leads to APIs being considered only for their immediate use case. Consequently, organisations end up with a collection of selective integrations between exactly two systems. While these integrations serve their short-term purpose, they eventually create a fragmented architecture that is difficult to maintain.
The role of the API team poses a problem as well. Many view it purely as a "service provider" that develops integrations on demand. Often, the team gets involved late in the project, after the basic requirements have already been defined, leaving no opportunity to optimise the API design for reuse. Consequently, the API team focuses solely on implementation and cannot influence the API landscape strategically. Additionally, many development teams lack a thorough understanding of good API design due to the absence of systematic support or enablement processes.
Another problem lies in the perception of the platform itself. Many developers view it as a requirement to be met rather than an enabler of modern integration. The focus remains on the technology rather than the actual added value of APIs. Instead of leveraging the platform to improve integrations long-term, developers often use it merely as a means for selective integration. Consequently, APIs are created out of immediate necessity rather than being recognized as valuable tools for optimising business processes.
At the same time, API platforms can be challenging and cumbersome to work with. They typically cover only a few standard integration cases and offer low levels of automation without significant customisation. This complexity frequently discourages development teams from utilising them.
Many also misunderstand API governance. While companies often have technical standards, they lack metrics to evaluate the actual benefits and effectiveness of APIs. They rarely ask questions like, "Is an API actually being used?", "How long does it take for development teams to successfully use it?", or "Will the API help reduce integration efforts in the future?". Without this data, determining whether an API truly delivers added value or is just another forgotten technical interface remains unclear.
Ultimately, simply providing APIs is not enough. They must be designed to deliver long-term value, be efficient to use, and align strategically with the enterprise architecture. Without this, an API platform becomes a well-intentioned but ineffective tool, perceived as a hurdle rather than an enabler.
API Effectiveness through Team Topologies
Effective APIs depend not only on technology but also on the right organisational structure. Companies must transition from project-driven API development to strategic API products. The concept of team topologies offers a clear framework for achieving this.
Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.
Team Topologies defines four different team types, with three being particularly relevant in the API context: Platform Team, Enabling Team and Stream-Aligned Teams.
A Platform Team forms the backbone of the API platform. It provides the infrastructure, ensures a good developer experience, promotes API reusability, and offers self-service functions with a high degree of automation. Instead of limiting its role to governance or tooling, the platform team should focus on making APIs usable and developing an API strategy with measurable goals.
An Enabling Team helps other teams view APIs as products. It assists development teams in establishing best practices, promoting reuse, and designing APIs for a broader user base. Without this support, API development often remains isolated and ineffective.
The biggest change, however, occurs in Stream-Aligned Teams. These teams take ownership of their APIs and develop them with a long-term product perspective. They no longer build APIs just to complete a project but to create sustainable value. This approach establishes true API ownership, directly impacting effectiveness. When teams fully own their APIs, they consider long-term use, extensibility, and quality. This results in better-designed, reusable, and economically sensible APIs.
A key advantage of Team Topologies is the shift from isolated point-to-point integrations to strategically planned API products. Teams must build APIs with a long-term perspective, creating a clear roadmap and defining metrics to measure success. Adoption rate, time-to-first-success, and reuse rate are essential for understanding whether an API is actively used and reused or merely another technical artefact.
Conclusion: API strategy is crucial for success
An API platform alone cannot achieve sustainable integration success. APIs must be effectively used and further developed, not just provided. A clearly formulated and implemented strategy is crucial; otherwise, the API platform remains a technical necessity used out of obligation. With the right team structure, however, it becomes a true enabler for digital transformation.
Achieving API effectiveness requires more than good technology; it involves viewing APIs as valuable assets and organising their development to ensure they contribute to corporate strategy over the long term. To maximise the benefits of an API platform in your organisation, focus beyond technology and emphasise the interaction between teams, processes, and strategy.
Was this post helpful?
More articles
fromMiriam Greis & Daniel Kocot
30.1.2025 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Blog authors
Miriam Greis
Lead API Consultant
Do you still have questions? Just send me a message.
Daniel Kocot
Senior Solution Architect / Head of API Consulting
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.