Leveraging SOA principles for API adoption 031214 - Wipro

www.wipro.com

Leveraging SOA Principles for API Adoption

Table of Contents 02

Abstract

02

Declining Preference for Traditional SOA

03

Onboarding API Bandwagon

04

Checkpoints

05

Leveraging SOA Best Practice for API Implementations

07

Conclusion

07

About the Author

Abstract With the emergence of mobile revolution and ubiquitous customer connects, there has been significant changes in the way organizations interact with their customers. There is a growing demand for agility, resilience and flexibility to stay ahead of the curve. The shift in the business models also saw a decline in demand of traditional IT models. There has been significant impact on one of the most popular themes of the past decade – Service Oriented Architecture (SOA). This paper looks into some key reasons that caused the decline in affinity towards “traditional” SOA and emergence of API as a popular trend. The paper also highlights the key checkpoints to look out for in the emerging API journey and emphasizes the need for preserving best practices of SOA for better results.

Declining Preference for Traditional SOA SOA at its peak has been a much sought after theme across multiple industries. It promoted benefits of reusability, time-to-market and better Stable phase, SOA success stories

ROI to name a few. SOA at peak – SOA Governance, Registry implementations

However,

more

than

a

decade

after

SOA’s

introduction, many organizations have failed to

Focus on CoEs and Shared services

leverage or showcase the expected benefits and return on investments. This has resulted in fading confidence and support for SOA initiatives.

Some of the key reasons behind this unexpected twist in tale are availability of SOA experts for end-to-end implementation, Overload of SOA processes, failure to report benefits on a consistent manner etc. 2

Initial implementations

2000+

Concepts of pragmatic SOA emerges; preference for reducing overheads Agile and Iterative programmes challenges SOA focus

Mobile and API revolution shifts focus to light weight, agile implementations

2015

Figure 1 - Traditional SOA demand over the years

Availability of SOA Experts and Evangelists

Technical Impediments

Majority of SOA initiatives heavily depended on external consultants from

Though it was not a mandatory requirement or a SOA principle, the

consulting firms. They championed the initiatives by building a case for

default model used by a majority of SOA initiatives was SOAP and WS

SOA adoption, evangelizing the business benefits to the business

standards. Unfortunately the schema models focused on elaborate

stakeholders, defining SOA Adoption Roadmap, defining SOA CoE and

structures increasing the payload size and modeling complexity. End result

governance for project delivery, to name a few. However, once the SOA

was highly cumbersome and complex, and low flexible modeling and

specialists moved off, the responsibility of governing, the processes was left

versioning scenarios added to project delays and complexity.

to the existing teams. Without the right direction and expertise, the initiatives lost direction.

SOA Overload

Popularity of ‘Agile’ Implementation

As indicated earlier, many SOA initiatives were driven by external consultants

Due to increased need for faster turnaround times, an increasing number

and in some cases, SOA enablement started running as the main charter

of organizations have started preferring an iterative or agile model over

instead of enabling business benefits. An overload of SOA governance,

the traditional waterfall model. Due to shortened cycles for architecture

processes, approvals and tight binding contracts caused increase in cost and

and design, the whole SOA objective of designing ‘enterprise’ wide services,

more importantly time delays in project. Soon SOA started gaining

ensuring right service granularity and enabling service reusability became

detractors especially in project execution and business teams.

increasingly difficult. There is a gradual shift seen from shared services and models, to domain and project centric implementations.

Failure to Report Benefits

The SOA initiatives that took off were able to clear the first hurdle of convincing the stakeholders and initiating the SOA program. But majority of the initiatives were not able to enable an effective mechanism to continuously report benefits back to the stakeholders. Along with the SOA overload mentioned earlier, lack of view on benefits caused business

The challenges faced by SOA are more attributed to the faulty implementation or the changing dynamics of environment and nothing to do with SOA principles which are still prevalent and applicable for good implementation.

stakeholders to reduce funding for SOA initiatives.

Onboarding API Bandwagon With the current digital transformation trends, there is definitely a need for organizations to be equipped for mobile wave and be flexible for quick changes.

With the huge urge to expose APIs, are we creating more challenges in future? Instead of overload of processes in

Organizations are having developer portals enabled and APIs exposed.

case of SOA, are we possibly facing a proliferation of

A number of API vendors like Layer 7, APIgee, Mashery and traditional

unmanaged APIs?

players like IBM, TIBCO, Software AG, Oracle, SOA Software are battling it out for the customer space. Those organizations that are ahead on technology adoption are aware and But what we may be seeing with APIs could be a reverse end of SOA

