IBM Cloud

White Paper

Why your business needs APIs

And why your APIs need IBM API Connect
2 Why your business needs APIs
Contents
2 Executive summary
2 Becoming an industry disrupter
3 What is a business API?
4 Using APIs in today’s business environment
5 Common business drivers for API initiatives
6 Exploring other drivers of API initiatives
7 What does a basic API management solution provide?
8 Identifying an optimal API management solution
9 Why IBM for your API business initiatives?
11 Where does API Connect fit in the enterprise architecture?
14 Getting started in the API economy
15 Final thoughts and recommendations
Executive summary
Industry boundaries are being disrupted as new entrants move
into marketplaces outside their traditional categories. The API
economy is fueling some of this disruption—and while it is still in
its early stages, its growth rate is increasing quickly. Many
companies have started their API journey, and many more are
ready to begin that journey as they try to become more agile,
obtain new customers and fend off these competitive threats.
Some businesses start API initiatives because they want to speed
to market and expand their reach to gain new customers. Others
are motivated by government and industry standards that require
APIs, or competitive threats. Regardless, APIs are coming to your
industry, and you need to be prepared.
Business and IT leaders, IT enterprise architects, API developers
and line-of-business consumers all want to understand the bigger
picture around APIs and the API economy. This white paper will
present examples of companies already executing API initiatives
and examine several important questions about APIs, including:
• What is a business API?
• Why do APIs need to be managed?
• What is truly required to obtain the promises of the
API economy?
To answer these questions, we take a detailed look at IBM
API Connect™ and its differentiators, as well as discuss how
IBM can help organizations make their API initiatives successful.
Read on for a demonstration of how APIs can work in the
context of your existing environment. Plus, get an architectural
perspective showing how you can use APIs and API Connect to
map consumers of your business assets to the systems of record
(SOR) that provide those assets.
Becoming an industry disrupter
Many industries are seeing new disrupters enter their markets.
Companies such as Apple and Starbucks, for example, now
provide payment options for consumer orders with Apple Pay and
the Starbucks App, respectively. Uber is disrupting traditional taxi
transportation, and e-insurance companies are springing up
without physical locations to introduce new insurance offerings
into existing markets. OpenTable has become a common
mechanism for booking restaurant reservations, one that extends
into payment for the meal and dining experience. Travel, retail
and other comparison apps can now appear and quickly become
prevalent in any industry. Born-in-the-cloud companies are
popping up with little notice and disrupting a variety of industries.

For companies that want to become the disrupter instead of being
disrupted by competitors, the need for speed and agility has never
been greater. Organizations must sharpen their focus on their
digital customers and expand their outlook beyond ordinary,
traditional offerings. They also need to view issues from the
perspective of their competitors and try to determine how to
move forward with new innovations and creative offerings to
increase their market. This disruption is being fueled by the use of
business APIs, and the new markets it creates are often referred to
as the API economy.
What is a business API?
Application programming interface is a very
old term that has been used to describe
technical interfaces for software programs in
which one program calls another through its
API. Often, these APIs were extremely
complicated and not really meant for wide consumption. A few
other software programs inside the enterprise might use the API
to invoke the program, and a partner outside the company might
use it as well—but with great difficulty.
This long-standing definition is not what’s getting businesses
excited about an API economy. The excitement is instead around
what is referred to as a business API or web API—although
sometimes the additional qualifier is left off. These business or
web APIs offer easy-to-understand interfaces for a recognizable
business asset—for example, a customer record, an account, a
product catalog, a price, an order and so on.
IBM Cloud 3
But I already have APIs!
Every company already has APIs. Your business is built by
accessing your core business assets, so you have APIs that
allow some audiences inside or outside your company to
access those assets. In the emerging API economy, it’s not
just about having APIs; it’s about self-service consumption,
security, analytics and speed to market.
These key considerations are driving the new focus on APIs.
How quickly can your business create a new, secure API that
is easily consumed without assistance and provides
business-level analytics about its use? If the answer can be
measured in minutes or hours, then you’re competitive. If
not, you’re likely to fall behind your competition. (See the
LinkedIn blog post, “I Already Have Partners Accessing My
Services. Why Should I Use APIs?” for an in-depth
discussion on this topic.)
A business API is a public persona for an enterprise that exposes
defined assets, data or services for consumption by a selected
audience of developers—either inside or outside your
organization. Business APIs are easy for application developers
to use, access, understand and invoke. And because a business
API extends an enterprise and opens new markets, application
developers can easily leverage, publicize and aggregate a
company’s assets for broad-based consumption.
4 Why your business needs APIs

