Blog

Cloud Application Integration — Why a New Approach is Needed

  • author image

The adoption of software-as-a-service (SaaS) applications has exploded in the past few years. Companies like Salesforce.com, NetSuite, Workday, Ultimate Software and Zuora, among others, have been trailblazers in their respective areas, be it CRM, ERP, HCM or billing. But the need to integrate these best-of-breed applications together, as well as with on-premises applications and databases, has not diminished as an enterprise requirement. End users of cloud applications were often initially attracted to the cloud computing model because of the promise of ease of use and rapid deployment. As both the market and overall adoption of cloud applications has matured, the need for the right data integration strategy has finally surfaced as a top business and IT imperative. Here’s why a new approach to an old problem is needed.

When it comes to cloud application adoption, before considering a new integration model, it’s important to understand the persona of the users who will need to perform the integration. Employees responsible for the deployment and maintenance of a cloud-based application tend to be cloud application administrators, business operations and analysts, not traditional IT roles. These people typically reside within the specific line-of-business (LOB) that uses the application, be it Sales, Finance, Marketing or HR and are responsible for ensuring that end users are productive and have the data they need to do their jobs effectively.

The traditional IT-based approach to integration has historically attempted to neatly segment integration practices into buckets such as data integration, application integration and process integration. Depending on the skillset and availability of IT personnel, an organization doing on-premises integration may use only one or all of the technologies that would map to each of these areas.

When it comes to cloud application integration, it’s important to determine not only who will be doing the work but also how complex the business logic is and what kinds of data exchange protocols are involved. To determine this, let’s first take a look at the primary integration technologies that are out there, and their suitability for integrating cloud applications.

Enterprise service bus technologies

Enterprise service bus (ESB) technologies make use of publish/subscribe algorithms to integrate data. Each subscriber signs up for specific topics of interest and, when an event is published into the channel, a single copy of the message is sent to each of the output channels.

The message routing can be configured to either allow or suppress certain classes of messages from being transferred or also to suppress routing of messages for topics that have no current subscribers. With any ESB architecture, message routing and mediation are important parts of the integration process. It is therefore crucial not only to know how to architect the mediation sequence to catch any error conditions but also to use the correct mediation services on the data.

When it comes to cloud application integration, even the slightest oversight in a mediation sequence can often result in critical data not making it to your SaaS system or integrations being performed out of order. And since there is no way to know whether your data was indeed integrated successfully, there is a very good chance that business process and data integrity rules get violated.

As a result, you often have to sacrifice data integrity in order to receive better performance if you plan to use these technologies to address your cloud integration requirements. The complexity of cloud application integration through an ESB only increases as the number of endpoints and number of topics increase.

Native cloud integration

With native cloud integration, the API of each application is utilized to not only access the object data but also to browse, read and write to the entire metadata layer of the objects in the application. In this manner, native integration allows users to simply map the respective source and target objects between disparate applications without having to worry about any sort of intermediary translation format (as in the application ecosystem API model), or complicated message brokering technologies.

But even in the native integration model, the individual(s) responsible for cloud integration (i.e., the application administrators) still must be able to deploy, provision and maintain the software. There is still a need to understand complex integration concepts. In essence, although the end result of having native integration may benefit these end users, they still have to go through the painful process of deployment, provisioning and maintenance, not to mention the resistance they would face from corporate IT.

Cloud Integration as a Service – the new way

Earlier I wrote the importance of understanding the persona of the user who needs to perform the integration. Cloud application administrators expect a high-degree of self-service and agility and the same holds true for cloud integration. A cloud-based approach to cloud application integration must deliver all the benefits of the native approach by reducing the deployment, provisioning, maintenance, and upgrade challenges. The right approach is a multitenant cloud integration service that offers the same ease of use and rapid deployment that a cloud application delivers.

This new way is rapidly gaining ground in enterprises of all sizes, and is keeping up with the ever-changing ways of the cloud. With the emergence of what Gartner is calling integration platform as a service (iPaaS) and more and more IT organizations embracing a “cloud-first” approach, we’re in for some very interesting technological advances in this space in the next few years!

Ashwin Viswanath is manager of platform product marketing, Informatica Cloud. He joined Informatica in 2011 and is currently helping to tell the Informatica “Hybrid IT” story. Ashwin has several years’ of product management and product marketing experience in Fortune 500 enterprise software companies such as Microsoft, Sun Microsystems and Oracle. He has deep platform experience working with technologies such as Windows Azure, Force.com, Heroku and Cloud Foundry. You can follow Ashwin on Twitter @Ash__V.

Comments

By Jack

From what I can see the Informatica Cloud is based on an orchestration of mostly autonomous on-premise agents. If the machine (hosting the agent) crashes all integration is stopped (SPOF). There is also no life cycle management for the agents as far as I can tell.
Or in other words – the Informatica Cloud is not really all that cloudy since it is basically just a cloud development environment which deploys to on-premise non-clustered agents that still need to be taken care of by enterprise personal.

Post Your Comment




Leave another comment.

In order to post a comment, you must complete the fields indicated above.

Post Your Comment Close

Thank you for your comment.

Thank you for submitting your comment, your opinion is an important part of SandHill.com

Your comment has been submitted for review and will be posted to this article as soon as it is approved.

Back to Article

News You Can Use

Register for LicensingLive! 2014

Click here for news on the Data Analytics Outsourcing market,  the 3G/4G M2M devices market as well as other news releases

 

 

 

 

 

 

 

 

Topics Related to this Article