by Mark O’Neill
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.
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.
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.
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.
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
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