Using APIs in today’s business Services Directive 2 (PSD2) that require banks in the region to
environment provide access to account information through trusted third
Companies in every industry worldwide are evaluating, parties. Visit the IBM PSD2 website for additional information
implementing and deploying business API solutions. (See the on these standards.
API Connect resources page to access examples of companies
using APIs.) Here are a few examples of companies that are using In the US, the federal government’s General Services
business APIs: Administration (GSA) released a set of API standards to help
drive open data initiatives with consistency around qualities of
•  arbip helps drivers and travelers throughout France
C service while promoting innovation. The standards are managed
coordinate car-sharing and carpooling. by 18F, an office inside the GSA. The purpose of the standards is
•  tarwood Hotels leverages cloud technology and APIs to
S to promote best practices around government APIs; these best
drive an iterative, low-cost and low-risk approach to practices are viewed as a living set of documents that can be
developing and deploying new services for Starwood guests improved over time. The standards are available at GitHub.
and personalizing the guest experience. Healthcare in the US also initiated requirements for the use of
•  almart provides its developers with an API-driven cloud
W APIs by 2018. (See the article, “Life as a Healthcare CIO,” for a
platform to speed time to market. The platform offers brief summary of the CMS Meaningful Use final rule.)
on-demand access to the resources developers need, including
infrastructure, storage, databases and web servers. The The UK government established recommendations for API
Walmart cloud also helps the business scale to meet standards to help drive innovation and an API economy.
unpredictable spikes in demand. In Singapore, the government is putting together a common user
•  es Bank offers the first API banking facility in India for
Y interaction layer using APIs to hide the various back-end agencies
inward remittance, enabling real-time banking from any and complexity encountered when trying to find the correct
enterprise resource planning (ERP) system. agency to meet specific needs. And in Brazil, the government is
also driving the use of APIs for open data initiatives. (See the
In addition, industries and governments are starting to look at list of Brazilian APIs at ProgrammableWeb.com.)
APIs as a standardized approach to cooperate in their domains
and drive new innovation. In the European banking industry, the For more information on industry standards and government
European Commission defined new standards called Payment regulations, see the IBM API Connect blog post, “API Industry
Standards and Regulatory Requirements.”

Common business drivers for
API initiatives
Companies that are executing successful API initiatives focus
on one or more of four key drivers: speed, reach, the Internet
of Things (IoT) and domains.
Speed (also known as two-speed IT, bimodal IT
or multispeed IT)
The speed driver focuses on allowing the
business and IT organization to run at
different speeds. Traditional IT management
of core SOR can be changed at a certain rate.
Trying to force rapid changes into core
systems in the enterprise can result in outages or security
exposures. Yet the business needs to react very quickly to new
opportunities and competitive threats. It needs a higher rate of
change than can be delivered by the controlled changes
required to the SOR. Using APIs, you can prepackage core
system assets for consumption by the business to create new
and innovative systems of engagement. This driver often tends
to be the first one that drives API use in the enterprise.
Reach
To reach new markets and obtain new
customers, you can make APIs available to
other enterprises, such as partners who,
through their interaction with clients, can
generate additional revenue and new
customers for your enterprise. For example, a clothing retailer
might partner with a travel company to provide destination-
appropriate attire as part of trip planning.
IBM Cloud 5
Internet of Things or devices
In many industries, devices are used in
conjunction with APIs to provide new and
innovative solutions. This approach tends to
happen in one of three ways:
•  device sends data through an API call, such as a shopping
A
cart that identifies items placed in the cart for either rapid
checkout or product cross-selling identification.
• A device is sent a command or data through an API call, such
as sending a targeted advertisement to a shopping cart screen.
• A device sends data through a non-API call using other
technology such as Message Queuing Telemetry Transport
(MQTT)—a high-volume messaging protocol and transport
for telemetry devices—because not all data calls require an
action. However, APIs can access the data inside the enterprise
and look for or react to particular situations or events. For
example, data from shopping carts can be transmitted to the
enterprise to be analyzed. Resulting data patterns can be used
to help determine common traffic patterns through the store,
shopper duration in particular locations and products
ultimately purchased, which can help identify marketing
opportunities or optimized product placement.
APIs are not generally used to provide a constant flow of
information that does not require any real-time action and is
only being used later for analytics purposes. However, an API
might be used to drive a business process or other action
based on insights gained from the analytics. APIs are a good
choice when you desire a real-time action on the part of the
device—making the device do something—or a real-time
action needs to be taken in the enterprise based on
information captured and sent through calls from the device.
6 Why your business needs APIs
Domains
Typically, domains refer to interactions across
multiple lines of business. Lines of business
can largely work independently, but benefit by
sharing data or the occasional need to share
data. APIs enable the data to be shared in a
controlled, secured manner. This approach allows a line of
business to provide access to selected data within its domain,
as required, to other lines of business. It also helps ensure
the security and capacity controls are in place such that the
other lines of business are supported without impacting their
core workloads.
Domains can also be physical locations. Companies that have
multiple locations, which may include cloud and on-premises
data centers, sometimes use APIs as a method to secure and
control the flow of data among locations. Considerations for
regulatory and compliance constraints based on geographical
and country specifications become evident and can be
facilitated through APIs.
Businesses often tend to start with a focus on the requirement
for speed. After initial success in this area, they address the
other drivers. It is not uncommon for businesses to benefit
from APIs across all four drivers.
Exploring other drivers of API initiatives
IT organizations are recognizing benefits from API initiatives
in addition to the main business drivers, including:
• Security and audit: These APIs provide a common point
of access to assets, becoming an easier way to secure access
for only the intended audience and audit the access of
those assets.
• Asset inventory and self-service managed consumption:
An API solution provides a single repository to inventory
and manage assets that are both internally and externally
accessible. Plus, it helps drive the ability for authorized
consumers to access these assets without assistance from the
central IT organization.
• Microservice architecture: Many companies are moving to
a microservice architectural style for their application
architecture and creating new business logic. APIs are a
natural extension to the microservices providing the security
and access controls, as well as promoting and managing
consumption of the microservices.
In addition, many IT organizations are acting in anticipation of
the business requirements because they recognize that the
business request is coming.

What does a basic API management
solution provide?
APIs expose business assets for consumption by a target
audience: developers. The developers—who may be inside
your company, in a partner company or in the public domain—
use these assets in the new capability they are building.
When exposing a business asset, a set of requirements exists to
manage and secure APIs that businesses want in place:
• Security: This requirement helps ensure only authorized
developers who are targeted to use the API access it. In
addition, API access to core business assets needs to expose
only the appropriate assets through the API, and as
necessary to make sure consumers using the applications
built with the API have access to only appropriate
information or transactions.
• Self-service: This requirement allows the intended
developer audience to sign up and use the API with minimal
effort. It should not be necessary to hand-hold the on-
boarding of each developer wanting to use the API.
• Lifecycle and version management: Prior to being made
available, an API is constructed and taken through a lifecycle
for testing. As changes are required, new versions can be made
available, and consumers can either be automatically moved to
the new version when possible or notified that they need to
move to the new version within a specified time period.
• Consumption management: Companies can establish
policies to allow a controlled number of calls of the API.
This requirement protects the core business asset and IT
systems from being overwhelmed with requests. It also can
be used to ensure appropriate controls for individual usage
and for monetization of the business asset.
IBM Cloud 7
• Analytics: The enterprise needs to understand who is using
the asset and how much it is being used. This requirement
is valuable to make sure appropriate resources are in place
and to ensure the API initiative is successful. The analytics
data and dashboard tells the enterprise what is working and
what isn’t.
For many years, IBM and other companies have offered API
management solutions to help guide organizations along their
journey in the API economy. At a high level, the solutions
provide the following capabilities:
• An API composer to access the SOR resources, perhaps
using existing service-oriented architecture (SOA) services
and an enterprise service bus (ESB) to compose APIs
• A lifecycle for testing
• Policies for security and consumption levels associated with
the APIs
• A self-service developer portal to make APIs available
to developers either inside or outside the company, and
where developers can register to use the APIs
• A gateway through which secured and managed developed
apps call the APIs; some transformation of messages and
routing may occur in the API—however, more robust
transformation or routing needs are typically handled in the
SOR environment, often by the ESB
• Analytics about API usage, which are gathered and displayed
through role-appropriate dashboards
8 Why your business needs APIs

