Conceptual curve

A new front for SOA: Open API and API management as a game changer – Part I

Kai Wähner
curve

A deep dive into the concepts of Open API and the obstacles and opportunities it presents.

Open API represents the leading edge of a new business model,
providing innovative ways for companies to expand brand value and
routes to market, and create new value chains for intellectual
property.

In the past, SOA strategies mostly targeted internal users. Open
API targets mostly external partners. So, API management requires
developer portals, key management, and metering / billing
facilities that SOA management never provided.

This article introduces the concepts of Open API, its challenges
and opportunities. API Management will become important in many
areas, no matter if business-to-business (B2B) or
business–to–customer (B2C) communication. Several real world use
cases will discuss how to gain leverage due to API Management.

The second part of the article discusses the components and
architecture of API Management solutions and compares different API
management products, and how these products complement other
middleware software.

The Open API Business Model

Service-oriented architecture (SOA) is already established
within most enterprises. It is commodity. As discussed by Anne
Thomas Mannes as long ago as 2009, the next software evolution can
be built on top of SOA – see “SOA
is Dead; Long Live Services
” for more details.

Welcome to the Open API Business Model, which finally represents
this evolution, building on top of SOA and services. The modern
buzzword for this topic is “Open API”. Analysts and software
vendors classify the product around Open API as “API
Management”.

What is Open API?

Let’s take a look at the definition of Open API from Wikipedia:
“Open API is a word used to describe sets of technologies that
enable websites to interact with each other by using REST, SOAP,
JavaScript and other web technologies. While its possibilities
aren’t limited to web-based applications, it’s becoming an
increasing trend in so–called Web 2.0 applications.”

This definition should be endorsed by clarifying that Open API
is also used for automated machine–to–machine (M2M) communication
more and more. It is not just used for communicating with web
browsers and mobile apps.

Drivers for Open API

The introduction of Open API establishes several benefits:

  • Enable New Business Models: Increase revenue
    from existing services through partner ecosystems, and extend
    presence to social and mobile platforms serving digital
    customers.
  • Deliver High Performance: Accelerate edge
    services performance through load balancing, caching, and a high-
    performance event- driven architecture.
  • Secure Internal Services for External
    Exposure:
    Standardize authentication and authorization
    across the enterprise and through to partners, and protect services
    from attack through security policies, message verification, and
    adaptive throttling.
  • Map Business Agreements to Enforceable
    Policies:
    Use throttles to enforce SLAs for service
    consumers, and monetize by metering or charging for systems
    integration.
  • Federate Disparate Enterprise Applications:
    Unify cloud and mobile platforms through service aggregation,
    content -based routing, protocol bridging, mediation, and
    lightweight orchestration.
  • Rapidly On-Board Partners: Create new channels
    with hot deployment of partners, services, and policies.

The benefits generate several opportunities for business.
Without IT, Open API would not be possible. However, Open API
initiatives usually are driven by the line-of-business, not IT (see
figure 1, tibco.com).

Business can increase revenue, reduce costs and improve
efficiency by introducing Open API:

Figure 1: Drivers for Open API

  • Revenue growth: New revenue streams via repurposed intellectual
    property
  • Expand channel partners and customers
  • Extend brand value and market reach
  • Cost reduction / improved efficiency: Reduce costs through
    partner self service
  • Increase supply chain and B2B flexibility
  • Enhance R&D through crowd-sourced innovation

Due to these opportunities, “[many companies want to] expose
APIs directly to third-party development organizations. These
inquiries come from companies across multiple industries, from
entertainment and media to retail, financial services,
telecommunications, and even government (see The Forrester WaveTM: API Management Platforms, Q1
2013
by Eve Maler and Jeffrey s. Hammond, February 5,
2013).

Real world use cases for Open API

Open API is not just a buzzword. Many success stories exist
already. The following shows different use cases where companies
increased their revenue significantly by making their internal APIs
public. These companies monetize with every service call.

PayPal is an international e–commerce business allowing
payments and money transfers to be made through the Internet. It
was acquired by Ebay in 2002, and was used mainly for payment of
Ebay auctions for several years. In the meantime, Paypal is
integrated into thousands other online shops which sell anything
from books on computers to coupons.

The payment process is easy to implement for the online shop,
and also easy to use and secure for the customer. Paypal earns
money with every payment of any online shop.

Paypal offers its payment service through several different APIs
and applications or gadgets on top of it – see the Paypal community
Paypal Forward” for numerous success
stories.

Amazon started as an international electronic commerce company
selling books, DVDs, and other goods. Today, it is the largest
online retailer worldwide. Therefore, Amazon needs thousands of
servers and a good, stable infrastructure. In 2006, Amazon started
renting parts of this infrastructure as cloud service
(infrastructure as a service) via Open API.

