APIs are how software talk, it is now the de facto standard for application communication, further to this, APIs are becoming the primary interface for business, essentially replacing the physical storefront, fuelling a whole economy centered around APIs and software. It therefore stands to reason that the management of them should be at the core of our strategy.
Aside from being a technology term, API Management is more broadly the capability of controlling and governing the API estate and associated API lifecycles across an organisation. This includes the ability to expose data externally via APIs and the provision of a framework with associated tooling to enable the development and publishing of APIs for consumption.
Provide greater security around your exposed data
Get greater understanding of the business value of your APIs
Reduce technical debt and complexity associated with large API portfolios
Reduce time to market with new API based initiatives
How to implement API Management
Typical API Management capabilities include
- API Gateway (for exposing APIs)
- API Developer Portal (for creation of APIs)
- API Marketplace (for subscribing to APIs)
- API Security and Governance
- API Traffic Management (throttling and rate limiting)
- Monetisation of APIs
- API Lifecycle Management
An organisation that has adopted an API-centric approach to business has typically implemented most of these capabilities, with the core component being the API gateway. The API gateway is essential to allow business functionality to be exposed externally for B2B and B2C interactions.
Organisations managing APIs will likely have roles and responsibilities associated with the API lifecycle and associated data management/stewardship. Familiar roles in the API management space include
- API Designer
- API Developer
- API Administrator
The roles around data specifically can vary, but data architecture is a key discipline required in API-centric organisations to ensure the validity and integrity of services. Data design is also an important factor when trying to avoid tight coupling and vendor lock-in with specific applications. A canonical data model is largely used in this instance to create a layer of abstraction from an application’s own physical data model.
Where APIs are used as the primary integration approach, a layered architecture is usually employed to separate API types. Here is a typical example
With the proliferation of APIs, it is easy to see how management of them must become a critical capability for any organisation, specifically the security and governance, which is often an area overlooked. Offering data and functionality to the outside world involves increasing your organisation’s attack surface, working within security boundaries that are likely to be new. This requires careful consideration and the need for policies, procedures and API Management technologies to mitigate any risk.
When adopting an API-centric approach to integration and exposing business functionality, it’s important to consider the entire lifecycle of an API. APIs are more often than not providing critical business services, and as with any other business service, there should be a plan for service life from inception to decommission.
Common Mistakes made with API Management
Common mistakes of API Management tend to be on the non-technical side. APIs themselves require action from multiple perspectives to be successful. The product or service viewpoint is often secondary to the technical one, resulting in technical success being prioritised over business success. It is common to see APIs measured and analysed on “location accessed from”, “API availability” and “API performance”, but less common to see API usage and adoption measured from a business success point of view. Failing to market and consider adoption of APIs as a product or service is what often leads to underwhelming results in API initiatives.
From an API Management perspective, the most common challenge encountered usually involves API security and access, more specifically the access to specific data items through an API. Situations such as returning data items to an individual that can only see certain items of data on themselves and not others, yet through the same shared API. Challenges such as this can be overcome, but can be difficult without planning security and access carefully. It is often the case that the same development approach is adopted for Experience APIs, Process APIs and System APIs, whilst this “can” work, there are significantly different considerations for an API delivering data to consumers, in which the data and access model should be designed agnostically of the API itself.
How Can Chakray Help?
At Chakray we have many API specialists, from API Strategy and enablement, API technology specialists, to API Development and Support. We have extensive experience in major API programmes, understanding what success looks like and the common pitfalls to avoid. Our knowledge extends across many industries giving us insights into how APIs are utilised for competitive advantage, and how API Management can best be utilised to support these initiatives.Get in touch
You May Be Interested In…
Further information and reading on subjects related to this page.
API Management: How to make your business grow with open source APIs
Are you thinking about how to boost the growth of your business If you want to bet on an innovative (and winning) strategy, include Open APIs in your
Success Story: Implementation of the WSO2 architecture
In full digital transformation process, working with a large number of isolated systems and applications, can become a big problem for users Learn
Talk to our experts
Contact our team to discuss your initiatives and find out how Chakray can help deliver your successful outcomes.Get in touch