In one of our previous posts we’ve already talked about the API Economy, in this post we’re taking it one step further: we’ll investigate what it takes to become a participant in the API economy. This participant can range from API consumer, producer or platform. An organization can of course take up multiple roles.
Before we start a word of caution: this is a change process for many organizations so be prepared for the fact that it will some take time to get there. Depending on your industry you might even be forced to become a provider of open APIs without the fundamental willingness to do so. Of course, the vision within an organization can evolve over time and drive you towards becoming a digital native provider. For these companies, APIs are business-as-usual and already a major driver of revenue.
Don’t consider the checklist below as a list of dogmas’ which you must implement. Instead use it as a source of inspiration and adopt that which fits within the culture, size, etc. of your organization.
- Create the necessary awareness at business and IT level
- Buy in from senior management levels is mandatory
- Define a clear strategy that explains to people at all levels why you’re doing this, what you want to do and how you’re going to do it.
- A good example was Jef Bezos’s mandate of 2002!!! that started their transformation towards the API economy. Amazon AWS is a direct outcome of this transformation. Before Amazon was “just” an online book store.
- Look for the necessary champions in your organization (both business and IT) that understand the capabilities and possibilities of the API Economy.
- Write guidelines for API development to ensure consistency across the different IT development teams
- Hint: “steal” the ones from Google (https://cloud.google.com/apis/design/)
- Don’t underestimate the learning curve for some people: organize sufficient training and awareness sessions.
- Setup an API catalogue containing information and meta-data on all the APIs available in your organization.
- Not having an overview of all the API will over time result in duplicate APIs or APIs that don’t follow the standards.
- Ensure all APIs are listed into the catalogue.
- Try to avoid Excel: this doesn’t scale to many users. A good recommendation is the open source WSO2 API Manager.
- Make use of the Open API Specification (previously known as Swagger) for documenting APIs
- Avoid Word/Excel for API documentation: such documentation isn’t structured enough. With Open API Specification you will have a more consistent API documentation across your company.
- Open API Specification is directly interpretable by IT tools (code generators, test tools, API gateways, etc.)
- Define the governance life cycle of an API
- Who is responsible for what (high-level design, detailed swagger, formal approval, etc.)
- Ensure the RACI is clear.
- Model the governance life cycle in your API catalogue to easily keep track of the stage of every API.
- Look for the necessary infrastructure components to support the use of APIs at scale
- API Gateway: Mandatory component for exposing your APIs to the outside world and ensuring that the necessary security is applied. Can also offer throttling, monitoring, etc.
- OAuth2 Identity Server: Management of consent and on-behalf-of security tokens across all your APIs.
- You don’t necessarily need to buy expensive big vendor solutions. Good open source versions exist. The big cloud vendors also offer SaaS versions on their platforms.
Innovation Architects 