Could BPEL be the missing key to solving SaaS integration problems?
Dr. Jerry A. Smith seems to think so.
Smith is the chief technology officer at Symphony Services. In a recent blog post, Smith takes to task the "conventional belief that SOA, Web Services, pre-integrated adaptors, or even specialized middleware frameworks can solve the wide array of integration challenges" of SaaS and on-site applications.
BPEL stands for Business Process Execution Language, an OASIS Web services standard. It tends to be discussed more among business process management circles than in the context of integration these days -- or at least, that's my perception and that's why I was interested in his thesis.
Smith's argument is a bit meandering, but his basic point is this: Integration of SaaS needs to happen at the business process level. The usual integration suspects -- SOA, Web services, middelware and EAI -- are important and certainly have a role to play, but they focus on integrating discrete services and, therefore, aren't enough.
In short, you can integrate the services and still not get the business results you want.
He contends we need a standards-based approach to SaaS integration and he believes BPEL offers that. He writes:
"The real business value in most systems is not in ... discrete services, but in the choreography of the services to support business value generation. Think about it, is there real business value in submitting an expense to an expense report service? No. The value is having an expense process solution that incorporates all end user interactions while applying company-specific business rules."
As an example of the kind of unforeseen business process problems you can have integrating SaaS, he points to an ERP company that created an SaaS offering and "exposed the services that composed their proprietary financial aide process as Web services." One university connected to them, but applied their own business rules to the financial aid process. The individual services were used properly, but the business process failed because the loan packages were invalidated.
He didn't say which ERP company or which university. The incident didn't ring a bell, so I did a quick search. I did find a similar incident at the University of Indiana -- in 2004. I'm unsure, however, if this was a SaaS deployment. A school spokesperson attributed most of the problems to "interface issues between the PeopleSoft application and the loan systems at lending institutions." (University ERP deployments are somewhat notorious, it turns out.)
Regardless, there's no question SaaS integration problems do exist. Just this past February, Dennis Hall, the director of Business Development at Pervasive Software, wrote about an SaaS conference where almost everyone complained of integration pain.
All of this angst is creating a new market of solutions to solve the SaaS integration problem. Heck, there's even an appliance now.
But Smith urges IT to add business process to the SaaS integration checklist:
"...pay more attention to the interaction of the business processes than those of just the services. SOA, Webservices, pre-integrated adaptors, and even specialized middleware frameworks play a very important role in solving the SaaS to enterprise integration puzzle, but they only get you part of the way there."