www.wipro.com Leveraging SOA Principles for API Adoption

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 07 Leveraging SOA Best Practice for API Implementations 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 ROI to name a few. However, more than a decade after SOA s introduction, many organizations have failed to leverage or showcase the expected benefits and return on investments. This has resulted in fading confidence and support for SOA initiatives. SOA at peak SOA Governance, Registry implementations Focus on CoEs and Shared services Initial implementations Stable phase, SOA success stories 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 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. 2000+ 2015 Figure 1 - Traditional SOA demand over the years 2

Availability of SOA Experts and Evangelists Technical Impediments Majority of SOA initiatives heavily depended on external consultants from consulting firms. They championed the initiatives by building a case for SOA adoption, evangelizing the business benefits to the business stakeholders, defining SOA Adoption Roadmap, defining SOA CoE and governance for project delivery, to name a few. However, once the SOA specialists moved off, the responsibility of governing, the processes was left to the existing teams. Without the right direction and expertise, the initiatives lost direction. Though it was not a mandatory requirement or a SOA principle, the default model used by a majority of SOA initiatives was SOAP and WS standards. Unfortunately the schema models focused on elaborate structures increasing the payload size and modeling complexity. End result was highly cumbersome and complex, and low flexible modeling and versioning scenarios added to project delays and complexity. SOA Overload Popularity of Agile Implementation As indicated earlier, many SOA initiatives were driven by external consultants and in some cases, SOA enablement started running as the main charter instead of enabling business benefits. An overload of SOA governance, processes, approvals and tight binding contracts caused increase in cost and more importantly time delays in project. Soon SOA started gaining detractors especially in project execution and business teams. Due to increased need for faster turnaround times, an increasing number of organizations have started preferring an iterative or agile model over the traditional waterfall model. Due to shortened cycles for architecture and design, the whole SOA objective of designing enterprise wide services, ensuring right service granularity and enabling service reusability became 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 stakeholders to reduce funding for SOA initiatives. 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. 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. Organizations are having developer portals enabled and APIs exposed. A number of API vendors like Layer 7, APIgee, Mashery and traditional players like IBM, TIBCO, Software AG, Oracle, SOA Software are battling it out for the customer space. But what we may be seeing with APIs could be a reverse end of SOA adoption. While SOA was blamed for it s over-governance and control, APIs could easily fall into issue of lack of it. With the huge urge to expose APIs, are we creating more challenges in future? Instead of overload of processes in case of SOA, are we possibly facing a proliferation of unmanaged APIs? Those organizations that are ahead on technology adoption are aware and have already taken steps to adopt the best practices for API implementation. It is worthwhile to look at some of the pitfalls that need to be handled for a good API implementation. 3

Checkpoints It is important to ensure that API adoption is not restricted only to enable mobility or security enforcement, but should consider the long-term view on flexibility and maintainability of the implementation. The following points discuss some pitfalls that might be encountered during API adoption and recommendations to address those. Understanding Resource Orientation Channel Driven APIs Representational State Transfer (REST) is an architectural style that is based on and well-aligned to web fundamentals. Though REST has been in use for many years, the prominence of Mobile and e-commerce revolution has given a new level of prominence to REST and JSON. Coding in REST 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 implementation background. Moving to REST is not just changing the protocol and format. 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 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 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 we following right URL structure, status codes and naming standards? Since many of APIs are exposed to external world, it becomes even more important to do it right the first time. Design considerations applied at the beginning will help achieve more stable implementations. Change Management Challenges 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. SOA strongly propagated the need for clear segregation of presentation layer from services layer for enabling loose coupling. In case of APIs, the very nature of the requirement requires a close interaction with channels and is supported by many products in this space. 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. Vanishing ESB 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 instead of complete transformation to APIs. While there is an urgent need to onboard and be API-enabled, we need to be wary of the adoption pitfalls related to this. These issues can be avoided by taking few simple steps that provide stability to the journey. Organizations that are leading the API adoption are clear on the objective and adoption and are taking the right measures to achieve the flexibility and business benefits of APIs. 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 are relevant for consumers to effectively use the API and hide the intricacies like the information provider, implementation details and technology used. With this, it provides the API owner the liberty of changing the implementation without impacting consumer. API design needs to consider abstraction as one of the key consideration at the design stage itself. Given the current surge on API adoption and the immediate need for API enablement, one of the major challenges that would be faced by organizations in immediate future will be to prevent the proliferation and ensure maintainability of the APIs. Since majority of APIs are driven by consumer need at the moment, reusability and prevention of proliferation will be the focus areas in immediate future, when it gets adopted at a larger level. Statelessness Discoverability One of the prominent usages of APIs is to provide proxy functions for accessing the core underlying information. The performance of the overall interactions largely depends on the provider service and 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, publish subscribe, delegation models, if applicable. The discoverability and documentation becomes even more critical in case of APIs. APIs needs to be supplemented with communicative metadata by which they can be effectively discovered and interpreted. 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. 5

Traditional SOA API World (current) Proposed (best in the world) Governance Stream-lined process methodologies and Governance Inbuilt governance mechanism in API Management products Derive best practices and form a light weight Governance model Standardization 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 Monitoring & Management Custom built Inbuilt in most of the tools Utilize the inbuilt capabilities and extend to higher degree of analytics. Security Implementation 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 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 manoj.santhakumar@wipro.com 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: info@wipro.com 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