API Management isn't SOA

Ed Anuff

Jul 24, 2015

In the previous post in this series, we introduced the basic tenets of API management. Before we dive in and explore each of the different aspects of a complete API management solution, it’s important to understand what API management isn’t.

It’s not integration-based architecture

To think of APIs as a continuation of the integration-based architectures that have long been in use within enterprise IT is a narrow view.

Because modern software is built as services, all development becomes API development. Rather than using web frameworks that invoke services and produce web pages, applications today are built by consuming and producing APIs. Mobile technology and HTML5/JavaScript have accelerated this movement to API development.

The communications mechanism for mobile is APIs. Sometimes, the same mobile developer is charged with building the server-side and client-side interactions. In other cases, such as for companies that needed to support native iOS and Android applications, specialists become responsible for building the client implementations. These specialists are often contractors, digital agencies, or system integrators. That is, they can be external to the company. This drives the requirement for an API to be central to the application development effort.

It’s not monolithic applications

Not only have applications embraced APIs on the front end for connecting to rich clients, they are used on the backend for integrating with internal systems; and on the sides for enabling other applications to access their internal data and processes.

This approach is achieved through micro services architecture (MSA): the concept of exploding an application into a set of component fine-grained services, linked together via APIs. The promise of SOA has become reality in micro services architecture.

The goal of an API tier in the enterprise infrastructure is to enable a large number of apps, from your partner channels or new app development teams, to access content and data from internal systems in a way that:

grants individual users appropriate levels of access control

shapes data to exactly the size and format necessary for ease of app development

validates or processes data with lightweight logic and combines it with or distributes it to multiple sources and services as necessary

enables deep analytics to measure developer productivity and app and API usage growth as well as derive business-level insights by examining the interactions described within the contents of the API traffic

It’s not SOA governance

API governance (API management), separate and distinct from SOA governance, has emerged as a new area of focus. API management concerns itself with providing standardized conventions for documentation and consistent security and access control mechanisms. It exists in support of the application teams rather than the centralized IT resources. It is generally not prescriptive except in a few vital areas, such as defining standards for security mechanisms including OAuth.

All of these distinctions lead to different approaches and decisions for designing, building, securing, deploying, and managing the lifecycle of the data and services a company exposes to developers and partners, both internal and external.

API management isn’t SOA governance. The two are separate and distinct. A centralized services governance process, owned by a special architectural team in IT, simply can’t maintain an iron grip on agile and decentralized API-first architectures.