have already taken steps to adopt the best practices for API

adoption. While SOA was blamed for it’s over-governance and control,

implementation. It is worthwhile to look at some of the pitfalls that need to

APIs could easily fall into issue of lack of it.

be handled for a good API implementation. 3

Checkpoints It is important to ensure that API adoption is not restricted only to enable

points discuss some pitfalls that might be encountered during API

mobility or security enforcement, but should consider the long-term view

adoption and recommendations to address those.

on flexibility and maintainability of the implementation. The following

Understanding Resource Orientation

Channel Driven APIs

Representational State Transfer (REST) is an architectural style that is

SOA strongly propagated the need for clear segregation of presentation

based on and well-aligned to web fundamentals. Though REST has been in

layer from services layer for enabling loose coupling. In case of APIs, the

use for many years, the prominence of Mobile and e-Commerce revolution

very nature of the requirement requires a close interaction with channels

has given a new level of prominence to REST and JSON. Coding in REST

and is supported by many products in this space.

requires a new way of thinking – thinking in terms of resources and concept of HATEOAS (Hypermedia as the engine of application state) that enables the continued interaction of resources. Alternate models like Pragmatic REST are also being applied. Many developers who are enabling APIs have come from SOAP-based

With this scenario, there is a strong reason that APIs “may” get modeled by the channels and there are possibilities of emergence of channel-specific APIs. API management support the concept of bundling to create Apps specific to channels; however care must be taken to have granular APIs that are reusable across bundles.

implementation background. Moving to REST is not just changing the protocol and format.

Vanishing ESB

Have the transformed API developers really understood the concept of REST and resource orientation? If not, what you may get could be a simple translation from SOAP implementation in JSON format instead of true RESTful services.

Lack of Time for Design

Many new API implementations are considering taking the step of bypassing the ESB layer itself. Though it makes sense for simple mediation and data interfacing type of interactions, we do need to consider larger perspective for complex scenarios like orchestration, store and forward, transaction handling etc. It is important to clearly identify and define the right use cases and identify only the relevant usage scenarios for APIs

One advantage brought in by API tools is the speed of enablement of APIs by means of policies. Due to easier nature of API enablement, normally

instead of complete transformation to APIs.

organizations tend to provide limited attention for design. Are we adopting the right design principles? Have we identified the guidelines for design patterns like security patterns, mediation patterns to interact with existing services? Have we considered failure scenarios? Are

While there is an urgent need to onboard and be

we following right URL structure, status codes and naming standards?

API-enabled, we need to be wary of the adoption

Since many of APIs are exposed to external world, it becomes even more

pitfalls related to this. These issues can be avoided

important to do it right the first time. Design considerations applied at the

by taking few simple steps that provide stability to

beginning will help achieve more stable implementations.

the journey. Organizations that are leading the API adoption are clear on the objective and adoption

Change Management Challenges

and are taking the right measures to achieve the flexibility and business benefits of APIs.

One of the biggest drawbacks SOA implementation is accused of is the complexity of model management due to heavy schemas and use of shared models like industry standard schemas. API models propose simplified models suited for light weight consumers like mobile devices. Though the schema complexity is reduced, the challenges of versioning, change management remain an important consideration. Frequent change on APIs will create user dissatisfaction and may result in non-usage of your APIs. A little time spend on planning will help in reducing frequent changes.

4

Leveraging SOA Best Practice for API Implementations An ad-hoc API enablement may result in multiple challenges in future. Few basic steps can allow much better and stable implementation without impacting the time-to-market and cost of implementations. This is where SOA learnings (do’s and don’ts) can be leveraged effectively. The need of the hour is a pragmatic approach that provides flexibility and agility for APIs without sacrificing the basic consistency and best practices of service orientation. As a starting point to adopt best practices, the key tenets of SOA are applicable for API adoption as well.

The need of the hour is a pragmatic approach that provides flexibility and agility for APIs without sacrificing the basic consistency and best practices of service orientation.

Abstraction

Reusability

In simple terms, abstraction refers to exposing only those details that

Given the current surge on API adoption and the immediate need for

are relevant for consumers to effectively use the API and hide the

API enablement, one of the major challenges that would be faced by

intricacies like the information provider, implementation details and

organizations in immediate future will be to prevent the proliferation

technology used. With this, it provides the API owner the liberty of

and ensure maintainability of the APIs. Since majority of APIs are driven

changing the implementation without impacting consumer. API design

by consumer need at the moment, reusability and prevention of

needs to consider abstraction as one of the key consideration at the

proliferation will be the focus areas in immediate future, when it gets

design stage itself.

