While it is true that integrating best of breed SaaS solutions can be problematic, the conventional belief that SOA, Webservices, pre-integrated adaptors, or even specialize middleware frameworks can solve the wide array of integration challenges is often not as true. So, knowing which side the problem is on make life a whole lot easier when integrating SaaS into on premise solutions.
But before we dive into that, lets go back a bit to compare and contrast a modern integration strategy with its counter part from the 1990s: SOA and CORBA. The question we want to briefly explore is, “Why did SOA succeed where CORBA did not?” Both are an integration strategy built on various types of services. Both are designed for highly distributed systems. Both have some level of message based payload used to transmit key process content. Yet, CORBA never really got off the ground and has virtually died, while SOA is being adopted at a wildfire pace. Why?
A significant part of the answer can be found in the fact that SOA is, for the most part, based on a set of standards. Take web services (as subset of SOA), for example, the transmission protocol is http, the data payload is xml wrapped in SOAP, the service contract is defined through WSDL, and services can be found through UDDI. All standards that have helped neutralize vendor variability often seen in technology driven phenomenon. CORBA, as good or bad as it was, never had this level of standards support or adoption.We now face a similar pivotal challenge with it comes to SaaS business process integration.
The real business value in most systems is not in its 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. Here lays the crux of the problem – services are not business processes and it is the business process that needs integration. Translation – “it’s the process stupid, not the service.”
Services development has been the focus of most, if not all, of the most activity surrounding modern integration activities. They are easily developed and can be readily exposed (through SOA, WS, API, etc.), but our ability to integrate business processes has largely not been addressed, with one exception – BPEL (Business Process Execution Language). Without a strong process integration standard that is widely adopted, like BPEL, integration between best of breed SaaS solutions and enterprise application will continue to be problematic and failure to achieve real business value will most likely be placed at SaaS’s doorstep.
So, you don’t think it can happen to you! Take the case of a large ERP (independent software vendor) company that develops ERP systems (e.g., financial aid, student admin, etc.) for the higher education community. They created a SaaS solution based on the main financial aide product line and exposed the services that composed their proprietary financial aide process as web services. One university used those discrete services to integrate the SaaS offering with their on premise systems, applying their own financial aide business process rules instead of those within the SaaS financial aide system. The resulting loan package was invalidate even though each used service was properly used (technically called – service transitivity). It took a while to figure out and was eventually corrected, but the down time cause a lot of client dissatisfaction and necessary support costs.
So, when dealing with the integration of SaaS to other enterprise solutions (on premise or otherwise), pay more attention to the interaction of the business processes than those of just the services. SOA, Webservices, pre-integrated adaptors, and even specialize 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. Spend equal time and effort in dealing with your business processes (e.g., BPEL) so that true business value can be sustained even when using best of breed SaaS solutions.
Read Full Post »