Today, Amazon is the worldwide leader in this segment. Revenue
is growing quarter by quarter – just take a look at “The Secret to Amazon’s Success Internal APIs
to understand how Amazon realizes this Open API approach.

Mobile enablement is one of the hottest topics for API
Management as most companies enable their workforce to become more
mobile, and also customers want to use their mobile phone for
communicating with the companies. The easiest way to solve this is
offering an Open API to push the implementation of new mobile
applications using these APIs.

A funny success story for mobile enablement is Domino’s pizza
service, where a hacker found out that he could order pizzas via a
command line API, see “Track Your Domino’s Pizza Order from a
Terminal
” (this is a post from 2008).

Think about yourself and your friends. How many of you guys
order a pizza or a taxi via mobile apps on your smartphone, today?
In a few years, you will use Google Glass or the panel on your
refrigerator to do these things.

These use cases make internal interfaces public as “Open API” to
be used by consumers. Besides, many other “enterprise scenarios”
exist where API Management makes a lot of sense, for example:

  • Partner Gateway: Access control for well known external
    parties
  • Mobile App Gateway: Access control for apps deployed
    externally
  • Cloud Integration Gateway: Governance and mediation control for
    SaaS
  • Internal Governance – Manage internal SOA

Technical Overview of Open API

The drivers for Open API were explained in the last section. The
most important thing is to be aware of these opportunities. The
upcoming section discusses the technical concepts of Open API and
its corresponding API Management products.

The section takes a look at the basic lifecycle, different
components, technical architecture and relevant roles for
implementing the Open API concept in your enterprise.

Open API Lifecycle

The lifecycle of Open API is illustrated in figure 2, (tibco.com). It can be described in four
steps:

  1. API Providers enable access to their data or business
    functionality using public APIs
  2. API Consumers (e.g. external developers) embed the API
    functionality in their applications
  3. API usage is monetized with a “pay for use” model
  4. Focus is on leveraging existing services in new ways.

Figure 2: Lifecycle of Open API

Components of an Open API Solution

Before API consumers can use APIs, different work has to be done
by the API provider. Offering an Open API solution involves the
following steps:

  1. Create a API engine on premise (in your datacenter or DMZ) or
    use a (private or public) cloud solution
  2. Open enterprise services as APIs
  3. Make it easy for others to use the APIs
  4. Act on feedback to improve your offering (e.g. regarding SLAs,
    customer satisfaction) and to increase revenue

To realize this solution, you need three components: API
Gateway, API Portal Platform and API Analytics. These components
are described in the following.

API Gateway

The API Gateway is a centralized access point for managing
enterprise APIs, providing mediation between internal and external
services, systems, and devices.

You create policies to secure and control services with these
capabilities to ensure performance and availability at web scale
through security and access control, event based runtime policy
management, and federated web scale performance

API Portal Platform

API Providers and API Consumers use an API Portal Platform. It
is a complete software environment for building, deploying, and
managing a customized developer portal for API exchange.

API providers use the portal for API portfolio and lifecycle
management, product creation and pricing, partner management, and
monetization.

API consumers use the portal to browse the product catalog (i.e.
combination of APIs for different prices / usage quotas), explore
and test APIs, and subscribe to services.

API Analytics

API Analytics is an integrated analytics server, which offers
reporting and monitoring capabilities, including:

  • Reporting dashboard (out-of-the-box or customized reports)
  • Monitor KPI’s & SLA compliance
  • Drill-down into specific user behavior
  • Understand API usage patterns
  • Full execution auditing and debugging
  • Isolate problems through data discovery
  • Trend analysis to identify future capacity needs
  • Look for opportunities to grow the API ecosystem
  • Architecture of an API Management Solution

After describing the different components needed to build an
Open API solution, let’s take a look at the basic deployment
architecture (see Figure 3, tibco.com).

Figure 3: Architecture of an API Management
Solution

Several challenges have to be solved. The three major
architectural challenges for API Management are scalability and
policy- based service delivery. Though, let’s first discuss how API
Management fits into enterprise architecture at all.

API Management in an Enterprise Architecture

The first question is how API Management fits into the existing
enterprise architecture. The short answer: It is a perfect
complementary add-on. It can be placed between existing services
and API consumers. Usually, it is deployed on premise in the DMZ of
the enterprise, or deployed as cloud service.

The architecture behind the DMZ does not have to change.
Existing infrastructure for realizing integration (ESB), business
processes (BPM), event processing (CEP), enterprise software (ERP,
CRM), etc. can still be leveraged as before. It “just” gets a new
gateway for publishment and monetization.


The second part of the article
looks how different API
management products
 complement other middleware
software.

Author
Comments
comments powered by Disqus