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
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
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.
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.
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.
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;
|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.
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.
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.
|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||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|
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.
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 firstname.lastname@example.org.
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 email@example.com