a simple string of back-end service calls and minor

Analyst perspectives
The API management space has been moving very quickly;
vendors are delivering products at a rapid pace with new
features and functions to improve their offerings. In 2016,
several analysts issued updated reports showing IBM
as a leader in their respective API management solution
evaluations. For additional information and to access the
reports, read the blog, “Analysts cite IBM API Connect
as a leader.”
transformations of data. In these scenarios, traditional API
management solutions can handle the challenge (Figure 1).
But what if more is needed to create the API—such as more
complicated transformations or more complicated integration
patterns? What if business logic is needed in addition to the
core services? Or, what if no core service exists that can deliver
what is needed, and this service has to be built? The answers to
all of these questions require development efforts beyond the
basic API composition previously supported.

Traditionally, this development would occur in the SOR

Identifying an optimal API
environment—the steady-state speed—which will not allow
management solution you to meet the goal of rapidly introducing new business
Has API management solved the problem? Is managing APIs
capabilities. In all likelihood, you can build some basic APIs in
enabling multispeed IT? The answer to both questions is
the traditional manner, but you must also create and run new
“partially.” The capabilities traditionally provided in API
APIs and microservices to support new business initiatives.
management offerings are necessary but not sufficient. One of
the primary business goals for API management is to allow the
business to execute at very rapid speed, while the core
enterprise executes at a more controlled, steady-state speed. A
complete, deployed API enables this goal to be realized. You
can make the completed API available to the app developer and Secure Manage
then manage and secure the API to allow the lines of business
to execute quickly while maintaining controls to protect the
core environment.

So how do you get to the complete, deployed API? In some

cases, a core system provides exactly what is needed to Figure 1. Basic API management solutions provide only part of the
complete the composition of an API. Other cases require capabilities needed to create a complete, deployed API.

Create Run
Secure Manage
Figure 2. API Connect offers comprehensive management capabilities for
APIs and microservices.
Recognizing this need, IBM introduced API Connect. It
provides a simple and comprehensive set of capabilities to
create, run, manage and secure APIs and microservices—all in
a single offering (Figure 2).
What does IBM API Connect do?
In addition to enhancing the manage-and-secure functionality,
API Connect has significant capabilities to create and run APIs,
providing a comprehensive solution through the entire
lifecycle. The solution includes automated, visual and coding
options to create business logic—microservices—to access,
transform and connect to back-end system resources at the
speed of business. If there is no core system service—for
IBM Cloud 9
example, to access a database without a service interface—you
can automatically generate APIs based on the database schema
and several other model-based assets.
API Connect provides a managed, scalable runtime environment
to deploy these microservices; it currently supports Node.js and
Java runtimes. Because this managed runtime is part of API
Connect, developers can execute new business logic in a
controlled manner. And they can do so without the lengthy
development and deployment cycles required to update the
SOR, thereby supporting the multispeed IT approach necessary
to succeed in the API economy.
Why IBM for your API business initiatives?
The IBM approach to API initiatives is not based solely on
product functionality. Companies today have made huge
investments in on-premises infrastructure but also are building
and executing strategies to move to the cloud. For the
foreseeable future, companies will manage IT investments in
on-premises infrastructure and for one or more cloud providers.
API Connect reinforces this hybrid cloud architecture by
supporting the same API Connect function in both cloud and
on-premises solutions. You can deploy components of API
Connect to IBM-provided cloud options—the IBM®
Bluemix® platform and public, dedicated or local clouds—as
well as select non-IBM cloud providers. By supporting the
same solution in all possible locations, IBM gives companies
the confidence and consistency to create and deploy APIs in
one location and then move them to another location as
needs and requirements change.
10 Why your business needs APIs
IBM supplies two options for the API gateway component
that is the key runtime component to secure and execute the
APIs that are created. These options are IBM DataPower®
Gateway and Micro Gateway. DataPower Gateway has been
in the market for more than 15 years with thousands of
deployments and is recognized for its significant strengths in
security, performance and scalability. It is a single, multichannel
gateway that helps provide security, control, integration and
optimized access to a full range of API, B2B, cloud-based,
mobile, SOA and web workloads. It also enables you to rapidly
expand valuable IT assets to new channels, giving customers,
employees and partners access to critical resources.
With such a powerful gateway already in many client
environments, deciding to build the API Connect solution on
DataPower Gateway was an easy choice. Clients who already
own DataPower Gateway can continue using their existing
infrastructure, assuming there is sufficient capacity available
for the additional API workload. Companies that do not
already own DataPower Gateway can easily add it to their
architecture as a physical appliance or a virtual appliance, or
they can execute it on Linux or deploy it in Docker
containers. For IBM-managed cloud solutions, IBM
administers DataPower Gateway instances for the client.
Micro Gateway is also supplied as a software-based option for
the API gateway. Built on Node.js, it enforces the
authentication, authorization and flow requirements of an
API. Micro Gateway has a limited number of policies
compared with DataPower Gateway, so you might choose
Micro Gateway for testing, internal deployments, or smaller-
scale and security requirements.
IBM brings an end-to-end solution perspective to API initiatives.
An API is not by itself a complete solution. APIs are consumed
by something—for example, a mobile app or a partner
application—and APIs need to connect this consumer with a
back-end SOR or other resources that provide the necessary
information and transactions to be executed. IBM has been
helping clients build these consuming and provider systems for
decades and understands that the solution must consider all the
components and not just focus on the API as a stand-alone entity.
While your API consumers may or may not all be within the
same company, taking this end-to-end perspective in
developing your APIs and running your API initiative so the
correct components, security and controls are in place is
important. Also vital is ensuring that parts of the solution are
being used in the most optimal manner. Some vendors offer
API-only solutions and have no experience beyond the API.
Others may be SOA or ESB vendors that are extending their
existing products to execute APIs. This architecture can be
suboptimal, leading to performance and security exposures
and poor governance over crucial SORs in the enterprise.
APIs play a key role in IBM strategies
APIs are a critical and highly strategic technology for IBM.
IBM Watson®, a core part of the IBM cognitive strategy, is
accessed through APIs. The Bluemix cloud-based,
platform-as-a-service (PaaS) offering includes API Connect,
and many Bluemix functions are APIs. The IBM CIO’s office
is also using API Connect for both internal and partnering
projects. Check out the IBM API Explorer portal containing
Watson, The Weather Company® and many other APIs at
https://developer.ibm.com/api
 IBM Cloud 11

