Internet of Things and Cloud Computing
Volume 3, Issue 1, June 2015, Pages: 1-7

Fifty Shades of API for Business in New Networked Economy

Debasis Roy Choudhuri1, Biswajit Mohapatra2

1Global Business Services (GBS), IBM India, Melbourne, Australia

2Global Business Services (GBS), IBM India, Pune, India

Email address:

(D. R. Choudhuri)
(B. Mohapatra)

To cite this article:

Debasis Roy Choudhuri, Biswajit Mohapatra. Fifty Shades of API for Business in New Networked Economy. Internet of Things and Cloud Computing. Vol. 3, No. 1, 2015, pp. 1-7. doi: 10.11648/j.iotcc.20150301.11

Abstract: Application Programming Interface (API) is increasingly popular and it became one of the critical vehicles of service enablement and IT collaboration in Cloud computing. Several large business enterprises invested a major portion of their IT budget into software redesign, restructuring the application architecture and their application service interfaces to decouple of the application boundary beyond limit. It will cover a detail understanding of API and its essence in the business and enterprise. It will also share a various shades and role of API in IT transformation journey in the networked economy of cloud computing and social media. The article also demonstrates how an enterprise can scale to manage the hyper growth of economy through collaboration of services by various service providers through API.

Keywords: Application Programming Interface (API), API, API Economy, API Transformation, Collaboration of API, Cloud Computing and API, API Architecture

1. Introduction

In architecture pattern of Software computer design, Service Oriented Architecture (SOA) is in the market space for a while and it became increasingly popular over the last decade. Several large business enterprises invested a major portion of their IT budget into software redesign, restructuring the application architecture and their application service interfaces to decouple of the application boundary beyond its limit. A counter argument also became popular that return on investment on this paradigm shift didn't provide an expected value over a period of time. However without getting into the debate of SOA, let us take a look at another demanding software design and redesign principle; API i.e. Application Programming Interface. We need to understand in a deeper level whether this is an extension of SOA or it does provide lot more capability in today's frequently changing business requirement and how an enterprise be agile to meet the business growth. Here we would like to discuss the power of API in IT transformation journey in the economy of Internet of things.

In simple definition, an API is nothing but a set of software routines, protocols, data-structure and tools, supported by set of language, scripts for building a software applications. It has been in our computer industry from ages. The question is that why everyone is so focused on API now. In common opinion, it's not something newly design or developed, it's more of understanding the value of it and how to leverage in collaboration with other services. Here it comes the power of API and application of API in software service design. So for developers, it is simply a specification of remote calls exposed to the API consumers however for business, supported by enterprise architecture, it's lot more than a remote call.

Figure 1. Momentum of API growth in current social media.

Today, technological advancement allows an enterprise to become disruptive in their transformation journey. None of the transformations are easy but there is an immense joy of adopting a new and better services integration to the business. It's a fact that we are regularly dealing with social media, cloud, mobile etc. so application design and development are no longer for in-house. Collaboration of services by various service providers and communities are easy and lot more economic with much bigger reach in today's world of digitization. We call business as a 'service economy' in API which is being powered for cloud, mobile analytics and social media who are supporting the hyper-growth of the economies.

One of the prominent player of API is eBay, an internet ecommerce service. As per CTO, eBay, their $7bn worth of items on eBay are through APIs. Twitter has increased more than 10 times of their request through API than standard website visits. Through Amazon’s Web services, organization is attracting more network activity than their traditional web sites. A simple diagram show below how it magnifies the global reach.

Figure 2. Journey of API from Service Organization to Consumer market.

The above figure 2 demonstrates a service organization can multiply their services to numerous times using API exposure through their business partners to resellers who reach to the global market. A very simple example could be a simple news feed or sponsored linked when we login to facebook as shown in figure 3. as it understands the user interest and feeds accordingly. So here API capitalizes the concept of personalization.

Figure 3. An example of API in Facebook in mobile device.

2. Type of API

As we can't ignore the basics, let us take a quick look of various API types which are fuelling the strategic business growth of an enterprise. We will highlight broadly three types below;

Table 1. Shades of various API.

Public and Open API These are open to any developer who can sign up and it's indented for consumers. The primary business driver is to engage customers through developers through external interface. From business view, we can consider search API for product details, getting an insurance quote for car insurance renewal or get an interest rate comparison for better home loan. Protected APIs for partners These are open to specific business partners, selected by enterprise or service provider. Usually it's targeted at end consumers or business users. The key motivation is here the data and type of business of the enterprise to integrate. From business view, we can envision that payment status check, payment gateway used in buying things in internet, getting delivery status of a consignment shipment. Private API within the enterprise There are exposed only to existing developers within the enterprise because it's targeted at employees of the enterprise for increasing the qualitative and quantitative productivity through in-house collaboration of existing services available than building from scratch. From business angle, we can leverage APIs to integrate various group within an enterprise such as central operations with and local operation, systems integration across the business units through common API, for example, login and authentication API through enterprise active directory.

