Boomi API Management: 5 Lifecycle Concentration Points
Your organization’s API catalog is growing. Or, maybe, you have plans to expand it, providing greater access to data and services across your organizations or to your clients and partners.
Do you need API Management?
As the number of APIs you develop and expose grows, you need to think about them less like small services and more like products. As products, API management becomes imperative.
A product like Dell Boomi’s API Management might be just the thing to wrangle all of the API assets your team is creating.
What is API Management?
We mentioned above that APIs should be thought of as products. Why? As more and more people rely on your APIs, you need to keep in mind the same factors you do with an application - Security. Versions. Documentation. And so on.
As such, you need to think about APIs as a product manager does, and you’ll need to manage the entire lifecycle. APIs require design, development, versioning, classes of services, consideration for monetization, testing, scalability - the list goes on but is no different from a standard product lifecycle.
To understand why this is important, let’s take a step back. What is an API? The commonly accepted understanding is that APIs - Application Programming Interfaces - is anything that provides an interface to an external application. Of course, they are a little more complicated than that straightforward definition sounds.
You can think of an API as two main components that work together:
- Code: the thing that does the heavy lifting. The implementation.
- Interface or Proxy: The “how” of using the API. Metadata, policies, the definition, the RAML/WSDL/WADL, etc.
This separation is what makes APIs powerful, but it also adds a layer of complexity. For instance, hybrid organizations need a way to share APIs across the ecosystem. We’ve seen this in some of our largest clients, where individual departments are the size of businesses themselves. Each has agency to determine their toolsets and platforms. But they also need to communicate with other business units with APIs.
Another example is when you want to enhance the data returned from an external API. Instead of merely consuming the data returned from a request, you may want to wrap that information with additional information or a security layer, like access management controls.
The Boomi Difference
Most integration platforms assume that both parts - the code and the interface - are on the same platform. Boomi doesn’t make that assumption. The implementation could live on MuleSoft, Google, webMethods - nearly anywhere. You can host an API proxy on Boomi that points to a non-Boomi API implementation, allowing the two parts to exist independently.
The Case for API Management
If you’re developing or publishing many APIs, or plan to, you’ll need to think through some of these product discipline aspects:
- API approval workflows
- Robust security policies
- An automated testing strategy
- A versioning strategy
- Rate-limiting, monetization, or class of service policies.
- Transformation policies to transform between various formats: SOAP, REST, etc.
You’ll also need all of the tooling behind that - the ability to publish APIs and make them discoverable, the libraries to support security policies and encryption, automated testing, support to enforce rate limiting, and the rest of the feature to support API management at scale.
If you’ve already got all that, great, you’re basically already doing API management. In reality, though, almost no one does.It’s an enormous undertaking to develop everything you need. And you don’t need to.
An API management platform supports and streamlines both aspects of API Management - the discipline of management and the underlying tools to support it.
And if you think you’re going to do this, just remember - Google bought Apigee’s API management platform rather than building it themselves. If Google doesn’t see the reason to spend time building this, why would you?
If you aren’t currently using API management, pay attention to these telltale signs you might need it:
- Duplication of APIs: Teams can’t find existing APIs, so they duplicate the functionality over and over. This is essentially the opposite of reuse – one main benefit of APIs.
- API security policies are being applied inconsistently: Each development team is“doing their own thing” and creating risk for the business
- Developers aren’t using existing APIs. They can find endpoints, but don’t know how to use the APIs, and must spend time trying to figure it out. They might give up and build it themselves.
- Lack of version management: Every time a new version is released, a consumer is impacted by lack of backward compatibility, often as a result of inadequate testing
If you’re failing at any of these, you’re not treating your APIs like products. To do that, you’ll need to work through the five phases of API lifecycle management.
The 5 Phases of Boomi APILifecycle Management
Design Time and Discoverability
A key concept of using APIs is reuse. API management platforms permit easy access and use, which, by extension, encourages reuse. How does it do that?
APIs are published to a catalog, creating visibility for the services and reducing the likelihood of duplication. Along with the catalog, developers have access to clear documentation, so that they know how to use the API when the need arises. The API management platform will also provide access to the API’s RAML or OpenAPI/Swagger specs (technical specs that are human-readable but can also be machine-interpreted by modern integration platforms).
Boomi’s Developer Portal addresses this need and provides access to developers to discover existing APIs as well as expose information about the APIs they develop.
Configuration and Build
For developers, API configuration using policies lets you add common and required management capabilities quickly, reliably, and consistently. These policies can be set within the API management platform.
Common examples of policies include:
- Rate limiting
- Performance and SLAs
On the Dell Boomi platform, most API build and configuration work is done in the web browser within the API Management dashboard.
In terms of API management, deployment is about where the API proxy lives - on-prem, in the cloud, or a hybrid environment - and how it scales.
But deployment is even more than that. Based on our earlier definition, we have two pieces to an API that are relevant - the code and the interface. Where each element lives needs to be defined as part of the management discipline and execution.
Lastly, you’ll also need to define the deployment configuration items. For Boomi, these are called process properties.
Within the Boomi platform, APIs are deployed in the Admin console.
Testing is key to any lifecycle, and API management is no different. There are a variety of tools available - likePostman - that allows you to verify connections and functionality of the implementation.
Using stubs here is important. A stub will let you test with limited time invested but still permits you to exercise the connection and communication with the API.
Management and Metrics
One of the strengths of a platform is the built-in tools for management and metrics. With an API management platform, you can manage the runtime, start and stop processes, deploy new revisions, and even monitor services for performance against SLAs and process execution.Platforms also come with built-in dashboards, making it easy to see trends in performance and usage.
There are also audit logs so that you can dig into and surface issues with an API, and resubmission capabilities so that you can re-run failed calls.
This is also where you’ll perform on boarding tasks for new clients to the API, handling access requests, and awarding credentials.
In the Boomi platform, API Metrics are provided in the API Management Dashboard.
5 Reasons NOT to Use API Management
Of course, not everyone needs API management.Perhaps, like the Scrooge of the digital age, you refuse to adopt APIs as part of your business. Maybe stone tablets are working out well for you. Perhaps you’re still struggling with your migration off of Lotus Notes.
All kidding aside, there are legitimate reasons not to need an API management solution. They include:
- You’re only doing basic integration tasks:Your only real need when it comes to integrations is for batch data synchronization or B2B communications with EDI.
- You don’t provide APIs: If you’re only consuming APIs, you really don’t need to worry about lifecycle management.
- You’re better off with event-driven architecture: You’re only doing transaction processing, capturing change data, and so forth. If the capabilities in Salesforce’s event triggers are adequate, you fit in here.
- You already have some API management - and it’s enough: Your current API platform may come with some basic management features, and that could provide everything you need for now.
- You have a very limited set of simple APIs: If you’ve only created a few, simple APIs and don’t have plans for many more, anAPI management tool would be overkill.
Shifting your thinking from single APIs to APIs as part of a product lifecycle can take some getting used to. If you have questions about how to mature your thinking, let us know. Big Compass is always ready to help advance a company’s understanding of the right solutions for you while on your modernization journey.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
+ Security violation
+ Policy enforcement
+ Time since the last version was published
+ Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents