From these cases, we’ve so far harvested five distinct stages of API adoption. Now, your mileage might vary, of course, but we wanted to share our experience with you, and hopefully help you lead your API initiative in the right direction.
Stage 1: API Awareness
In the first stage of API adoption, APIs get simply introduced as a lightweight method of application integration. Oftentimes, we see integration needs of mobile applications as the first targets. In a mobile-first approach, APIs are simply extracted from the User Experience Design – or: Human Interface Design, as Apple still prefers to call it. In other words, APIs are designed to make life simple for app developers. And because the web-centric model of APIs tends to resonate well with the development frameworks for mobile apps, the threshold to adopt APIs is quite low. In this stage, expect your developers to quickly become enthusiastic – the new, simplistic programming model for remote procedure calls proves way much easier to implement than the technologies they’re used to. Moreover, the developers feel in control over the entire integration pathway, which greatly increases the development efficiency. It significantly speeds-up the overall process, which in turn makes product owners happy. And so, the infections quickly spread – especially to the teams working in the fast-paced mode of IT.
Stage 2: API Platform Architecture
Once the benefits of APIs are firmly established, you’re likely to start thinking about different kind of concerns – if only because certain vendors are pushing their API technologies. The concerns that typically get entered on the management agenda in this stage are the ones such as: the risks involved with API usage, how to control the quality of your APIs, and how to manage those APIs on the enterprise scale.
API Management products tackle these concerns through multiple components. An API Gateway is the technology of choice to guard the access to your APIs. It acts as an application-level proxy which enforces a set of policies. These policies address several risks involved – such as the limitation of access and the protection against capacity overflow. The first set of policies grants access only from identified applications, developed by trusted developers, who can prove they own a valid subscription to your API. Additionally, end-user authorization might come into play. After all, not everybody using an application gets treated the same. Rate limitation is a different kind of technique, aiming to limit client applications to a reasonable amount of API invocations per unit of time. Any subsequent invocation request gets throttled out. Additionally, more intelligent rate-limiting policies may limit the total number of invocations from all sources combined. After all, is protection of your back-end systems against an overflow of API invocations your target, then that is the most straightforward approach.
To make this all work, policies should be defined (at a Policy Administration Point) and published, and API subscriptions must be managed. That’s where an API Publishing Portal and an API Developer Store come into play. It makes a lot of sense to implement a single store for all the APIs on offer. Developers who consume APIs will be thankful if they have a single point to discover, test, and subscribe to your APIs.
Setting up a system of gateways and portals can be very straightforward. Oftentimes, however, all kinds of requirements must be taken into consideration. Think of performance, (global) scalability, availability, manageability and security requirements, to name a few. The API management components must be fitted into an existing enterprise architecture, including an identity provider, an RDBMS, an analytics engine, a log aggregator and a health monitor. And if you have multiple data-centers, in the cloud or on premise, the degree of freedom to choose increases proportionally. You get the idea. So, it is probably best to plan for several design workshops with your leading architects.
With centralized API Management comes the first effort of standardization – most notably naming conventions and life-cycle management policies. Of course, the importance of creating the outside image of a well-managed and synchronized enterprise varies from company to company, and with it the richness and enforcement of standards, but few can avoid having some standards in place at all.
Stage 3: API Management Core Processes
An approach we experience most of the times, is to start with adopting much of the API Management functionality out-of-the-box – the minimum viable API Management configuration – and only later start with scaling, customization, and fine-tuning efforts. These changes will not affect your overall architecture, but it may, for instance, impact the look-and-feel, and even the functionality of your portals.
Developer engagement starts to get more and more attention. For instance, to promote the collaboration of API providers and consumers across time, language and geographical boundaries. What are best-practices for documentation? How to classify APIs? How to build and maintain consistency across APIs? Finding the right answers to those questions is often a complicated puzzle to solve.
Another area of concern are the management processes supporting developers in your developer store. Out-of-the-box, those processes are simply self-managed by the developer. In certain cases, this may be good enough. More often, we find that the businesses or business units offering their APIs want to have some control over the developers who implement them. This may range from simply verifying an email address, where perhaps all addresses outside the company domain get filtered out, to an extensive vetting of developers and their organizations, up to a thorough investigation of the applications they develop.
WSO2 API Manager allows you to completely define your own processes, in your preferred workflow, business process management or case management system. And if you don’t have such a system available, or you don’t want to invest in it anymore, rest assured the WSO2 Business Process Server is a great choice to do that job for you.
Stage 4: Advanced API Management Practices
Over time, the number of APIs you manage, the number of developers you engage with, and the number of API invocations you’re faced with, are all on the rise. That’s good, your business is thriving.
To keep up with your growing business, you’re depending more and more on your API Analytics dashboard. You want to discover your bottlenecks early, and preferably fix them as and when they occur. Instant up- and downscaling of your API gateways is an increasingly common approach. The good news is that your advanced API Analytics is the ideal system to monitor the health of your system, and initiate up- and downscaling events. Moreover, it can also monitor – be it intentional or not – undesirable usage of your APIs – and initiate a proper counter-action – dynamically limiting rates per developer, per application, or IP address, for instance. Or even revoking an API subscription, or blacklisting an IP address altogether. You’re in charge of your platform, and the good thing is that you don’t have to intervene personally when your policies are violated.
Frankly, the way these advanced counter-policies are developed are mostly as a follow-up on some kind of incident. That resonates nicely with our recommended practice: do not spend too much time in dreaming up nightmare scenario’s, but rather monitor your systems closely and aggressively evaluate and follow-up any incident, such that there is a zero chance of repeat. In other words: move fast, and repair anything that breaks along the way. And don’t miss any opportunity to learn and enhance.
Monetization is another theme that comes with more experienced API enterprises. With monetization of your APIs, intimate developer engagement grows in importance even more. Your API Developer store has now become a portal to seduce more customers, and to keep them happy over time. Hence, you want to share statistics on their API consumption, and on your service levels. And most important of all, you want to meter usage data in accordance to your billing plan. WSO2 API Manager Analytics is there to help you out.
Stage 5: API First
In the fifth and currently final stage, enterprises come to the realization that what works well for the front-end integration, could work equally well in back-end integration. The traditional SOA integration effort tends to get discharged as unnecessarily cumbersome, disappointingly ineffective, and insufficiently aligned with today’s agile development practices. So, APIs become the core language of enterprise integration.
To adopt an API First strategy, a couple of things need to be in place. First, your API gateway must become the single-point-of-entry to your services. Only then can you trust your policy enforcement point to effectively shield your services form policy violation in all cases. No more excuses, all service calls are routed over your API gateway. And all service invocations are actively monitored and subject to managed policies. No exception.
Secondly, your integration approach must be turned upside-down. Your service consumer teams have no longer to wait for the integration squad to do their magic – mostly to discover in the end, that the service interface leaves much to be desired after all. In an API first approach, you start with defining your API first, and simply generate your stubs and clients so your teams can immediately start experimenting and enhancing. And only when you’re certain that an API is well-defined, then you start building your service providers and your service consumers. You can do that in parallel, because the integration has already been validated and verified. In terms of efficiency gains, this is probably the greatest boost you can expect from your API management initiative.
Final note
The API era is still fresh and developing rapidly. Consequently, we’re far from certain that the fifth stage will be the final stage. If the omens prove right, it promises to continue to be an exciting time to be in integration. In any case, expect us to keep you posted on our findings.
Where are you currently on your API adoption journey? Still in the early stages, or running in front? Maybe already beyond the fifth stage? We’d love to hear from you in the comment section. Should you in the meantime have questions on how to become more API-savvy? Don’t hesitate to contact us right away. If you allow us, we’ll proudly guide you on your API adoption journey too.
