APIs are becoming the mainstream approach for exposing Enterprise capabilities and data to external world. In fact, in most of the scenarios, APIs are seen as the natural extension of Enterprise Business Services delivered through SOA. For example, a Mortgage calculation functionality delivered through SOA as a Business Service can be made available to internal Branch and Call Center applications as reusable asset, and at the same time it can be extended further in API domain as RESTful API to digital channels like internal home loan mobile app and partner mobile app. SOA and APIs have synergy and they co-exist.
In SOA paradigm, application functionalities and data take the form of Business Services; in extended digital ecosystem they are shaping into APIs. Having said that, not each and every Business Service will be candidate for API, there should be proper assessment to decide what Enterprise functionalities and data are candidate for APIs.
SOA-ESB layer is the building block for API Management Platform. Organizations having right integration-SOA foundation are better placed to deal with fast paced API economy.
APIs are made operational and hosted on API Platform, usually known as API Gateway. The diagram below shows the API Gateway as a glue between API Consumers (Enterprise channels, Partner and Third Party apps) and API Provider. Diagram also depicts the alignment of API Gateway with SOA-ESB platform and underlying applications.
When it comes to realizing this vision of APIs, RESTful integration style plays key role as shown in the diagram. Role of REST based architecture will be discussed in a separate article “Lightweight and Affordable Integration Style”
The table below highlights the role of SOA and API in Enterprise from various aspects.
SOA is primarily a reusability strategy of application’s functionality and data.
APIs are primarily a channels and digital strategy of delivering services through mobile apps and web apps.
SOA architecture brings Business agility by means of shorter time to market for new business processes and products within Enterprise domain.
API model crosses Enterprise boundary and opens up new revenue channels by means of collaborative offerings and optimal customer engagement.
SOA is practiced primarily in application integration and middleware domain within Enterprise.
APIs are primarily targeted for Enterprise channels and Business-to-Business integration domain.
SOA layer exposes Enterprise capabilities as Business Services (functional and data services) that have reuse potential across multiple business processes and channels.
Exposes Enterprise capabilities as APIs that are candidate for collaborative offerings and that are more relevant for usage in mobile and web apps (Enterprise’s own apps as well as partner-third party apps).
SOA integration style based on SOAP is relatively complex and time consuming.
API model is typically based on lightweight integration style to facilitate quick collaboration as required by partners/third parties. Widely used style is REST.
Involves exchange of well-defined and structured data format (SOAP messages) between Service Consumer and Service Provider.
Involves exchange of lightweight data format between API Consumer and API Provider. Widely used format is JSON.
|Service Description Language:|
SOA works on strictly defined contracts between Service Consumer and Service Provider. WSDL is used to describe Business Services.
|Service Description Language:
This area is still maturing and there are couple of active open source initiative in this space promoting JSON schema or RAML (RESTful API Modeling Language) for describing RESTful APIs.
Security standards in SOA space are different due to varied security requirements of application integration (SAML, WS-Security standards)
APIs are secured with different security model. Fine-grained access control are enabled at API level. (OAuth/XACML).
SOA needs strong governance as it is not easy to identify appropriate reusable assets and design them for optimal reusability.
APIs need less governance and capabilities can be quickly exposed with less overhead of governance.
Functional Services: Credit Check, Funds Transfer, ATP Check, Credit Score, Insurance Premium Calculation etc.
Data Services: Account Details, Card Details, Customer Profile, Bill Details, Lending Rate, Product Catalogue etc.
Public APIs – Insurance Premium Calculation, Product Catalogue, Lending Rate, Purchase Order etc. (these will be used by external apps as well as internal apps)
Private APIs – Account Details, Card Details, Credit Check, Funds Transfer etc.
So in a nut shell, these 2 platforms – API Platform and ESB-Service Platform on the top of back-end Business applications will enable reach of Enterprise services-data to digital world while retaining internal reusability paradigm. In some use cases, APIs can be enabled directly from back-end functionality/data (without involvement of SOA-ESB layer).
Data services (information reusability) have a huge potential in SOA space, they will have even bigger scope and potential in API based digital model. Sharing information in digital world and allowing channel partners to access data on demand creates a strong base for collaborative offerings.
Please refer to ‘Publication Schedule’ page for upcoming articles.
Please note that the articles in this portal discusses API examples from the perspective of mainstream business segments like Telecom, Banking, Retail, Manufacturing etc.