5 Steps to API Adoption

API adoption at enterprises is composed of 5 steps. What I have discussed in this blog is based on my experience with over 10 customers in last 18 months.

So you have reached a point where you know what APIs are and how the API technology can benefit your enterprise. The question you are asking is where do I go from here? Today many enterprise are in this state.

In most of the enterprises, the effort to adopt API is driven by the central IT team(s) that collaborates with the business unit development teams. Path followed by these central IT teams vary and all have their own unique (sometime interesting) challenges. Here is a high level step by step guide/plan that can get you from your current (mostly SOA centeric) space to a state of API nirvana, a state in which the promises of the APIs such new business models and revenue streams *may* be realized.

1. API Strategy creation

  • What are the needs?

The very first thing you need to understand is the need. What is it that you are trying to do with  API i.e., identify the use cases. In this stage it is critical that the central IT team engage the business units to identify the API use cases. Once you have a good handle on the use cases and a fairly good idea on business/IT benefits you are ready to build a plan. 

  • Business case for the API

The one challenging question that you are trying to answer here is - What is the ROI on this investment in API technology? Technology teams always struggle with this question. Unfortunately there is no straightforward answer to this question. The advice I have is that look at your business strategy/goals and carry out an determination of how  the API use-cases identified in the previous step(s) are enabling the business to achieve their goals. 

  • Roadmap for API

Here you need to think of next 3 to 5 years with an eye towards the potentials offered by API technology. One mistake some enterprises today are making is that they are driven by their current narrow focussed needs. For example your need for API today may be for Private API only; suggestion here would be to get business's view on the possibility of API monetization in next couple of years down the road. This obviously would require the IT Teams to educate the business on possibilities that API technology has opened up.


2. API Management Platform selection

  • Setup the criteria for the platform selection

There is no standardization of the API management platforms. All products provide at a minimum (a) Gateway (b) Developer portal (c) Policy management (d) Analytics. Each of these products have their own sweet spots and painpoints. So the challenge is how do you select the platform? Unfortunately a number of organizations are starting at this point rather than carrying out steps discussed in #1.

Develop a criteria matrix with weightage. The criteria is not just the features of the platform but other aspects as well, so here is a list of typical criteria that is used for the platform select process:

a. API Uses (drives feauture weightage)
b. Community support
c. Skills availability
d. Your API Roadmap
e. Enterprise landscape
f. Existing vendor relationship

will cover these in details in another blog (some day soon)

  • Carry out a POC/POT

Try out the API platforms. Most of the API products today offer a SaaS version trials for free. Vendors I work with are open to paticipating in these POCT/POT so take advantage. The idea here is to get the teams to roll up their sleeves and try out the products. There is no substitute to actual experience with the products. Keep in mind you may not be able to connect back to your on-premis services (or data) but use may the free cloud offerings to simulate the backends.

  • Take input from neutral parties

Connect with a trusted partner. Consultants like us are working day in and day out with multiple enterprises that are working towards the adoption of API. Consultants can (and should) provide you a neutral opinion to you based on your specific situation. 

3. API Practices setup

  • Infrastructure setup

No matter whether you are going with the on-premise or SaaS or hybrid model, my suggestion would be to engage the platform vendor to create the infrastructure blueprint. Do not forget to ask the vendor for automations needed for managing the on-premise infrastructure (one area that may become a painpoint).

  • Practices setup

So now you are ready with the infrastructure, what next? You do not want a free for all play field, there has to be rules and practices to be followed by all constituents. Most organizations treat their SOA practices as the starting point. It is OK to do that but you need to keep in mind the differences between SOA and API. Don't forget that SOA has many painpoints that have bee addressed by API e.g., provisioning, runtime visibility, impact analysis ....

My suggestion to the customers is to spend no more than 6 to 10 weeks on this exercise. The objective should be to come up with the minimal set of practices that can be put to use by the API developers and the applications asap. Typical assets generated at the end of this exercise are:

a. Best practices for API e.g., RESTful versus RESTish
b. API specifications/contract management e.g., use of Swagger
b. API Governance & Lifecycle
c. Infrastructure provisioning e.g., how multi tenancy on the platform will be utilized
d. Exemplars & Realization patterns

4. API Adoption

  • Define the guidelines

One of the common confusion I have seen is that teams tend to think that once they have adopted API platform they have to invest in creating API by re-coding their existing SOA/SOAP/XML services to RESTful/JSON. There are many such questions that development teams have - the best way to answer these questions is to create some guidelines that would help the development teams get answers for such common questions. For example the go forward path for existing services would be keep it & just create a proxy on the API platform and apply appropriate policies :)

  • Develop an API community

A number of enterprises today are toying with the idea of creating an API marketplace (or storefront) within their enterprises. On paper this idea is great but the fate of this idea from realization perspective is decided by many factors such as culture, sponsorship, nature of assets etc. My suggestion is to consider this idea as part of a longer term strategy but at the minimum get an effective developer portal up and available as soon as you can. Developer portal is a first class citizen in the API platform technology stack. It is the starting point for developing an API community in your enterprise. All API platforms provide a portal product; some are more flexible & extensible than others. Consider API platform flexibility/extensibility as one of the critera for platform selection. For example you may decide to have a discussion forum on the portal - does the product you are considering offer the flexbility and if yes what would be the effort?

  • Generate the buzz

Promote the idea of API community through the enterprise. Many enterprises today are parterning with vendors and consultants to conduct Hackethons, Boocamps & Roadshows. The challenge here is to get the development teams to adopt the idea of creating composable apps using API as the building blocks. Use all opportunities to educate your IT and even the business teams on the possibilities of API.

  • Assist the teams in building API

Realization of API is dependent on your IT organizations existing development practices and technology stacks. Some organizations I work with are looking to also adopt microservices and consider it as part of their API adoption roadmap. My suggestion would be to keep the adoption path for API independent of the microservices path as these aspects complement each other and are not essentially inter-dependent; at some point they intersect. From platform perspective your enterprise will need to invest in education of the platform operations and API development teams. A common model being used is that the central IT team takes on the responsibility of developing the initial set of API(s) and at the same time educating the business unit developers. The long term goal is for the business unit development teams to take over the responsibility of API development. This is the stage when the central IT team collaborates with the development teams to refine the best practices and guidelines.

5. Learn, Innovate, Mature 

API platform technology is evolving, there definitely are many benefits that your organization will start to see immediately but lets not forget all new technologies come with a baggage of its own painpoints. In case of API technology we are yet to dsicover those painpoints. The suggestion is to keep on learning & evolving by way of building API(s). 

Last but not the least - Its a well accepted fact that the best way to learn swimming is to jump in the pool but make sure there is a trusted life guard nearby (i.e., in this case a trusted partner or mentor or consultant).