IBM Cloud White Paper

The business of APIs: Best practices

2 The business of APIs: Best practices

Contents Executive summary

Many enterprises are planning their journey and participation
2 Executive summary
in the API economy. Some view this plan as an IT initiative,
3 The business of APIs: Introduction but those who truly understand the potential are attacking it
with a combination of business and IT perspectives. This paper
4 Business strategy
focuses on best practices to drive success using this blend of
7 Domain ownership and organizational structure business and IT.

10 Governance model Determining an API economy strategy and planning a

roadmap have several significant benefits:
11 Monetization

12 API identification • Consolidating and standardizing common APIs—or simply

business services—within an organization
14 Communication
• Lowering cost of operations by having a central repository
15 Legal and privacy and index of enterprise business services such as retrieve
credit score
16 Success criteria and metrics • Accelerating digital projects and improving time to market
17 Technical governance with safe, quick access to business services by both internal
and external parties
18 Closing thoughts and recommendations • Identifying a partnership ecosystem—especially outside your
own industry—to formulate new value-add products and
services to be more competitive
• Defining a new business model for monetization purposes
such as a mobile marketplace; that is, curating your
company’s business capabilities aggregated with your
partners’ business capabilities to provide a diverse range of
related or complementary services
 IBM Cloud 3

In this paper, we share best practices and lessons learned The business of APIs: Introduction
based on interactions between IBM and its clients. The paper Emerging entrants and companies initiating new, market-
focuses on the core nontechnical aspects of executing an API changing offerings are disrupting many industries. Here are
initiative, including: just a few examples:

• Business strategy • Apple Pay is disrupting payment services

• Domain ownership and organizational structure • Smart cars are disrupting the automotive industry
• Governance model • Online commerce enterprises such as Alibaba are investing
• Monetization in the property and casualty insurance industry, disrupting it
• API identification with new service models and offerings
• Communication • Financial technology companies (fintechs) such as
• Legal and privacy Betterment and Bats Chi-X have disrupted the high barrier
• Success criteria and metrics to entering financial markets
• Technical governance • Uber has disrupted transportation
• Netflix has disrupted the media and entertainment industry
For each area, we describe the issues and offer recommendations.
In addition, we provide sample worksheets to help you
organize your approach within that segment of the initiative.

This paper is intended for business and IT leadership

interested in jump-starting their API initiative by learning
about best practices being used by other enterprises. It is not
meant to be introductory, and prior knowledge of the basics of
business APIs and the API economy is expected.
4 The business of APIs: Best practices

APIs give companies a mechanism to become the disrupter, or Additionally, this paper is targeted toward enterprises that see
at a minimum to more rapidly respond when a disrupter enters APIs as a platform strategy, not an individual project.
their market segment. They offer an opportunity to bring Individual project orientation may result in a quick initial
significant value to a business. To capture this value, business project, but will not provide the best practices to drive the
and IT need to work together on the API initiative. This paper repeatability required to move forward at the enterprise level.
is intended to address the less-technical—but no less Many of the most successful businesses using APIs view them
challenging—issues of an API initiative: instead as a corporate channel to market—a strategic asset.

• Business strategy
• Domain ownership and organizational structure Throughout the paper, we include sample worksheets to
• Governance model help you gather and organize your approach to each topic.
• Monetization Some of these worksheets have fields prefilled with
• API identification suggestions. You can use these worksheets to organize the
• Communication initiative with your own data and choose to use or disregard
• Legal and privacy the samples shown.
• Success criteria and metrics
• Technical governance

Often, the early phases of an API initiative are led by IT, which
Business strategy
Why are you planning to create APIs? If you cannot answer
in turn is focused on the technical implementation, architecture
this question at a business level, please stop the initiative
and security implications of adding APIs to the current IT
and regroup.
environment. All of these topics are important but are not
covered in this paper. Visit the IBM® API Connect™ site on
Some IT divisions within organizations begin API implementations
IBM developerWorks® and the IBM API Connect product
without clear-cut business use cases. These initiatives will find
website to learn how IBM can assist you with these
success difficult because there is no defined business goal or
technical aspects.
goals. Those goals may be driven by revenue, new routes to
market, new value-add products and services, efficiencies, time
to market or other elements, but they must be outlined at the
start so all decisions and actions can progress toward the goal.
 IBM Cloud 5

