A new front for SOA: Open API and API management as a game changer – Part I
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?
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:
- API Providers enable access to their data or business functionality using public APIs
- API Consumers (e.g. external developers) embed the API functionality in their applications
- API usage is monetized with a “pay for use” model
- 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:
- Create a API engine on premise (in your datacenter or DMZ) or use a (private or public) cloud solution
- Open enterprise services as APIs
- Make it easy for others to use the APIs
- 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.
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 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.