3 Reasons to Create an API Platform for your API Practice

Businessman touching tablet and laptop, managing global structure networking and data exchanges customer connection on workplace. Business technology and digital marketing network concept.

Having an API doesn’t matter if nobody’s using it. That’s from the O’Reilly book “APIs: A Strategy Guide”.

Gartner, in the 2019 Magic Quadrant for Full Life Cycle API Management says:

Effective API programs lay the foundations for digital transformation by enabling organizations to build a platform and develop an ecosystem.

Building an API Platform leads to more API use, and it is usage – not existence – that matters. Said differently, winners will focus on API consumption not API production.

An API Platform matters for three reasons

There are three important questions to ask yourself about your API practice to understand the reasons why you want to think about a platform approach to APIs:

  1. How do you know what’s going on with your API? Those of us who use jargon often say something about eliminating shadow IT, but it really comes down to how do you know what’s going on? How do you know who’s using your API? How do you know you’re your SLA’s are? How do you know how to plan for future growth expectations? How do you make sure everyone is “using the API right?”
  2. How do you encourage collaboration? This gets at the heart of the O’Reilly comment above. Success is not creating an API but getting others to use it.
  3. How do you ensure API security? I like to think about taking security out of the hands of developers (in large part, not completely) and putting it into the platform, driven by policy, and owned by the security experts.

Tangent: Why APIs?

APIs get people excited because they make it easier to connect digital capabilities. You have a piece of data in that system over there… does it have an API? Wait, I need to add authentication for my enterprise… is there an authentication service I can use? What’s the API?

APIs brought complex integration to consumer awareness. APIs were the consumerization of integration. Many highly technical people thought of marketing people developing “software” (like using a Zapier Zap to put Marketo leads into a spreadsheet) as not “real” programming. This was like when real computer people thought Windows was unnecessary because they could do everything they needed in DOS.

Yeah, they could. But few others could as well. There is power in simplicity, and APIs bring simplicity to integration.

As often happens in big-enterprise technology departments though is that it’s harder to change incentives and process that it is technology. And so, APIs enabled the same people to integrate faster, because APIs made integration easier.

Faster meant they could do more. But it was still the same ‘they’.

Companies that really want scale need to change the ‘they’ and let anyone that wants to self-serve their integration needs.

In fact, Axway surveyed 550 senior IT leaders to get their views of integration and we found that:

“86% of IT leaders believe that IT should not just be integrating for other departments but should spend more time enabling others to integrate for themselves (while remaining compliant and secure).”

In short, APIs enable speed through simplicity, but they also need to enable scale. And the way to do that is through an API platform.

What should you do first?

I mean, you know I’m going to say build an API platform. What does that mean? What capabilities are you actually building?

  • Analytics.
  • Catalog.
  • Visibility.
  • Dependencies.

Developer Portal. Deliver SLAs, manage developer groups, understand and connect the community so that API product owners can deliver the APIs their customers need. I love Engie Group’s customer story as proof of this point.

  • Security by policy.
  • API Gateway.

There’s more, of course. And, the devil’s in the technical details for sure. These three areas though are enough to start to understand your own organization’s priorities and start to socialize the idea of creating a platform of your own.

It’s not about the capabilities, but the results.

Can you eliminate shadow IT integration?

Are you encouraging collaboration?

Are you gaining more consistent and API specific security, without requiring that every developer also be a security expert (and the expensive salaries that go along with that experience)? Are you preventing known API security vulnerabilities by implementing protection in an API platform rather than in each individual application or API stack?

Two Common Questions

My cloud service has an API Gateway, do I have a platform?

No. For starters, you might have internal needs that don’t make sense to put into the cloud. When you think about a platform, you need to think about a hybrid solution (on- and off-premise) so that you have the flexibility to deploy elements of the platform wherever it makes sense for both your technical architecture and business constraints. Also, because you likely have multiple clouds inside your org, that means you would have multiple, silo-ed API infrastructures.

91% of Sr. IT Leaders in organizations agree that being able to integrate seamlessly across different systems, departments, and partners is crucial for success. How can you get an end-to-end view if solutions are siloed by technology/cloud platform?

Those tools are a good start, have a look at the Gartner 2019 Magic Quadrant for Full Life Cycle API Management to see how we all compare.

I’m already using an API security gateway; do I have a platform?

No. You have an API security gateway. Sometimes, you can attach a developer portal to that to help organize your developer community. You should be careful though that the developer portal is abstracted from the gateway as some vendors have a 1:1 relationship between API Gateway and API Portal.

Also, you want to take advantage of the “right security, in the right place”. A cloud API Gateway can provide interesting DDoS protection (before the traffic hits your site) and the API Security Gateway can do good policy-based authentication. Again, silos. You need a platform that brings it all together so that you get end-to-end visibility, dependency analysis, and understand in what shadows your security gaps are hiding.

Summary

The O’Reilly API Strategy Guide says that consumption is important. I interpret what Gartner says to mean that it’s the API platform that enables digital transformation.

When you shift your focus from publishing APIs to consumption of digital capabilities through APIs, you’ll start to appreciate the scale you can achieve. You’ll be enabling your business to self-serve their own integration needs without compromising security or governance, and while achieving even better end-to-end visibility and dependency analysis.

For more, make sure to read the Gartner 2019 Magic Quadrant report for Full Life Cycle API Management.

Gartner, Magic Quadrant for Full Life Cycle API Management, Paolo Malinverno, Mark O’Neill, Aashish Gupta, Kimihiko Iijima, 9 October 2019

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

LEAVE A REPLY

Please enter your comment!
Please enter your name here