Companies that are executing successful API initiatives focus • Internet of Things (IoT) or devices: In many industries,
on one or more of these four key business drivers: devices are used in conjunction with APIs to provide new
and innovative solutions. This tends to happen in one of
• Speed (also known as two-speed IT, bimodal IT or three ways:
multispeed IT): Typically the first driver of API use in an 1. A device sends data through an API call, such as a
enterprise, this element is focused on allowing business and connected car sending data on driving patterns to an
IT organizations to run at different speeds. Traditional IT insurance company.
management of core systems of record can be changed at a 2. A device is sent a command through an API call, such as a
certain rate. Trying to force rapid changes into these core security office issuing a command to pan a remote security
enterprise systems could result in outages or security camera to the right.
exposures. Yet the business needs to react very quickly to 3. A device sends data through a non-API call using other
new opportunities and competitive threats. It needs a higher technology such as MQTT—a high-volume messaging
rate of change than can be delivered by the controlled protocol and transport for telemetry devices—because all
changes required by the systems of record. Using APIs, you the data does not require action. However, APIs are used
can prepackage core system assets for consumption by the to access the data inside the enterprise and look for or
business to create new and innovative systems of engagement. react to particular situations or events. For example,
• Reach: To reach new markets and obtain new customers, medical monitoring devices are constantly sending data
you can make APIs available to other enterprises—for and analytics are used on the data to try and spot
example, partners—who through their interaction with problems. If a problem is found, APIs are used to alert the
clients will generate additional revenue and customers for doctor and patient.
your enterprise. For example, an insurer may work with a • Domains: Domains typically refer to interactions across
low-cost smartphone manufacturer to preinstall its insurance multiple lines of business. They can largely work independently,
app and enable opt-in push notifications for relevant but benefit from sharing data. APIs allow the data to be
location-based information and interaction. The goal is shared in a controlled, secured manner. Domains can also be
to gain access to younger generations of users in over seen as physical locations. Companies that have multiple
20 emerging growth markets. locations, which may include cloud and on-premises data
centers, sometimes use APIs as a method to secure and
control the flow of data between locations.
6 The business of APIs: Best practices

Business goal Priority Time frame Internal sponsor API audience

Financial
Market share
Internal development
Partnering
Competition
Time to market
Innovation
Regulatory

Figure 1. Business strategy worksheet.

There are plenty of reasons why your business could or should Whether on this list or not, the reason for the API initiative
be interested in an API initiative; beyond the four listed should be clearly understood. It is common to have multiple
previously, other common drivers include: reasons for using APIs, as is having a prioritized multistage
view of when each target area will be addressed.
• Mobile development and internal use
• Partnering and partner onboarding Another aspect of business strategy is defining the audience
• Financial; API monetization for the APIs. We typically think of three potential audiences:
• Time to market internal employees, partners and public consumers. However,
• Competitive pressure you could define further breakdowns for different internal
• Regulatory requirements audiences—such as lines of business, types of partners,
• Innovation suppliers versus distributors and so on.

A worksheet can help you document goals and define your

audience when laying out your strategy. A sample worksheet
is shown in Figure 1.
 IBM Cloud 7

Domain ownership and Enterprises that have already undertaken a service-oriented

