Fundamentally, as companies increasingly adopt more and more SaaS/Cloud based applications, as more and more data are cloud-based, and as social networking data becomes increasingly critical to sales, marketing and customer satisfaction applications, the "old style" integration stacks that were originally created to run on PCs or Servers will be a less than optimal solution.
This is the normal evolution of things. The mainframe-centric nature of computing gave way to Client/Server which in turn gave way to Internet and then SaaS/Cloud.
Just like Mainframe-based applications could never really be retrofitted to be good client/server applications, or how non-relational databases never really worked well with SQL front-ends slapped on, Older architectures (Server or LAN-based application integration suites) can't simply been retrofitted or wrappered to become sky-based.
As I mentioned yesterday:
As the nature of applications and data change, so must the nature of the integration suites that bring them all together.The EDI hub from 1990 isn't going to provide the right architecture for this. The B2B or EAI server from 2001 can't do this. The nature of the problem has changed.
I'm not saying that every bit of "old style" integration technology needs to be thrown out. A lot of the technologies are similar. But the changing nature of data, applications and integration is significant enough to drive important changes in the integration suites that bring all this data together. Especially for those organizations who plan on (or already have) a lot of Cloud/SaaS-based data.
The Locus of Integration
Apart from the things that I've already mentioned, there is one more important thing that older architectures aren't adept at handling: the changing locus of integration.
Many years ago, the locus, or "center of effort" for integration was the mainframe. Simply because every application and every bit of data were mainframe-based.
In the 1990's and early 2000's when many integration stacks were first built, the locus of integration moved to "the data center", as applications were mostly distributed on servers based in the data center, and connected via the LAN/WAN".
As an increasing number of applications and data silos are sky (i.e. Cloud and/or SaaS) based, the locus of integration is shifting closer and closer to the sky. For many organizations, this locus is ALREADY closer to the Cloud than it is to the data center.
At the point where the locus of integration becomes closer to the sky than the ground, it makes sense to consider moving the ACT of integration itself (i.e. the Integration hub) into the Cloud.
So, one key aspect of Integration for 2011 and beyond is the ability to support the changing locus of integration by supporting data center-centric, cloud-centric or hybrid modes of integration - by having an integration platform that can be ground-based or sky-based - SEEMLESSLY.
Anyone can take a COBOL program from 1975 and somehow make it work on Amazon's Cloud. I'm not talking about that. I'm talking about a modern event-based, services-based integration architecture - based on (not just supporting) approaches such as REST or SOAP. With modern tools for development, configuration and deployment. So that the experience for the end-user is 99% the same regardless of WHERE the integration solution is deployed. Think "Google Docs" not "Microsoft Office circa 2001". Not wrappered or faked, but native.
For those companies whose future is heavily based on SaaS and Cloud platforms, a truly Cloud-capable integration platform simply makes sense.
Cloud-based Integration for Cloud-based Applications
Thus, it comes as no surprise that 95% of respondents plan to implement Cloud-based integration. Over 40% of respondents indicated that Cloud-based integration will be part of their future within 2 years.
I was personally a bit baffled by 5% stating that Cloud-based integration would "Never" be implemented at their organizations. I suspect (although do not know) that those organizations have certain characteristics that do not lend themselves to the movement of sensitive data outside carefully protected boundaries. Or, as David Linthicum pointed out recently, organizations such as the Federal Government - who, although they acknowledge the cost savings of Cloud over time, they lack the seed capital to make the move "right now".
Conclusion and Recommendations
It's clear that the very nature of applications and data - where they reside, what forms they are in, how and by whom they are used, how often they change, etc. is in a state of rapid transformation.
The very nature of application and data integration needs to change at an architectural level in order to accommodate the corresponding architectural-level shift in applications and data. To date, many of the traditional application integration technologies have failed (in varying degrees) to rise to that challenge. Their older LAN or Server-based architectures will leave them increasingly at a competitive disadvantage.
It would behoove those choosing Cloud-based integration solutions to be careful in choosing Cloud-based integration platforms to make sure that they're getting the real deal. Otherwise, they may find themselves giving answers like "cost too much", "took too long", "wasn't flexible enough" in some future market research survey.
This leads me to one item of the study, which presented some interesting data on cost concerns related to integration. I'm going to save commentary on that for a posting next week. "Cost" is a favorite concern of mine, and I feel it deserves its own article.
Note: The data referred to in this article come from "2011 Application Connection Priorities a research report by GatePoint Research.
_
Leave a comment