Where does API Connect fit in the
enterprise architecture?
API Connect features both enterprise-focused and developer-
focused capabilities. Everything is provided to create, run,
manage and secure the APIs and microservices as well as connect
them to the SOR. API Connect is also designed as a
comprehensive solution for developers to access the API
portfolio, register and consume the APIs, and visualize analytics
about their usage of the APIs selected. API Connect contains the
following components that work together to provide an end-to-
end API management solution (Figure 3):
• Developer Portal (1): This portal allows target developer
communities to see the APIs available to them and offers
everything necessary for self-service API consumption by
the developers. Social aspects such as blogs, FAQs and
other capabilities can be used to help developers and
drive API usage.
• API Manager (2): As the core server component for API
Connect, the API Manager provides all the lifecycle
management and design and development aspects for
creating and managing APIs. It also has analytics views
based on roles.

Developer
2 API Manager 4 Toolkit
Developer
External app Partner app 1
developer developer Portal

Container
5 Data store
Internal app manager
developer

Cloud service
Microservices Microservices
Mobile and Business traffic
web apps Partner apps 6 compute runtime
(Node.js/Java)
Application server
API gateway
3 (DataPower/
Micro Gateway)
API traffic
ESB/middleware
Enterprise IoT
internal apps

IBM z Systems®/
legacy apps