organizational structure architecture (SOA) initiative are in an excellent position to move
Almost every company has multiple lines of business that forward with an API initiative. SOA initiatives provide a robust
can benefit from exposing assets as APIs, in addition to the platform to build upon. And the services identified in the SOA
central IT organization that will be involved in the initiative. are the foundation that will be used for the APIs. Marrying the
Effective API efforts need to address how these organizations API initiative and SOA initiative, and understanding when a
will work together. requirement should drive API creation and when it should drive
a service, is a critical set of criteria that needs to be defined by
A common best practice is to form a group in the IT organization the core API team.
to own the API technical implementation and infrastructure.
Whether the deployment is on premises or in the cloud, a If an enterprise has not previously implemented an SOA
central team providing consistent methodology and tooling infrastructure, should it do so first? The answer is no. Waiting to
across the enterprise will result in cost savings and reduce build an SOA infrastructure would result in extreme delay and
duplicate efforts. Agreement on tooling platform selection and potential lost business opportunities that would have been
skills enablement will come into play because the partitioning of enabled through APIs. A better approach is to implement your
control and funding are renegotiated across the traditional API initiative first, and then let this help drive the creation of
organization lines (by matrix or otherwise) in an API situation. your system-of-record SOA services.

The IT organization will establish the environments

(development, test, QA, production and so on) in which to
Who should drive the API initiative?
implement the tooling and infrastructure to help with API
creation, runtime, management and security. These tools can One of the most common mistakes that businesses make
also be used to develop the methodology for deploying APIs is assigning the IT team that built their SOA services and
into the environments and, if they are on premises, to implement infrastructure the task of executing the API initiative by
the operations of the environment. Interoperability of technology themselves. While the work these teams did may have been
and people should be a focus area regardless of ownership excellent, the purpose of the API initiative is different than
that of the SOA. If the group creates APIs as an interface to
domains. However, this team will not define the business APIs.
each service that was built for the SOA, they will just add
another layer—missing out on all of the potential value that
could be obtained by the API. While some APIs may call one
existing service, this is not always going to be the case.
The team needs to take a business-oriented or consumer-
oriented approach. We will discuss this point further in
the “API identification” section.
8 The business of APIs: Best practices

Many businesses struggle with the boundary between APIs and

SOA services. No hard and fast rule is available. Some best
practices in this situation are to not think about technology, but Executive Business
rather the purpose of the asset being created. If the asset is an steering domain
committee owners
update or new core business function that will be useful to all
consumers and needs to be thoroughly planned and governed, it Core API team
is an SOA service. If the asset is about making a core business
function consumable quickly, enforcing security and other API product
policies, and meeting the needs of a consumer in a tailored manager
fashion around the core systems, then it is an API. Having a view (business)
across the complete solution—consumer to API to service—
Integration
provides the best results for each component. and API
Operations
developer
So, who should identify the business APIs? (technical)

Figure 2 highlights many roles in a high-level organizational

structure. Note that several people may be in each role and a Internal
Integration
app
single person could be assigned to multiple roles. architects
developers

A critical role in the structure is the API product manager, which

Service
is typically a new role in most enterprises. The person or people owners
in this role own the success of the API or APIs and the API
initiative. Therefore, this role requires strong leadership skills,
as API product managers will be working across departments
and must influence parts of the organization they do not control. Figure 2. High-level organizational structure for an API development team.
While primarily business-oriented, the API product manager
needs to bridge to the technology side.
 IBM Cloud 9

Role Person(s) assigned

API product manager and initiative leader
Business leader (if different)
Technical leader
Executive steering committee
Governance leader
API and domain owner 1
API and domain owner 2
API evangelist
Marketing and communication plan owner
Integration architects
App development leader (internal)
Partner interface
Test leader
Legal interface
Finance interface

Figure 3. Role assignments worksheet.

Key tasks associated with the API product manager role include: The other roles depicted in the organizational structure, shown
in Figure 3, already exist or have similar roles in most enterprises:
• Working with the domain owners to identify desired
business APIs to bring to market • API developer: This technical role creates, tests and deploys
• Working with the API developer to drive creation of the API the APIs. The skill set is similar to integration specialists.
• Reporting to executives on metrics • Operations: This traditional operations role ensures
• Defining the product characteristics of the API availability and service-level agreements (SLAs). If deployed
(monetization, rate limits, audience and so on) in an off-premises cloud such as the IBM Bluemix®
• Communication platform, then the cloud provider is acting in this role.
10 The business of APIs: Best practices

