The Changing Face of API Management
Blog: The Tibco Blog
It is a simple fact that in today’s business environment, if you stand still for very long, you will get run over by the competition. If you need proof, all you have to do is look around you. Entire industries are rapidly transforming as a result of new entrants into their market that have come out of nowhere to provide completely new and innovative ways to engage with customers and business partners.
As participants in this, we are inventing a new class of applications that combine internal and external software and services. We are also fundamentally rethinking how an application needs to interact with the world around it, where everything has a digital heartbeat and is web connected. And we’re trying to do this in a way that is secure, at the same time that security is getting exponentially harder to understand and the business impact of a breach has never been higher. That’s a pretty tall order. If you work in IT, you better keep your resume updated.
What all of these things have in common though, is the use of APIs. APIs have become the connective tissue for the enterprise and the glue that holds these modern applications together. APIs are everywhere. They are so pervasive and so critical to the execution of digital strategies, that the business risk associated with APIs cannot be ignored. APIs need to be treated like products; which is basically what they have become.
The question many of you are asking yourselves might be, how do I do that? What kind of products do I need? What kind of new practices do I need to adopt? How do I get started?
The short answer is that you need an API platform. The longer answer is that there are a lot of different ways that APIs can be used, and you need a way to map your business needs to the capabilities that an API platform can provide.
You’ll notice that I’m referring to this as an “API platform” and not an “API management product”. There’s a simple reason for that. Exposing backend data with an API today can often go beyond the capabilities that a traditional API management product can provide. More sophisticated backend APIs can require interactions and flows between multiple applications and services to get what you’re looking for. This is especially true when the API sits in front of a collection of microservices. To do this right, you need some of the more advanced capabilities that only integration functionality in an API platform can provide, such as advanced API modeling and mocking, microservices creation and composition, SOAP refactoring, choreography and orchestration, and interop with existing ESB services and messaging brokers.
Over the past couple of years, traditional API management products have begun to evolve into API platforms, combining API management and integration functionality; but there’s a lot of variation in terms of the scope of functionality that different vendors provide. There is a need in the market for both mainstream traditional API management products, as well as their more advanced brethren; the API platform. It’s really just a case of picking the right tool for the job at hand.
If you are evaluating an API solution today, here’s a few questions you can ask yourself to help you determine which of these product approaches is best for you:
Can I get by with buying a traditional API management product?
In many cases, this is all you need. If your main goal is to expose some simple backend data securely and make your APIs discoverable through a portal for external business partners, this might be good enough, especially if all you use is a synchronous request/reply message pattern with APIs that are not overly complex.
Having the ability to “productize” APIs and put some controls in place regarding who can access them, how they can be used, and to define some operational policies to protect your backend systems from bad actors, will go a long way towards creating successful API initiatives.
And, if you already have an integration platform and you just want to expose some of your APIs externally, then just adding a standalone API management product to your integration portfolio might be the most cost-effective approach for you.
How do I know if I need a full featured API platform?
Most people who need to go beyond basic API management have much more sophisticated use cases to deal with, more complex message exchange patterns to support, and a need to more deeply integrate their APIs into their backend IT infrastructure.
If you anticipate the need to do any of the following, you should evaluate an API platform that includes integration functionality:
- Refactoring of existing SOAP services into more fine-grained REST APIs
- Plans to build and deploy microservices architecture
- Support for IoT applications or sensor-enabled streaming devices
- Multi-channel apps that service a wide variety of mobile device types and form factors
- Movement towards containerized, cloud-based DevOps architecture, or a PaaS delivery model in general
- Expectations of frequent changes to your API scope or functionality
This set of guidelines is far from being all-inclusive, but will get you pointed in the right direction. I’ve been thinking about developing a more detailed buyers guide for API management that will go into a lot more detail on this stuff. Check back on the mashery.com site from time to time if you’re interested, or contact us if you’d like to discuss further.
Leave a Comment
You must be logged in to post a comment.
