BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
App integration has been an enterprise software pain point since the mid-1980s, when I first began covering IT. The same old problems of making disparate software work together persist, largely because proprietary interests outweigh the benefits of open standards. Also, app integration has always been an afterthought for buyers enthralled with the latest new app, and the pain of integration is continually forgotten (like the pain of childbirth, thanks to beta-endorphin).
Those two factors haven't changed in the cloud computing age, so I'm skeptical that new cloud-based integration services will get it right now. Then again, I'm also hopeful, thanks to some cloud services' integration-first tactics and sweeping changes in enterprise software team practices.
Way back in the 1980s, businesses' in-house departmental apps were often incompatible with each other. Integrating with customers' and partners' software? Forget about it. In this Tower of Babel scenario, most enterprises had a mix of apps built on different operating systems, databases, development languages, etc.
What happened next? In Utopia, software and hardware makers would have collaborated on standards, interfaces and other things that make all things computer play well together. Interoperability and integration problems would have faded away, spurring innovation and the creation of a money-making model for the innovators. Instead, proprietary packaged software was created, and a short-term near-nirvana set in for those who bought everything from one vendor.
"In two recent TechTarget surveys, application integration is the top cloud problem cited by software architects, engineers and C-level execs."
The honeymoon hangover brought package pricing hikes and suite glut. The emergence of open source operating systems(particularly Linux), and applications made vendor lock-in feel particularly onerous, as innovators created point products better than some components of software applications. Some businesses went whole-hog on open source or mixed open source and proprietary software, but they all faced integration hassles.
They still do. In two recent TechTarget surveys, application integration is the top cloud problem cited by software architects, engineers and C-level execs. In the new 2013 TechTarget Cloud Pulse Survey, many respondents said they overlooked customization and integration issues until problems arose. Yet 64% said that connecting data, applications and processes between cloud and on-premises systems is an immediate or near-term problem.
Likewise, respondents to TechTarget's Applications Survey 2012 ranked integration and customization at the top of the problem board for Software as a Service (SaaS) applications (14% each). In the Cloud Pulse survey, SaaS applications have posed integration challenges for 34% of respondents, whose programs can't interoperate with other programs from the cloud or in-house. And once again, customization was tied with integration: Even with customization, 34% of Cloud Pulse respondents said SaaS apps can be inadequate for the client's business needs.
Adding cloud apps to an enterprise app portfolio opens up that old can of worms, according to Cloud Pulse Survey respondents Saurabh Sharma, Ovum senior analyst, and CIMI Corp. cloud architect Tom Nolle. Once again, they told me, an odd mix of apps -- legacy, mobile, cloud, and so forth -- are thrown together, but in this case, they're in a dynamic resource assignment environment, the complexity of which makes integration difficult. "Things move" in the cloud, and integration of moving apps and data is hard to achieve, Nolle says.
Proprietary protectionism, an integration roadblock I've mentioned above, is upheld by most SaaS vendors, Sharma says, and the industry is unlikely to standardize on an architecture for the cloud that would make things easier. Also, Web services application program interfaces, or APIs, aren't the promised silver bullet for clear interaction between SaaS and on-premises applications. That's because on-premises apps have been developed under different standards and often need much custom-code development to interact with SaaS environments.
Even with human greed blocking standards, there are hopeful signs for progress in application integration in the cloud and on-premises:
Platform as a Service (PaaS) is helping developers build cloud-compatible apps. When asked what factors led Cloud Pulse respondents to select their PaaS providers,
- 49% said the provider was part of a cloud ecosystem that was already being planned;
- 36% said the provider supported the application development language;
- 35% noted the provider integrated with existing architecture;
- 31% noted the provider had better features or functions than other providers; and
- 25% reported developers already had experience with the PaaS platforms.
PaaS platforms are primarily used to develop and deploy cloud applications, 63% of respondents said. PaaS also plays a role in extending SaaS offerings such as SAP (43% of respondents), developing and deploying mobile applications (40%) and providing an application testing environment (36%).
Service-oriented architecture (SOA) provides a strong integration foundation in many ways, including lowering the cost of integration by exposing services that adhere to open standards. Built on a Web services paradigm, SOA apps are easy to migrate to the cloud and integrate with other Web services-based programs, and they mesh well with cloud's application-to-resource relationship model.
The move to DevOps teamwork requires developers to think about deployment strategies and IT to provide interoperability and integration context for developers.
New cloud-focused tools and services are providing some relief. These include such current application integration tools and services as Dell Boomi, the Informatica cloud integration platform, CloudSwitch integration services, IBM Cast Iron, MuleSoft and more. New tools and services are on the way. For example, Tasktop's introduction this week of Software Lifecycle Integration services promises to put integration strategy firmly in businesses' application planning as an aforethought, not an afterthought.
More app integration hope
I've seen help-wanted ads for the position of "integration architect" lately. If this is a move to having in-house integration experts, I'm all for it. Integration can't be an afterthought, if it's the core focus of a DevOps team player.
Open standards will always be the holy grail for application integration and interoperability. Until vendors work out a money-making model that incorporates open standards, however, putting some new integration tools, services and an in-house expert to work can ease, if not erase, some of the pain.
What application integration problems have you encountered? How have you approached them? Tell our site experts about your app integration experiences -- and ask them questions about your integration challenges.