Internal Partner Public

• Lighter concern about API • API identification • API identification
identification, versioning and • Versioning plan • Versioning plan
security (use internal) • Security and privacy • Security and privacy
• Monetization = chargeback • Monetization—maybe? • Legal
• Entitlement enforcement • Entitlement enforcement soft • Monetization
usually soft or hard • Entitlement enforcement
usually hard

Always required: Communication, measurements

Figure 4. API governance growth by audience.

• Domain owners: These organizations own the business Governance model

assets. Ensuring these groups are involved in the API Just hearing the word “governance” makes many cringe. The
identification process, have bought into the initiative and challenge for API governance is to have the correct amount of
understand the value proposition is critical. governance without it becoming a roadblock to innovation. One
• Executive steering committee: This committee of the key drivers for an API initiative is speed, so lengthy
provides executive, funding and resource commitments. governance processes could defeat the entire initiative. Typically,
The API product manager needs to provide them with systems of record (and the SOA services that represent them)
measurements and reports. require robust governance processes for the availability of these
• Integration architects and service owners: These systems. Assets exposed through APIs should not have these
traditional roles represent the existing IT services. same governance requirements, thus allowing for a more
• Internal application developers: These groups are expedited, lighter-weight governance process.
the internal target audiences for the APIs. There may be
many of them, such as the mobile app development team Many businesses take a staged approach to API audiences by
or a different line of business (LOB) consuming APIs starting with internal consumers, moving to partners later
supplied by the original LOB. and potentially moving to public APIs in the future. As the
initiative grows and audiences stretch further from your
organization’s control, the governance processes can likewise
mature and grow. The best practice is to start with a small
governance process and add as necessary. Figure 4 shows a
potential growth path for governance.
 IBM Cloud 11

APIs

Free Developer pays Developer gets paid Indirect

Pay as you go Revenue share Content acquisition

Freemium Affiliate Content syndication

Tiered Referral Internal—consumer

Points-based Internal—non-consumer

Transaction fee B2B—customer

B2B—partner

Business expansion

Figure 5. API monetization business models.

Information governance is an especially important best practice Monetization

when industry standards are involved, such as in finance and IBM published a separate paper on the monetization topic,
healthcare. API development can proliferate through enterprise titled “API Monetization—Understanding your Business
innovation, but the payload data model and taxonomy should Model Options.” In that paper, we focus on the business
have some level of uniformity and predictability—more so if models for API monetization. We describe four groups of
the business model is a back-end-as-a-service (BaaS) model or a API models: free, developer pays, developer gets paid and
business-to-business (B2B) channel expansion model. indirect, with many sub-models for each. We explain each
monetization model and provide examples of companies that
are executing that model. Figure 5 shows a breakdown of the
four primary models and their sub-models.
12 The business of APIs: Best practices

The paper also provides initiative guidance and considerations, When identifying a candidate API, the API product manager
plus a recommended project approach to implementing needs to understand the target API user (question one). The
API monetization in your enterprise. Download the white second question is probably the most important of the three.
paper here. Understanding what the audience is trying to accomplish can
result in the best API interface. If the definition is focused on
API identification consumer need, then the interface is more likely to be useful to
Identifying good APIs is one of the most critical factors in that audience and more likely to stand up to change (versioning).
achieving API initiative (and associated business) success. APIs
need to be focused on the needs of the consumer, and they If the interface to the API is not directly related to the
should be simple. Three questions lead to a good API: back-end system of record resources, then the API does not
necessarily have to change if the resources change their
• Who is the audience? interface. A new backward-compatible API can be delivered
• What do they want? and consumers can be migrated seamlessly to the new version.
• Under what terms and conditions are you willing to make However, if the API is focused on the interfaces to the back-
the asset available? end system of record resources, then each time one of these
systems changes, the API is likely to change as well. This
Notice that none of these questions mention the systems of non-backward-compatible version of the API can require
record that will ultimately deliver the response to the API consumers to update their application—which will be viewed
request. Many companies incorrectly define their APIs by poorly by the consumer if it happens often, and typically
looking at what the systems of record do and adding an API in indicates to them that your APIs are not stable.
front of them. This approach may simplify the process for the
API provider, but it does not meet the needs of the consumer. The third question is related to the policies you want to have
around the API. What security measures are required to allow
the API to be used correctly? Are there rate limits that must
be enforced?
 IBM Cloud 13

