This content is part of the Essential Guide: Enterprise architect's guide to API best practices and trends
Manage Learn to apply best practices and optimize your operations.

SOA architecture: Why you need API management

While some of the hype around SOA architecture may have died down, the importance of API management remains.

Why do I need API management? What are the benefits of it?

Todd BiskeTodd Biske

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.

Follow us on Twitter at @SearchSOA and like us on Facebook.

Next Steps

Should you choose JSON for building APIs?

Dig Deeper on Distributed application architecture

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you agree that management features don't sell products?
In API Management, it is management features like root-cause analysis, quota management, and analytics which provide great value and do indeed "sell products"
While they don't make the sale, they are a "strong" criteria to support rich/robust features that meet the problem space. Two comparable products feature wise, with one that has a "console" based administration mechanism, is going to win the beauty contest every time.
It's benefits like greater customer intimacy that sell products.
API management infrastructure extends traditional SOA infrastructure with self-service subscription, key management, developer portals, and analytics
API management infrastructure features are self-service subscription, key management, usage tracking, rate-limiting / throttling, billing, developer portals, and analytics. useful features that do encourage buying additional products.
I don't believe Management Features are geared towards the right Audiences.
These most often don't consider the Entire Teams behind a Product and will often only provision for one of the Streams, either Dev, Testing, Support, Business.
When Management Features encompass an E2E, this is when we will be able to build relationships and understanding within an IT House and deliver a product that everyone feels they have Passion, Care and Ownership of.
There several factors. One being the expectations of the targeted users of a product. So, what I'm stating is that the type of product and the expectations of its users could determine a products success. If an instance of a product was mentioned and the primary functions it would serve or serves, then I'd be able to answer whether or not management features are critical to its sales
Good point, LordLionO. Expectations are definitely key! This kind of reminds me of the discussion around using SOA. Some people dislike it because they think it can solve anything, when in fact, it can't be everything to every one.
"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." YES. I couldn't agree more. By broadening out the definition and talking about "interfaces" which exchange data, it embraces SOA, as well as even EDI and file-transfer.

In the early days of SOA, there was a mistaken belief that it was all about RPC calls (a more "firewall-friendly" CORBA). RPC-style SOAP was in fashion. You had products that generated SOAP in front of Java Beans. None of that made sense, and it was too tightly coupled. So, people rightly moved to document-based SOAP, and it became more like "email between applications". The paradigm was not "running a function call" but "sending data". We shouldn't repeat these same mistakes with REST.

- Mark O'Neill - Axway
API is an echo of the SOA perspective.

SOA can be a strategy to align IT assets with business capabilities, business resources, and business processes. SOA’s strong focus on sharing and re-use can optimize IT asset utilization. Most intriguingly, SOA was promised to re-invent business-to-business interactions, enable better partner relationships, and support process networks[1]. External services were seen as a mechanism to extend an enterprise’s economic reach by reducing interaction costs, incorporating external business capabilities, enabling business specialization, and creating higher-value solutions that extend business processes across a partner network.

The current API economy buzz co-opts the SOA business value proposition, injects lessons learns, and rides popular industry trends (i.e. REST, Internet of Everything, mobile, Cloud services).

API governance extends SOA governance best practices. API governance encompasses API subscriptions and API promotion meta-data. Governance activities managing API promotion meta-data include rationalizing keyword tags used to categorize APIs, and developer documentation content management. The governance process should enforce design-time checkpoints before API publication.

Further insight can be found at the cobiacomm Home Port blog

Chris Haddad - WSO2
Mangement is easy. Pragmatic Veteran chiefs -in Double- with Theorist Analysts IT.
Luiz "new engine in old car" Fortes. Father of Fortes Doctrine. Double or Pair, is the same.