There is no doubt; the API Management product space has become very dynamic, with the anticipated big spending pipeline and the IPOs and acquisitions news we have seen in the last few years, you can read all about it in the analysts’ reports.

Companies publish APIs for different reasons, for instance, B2B integration, mobile enablement, and product based revenue generation opportunities.

However, many still struggle with the idea; on why their organization might need an API management program and I still find some of my customers ask the question; isn’t API management is another form of SoA (Service Oriented Architecture)?

While many wrote great articles about this, explaining the difference, however it’s still a mystery for some. Why? I think those are not clear on the use cases. Without a use case it’s hard to understand.

In this blog, I’m going to use a “use case” to highlight the need, hoping that will help answering the API Management Question.

The confusion around SoA with lipsticks is coming from the word “integration”, while both SoA and API Management are solving an integration problem among others; yet, SoA is focusing on “internal” integration and governance while API management is focusing on “external“ integration and exposure, read further for more explanation using the following business use case.

Some of us would remember, back in 1995, when the business started asking the IT organization to create a website, the website request originated –most of the time- in the business, the web marketing and sales channels’ requests or projects usually initiated by the business units and this is why those initiatives were well sponsored, funded and supported with a high probability of success, the same concept applies to APIs, you can think of this as “API as a product”.

Assume the following business use case, ACME is a Payment processing company. For the longest time, the typical use case and business model is to strike business deals with the customers who you know well, the customer is more of a partner who you can trust.

ACME create and distribute integration SDK to the trusted customer base using proprietary protocols, there’s a close relationship and dependency between the API provider and the consumer, the ACME technical staff train the numbered customers and consumers on the new releases and versions.

Recently, ACME business units and product management realized a significant competitive pressure coming from the smaller tech savvy players who are very attractive to a new market segment which is the customer “you don’t” know. Those customers are looking for a loose coupling without a strong relationship with the provider or having a strong dependency on the published APIs.

For ACME to survive in such an environment, the product management team created a new set of integration requirements.

Create and expose public APIs over an abstraction layer that will enable the following,

• Easy integration; where the consumers can use self-serve approach without interacting with the API provider.
• Clear and appealing API documentation.
• Quick time to market mobile app enablement to enable the next generation set of apps developed by “third parties”.
• Secure access to protect from the consumer “you don’t” know using access keys and standard protocols.
• Access and traffic control, where you can control traffic and overcome denial of service attacks or similar threats.
• Create the ability to monetize APIs and create different access tiers.
• Create the analytics capabilities to analyze the API usage and use the information to create revenue generation opportunities and realize competitive advantages and disadvantages.

The above requirements created the need for an API management layer, similar to the situation where business needs created the demand for the website industry we have in hand right now.

For those technical executives who would like to sponsor an API Management project; it’s a noticeable risk if there’s no urgent business need realized for your API program or you don’t have the business case that will sponsor your API program.

Also, as you can see the above requirements are not in the SoA or the internal integration space, however you would still find shared distributed computing design patterns such as mediation and transformation and event driven architecture.

I hope, the above use case, clarified the API Management need for some.

Disclaimer;

Those are my personal views and not representing the people I worked with, the companies I worked for, or my/our past and present customers in any shape or form. Any resemblance to real life use cases or situations is accidental and not intentional in any way, shape or form.

Hope this is helping some and again I understand other’s experience and views could be completely different than mine and I completely respect that.