by Mark O’Neill
The
management and delivery of Enterprise APIs is far more demanding than that of
the consumer API. While consumer-oriented APIs have gained huge popularity as
they are used to expose public services and drive advertising revenues, enterprise
APIs typically transmit sensitive information, have onerous performance demands
and must comply with regulatory frameworks.
Today’s business users demand access to applications and data from multiple devices, inside and outside of an enterprise, on a 24x7x365 basis. This trend means users interact with enterprises through many different interfaces and those interfaces all converge at the Application Program Interface (API) layer.
APIs must be managed so that usage is tracked and security is achieved. However, API management as an IT and business discipline is still in its infancy. Current API management deployments are usually leveraged for social media, media, basic service, and consumer oriented e-commerce APIs. As a result, current API management practice has focused mostly on developer enablement portals, providing self-service options for an open community of developers consuming public-facing APIs.
As API management becomes more popular, organizations are tasked with delivering “enterprise APIs” that transmit sensitive information or execute business transactions. This piece will not only examine different drivers of enterprise API management but will also recommend effective reference architectures that best fit API management use cases.
Enterprise
APIs
Before we examine enterprise APIs, it is
worth noting the differences between consumer and enterprise APIs. Consumer
APIs generally drive traffic to generate advertising and e-commerce revenue, or to deliver a
public service In contrast, enterprise APIs typically transmit sensitive
information or execute business transactions to approved and authenticated
counterparties.
For example, a financial services API may manage personal or corporate banking accounts, a human resources API will usually manage 401k accounts, with a healthcare API managing access to patient healthcare records. Additionally, enterprise APIs are used to transmit information subject to legal or compliance requirements or in the transmission of information with national security or public safety implications. Note, in certain political jurisdictions, such as the European Union, privacy and data regulations also have an impact on the protection of data associated with consumer APIs.
Because enterprise APIs handle sensitive information and business transactions, any inappropriate use could have serious repercussions, including financial loss and loss of compliance. As such, designing an API delivery strategy for enterprise APIs demands a higher level of operational requirements than designing a consumer- focused strategy.
API
Delivery Strategy
A best practice approach for developing an
API delivery strategy is to ensure any solution implemented provides assurance
for confidentiality, integrity and security. The strategy should also include
an evidential audit trail as well as integrating with internal and business
partner systems, and complying with internal policies and compliance mandates. It
should also control and provide evidence of API performance and enforce access
control and on-boarding process requirements.
Source of APIs
An important consideration of an
organization’s API delivery strategy is determining the source and readiness of
an API. Within this context, there are generally three main sources of APIs:
new APIs, existing APIs and partner-provided APIs.
New APIs
Let’s take a look at the simplest scenario:
working with new APIs. Most
consumer APIs tend to be new APIs because the technology is new. These are
newly developed APIs that are compatible with the latest web- and mobile-centric
API design patterns and standards such as Representational State Transfer (REST),
JavaScript Object Notation (JSON), OAuth, and HTML 5.0 WebSockets. However, new
APIs still require operational support such as security and monitoring from the
API delivery platform.
Existing
Services and APIs
Most organizations who have invested in B2B
integration or Service Oriented Architecture (SOA) have an abundance of web
services and APIs that are already in use for internal or external
point-to-point integrations. These services are usually based on standards such
as Simple Object Access Protocol (SOAP), XML, Electronic Data Interchange (EDI)
or Java Message Service (JMS). To become compatible with the new web and mobile
API patterns, these services will require a rewrite or transformation. Because
these services are used for internal or trusted B2B integrations, they will
likely require extensive operational support from an API management platform to
add security, control and monitoring. Furthermore, SOAP-to-REST transformation
may require advanced transformation capabilities.
Service
Provider/Partner APIs
Another scenario is when an enterprise is
delivering an API based substantially on APIs provided by its vendors or
service providers. In this situation, the API management platform may need to
route, aggregate or transform service provider APIs to ensure an optimal
experience for its API consumers. Additionally, the API management platform
will need to decouple inbound APIs from outbound APIs to preserve operational
flexibility and business agility. Within this scenario, it is worth flagging
that sensitive or private information should not be shared with service
providers. Ideally, sensitive or private information should be stripped,
redacted or encrypted before being sent to service provider APIs.
Best Practice: Reference Architecture
Fundamentally, an enterprise’s choice of
API management platform architecture will be driven by three factors: the type
of APIs an enterprise needs to deliver, the readiness of its source APIs and
integration requirements.
An enterprise will need a robust and flexible API management platform that offers a high level of security, integrity and integration capabilities.
There are several incrementally more powerful API management reference architectures to suit an organization’s various needs.
As this piece is focused on enterprise APIs, we’ll closely examine the two-tier API delivery platform which is most suitable for the scalable delivery of enterprise APIs.

Two-Tier API Delivery Platform
A two-tier API delivery platform provides
both a more flexible and scalable solution by separating the portal tier from
an additional API gateway tier. The API gateway tier provides full API
lifecycle support with integration to internal and external systems such as
identity management, partner management and service registry. Additionally, the API gateway tier
provides the runtime engine for API delivery as well as a single set of
infrastructure services to support multiple portals.
Two-Tier API Delivery Platform Considerations
A two-tier architecture can be deployed
locally, in the cloud or in a hybrid model. Depending on the extent of the integrations, many scenarios
will require the API gateway to be situated on-premise. The portals can be
deployed either on-premise or in the cloud, independent of the API gateway
deployment location. While there are strong reasons to deploy partner and
provider portals in the cloud, an internal developer portal is probably best
suited to an on-site deployment.
The two-tier API delivery platform option is better than an all-in-one option if businesses requirements include any of the following: managing enterprise APIs, backend APIs requiring non-trivial transformation and orchestration as well as situations where a standalone identity repository for API management is not acceptable. It is also useful in situations where support is required for existing trusted relationships, security protocols, and certificates as well as non-trivial access federation scenarios. A full list of possible business requirements serviced by the two-tier enterprise API delivery platform option is available here: http://www.vordel.com/solutions/api-gateway-architecture-data.html
It’s all about the API
Economy
A flexible and powerful API management platform that fits business needs can
create differentiation and help enterprises compete in the new “API Economy”.
So in summary, when an organization is considering an API management strategy,
it should firstly understand the type of APIs it needs to deliver and consume. The
organization should then assess the API’s integration requirements to existing
infrastructure, and then decide on the correct reference architecture to match
these requirements. All of the above points to a scenario where organizations
need to start considering a container for APIs where they can control the
administration, monitoring, security and transformation of all traffic to and
from their APIs.
Mark O'Neill is the CTO of Vordel (Newton, MA). www.vordel.com