The enterprise support teams to be able to respond to new customer and market growth demanded by the business. API allows for more frequent and faster delivery times. It allows business owners to get quicker feedback and make necessary adjustments to their investments. API also allows us to have smaller focused teams that align with business revenue and cost centers that enables business owners to more easily see where resources are allocated and move them from low impact business areas to new or higher impact business areas. Now if business owners want to appreciate their users, API enables a better user experience.

The critical collaborating factor is that business owners should be able to off load work to third party partners without the risk of losing intellectual property. API with appropriate security model allows us to decouple for non-core business functions without disclosing of the core services. By adopting an API model, it becomes quickly obvious where there is a duplication of service. Single platform development allows you to more easily eliminate duplicate services and reduce development costs. We will review this in more detail in Architecture view point.

3. An Architecture View Point, how a Business Can Leverage it

A right API architecture and strategy should embrace a new business model and changes in business strategy, IT strategy followed by IT implementation. An API strategy should understand the demand of new business initiatives, driven by increased customer interactions, information and new channels. An API architecture is not something brand new build of architecture, it's an expansion and modification of the existing architecture, supporting scalable exposure of API with a controlled fashion. Before we discuss the understanding of enterprise architecture involved in supporting API economy, let us take a look at the difference between of System of Records (SoR) and System of Engagement (SoE).

A System of Record (SoR) is a common terms used in Data Management for an information storage system. It's also considered as authoritative data source for information system. For an example, an ERP-type systems runs in an enterprise, manages various information such as financials, manufacturing, human resource etc. They are required to be integrated to make sure all that data is consistent. According to Geoffrey Moore, "Systems of Engagement (SoE) is the transition from current enterprise systems designed around discrete pieces of information ("records") to systems which are more decentralized, incorporate technologies which encourage peer interactions, and which often leverage cloud technologies to provide the capabilities to enable those interactions." SoE are directly used by business users and employees through applications like social networking, learning system, email system etc. So in simple terms, System of Records (SoR) are nothing but an authoritative data source while System of Engagements (SoE) are various type of applications which engage customer, business users, employee to access various data in a meaningful presentation through various channels like mobile, tablet, computer, advertisement kiosks etc. For an example, if I search my favorite timepiece in a social network to find their names and features which suits my requirement, I will easily find them. They also seem to post rich content and information to engage the customer, hoping wining more consumer base.

Before getting into the API development and API deployment in a cloud architecture, it's important to understand the identification of API as per the business need. Here is a top-down and bottom-up approach shown in figure 4 below.

Figure 4. a High Level approach to API identification.

The above figure shows that identification is a top-down approach where choice of API should be based on maximum impact on business KPI, an approach to develop a strategy to the right set of APIs(e.g. product details in search of a medicine and its composition, list products support APS sensors in digital camera etc.) where as the bottom-up approach shows three levels of attributes, supporting the top-down approach, for example functions that have maximum hits in a day in production environment, volumetric data, like concurrent users, users to transaction volume mapping, and so on. Top-down approach shows degree of impact where as bottom-up approach shows degree of reusability.

Once the API is identified, an appropriate reference architecture can be adopted to develop, deploy and manage the API. We are currently engaged with many of our business partners and clients for developing strategies, indentifying key functions to supported for them as an API services. From our experiences with respect to client enablement strategy for cloud, we realised that our client needs assessment for defining strategy for developing a complex integration solutions for application communications that span multiple mobile, cloud, and on-premise environments allowing our clients to take advantage of the rapid rise of social, mobile, and cloud platforms.

The figure 5 below is a simplified view of an IBM Open Cloud architecture platform where SoE application solution can leverage the API to marketplace, various internet and commerce applications in the API economy. Here the bottom layer shows the reusability, aggregation and orchestrating capability of an enterprise architecture foundation which supports the middle layer i.e. API management layer for publishing and monitoring the perceived business value. Top layer shows, SoE enterprise applications for business partner’s or exposed for general consumption.

Nowadays, API strategy is an integral part of both business and IT which guides the design decision, specific processes, interfaces and common services for deployment of IT solution, supporting business objectives. Typical technologies involved in developing these external services are REST, JSON, HTTPS, OAUTH, RSS, SOAP, XLM etc. while the enterprise services are mostly developed by J2EE, .NET, WSRP, SQL, C/C++ etc. These are very well known matured language or software suites. So application of the right technology at right place is the key success for an enterprise architecture to leverage the power of API.

Figure 5. Simplified API Reference Architecture.

4. Adoption and Implementation of an API Architecture

One of the most critical thinking comes to our mind is to develop a plan for an enterprise who wants externalize through API exposure within and outside the enterprise and it involves several key roles within and outside the enterprise to enable an API adoption plan. Some of the obvious ones are listed below from top-to-bottom:

Business stakeholders who wants to engage the customer in new market space.

Application Developer who will use the API for general, private or specific purpose of consumption as defined in the type of API above.

IT stakeholders who will make the API secure and scaled up to manage deployment and maintain.

Team of Business and IT stakeholders to respond the business need to manage the growth as it penetrates into the existing and new market space.