Figure 3. The end-to-end API Connect topology consists of several interacting components that enable access to APIs, supporting the full create, run,
manage and secure API lifecycle.
12 Why your business needs APIs
• API gateway (3): This component—either DataPower
Gateway or Micro Gateway—serves as the runtime gateway.
• Developer Toolkit (4): A downloadable component that
enables API developers—not consumers—to work offline,
the toolkit can be used to develop and test APIs and
microservices. Once complete, developers can transfer the
API and microservices to the API Manager to complete the
lifecycle and deployment.
• Container manager (5): This component provides unified
operations and management for the microservices compute
runtime. You can use the IBM-provided Bluemix container
service or another container manager of your choice, such as
Docker Swarm, Kubernetes, Apache Mesos or others.
• Microservices compute runtime (6): This runtime
executes API and microservices business logic written in
Node.js or Java.
Here is a step-by-step scenario that outlines how the
components are used and how they interact:
1. An API developer uses the Developer Toolkit (4) to develop an
API on their laptop while offline. The developer can test
the API using a local Micro Gateway that is part of the
toolkit, if desired.
2. When ready, the API developer connects to API Manager (2)
and uses it to continue working on the API by adding
policies, completing testing and taking the API through its
lifecycle until it’s ready to be consumed by others.
3. When ready, the API is deployed from API Manager (2) to
the Developer Portal (1) and the API gateway (3). The API is
now ready to be used.
4. The appropriate target consumer audience logs on to the
Developer Portal (1). This consumer can be an internal
developer, a partner or an external developer who finds the
API and chooses to use it to build an application.
5. The applications invoke the API when necessary, which
flows it to the API gateway (3), where appropriate security
and other runtime policies are enforced.
6. For APIs that do not require any new or changed business
logic or other microservices, the API traffic flows from the
API gateway (3) directly to the back-end SOR, ESB or cloud
applications; retrieves the necessary information; and returns
through the gateway to the invoking application.
7. If the solution requires new business logic or microservices,
then the same Developer Toolkit (4) and API Manager (2)
are used as with APIs. However, when it is time to deploy the
microservices, the container manager (5) is used to deploy
them into the microservices compute runtime (6).
8. During the app’s runtime, it calls the API in the API gateway
(3) as before. However, the gateway recognizes that this
invocation requires microservices and calls the necessary
microservices in the microservices compute runtime (6).
In turn, it can invoke the SOR, ESB or cloud applications
and retrieve the necessary information. The data is then
returned to the microservices compute runtime (6), where
additional business logic can be executed before responding
through the API gateway (3) back to the calling application.
Note that it is also possible to invoke business logic prior
to calling the back-end systems.
API Connect works with both IBM and non-IBM products
and technologies as consumers of APIs and the resources that
the API connects to in the SOR. However, if you want to use
additional IBM solutions for these purposes, IBM has pre-built
connections to ease the integration.
 IBM Cloud 13

Services
on CICS
Cloud Web z/OS
Connect
Mobile IoT IBM API Connect Services
Systems of Management on IMS
engagement +
runtime gateway
enforcement Systems of record
DataPower
Gateway

Developer Portal API analytics

MobileFirst
Platform Foundation
Figure 5. z/OS Connect pushes interfaces directly into API Connect.

Many businesses have their core SOR assets executing on the

mainframe under the IBM z/OS® operating system.
API Connect
Numerous mechanisms are available to connect to the
mainframe including using IBM Integration Bus. A new
capability called z/OS Connect helps simplify connectivity by
Figure 4. Pre-built connections among IBM products ease integration, as creating REST interfaces to existing IBM Customer
in this example of integration between API Connect, DataPower Gateway Information Control System (IBM CICS®) servers and IBM
and MobileFirst Platform Foundation.
IMS™ subsystem transactions. z/OS Connect can push these
interfaces directly into API Connect so the business assets are
If a business is using the IBM MobileFirst™ Platform available for use (Figure 5).
Foundation, for example, IBM has integrated DataPower
Gateway as the gateway for the complete solution and can
supply APIs from API Connect to the MobileFirst Platform “The business of APIs: Best practices” white paper provides
Foundation (Figure 4). additional information on organizational structure and
several other important topics. Download it here.
IBM Integration Bus—the IBM ESB—also has eased integration
with API Connect. IBM Integration Bus V10.0.0.2 and higher
has the capability to push REST interfaces created within it
directly into API Connect. API Connect can then use these
resources (possibly combined with other resources) to create an
API to be published for consumption.
14 Why your business needs APIs

