With the shift towards hybrid cloud architecture and the exponential growth of mobile applications it is essential to establish an integration strategy that supports new computing models that include on-premises, cloud and mobility.
Legacy middleware has a monolithic architecture, proprietary components, complex operating environments and expensive licensing. A dated integration style greatly slows mobile development by forcing integration through specialized software and staff.
A modern integration architecture consists of the following features:
- Metered or subscription based pricing
- Integration flows that connect applications residing in the cloud and on-premises
- Native cloud deployment without installing and managing integration hardware
- Cloud features such as multitenancy, elasticity and self-provisioning
- API developer self-service for rapid mobile and responsive web development
- A lightweight services framework to create APIs natively within application components in a microservices style
- A DevOps style build and deploy
A modern architecture of integration has the following benefits:
- Faster innovation and time-to-value due to improved developer productivity and DevOps style infrastructure management
- Lighter weight architecture that can be deployed across platforms including cloud and mobile
- Lower cost and risk with the acquisition cost a fraction of proprietary software.
While many legacy ESB vendors now support cloud features they remain expensive and cumbersome in cloud deployments. Also, the legacy integration style of using monolithic enterprise application adapters is dated and costly when compared to API integration. Therefore, cost and technical factors lead to the need to migrate legacy integrations to a modern integration platform. Since these legacy integrations are mission critical and integration key to future success, it is necessary to take proven approach to migration that reduces costs and risk including the following steps:
- Assessment and business case
- Training / knowledge transfer
- Architecture and standards
- Development
- Testing
- Deployment and management
The post is an excerpt from the white paper Steps to Migrate from Legacy Integration Software and part of Perficient’s integration migration guidebook. Please fill out the form below to download and contact Perficient for more details.
Hi Eric,
I just read your article on Unplug your ESB and I was looking for the reason for that statement. First thing what I felt is that you thought about to address two different problem statements i.e legacy integration and API management , using ESB technology and for which you are suggesting that fast growing mobile and App world cannot be fit with pace of conventional ESB integration architecture.
Based on my understanding mobile which relies more on API’s can be achived on ESB but the runtime governace like metering, rate limiting etc is the job more of a API managment platform like APIgee, Layer7 , mulesoft etc.
ESB still has its own world for heavy lifting and legacy integration which I believe cannot be unplugged . Multi-tenancy , Self provisioning are not related or anything to do with conventional integration and cannot be applied for business cases which require a centralized middleware or integration system.
I totally agree with your point that cloud based integration model is cheap in perspective of maintenance and other supporting features.
Regards
Arun
Hello,
is it possible to get the “Steps to Migrate from Legacy Integration Software” whitepaper?
Best regrads,
Dirk Broens
The real 2 questions are:
Why you need ESB in a well defined SOA environment?
Why you need ESB if you have all new technology that supports integration out-of-box?
I wrote this a few years ago on when to use an ESB. A lot has changed but still best practice on when one actually needs an ESB. http://it.toolbox.com/blogs/the-soa-blog/how-to-use-esbs-for-soa-26280