Enterprise SaaS Customers: Are You Ready for the Two Headed Monster?

I have been pondering about the technical implications of SaaS for the enterprise. So far, I think the high order bit boils down to two things: integration and application composition of on-premise and in-the-cloud services.

The integration and composite application mantra is by no means new pursuance instigated by enterprises adopting SaaS. What’s important to note is that while enterprises are wondering about whether to outsource IT services to SaaS providers, they must think beyond cost savings and keep in mind the other requirements imposed by the need to have an enterprise IT that will work as seamlessly together as possible.

This figure below should make clearer the relationships between integration, composite applications, SaaS and on-premise software services:

Composite application is where business functions and information can be effectively integrated for the end users. The business benefits of a well designed composite application are many, including reduced redundant data entry, better human collaboration, heighten awareness of outstanding tasks and their statuses, and improved visibility of inter-related business information. The technical capabilities needed to assemble composite applications include human workflow and rules engine to drive the more complicated user task sequences, entity aggregation framework for integrating and synthesizing data from multiple sources, an eventing/publish and subscribe mechanism that allows the user to monitor for current business activities and information. More advanced composite applications will also have offline and caching capability which allow the users to be productive when not connected to the network.

As enterprises extend their service-oriented IT boundary to embrace on-premise and in-the-cloud SaaS services, the design of composite applications will have to factor in the information and events that are available from both in house and outsourced systems in order to provide for the high fidelity application user experience.

The data integration layer shown in the figure helps insulate composite applications from the burden of sourcing data from on-premise and in-the-cloud systems. Many enterprises have already implemented integration solutions using much hyped ESB technologies and the like. So, from the technology challenges perspective, the solutions to integrate with SaaS providers are not all new. Most existing integration brokers that perform message transformation and content-based routing functions can be similarly applied to integrate with SaaS providers. What is now elevated is the need for better architecture and IT governance as there is less control over how the SaaS provider is implementing their software services. This is exactly where SOA practices can help enterprise lay the foundation for migrating on premise services to the cloud. Instead of focusing on implementation details, enterprise IT should focus on the “what” that they are getting from SaaS providers, including having contractual understanding of agreed upon service levels, integration points and violation actions.

I have come across a few common SaaS integration scenarios that are listed here:

- Bootstrapping data at the SaaS provider from one or multiple existing on-premise systems.

- Importing data from the SaaS provider back to on-premise systems. For instance, importing HR data from the SaaS provider to the in house ERP system.

- Exporting data to the SaaS provider from on-premise systems. For example, exporting product catalog information from an in house product system to an external CRM system.

- Identity systems integration to facilitate single sign-on and reuse existing access control policies.

Because of these integration requirements, enterprises should look beyond SaaS solutions that are tightly coupled with a user interface. It is essential to test drive SaaS providers for integration hooks like programmable interfaces or messaging endpoints to enable the integration scenarios. Furthermore, as line-of-business applications commonly process long running transactions, it may also be necessary to look for SaaS provider interfaces that understand how to handle asynchronous application requests. Similarly, enterprises may also need to consider exposing callback interfaces that are visible through the corporate firewalls so that processing results at the SaaS provider can be sent back and correlated with the original application request.

I had figuratively described before the SaaS ISV architecture challenges as the three headed monster of scalability, configurability and multi-tenant efficiency. I’m hereby declaring integration and application composition architecture concerns as the two headed monster that haunts every enterprise SaaS customer.