Once you have answered these three questions, the API Many businesses have had tremendous success implementing a
product manager and API developer must work together and microservice approach based on creating and running new
potentially iterate to define the API. The API developer business logic in front of their core systems:
needs to map the proposed consumer interface for the API
to the back-end system of record interfaces and possibly to • GoDaddy is now serving hundreds of thousands of small
many other systems to provide only the desired result back businesses’ websites, replacing legacy hosting platforms.
to the consumer. The move to a microservice approach based on Node.js is
improving customers’ performance by 4 times and has
Working from the API consumer inward, new business logic reduced server infrastructure costs by 10 times.1
may need to be added at a microservice layer in front of the • Groupon refactored its approach by making parallel API
existing systems of record. If the current systems do not requests to services. This approach resulted in improved
completely address the requirement, additional coding may be site-wide page loads of 50 percent.2
necessary to add business logic to the existing environment. • LinkedIn rebuilt its mobile app with a microservice (Node.js)
The ability to create and run new business logic in front of the back end. As a result, system speed improved 20 times while
systems of record allows for the required speed to deploy new reducing the number of servers by 90 percent.3
business offerings quickly. Without this capability, the business
will revert back to waiting for changes to the systems of record, You can use the worksheet shown in Figure 6 to aid your API
which could elongate the initiatives’ development cycles. identification efforts.

API Use case(s) Target audience(s) Business model Owning organization

Figure 6. API identification worksheet.

14 The business of APIs: Best practices

Communication or run events and conferences related to APIs. Doing so will

“If you build it, they will come” does not work in an API help build your skills and also let you communicate and collect
initiative. The best practice is to plan for and address the need new ideas on how to get your message out.
for communication.
Be sure to communicate the status of the initiative and the
APIs need to be marketed to the target audiences. How will achievement toward the initiative goals to the executive steering
the audience know the APIs exist if you do not tell them? How committee. Communication helps the executive committee
will they learn about the benefits of using the API? Common understand the initiative’s value, which helps maintain the
approaches include executing “lunch and learn” sessions for funding and drives future expansion of the initiative.
internal audiences or using your partner channel communications
to reach that audience. You can also publicize external public You may need to target communications to multiple, different
APIs on common sites such as www.programmableweb.com. audiences, so tailor the message to what each audience needs to
know. Do not give the executives the same messages you are
Running hackathons for your APIs is another idea. This type of delivering to the app developers. Develop a communication plan
event is a great method to communicate as well as obtain to help determine the most important information for each
feedback and direction on your APIs. You may choose to attend audience. The worksheet in Figure 7 can help with this process.

Audience Message(s) Owner Communication type(s) Frequency

Executives
Internal app developers
Partners
Public
Business domain owners

Figure 7. Communication plan worksheet.

 IBM Cloud 15