adopted at a larger level.

Statelessness

Discoverability

One of the prominent usages of APIs is to provide proxy functions for

The discoverability and documentation becomes even more critical in

accessing the core underlying information. The performance of the

case of APIs. APIs needs to be supplemented with communicative

overall interactions largely depends on the provider service and

metadata by which they can be effectively discovered and interpreted.

backend. Majority of current API implementations are HTTP and Request/Reply-based invocations as default implementation. Considering the expected scale of API invocations, it is extremely important to manage statelessness and light weighted implementation in-order to ensure limited impact to overall infrastructure. To ensure this, APIs may need to consider alternate paradigms like deferrals,

Utilizing SOA principles, lend the required stability for API implementations. Hence effective approach will be to take the best of both to ensure the right implementation. Figure 2 gives a view on some additional dimensions of implementation and proposal to adopt best of both worlds.

publish subscribe, delegation models, if applicable.

5

API World (current)

Proposed (best in the world)

Stream-lined process methodologies and Governance

Inbuilt governance mechanism in API Management products

Derive best practices and form a light weight Governance model

Well-defined templates, guidelines and best practices

Limited standards followed being an emerging area

Derive best practices and define basic standard like naming standard

Model Management

Complex and Time consuming (CDMs, SOAP, XML, Shared models)

Simple and Light weight models adopted(e, JSON)

Continue Simple and Light weight models supported by basic standard

Documentation

High level of process and technical documentation

Light weight documentation (eg. Swagger, RAML etc.)

Continue light weight documentation approach. Ensure proper documentation

Change Impact

Smaller impact as the consumers are mostly internal

Larger impact as APIs are mainly exposed to external world

Approach to be adopted ensuring the right design at first time

Time-to-market

High, due to complex models and process

Low, due to simple models and light weight standards

Continue the simple model

Design and Implementation

Normally stable, reliable and scalable as sufficient time is provided for design

Less time available for detailed design

Define and leverage design pattern, checklists and standard

Custom built

Inbuilt in most of the tools

Utilize the inbuilt capabilities and extend to higher degree of analytics.

Well established as mostly used within the enterprise

New models like QAUTH supported by tool

Define clear checklist and approach for security along with tool to reduce vulnerability

Traditional SOA

Governance

Standardization

Monitoring & Management

Security Implementation

Figure 2 - Recommendations for API adoption Please note that the API implementation view is based on observations from current trends in the industry. It is a general view considering the initial stage of adoption and may have exceptions in specific cases. 6

Conclusion Considering most of the organizations have attempted SOA in some form or the other, it is inevitable that API and SOA will have to co-exist in the near future. Though “Traditional” SOA model adoption is declining in overall industry, it might be judicious not to miss the best practices of service orientation which can go a long way in enabling a scalable and reliable API implementation without sacrificing the speed or agility of business enablement.

About the Author Manoj Santhakumar Manoj has over 14 years of experience in end-to-end implementations in integration space covering areas like Consulting, Architecture, Program Strategy and Solution Delivery for Payments, Banking, Insurance and Telecom domains. He has been instrumental in setting up Integration Competency Centers and enabling BPM and SOA Transformations in multiple client engagements. Manoj is currently working as Senior Consultant as part of Architecture and Consulting Group under Connected Enterprise Services (CES) Practice of BAS. Manoj can be reached at [email protected]

7

About Wipro Ltd. Wipro Ltd. (NYSE:WIT) is a leading Information Technology, Consulting and Business Process Services company that delivers solutions to enable its clients do business better. Wipro delivers winning business outcomes through its deep industry experience and a 360 degree view of "Business through Technology" - helping clients create successful and adaptive businesses. A company recognized globally for its comprehensive portfolio of services, a practitioner's approach to delivering innovation, and an organization wide commitment to sustainability, Wipro has a workforce of over 140,000, serving clients in 175+ cities across 6 continents. For more information, please visit www.wipro.com

DO BUSINESS BETTER CONSULTING | SYSTEM INTEGRATION | BUSINESS PROCESS SERVICES

WIPRO LIMITED, DODDAKANNELLI, SARJAPUR ROAD, BANGALORE - 560 035, INDIA. TEL : +91 (80) 2844 0011, FAX : +91 (80) 2844 0256, Email: [email protected] North America Canada Brazil Mexico Argentina United Kingdom Germany France Switzerland Nordic Region Poland Austria Benelux Portugal Romania Africa Middle East India China Japan Philippines Singapore Malaysia South Korea Australia New Zealand

8

©WIPRO LIMITED 2014

IND/BRD/NOV 2014-JAN 2016