Now to implement the API architecture, it needs to have a API transition plan followed by Management action plan. Here API governance is also very important as it maintain the process, policies, communication, continuous quality improvement in API capability to support the organization growth. So in high level a following steps can be adopted to implement the API architecture:

Develop API assessment plan to meet the requirement of right choice of API, supporting maximum business KPI as defined in above figure 4.

Develop the objective and principle for API

Initiate the development API management

Validate the API objective and principle defined before, adopt any appropriate adjustment needed

Develop a team to define the API as per development life cycle

Determine the API governance model

Outline the API development and adoption approach supporting the API architecture defined

Define the usage of the API for business and developer groups

Develop a deployment plan and API consumption roadmap for API externalization

Develop a communication plan

Transition to the API management team

The below table 2 shows some of the successful implementation of API in various domain as an example.

Table 2. Example of various three industry domain their API usage by client.

Industry Domain Popular Company Company's API offering Client uses The benefits realised
Telecommunication Industry AT&T API suite includes APIs for contacts, SMS, MMS, advertising & payment Facebook AT&T subscribers will benefit from directly charging in-app purchases to phone bill
Retail Industry Best Buy Shares sales through partner apps. Increase use of gift cards & loyalty programs eBay, Netflix Business Partner's innovations in gifts, mobile, loyalty, product location and price comparisons
Services Industry, Payment Services PayPal Seamless payment mode integrated into Point Of Sale (POS) Home Depot Customers can pay with PayPal at POS, controlling fraud incidents and reducing credit card fees

5. Conclusion

We would like to summarize with a view point of why do business uses API.

Developer uses API for up-scaling the development for internal, partner or external interface.

Enterprise business empowers their business users and partners by application creation, tapping wider user base by building new use cases.

Business enriches consumer experience by using API for wider consumer knowledge, better understanding products and services such as language variations, localization, demographic focus etc.

Last but not the least, business enterprise entertains completion by leveraging the partnership through reusable assets, broadening the user base and reducing the development investment.

So in summary, API is not just extension of SOA. Here the breath is not restricted to internal or enterprise consumption. Here consumers are both external and internal developers. It embrace more open community and business, leveraging social media. It's lot more fine grained and easy to adopt supporting communication channels. It follows simple a journey to start such as

Create an API -> Control the API -> Connect the API -> Ready for consumption.


We wish to acknowledge and thank the IBM, supporting the various offerings around API architecture, assets for delivering our various business solution and engagements.


  1. IBM API Management, API and its service management features, reference link:
  2. IBM Developer works, API economy, article ' Where are you spending your enterprise IT dollars?', reference link:
  3. IBM Developer works, API economy, article When your APIs are ready to be liberated, are you ready to free them?, reference link:
  4. Accelerate to Green IT - A practical guide to application migration and re-hosting , reference link:
  5. Security API for Mobile Applications Developers, section Overview, reference link:
  6. IBM Open Data, Transcript section, section no. 2, 3, 9, 10, reference link:
  7. Web Development Trends for 2015 And Beyond, section - The Rise of API Driven Development, Predictions for 2015 and Beyond, reference link:
  8. Programmable Web, the world largest API repository, section 'Bing Ads', ' eBay Business Policies Management API', 'eBay', 'Google App Engine', reference link:
  9. API Keys | API Client Library, section ' Acquiring API keys', reference link:
  10. Technical Documentation Facebook, this section is referred as an example of usage public APIs , reference link:
  11. Cloud Computing Reference Architecture (CCRA) 4.0 Overview, section Introduction, page # 8, 30, reference CCRA 4.0 Overview_20140918_non_conf.pdf
  12. Tech Republic Australia, SOA vs. API to deliver IT Services, article ' Two schools of thought about how to offer enterprise IT as a service have emerged: SOA or APIs ', reference link:
  13. The Importance of an Application Modernization Strategy, an ISACA Journal, reference link:
  14. Pattern Driven Enterprise Cloud Transformation – An Innovative Approach to Hybrid Cloud Adoption, reference link:
  15. Cloud API, section Cloud provider cloud APIs, reference link:


Debasis Roychoudhuri is an IBM Certified Senior Architect and Cloud Evangelist in IBM. He has 16 years Industry experience, specializing in software application architecture, consolidation and migration to various cloud environments. He is involved in several cloud education initiatives in Indian Institute Technology (IIT), Indian Statistical Institute (ISI) and Indian Institute of Management (IIM) as part of IBM University Relationship program. He has published several technology articles in developerworks, Computer Society of India CSI. He is managing large financial clients of IBM Australia as a Cloud Evangelist. He can be reached at

Biswajit Mohapatra is an IBM Certified Executive Consultant and Global Integrated Delivery Leader for IBM Application Development and Innovation Digital Modernization Service (DMS) practice. He is IBM India Competency Head for Global Specialized Application Modernization, Application Workload Optimization and Cloud Migration Competency. Biswajit is a known thought leader in Indian IT community for leading Cloud modernization initiatives driving industry academia collaboration from concept to realization. Biswajit has several international journal publications on cloud modernization. He can be reached at

Article Tools
Follow on us
Science Publishing Group
NEW YORK, NY 10018
Tel: (001)347-688-8931