Getting started in the API economy
API initiatives are best done iteratively using an agile-like
methodology. Don’t wait for perfection or for all answers to
be known; API initiatives are about speed and need aggressive
change agents as leaders. In the early stages, focus on a few key
items to ensure success and maximum value:
• Obtain executive and business backing. APIs are a product
to be delivered by your business, not a technology for IT to
improve efficiency. Lack of executive or business buy-in can
result in a technology implementation with little or no impact
on the business. The leadership absolutely needs to
participate. Emphasize the importance of backing the
initiative by sharing the “Evolution of the API Economy” study
from the IBM Institute for Business Value with executives.
• Establish a strategy and goals. Understand why you are
executing an API initiative, and set goals for the initiative
that involve time frames and reporting metrics.
• Make a commitment to roles, responsibilities and
resources. Resources that are dedicated to the API initiative
help you make governance effective.
• Get the message out. Become an API evangelist. The
core team’s role or roles must be understood and propagated.
Involve people skilled in formal communication and
education campaigns. Also, collect and publish metrics.
IBM is ready to assist you with a full range of workshops and
services offerings (Figure 6). For more information about the
workshops, visit the Digital Transformation Workshops and
Service Engagements sign-up page.

Enabling your API economy journey

Digital
Enable and transformation Managed
Quick-win integrate • Applications services
pilots • Lines of • Agile • As a service
• Running business • Return on • Service-level
Boot camp agreement
• Measure • Go live investment
• API Connect
• Validate • Secure • Production
deep dive
Discovery • Best practices
workshop • Architectures
• Scenarios • Platforms

i Quick start
• API Connect
• Capabilities
• Patterns
• Next steps
Quick-win pilots
• Testing
deep dive Quick starts
• Monitor
• Hands-on • API Connect
• DevOps
Briefing • Features • MobileFirst
• Economy • Skills • Bluemix
• Value • Integrated bus
• IBM • IBM WebSphere® Liberty

Figure 6. IBM workshops and quick-start services can help you move quickly along the path to full participation in the API economy.
 IBM Cloud 15

Final thoughts and recommendations About the author

The API economy is underway. Built on the idea of speed, it
will quickly expand. If your organization has not started
strategizing and planning for business APIs, the time is now.
Do not wait until you know all the answers and have
everything in place. Plan stages for the rollout and build on
what you learn. If you have already begun your API initiative,
look to capitalize on your successes and quickly identify false
starts. Also, explore other drivers and use cases to obtain
additional value.
As we move into the API economy, huge opportunities for
new and innovative solutions await. IBM brings significant
API economy knowledge, products and strategies, and would
like to be your partner on your API journey. Let us share our
expertise and experiences to help maximize the value of APIs
for your enterprise.
To understand more about the IBM approach to the API
economy, visit the IBM API economy website. Learn more
about API Connect at the API Connect website, or download a
trial version of API Connect.
Alan Glickenhouse, API Business
Strategist, IBM
Alan Glickenhouse is a business
strategist on the IBM API Connect
offering management team. He
joined IBM in 1981 and has held
numerous positions in sales,
technical sales, marketing,
development and technical support.
On the API Connect team, Alan assists clients in all industries
with their business strategy for APIs, understanding their
business direction and existing environment (both business and
technical), and helps businesses successfully adopt an API
strategy that fits their environment. Alan has an AB from
Vassar College in Computer Mathematics and has several
SOA certifications. Contact him at glick@us.ibm.com or
follow @ARGlick.
© Copyright IBM Corporation 2017

IBM Cloud
Route 100
Somers, NY 10589

Produced in the United States of America

March 2017

IBM, the IBM logo, ibm.com, Bluemix, CICS, DataPower, IBM API
Connect, IBM Watson, IBM zSystems, IMS, MobileFirst, WebSphere, and
z/OS are trademarks of International Business Machines Corp., registered
in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks
is available on the web at “Copyright and trademark information” at
ibm.com/legal/copytrade.shtml

The Weather Company is a trademark or registered trademark of TWC

Product and Technology, LLC, an IBM Company.

Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.

Linux is a registered trademark of Linus Torvalds in the United States,

other countries, or both.

This document is current as of the initial date of publication and may be

changed by IBM at any time. Not all offerings are available in every country
in which IBM operates.

The performance data and client examples cited are presented for
illustrative purposes only. Actual performance results may vary depending
on specific configurations and operating conditions. THE INFORMATION
IN THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT ANY
WARRANTY, EXPRESS OR IMPLIED, INCLUDING WITHOUT
ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION
OF NONINFRINGEMENT. IBM products are warranted according to
the terms and conditions of the agreements under which they are provided.

The client is responsible for ensuring compliance with laws and regulations
applicable to it. IBM does not provide legal advice or represent or warrant
that its services or products will ensure that the client is in compliance with
any law or regulation.

Please Recycle

APW12365-USEN-01