How your business can successfully monetize API enablement. An illustrative case study

Transcription

1 How your business can successfully monetize API enablement An illustrative case study

2 During the 1990s the World Wide Web was born. During the 2000s, it evolved from a collection of fragmented services into a fused ecosystem to provide consumers a truly simplified and integrated experience. Today, the lines between , photo sharing services, social networking sites and news sources continue to blur at an increasing pace, and this is thanks in part to application program interface or API. This convergence represents a new business model for organizations exposing (or publishing) services programmatically to both end users and other organizations. It also represents a novel stream of revenue associated with this new channel. This revolution is well underway with Amazon quickly approaching one trillion transactions through its various service offerings and salesforce.com generating more than one-half of its revenue from services (as opposed to its online CRM user interface). 1 What are exposed services and what are businesses doing with them? Exposed services can enable a number of things, such as allowing cloud-deployed systems to interact with one another and make calls to systems deployed locally, big data processing, mobile apps functioning and more. These services are the fusion of the Internet economy. So how do exposed services work technically? Enabling technical services programmatically for external consumption involves creating an API and exposing it similarly to how a company would publish a web page. APIs have been around for decades; computer programmers use APIs to communicate between system components behind the scenes. Now, driven by Internet technology advances, today s APIs are business assets they offer a simplified interface to access valuable business data and functionality organizations can leverage to expand their reach to partners, third-party developers and ultimately consumers. s have data and functions that consumers need and want but cannot access until the information is exposed for public consumption. For example, before heading to the airport, a frequent traveler might check an airline app on a mobile phone to determine if a first-class seat upgrade is available and possibly even sign up on a waiting list using the same mobile app. Compare that to standing in a long line at the counter at the airport and asking the same question. Having the right information available at point of need is priceless and can help solidify customer loyalty. This is possible because the airline has exposed key APIs to enable access to this key information. As consumer expectations rise for being ultra-informed on a 24/7 basis, people flock to online app stores and cloud services to improve their connectivity to key information sources. In the past, there were a number of technology-related challenges that hampered the publishing of data and services. Now, as technology has rapidly advanced, there are plenty of products to allow rapid publishing. The question today becomes not is it possible, but is there demand for these key APIs? At the same time, exposure introduces an avalanche of questions on topics ranging from security to process, which drives the need to look at APIs in a whole new way. 2

3 Realizing ROI: An API enablement project The remainder of this white paper focuses on an API enablement program that Accenture completed for a large company that sought to bring together many existing, fragmented services into a truly integrated platform. 2 The objective was to provide a game-changing experience to customers, as well as create new channels to monetize existing functions. The company had three key goals: 1. Complete integration without doing harm: Maintain current business processes that rely on the existing ecosystem, while also integrating these services to enable a truly new experience for customers. 2. Enable productivity of the delivery organization and attract developers from beyond: Maximize productivity of internal developers, while also attracting third-party developers from the development community to the platform. 3. Implement scalable computing capacity: Provide elasticity in computing power to support an expected dramatic increase in consumption of services by leveraging an external cloud, which meant internal platform services had to be consumable by systems outside of corporate firewalls. The initiative also had three relevant constraints: Services to be integrated had a proliferation of data formats, interfaces and technology platforms. service-oriented architecture (SOA) middleware platform was widely deployed and used in the existing ecosystem. Services exposed were often large, complex and convoluted but supported many existing business processes. Requirements called for exposing interfaces dealing with singular entities (a specific customer), as well as large data sets (all customers in a particular zip code). 4 3

4 Five important lessons from the journey Through the project s implementation, there were five key insights learned: Let a container do the work Web applications have threads to manage, authentications to validate, flows to define and more all handled by a web server. Likewise for exposed APIs, there are key concerns that should be left to the container to manage, including security, caching, transformation, analytics, aggregation and expansion of services, and flow control. For this project, Accenture used an API Gateway to quickly define logical exposed services. These acted as facades to existing SOA services but provided a simpler interface with fewer data elements, cached response data, integrated security access to an existing identity and access management (I&AM) solution, aggregated services from multiple middleware platforms, and translated data from more than five formats (SOAP, flat file, XML, etc.) to Representational State Transfer or REST. The biggest benefit was productivity. The API Gateway creates logical services with life cycles that are managed via reusable policies so there is very little code to write or configuration to test. Furthermore, the logical services in the gateway do not affect existing services, meaning these do not require any regression testing. Using this approach, the team achieved the goal of doing no harm. Application architecture Exposed APIs represent a new application style (distinct from web or batch applications, for instance) and there are many architecture concerns to be addressed. Beyond using a simple system diagram, the architecture has to include well defined patterns, naming standards, enforceable models, reusable framework code and the like. This is a key success factor many projects ignore up front. By doing so, they essentially defer these critical design decisions to developers to define along the way. On the Accenture project, the existing ecosystem could be drawn as follows at a high level (see Figure 1). Figure 1: ecosystem Business Unit A Bus Business Unit B 4

