Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

iPaaS: A new approach to cloud Integration

Craig Stewart, Senior Director of Product Management, SnapLogic | April 1, 2015
Comparing "Integration Platform As a Service" to legacy approaches to cloud and data integration, such as traditional ESB systems

This vendor-written piece has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favour the submitter's approach.

Application integration has often been an exercise in frustration long delays, high costs and over promises by vendors. How many ERP projects have you heard of that were canceled or shelved due to complex customization and integration challenges?

Integration though, is coming to a new place. Cloud technologies and open APIs are helping enterprises merge on-premise and off-premise systems without considerable coding and re-architecting. Instead of requiring specialists in SOA, enterprise service bus (ESB), extract transform and load (ETL) and data warehousing, organizations are hoping the concept of Integration Platform as a Service (iPaaS) can be used to integrate systems in half the time using technically-savvy generalists and increased involvement from lines of business.

As defined by Gartner, Forrester, Ovum and other analyst firms, iPaaS represents a new approach for enterprise IT organizations that are undergoing a rapid transition to the cloud and have big data plans.

Behind the move to more flexible, cloud integration platforms are two core trends: "cloudification," the race to transform organizations to cloud-based architectures; and the need for agility, as business users expectations' for rapid delivery of new web, social and mobile services continue to grow.

In our recent TechValidate survey we asked about the drivers for adopting a cloud integration platform and the top response was "speed and time to value." Respondents also took issue with legacy, on-premises tools to address cloud integration requirements, with 43% noting the high expense of hardware and software purchases and configurations. More than a third (35%) said change management is painful in legacy tools where end point changes mean integration re-work.

Let's look at the legacy approaches to the problem:

* The Enterprise Service Bus:  ESB is a middleware architecture that was designed to manage access to applications and services and present a single and consistent interface to end-users. ESB incorporates the features required to implement a service-oriented architecture (SOA), and was appealing to enterprise IT organizations struggling with constantly changing application versions and upgrades.

"Loose coupling" would introduce much more flexibility to application lifecycle management, it was the thought. Unfortunately for most, implementing the SOA and ESB vision was too expensive and unwieldy. IT organizations needed to install three environments (development, test and production), leading to delays.

Secondly, ESBs were not very flexible in managing change, such as adding a new field to an end point, because of the inflexible underlying technologies. Thirdly, ESB projects required high-priced specialized integration experts. As a result, many IT organizations have continued to use the same old point-to-point enterprise application integration (EAI) methods of the past, which does not bode well for integrating the more dynamic cloud applications businesses now prefer, such as Salesforce and Workday.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.