Ground to Cloud – some SaaS integration considerations
Integrating Software as a Service (SaaS) offerings into your IT landscape is similar to integrating local “on premise” applications in many ways, especially if Web Services are your main information exchange technology. But in many other ways, it’s different. Obviously you have the “insecure internet” in between. Extending your enterprise wide master data and authorization management to external applications is a challenge. And you have less control about the remote packaged application, for example you cannot directly access its file system or its underlying database (which isn’t a good integration approach after all, but can be useful for things like monitoring).
Oracle released a whitepaper about integration SaaS (“Cloud-based”) applications. They ask if we need to reinvent the wheel after having moved “from CORBA to Client/Server to Web services, EAI and SOA”. Of course, their answer is no, if you use Oracle Fusion Middleware products. I agree that a middleware layer capable of accessing heterogeneous systems, validating, enriching, transforming and routing messages, orchestrating processes, as well as monitoring and securing your whole IT landscape is a key component. The Oracle paper assumes that “most cloud applications support Web Services”. While this is true, I recommend carefully examining the extent of this support. Given your functional requirements, look at the APIs very closely. If it enables you to do everything you can do using the UI, plus bulk data import and export, you are probably fine.
For nonfunctional requirements, like monitoring, transactions, and security, things are a bit more complicated. For example, if the cloud application employs its own user management, you might have to replicate the user accounts from your company’s master system to the cloud app and make sure the “cloud copies” are not modified in an inappropriate way. Modern SaaS offerings might support SAML or OAuth, but don’t bet on it. When considering a cloud application vendor, I recommend scrutinizing the following points (this is a short summary of an evaluation catalog I developed for a client a couple of months ago):
- Protocols, APIs, and data formats (considering versioning strategies and documentation)
- Authentication Management (users, groups, replication or assertion propagation? Support for Single-Sign-On, SAML, OAuth etc.)
- Authorization (granularity, support for XACML?)
- Backup / bulk data exchange
- Master data management (replication/synchronization)
- Staging (including data and configuration migration between stages)
- Supported SLA types and their enforcement, Monitoring capabilities
Picture: Mount Pilatus. Taken March 2012 from a ship on Lake Lucerne.