5 When Accenture introduced the API Gateway, the team had to think through where business process orchestration would occur. The gateway supports orchestration definition that requires no code to be written but with a key tradeoff: more fragmented business process logic. Accenture categorized the services being consumed by a particular API. In the instances where all services met the threshold criteria, the orchestration was implemented the API Gateway. This left a number of APIs requiring programmatic orchestration for which the team architected a new custom layer (see Figure 2). Accenture subsequently defined pattern models down to the object level covering each type of use case, framework services to extrapolate reusable functions and remove complexity, and structural code generation capabilities to enforce both the models and services. It was important not to overestimate the capabilities of the container. In the end, the exposed API was the facade; therefore, maintainability, performance and development productivity is now driven by how the application is structured, and how it is integrated into the client s ecosystem. Beyond internal developers Speaking of integration, the client was well versed in SOA, having spent years establishing a SOA platform, governance and connection for its systems. After working to expose services outside the enterprise in an industrialized manner, Accenture now needed to start the journey from SOA services to API services. Fundamentally, the technology is similar (integration patterns and platforms, interface definition, even data formats can be identical) but APIs need to enable distribution and consumption well beyond the audience of the more predictable sort to which SOA caters. Figure 2: Custom layer Business Unit A Business Process orchestration Bus Business Unit B API Gateway Accenture used the API Gateway developer portal to publish and govern materials in order to help nurture an external community of developers and expand reach. The portal provided a mechanism to quickly create documentation based on defined APIs and solicit feedback from developers, as well as to facilitate collaboration outside the client s and Accenture s internal community. From a design perspective, the team had to shift its mindset as well since the APIs were now business products. Enabling maximum reuse of services is the name of the SOA game (leading to large granularity of services), while catering to specific use cases for easy consumption is the name of the exposed API game (likely leading to much smaller granularity of services). Accenture intentionally designed the APIs on the project for specific use cases, giving up reusability, which was acceptable given both the intent for the APIs to be simple and easy to consume, as well as the fact that they were relatively cheap to build. 5

6 RESTful or RESTless? Accenture broadly categorized the use cases into two categories: transactions requesting information for a single entity (address and phone number for John Smith, for example); and requests for large data sets (a list of all customers in a specific zip code). The single entity transactions are likely to be used by a developer writing an app, whereas the large data sets are needed for a new application Accenture was developing and deploying in the cloud. It was important to reuse the same point of entry into the client s ecosystem so that the team could use the same security, orchestration capabilities and other important components (see Figure 3). This approach had an important implication to the architecture. Many people design API applications based on REST principles, however this is inherently designed to manage singular entities. This approach can be extremely effective for transactions dealing with single instances of data records. However, the cloud application Accenture designed consumed large data sets. A purist RESTful design would have yielded a number of database calls from the back-end systems equivalent to number of records, which could have reached into the thousands. Instead, the team designed key interfaces to call complex services that leveraged complex SQL joins to retrieve the necessary data in one database call. The lesson learned? Cater to the use case and be pragmatic; do not blindly apply a single solution. Figure 3: Addition of API consumption layer to blueprint New Application Mobile App Business Process orchestration Bus API Gateway Business Unit A Business Unit B 6

7 Conclusion The fusion of the Internet and expectations of end consumers is quickly driving increased demand for a simple, robust and standard mechanism to exchange data outside the enterprise. Fortunately, there are some strong tools such as those provided by API Gateway, Layer 7 and WSO2, to enable the API revolution. Learn the capabilities of these tools and avoid reinventing answers to problems that they already solve. Using these tools will make it possible to focus resources on establishing key architecture principles, which is critically important for deploying systems to the cloud, processing everexpanding amounts of data from various sources and building mobile apps that will satisfy customers.

8 For more information about API enablement, please contact: Max Furmanov Director Emerging Technology Innovation Edy Liongosari Managing Director Accenture Technology Labs Jean-Marie Hunold Global Lead Emerging Technology Innovation About Accenture Accenture is a global management consulting, technology services and outsourcing company, with approximately 261,000 people serving clients in more than 120 countries. Combining unparalleled experience, comprehensive capabilities across all industries and business functions, and extensive research on the world s most successful companies, Accenture collaborates with clients to help them become high-performance businesses and governments. The company generated net revenues of US$27.9 billion for the fiscal year ended Aug. 31, Its home page is References 1 Forbes, Welcome to the API Economy, by Roberto Medrano, Aug 29, This case study was created for illustrative purposes and is an amalgamation of actual Accenture client projects. Copyright 2013 Accenture All rights reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. ACC U/