Large companies today depend on their enterprise applications, such as SAP and other enterprise resource planning software, to run smoothly. Increasingly, other business units require Software as a Service or cloud-based software to do such things as update customer records in customer relationship management applications. That process usually requires converting data formats, and doing conversions manually is time-consuming and difficult.
Most enterprises turn to one of three types of connectors: SAP Web Services, vendor-supplied enterprise service buses (ESBs) and, increasingly, cloud connector and data integrator products. These products translate data to and from enterprise applications to Software as a Service (SaaS), integrating the products so the sales force can update customer records on the road, and the accounting department can have the new billing information instantly. But what works best, and in which situation?
The real difficulties in integration arise when no one understands how communication between enterprise applications and SaaS work, according to Axel Angeli, SOA evangelist at Logosworld. "The interpretation of the content is the real challenge," he said, likening integration to a discussion at the United Nations, where everybody has an opinion but nobody has a solution.
"The most common mistake is not using middleware and trying to use peer-to-peer for integration," Angeli said. "If you don't have middleware, somebody has to … code the translation, taking care of the error handling." He cited an example of searching for the state tax in California and deciding, if the server doesn't provide a reply in time, who will handle the error.
Using SAP Web Services works best when you run an SAP shop, according to experts. SAP's approach is very SAP-centric, according to Carter Lusher, chief analyst for enterprise applications ecosystem and research fellow at Ovum Ltd. "They are opening up their data and their functionality through their [application programming interface] API, but that still puts the burden on the customer to do something with that," he said.
Another expert put it more bluntly. "SAP Web Services are just Web services as devised by SAP," said Martijn Linsson, founder of We Wire People, a company specializing in application and system integration. He found Web Services insufficient for integrating enterprise applications to SaaS, and recommended that companies examine the existing IT landscape carefully before they choose an integrator.
ESBs are the most-used method of integration in SOA, and most SaaS vendors are deploying their own ESBs or providing them, said Dana Gardner, principal analyst at Interarbor Solutions LLC. Comparing cloud-based connectors with software ESBs is difficult, because ESBs are a function of both. It depends on how much is on-premises and off-premises, he said.
A new form of ESBs is the cloud-based connectors provided by vendors, including Dell Inc.'s Boomi, IBM's CastIron and MuleSoft Inc.'s Mule ESB. A practical problem that exists with integration is an explosion of software APIs, and keeping tabs on vendors' shifting APIs is costly and time-consuming. The cloud-based connectors make it easier to connect SaaS to on-site applications, according to Lusher. "That doesn't eliminate all the work [or] all the fragility, but it does go a long way to integrate enterprise applications from cloud to cloud or cloud to on-premises," he said.
According to Ross Mason, MuleSoft founder and CTO, Mule ESB lets architects connect programs like Salesforce.com to SAP in a matter of days. MuleSoft, however, isn't recommended for situations with a lot of user interface requirements, he cautioned.
When choosing an integrator, look for products that are readily supported that you can outsource for maintenance, We Wire People's Linnson said. "Other than that, you just have to go with the best product for you, which is a tough choice. … You can't choose products until you know how your systems work together and what their limitations are," he said, adding that he has seen many projects go sour because companies chose a product simply because it was growing in the market, without examining their IT needs.
In addition, look for a connector flexible enough to do what you need it to do against the API, said Rick Nucci, Boomi's general manager. The resiliency to recover from network failures or packet loss also is important, as is error handling, he said."The connector should do a good job at telling you, 'Here's why I failed to send the message, here's the message I got back from the application, and here's what we suggest you do to go about fixing it,'" he added.
Boomi would not work for enterprises that need to do on-premises extract, transform and load (ETL) in the magnitude of terabytes per hour, Nucci said. "That type of volume you'll see in ETL providers that have been doing that a long time and are very good. Boomi is not an optimal solution [because of] the volume of data," he said.
Finally, look for vendors that have a proven track record, Interarbor Solutions' Gardner said. "There's a sense that an organization like SAP is in this for the long haul, and the cloud providers they work with are involved in long-term strategic decisions," he said. This translates into partners that will be around for a while.
"Implementations are not just something you pick up and move somewhere. They are investments that you'll want to be able to get a return on for a long period of time. 'Fly by night' and integrations don't make too much sense together," Gardner said.
This was first published in August 2012