Enterprise architect's guide to API best practices and trends
A comprehensive collection of articles, videos and more, hand-picked by our editors
Why do I need API management? What are the benefits of it?
The terms have changed, but the need is the same. In the heyday of SOA architecture hype, vendors spoke of products to support SOA governance. Some had repositories, some had gateways, and some had both.
Nowadays, those same vendors (and some new ones) are talking about API management. I'm not concerned with whether this is a rebranding effort, technology evolution or technology innovation. Instead, I think this is representative of a fundamental need that still exists in many organizations, that is, the need for consumer-focused, service-based thinking.
SOA architecture in the enterprise and beyond
Let's face it, corporate IT is a very project-centric culture. Management within IT is primarily focused on two things: getting projects delivered on time and on budget via project managers, and getting people assigned to those projects via people managers.
There is little notion, if any, of product management, and the idea of service management is likely constrained to the IT operations organization. When the system goes into production, support is constrained, not to basic care and feeding but solely to keeping the lights on. Staff moves on to the next project. Applications go untouched for years. System upgrades and updated service integrations are neglected in deference to the delivery of new capabilities. A new capability with potential for revenue gain is going to trump upgrading your underlying application server every time. That's just the tip of the iceberg.
The reality is that projects are more complicated than ever. Want to make a project manager cringe? Just tell him or her there's another team that needs to be involved in the delivery of the solution. On top of that, it's very likely the new team doesn't have a formal engagement model for what they need to do.
Of course, that assumes you were first able to determine who the right team was. If the team is responsible for a Web service, is that service adequately described to allow the developers of the consuming system to use it properly? More often than not, the descriptions we have are from the last project, which are geared to the people building the service, not the people using the service.
Now is the time to start changing the culture and embracing the concepts of service and interface management.
Getting back to the acronym du jour, SOA architecture governance and management was focused on this problem as constrained within the enterprise. Application programming interface management extends this concept beyond the enterprise. I've even seen the term business API start to get used, although business interface is a more accurate term, as we're really not programming the business, we're interacting with it.
Risks of poor API management
Everything in a business has an interface; some are just better documented and better managed than others. Unmanaged interfaces will eventually lead to inconsistency and a poor experience for the people who use them.
The risk to a business with poor interface management will only get greater. I'm not aware of any company stating its projects are getting simpler and involve fewer systems. Instead, we're faced with projects that span multiple channels, user communities, teams and systems from within and outside the company.
Now is the time to start changing the culture and embracing the concepts of service and interface management. Amazon had the right idea -- create an API for everything and drive your interactions to those interfaces. You won't get it right the first time, so make sure your funding mechanisms allow for continued evolution of those interfaces.
One can't manage interfaces only when projects allow. Instead, strive to make everything about those interfaces as easy to use as possible. One key feature API management tooling has embraced that was not prominent in the SOA architecture heyday is that of identity token provisioning. It's one thing to have a fully documented API that allows a consuming system to be coded, but are you going to use a service that has an API for getting identity tokens that allows you to run as fast as you can go, or one that requires your team to wait four weeks for a manual process?
While a vendor once told me, "Management features don't sell products," I'm very glad to see vendors are still plugging away promoting technologies that assist in service and interface management efforts. Increasingly, companies that do this well are going to succeed. One only needs to look at the disruption created by Amazon's cloud computing offerings to know how quickly this change can happen.
About the author
Todd Biske is an enterprise architect with a Fortune 50 company in the St. Louis metro area. He has had architecture experience in many different verticals, including healthcare, financial services, publishing and manufacturing over the course of his 20-year career.
Todd Biske asks:
Do you agree that management features don't sell products?
8 ResponsesJoin the Discussion
Related Q&A from Todd Biske
There isn't a shortage of success and failure stories with any integration method. Here's a look at when REST integration with SOA may be best.continue reading
Messaging middleware has shifted from integration with legacy systems to integration between any two systems.continue reading
XML appliances are only able to enforce policies placed in the request path, reminds enterprise architect Todd Biske, so it's important to ensure ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.