Leveraging SOA Principles for API Adoption
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
ROI to name a few. success stories
SOA at peak – SOA
Governance, Registry Concepts of pragmatic
implementations SOA emerges; preference
for reducing overheads
However, more than a decade after SOA’s
Agile and Iterative
introduction, many organizations have failed to programmes
Focus on CoEs and challenges SOA focus
leverage or showcase the expected benefits and Shared services
return on investments. This has resulted in fading Mobile and API
revolution shifts focus
confidence and support for SOA initiatives. to light weight, agile
Initial
implementations implementations
2000+ 2015
Some of the key reasons behind this unexpected twist in tale are availability
of SOA experts for end-to-end implementation, Overload of SOA Figure 1 - Traditional SOA demand over the years
processes, failure to report benefits on a consistent manner etc.
2Availability 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 The challenges faced by SOA are more attributed to the
convincing the stakeholders and initiating the SOA program. But majority
faulty implementation or the changing dynamics of
of the initiatives were not able to enable an effective mechanism to
environment and nothing to do with SOA principles which
continuously report benefits back to the stakeholders. Along with the SOA
overload mentioned earlier, lack of view on benefits caused business 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
With the huge urge to expose APIs, are we creating more
quick changes.
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.
3Checkpoints
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
With this scenario, there is a strong reason that APIs “may” get modeled by
concept of HATEOAS (Hypermedia as the engine of application state)
the channels and there are possibilities of emergence of channel-specific
that enables the continued interaction of resources. Alternate models like
APIs. API management support the concept of bundling to create Apps
Pragmatic REST are also being applied.
specific to channels; however care must be taken to have granular APIs that
Many developers who are enabling APIs have come from SOAP-based 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
Many new API implementations are considering taking the step of
translation from SOAP implementation in JSON format instead of true
bypassing the ESB layer itself. Though it makes sense for simple mediation
RESTful services.
and data interfacing type of interactions, we do need to consider larger
perspective for complex scenarios like orchestration, store and forward,
Lack of Time for Design
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
instead of complete transformation to 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 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.
4Leveraging 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
Utilizing SOA principles, lend the required stability for API
Request/Reply-based invocations as default implementation.
implementations. Hence effective approach will be to take the best of
Considering the expected scale of API invocations, it is extremely both to ensure the right implementation.
important to manage statelessness and light weighted implementation
Figure 2 gives a view on some additional dimensions of implementation
in-order to ensure limited impact to overall infrastructure. To ensure
and proposal to adopt best of both worlds.
this, APIs may need to consider alternate paradigms like deferrals,
publish subscribe, delegation models, if applicable.
5API World Proposed
Traditional SOA (current) (best in the world)
Stream-lined process Inbuilt governance mechanism Derive best practices and form a
Governance
methodologies and Governance in API Management products light weight Governance model
Derive best practices and
Well-defined templates, Limited standards followed
Standardization define basic standard like
guidelines and best practices being an emerging area
naming standard
Model Complex and Time Continue Simple and Light
Simple and Light weight models
consuming (CDMs, SOAP, weight models supported
Management XML, Shared models)
adopted(e, JSON)
by basic standard
Continue light weight
High level of process and Light weight documentation (eg.
Documentation documentation approach.
technical documentation Swagger, RAML etc.)
Ensure proper documentation
Approach to be adopted
Smaller impact as the Larger impact as APIs are mainly
Change Impact ensuring the right design at
consumers are mostly internal exposed to external world
first time
High, due to complex models Low, due to simple models and
Time-to-market Continue the simple model
and process light weight standards
Design and Normally stable, reliable and
Less time available for detailed Define and leverage design
scalable as sufficient time is
Implementation design pattern, checklists and standard
provided for design
Monitoring & Utilize the inbuilt
Custom built Inbuilt in most of the tools capabilities and extend to
Management
higher degree of analytics.
Security Define clear checklist and
Well established as mostly New models like QAUTH
approach for security along with
Implementation used within the enterprise supported by tool
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.
6Conclusion
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
7About 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 2016You can also read
