Introduction
Are you an Integration Architect going ape with positioning API management and the never ending middle ware rebooting?
I think there are many good blogs explaining the differences of various products and when we have to use them but I want to look at it from the lens of a customer and an integration architect.
Let’s cut the marketing red tape and put the things in a perspective. SMACT (Social, Mobile,Analytics,Cloud,Things) is changing the "definition of the consumer and the system and an application" .
“Businesses are no longer the sole creator of a brand; it is co-created by consumers through shared experiences and defined by the results of online searches and conversations.” – Brian Solis
Definition
In theory, the term API means “Application Programming Interface”. Does that mean we are going back to point to point interfaces and kissing good bye to the ESB products and SOA for connecting up and integrating light weight applications quickly in future?
In my view, if I had the power to redefine the term API then I would define it as, “A light weightagile reverse proxy middle ware used for Any Point Integration of micro service interfaces with no clear definition of boundaries on where and how they are deployed and consumption of micro services quickly”.
Evolution
A decade back, SOA, ESB products and SOAP gained momentum for connecting up and integrating loosely coupled B2B and A2A distributed applications.The web developers still builtpoint to point UI applications for faster user response time i.e. less latency time and throughput. They avoided using SOAP services as they don’t want to hit themselves to the wall due to the performance over head of parsing the XML back and forth.
In 2016 and future, the world and definitions of the applications, integration and data is constantly changing! We have limitless integration possibilities with the driver less connected cars, drones on rampage, bionic 360 degree 3D holographic clones of Leonardo di Caprio
, IoT enabled smart cities using energy grids and cyborgs on a high speed cloud!
There was 5 exabytes of information created between the dawn of civilization through 2003, but that much information is created every 2 hours – Eric Schimdt
The Ugly Truth and Sin of the City!
As much as the world hyped SOA and open standards, I don’t think there are many organizations that replaced or service enabled their entire integration landscape using ESB products due to the skyrocketing costs and long-time scales for implementing the integration projects. It is also partially due to the lack of business interest in transforming the integration landscape as they fail to see tangible business benefits of changing some thing that worked for years.
The classic life of an IT consultant, “If you are finished changing, you are finished”!.
They instead followed a hybrid approach and used ESB products to reconnect all systems without changing the legacy interfaces and created new services using ESB products . They either designed SOAP services on top of legacy interfaces or connected with legacy systems via SOAP Services depending on the capability of the legacy systems.
The file transfers, legacy protocols, JMS messaging and EDI protocols still exists even now and is not going to go away anytime soon as many small scale entrepreneurs still use phone or fax as mechanisms for connecting up in places where there is no internet penetration. I don't think any business would shut the existing channels, but it will open up new channels and decommission the old channels when the world transitions into the next century.
Does Integration Landscape in future looklike a layered cake? When will we stop using FTP Channels, Does any one know date of expiry for file interfaces or transfers?
I think many big fortune 500 companies still use that as a fundamental mechanism for interfacing. The smaller companies and start-ups are widely using API's built using open standards to penetrate into the new markets quickly and hence if big companies don't catch up then they will surely be wiped off the fortune 500 list.
Lip Stick on the Pig!!!!
The most meaningful technological innovations cannot be applied as easily as the proverbial “lipstick on the pig” unless the business processes are completely redesigned and developed from scratch to meet the latest market requirements and specifications.
Would you redesign or repair a used dress from the scratch for 21st century after it is made and sold to the consumer unless the product is faulty?
I think the same formulae applies to the integration landscape, we aren't going to change the brittle legacy interfaces using new technology unless you are a cash rich business to pump money into the integration projects as the legacy systems might disappear in future. Instead, you dress up and mask it and expose it up to the new channels using API management tools. Ain't it?
Future Integration Wardrobe!
The fundamental questions that needs to be answered though the products are not replacing each other, When and why and where will you use API management tool? When and why and where will we use SAP PO? When will you create services and publish on UDDI repository or ESOA discovery platforms and when will you publish services on API Hub platforms?
Gold Standard to design Micro Services!
According to recent buzz and organizations embracing agile and lean working model, SOAP services will eventually fade out due to the complexity and performance overhead associated with parsing XML(s) and many organizations will go ahead with lightweight REST services until something else sweeps the world in the future.
Ideally, we should redesign the integration landscape using micro services enabled by API management where ever possible for faster penetration into different markets and channels but we all know it is not how it works in reality and big organizations.
My gold standard on when to design and publish services on API Management / API hub is:
- When the organization is designing customer facing application services that needs to be consumed by various devices
- When the new integration requirement arises for connecting up the applications on the cloud and on premise
- When the organization identifies non-confidential interfaces that can generate revenue when exposed to the wider world
- When the micro services doesn't need to transfer large volumes of data for connecting up applications
- When the integration platforms are upgraded or replaced, we should use the opportunity to perform fitness assessment on whether interfaces can be enabled as micro services using API management tool to tap new markets and channels and consumers.
- When you want to consolidate services across disparate endpoints and systems and expose it a single service to the consumers.
- When services don't need complex mapping and logic for passing data from the source to destination i.e service should be truly micro service in architecture.