Legal and privacy • What requirements do you have for attribution of the
Lawyers by nature are often cautious and may be nervous content or use of your brand? Do you need to give attribution
about making information available through this new API to some other entity?
channel. This is similar to legal teams’ concern and caution • How will you find out and handle consumers who do not use
when the World Wide Web began rapidly expanding in use the API appropriately?
and pervasiveness. Use the web as an analogy with the legal • What are your liabilities?
team to explain that this channel is new and represents a
significant business opportunity. Saying that the API cannot be Managing customer privacy is an important consideration. The
done is not an acceptable response; the product manager will appropriate level of security must be in place to ensure only
need to work with the legal team to find a satisfactory way to authorized users access the customer’s data. Apps need to be
make it work. Be prepared to answer these questions to move validated so they are allowed to access the API. The app user’s
past this hurdle: identity must be secured so that the app itself does not have
access to the user’s credentials. OAuth is a common protocol
• Do you own the data you are providing? used for this purpose. The customer’s identity also needs to
• Are the intended audiences entitled to access this data? pass into the systems of record to ensure only that specific
• What rights are you granting the consumer of the API to use user’s data is accessed.
the data provided?
• How will you communicate the terms of use to the Do not forget about organizational privacy as well. Several
API consumer? organizations that consume the same API may be competing with
• How are you ensuring privacy? one another and should not be able to see each other’s customers
• What is the required policy for data retention? or data. Figure 8 provides a worksheet to help you determine the
privacy and legal concerns involved for each API candidate.

API candidate Privacy concern? Legal concern? Issue owner

Figure 8. Legal and privacy worksheet.

16 The business of APIs: Best practices

Success criteria and metrics Look at technical metrics as well to see where improvement
Establish meaningful, measurable goals for success and gain is required:
executive agreement up front. Common metrics include:
• Are developers coming to the site and not signing up?
• App developer sign-ups • Are API calls coming back with errors?
• API usage rates and rate of growth • Is performance acceptable?
• Number of apps driving usage of more than n transactions
per time interval Publish reports or make dashboards available to the
• Revenue generated appropriate audience for easy access to metrics. Figure 9
• The type of data being requested, and the type of data not provides a worksheet to track details associated with
being requested measurements. You can customize the worksheet for
• Usage patterns, dates, locations—if any the measurements you deem important for your audiences.
• Whether app developers are using multiple APIs

Measurement Goal Report type Owner Audience Frequency

Developer registrations
API usage rate
Revenue
Error rates

Figure 9. Measurements worksheet.

 IBM Cloud 17

Technical governance –– Make it easy to try your API.

As mentioned earlier, the focus of this paper is on nontechnical –– The back-end systems behind the API interface may be
best practices. However, some borderline items that bridge both complex, but do not show the complexity. One API call
technical and nontechnical concerns are worth mentioning. may access three back-end systems, extract lots of data,
Note that this list is not intended to be the complete view of throw 90 percent of it away and reply back with the
technical governance. Here are a few recommendations: 10 percent that answers the API request. Do not supply
three APIs and make consumers do the work of parsing
• API standards and best practices: Representational State each request’s results to find what they need.
Transfer (REST) and Simple Object Access Protocol (SOAP) • Lifecycle: Require few stages. If there are too many stages,
are the most common API technologies. Usually REST and the cycle to make an API available will be too long.
JavaScript Object Notation (JSON) are used for lower- • Deployment and publishing: Early environments, such as
bandwidth devices and to reduce the amount of data development and test, are usually handled synchronously.
transmitted. REST/JSON also tends to be simpler to However, production is usually isolated and requires a
understand and consume. disconnected deployment approach (usually scripted).
• Naming standards: Choose a naming standard that is • Versioning: This recommendation is most critical for public
meaningful to the organizations providing the APIs and easy APIs. Plan for change. Try to make APIs backward-
for a consumer to understand. compatible (as described previously), so you can move
• Granularity and simplicity: consumers automatically to the new level. Often a need
–– APIs are fine-grained—not like SOA services—and exists for multiple versions in production at the same time.
they typically do one thing. Make a plan to move consumers to the new versions and
–– Easy-to-understand parameters: Aim for self-documenting retire older versions.
parameters using easy-to-understand names. Supply
samples to call the API and the returned data.
–– Don’t do anything unusual. Unusual techniques will
confuse app developers and make them less likely to
use your API.
18 The business of APIs: Best practices

• Scale: API entitlement levels are used to help plan for Closing thoughts and recommendations
capacity, and the API gateway enforces these entitlements. Do not wait until you know all the answers and have
With IBM API Connect, scaling should be simple using everything in place to get started with an API initiative. The
additional instances added to a cluster for the gateway or market is moving too fast—an Uber, Netflix or Apple Pay
management clusters. The gateway can protect back-end could disrupt your space at any time. Plan stages for the rollout
systems of record from becoming overloaded. Watch the that build on what you learn and iterate quickly.
analytics to see how your requests are being managed.
If your APIs are successful and you are generating more Many businesses start by targeting a particular group of internal
revenue, scaling the systems of record behind the API layer developers—often mobile. This approach allows for some initial
to handle the additional requests as well may eventually mistakes, learning and corrections as the team becomes more
be necessary. knowledgeable about APIs. We recommend a “fail-fast”
• Integration: Set up guidelines for integration and when approach. Failing is not a terrible thing; taking a long time to
something should be an API versus a back-end service. recognize it is. Starting internally also promotes a lighter
Where should the integration occur? Is a required new governance model. A second internal audience or other lines of
capability something that should be delivered as an API, or is business may follow the initial stage to obtain further experience.
the change really required in the systems of record? Watch
out for inappropriate API proposals that are trying to take The next stage is to expand to partners. Typically, companies
advantage of the lighter-weight governance around APIs. start with known partners who they want to engage in a new
type of interaction that can be facilitated through APIs. This
stage introduces additional governance and requires tightening
up security, privacy and scaling. Plan well for change and
versioning of your APIs. A second phase of this stage is to start
creating APIs to enable new partner onboarding.
 IBM Cloud 19

After that, the next stage is to go public. Initially, this stage will About the author
involve only APIs that enable already publicly available Alan Glickenhouse,
information—probably similar information to the information API Business Strategist
available on the current website. As time progresses, new and
innovative cross-enterprise solutions will evolve, driving Alan Glickenhouse is a business strategist
additional revenue and incenting further exploration of the on the IBM API Connect offering
API channel. management team. He joined IBM in 1981
and has held numerous positions in sales,
As we move into the API economy, there are huge technical sales, marketing, development
opportunities for new and innovative solutions. The companies and technical support. On the API Connect
that derive the most value from those opportunities will have team, Alan assists clients in all industries with their business
their business and IT organizations closely aligned, working strategy for APIs, understanding their business direction and
together to drive success. IBM would like to be your partner existing environment (both business and technical), and helps
on this journey, sharing our expertise and experiences to help businesses successfully adopt an API strategy that fits their
maximize the value of APIs for your enterprise. environment. Alan has an A.B. from Vassar College in Computer
Mathematics and has several SOA certifications. Contact him
To understand more about the IBM perspective on the API at [email protected] or follow @ARGlick.
Economy, visit the IBM API economy and Digital Transformation
websites. IBM API Connect is a complete foundation to create,
run, manage and secure APIs. You can find more information
about IBM API Connect at the API Connect website and
download a trial version here.
© Copyright IBM Corporation 2016

IBM Cloud
Route 100
Somers, NY 10589

Produced in the United States of America

July 2016

IBM, the IBM logo, ibm.com, Bluemix, developerWorks, and

IBM API Connect 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

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.
1
“GoDaddy Joins Newly Unified Node.js Foundation,” June 18, 2015,
https://aboutus.godaddy.net/newsroom/news-releases/news-releases-
details/2015/GoDaddy-Joins-Newly-Unified-Nodejs-Foundation/default.aspx
2
Ó Maidin, Cian, “Why Node.js is becoming the go-to technology in the
Enterprise,” NodeCrunch blog, March 10, 2014, www.nearform.com/
nodecrunch/node-js-becoming-go-technology-enterprise
3
 aul, Ryan, “A behind-the-scenes look at LinkedIn’s mobile engineering,”
P
Oct. 2, 2012, http://arstechnica.com/
information-technology/2012/10/a-behind-the-scenes-look-at-linkedins-
mobile-engineering/2

Please Recycle

APW12355-USEN-00