How to provide SaaS integration with enterprise systems (from the SaaS provider perspective)?

Question

I'm doing some general research for a potential SaaS project. The solution we are considering creating will need data integration capabilities with various enterprise systems.

I understand that SaaS adds complexity to enterprise integration since it lives in the cloud and outside of the firewall.

I've read a few articles that describe approaches for enterprises to integrate data with SaaS solutions. Integration approaches range from the primitive FTP transfers, custom point to point integration, to a vast and growing range of commercial solutions (appliance, cloud-based, and EAI).

These articles are focused on the customer perspective. In other words they are intended to help enterprises better understand their options for integrating with SaaS providers.

Can anyone provide some insight and advice from the SaaS provider perspective when it comes to making their solution as easily integratable as possible?

I assume the SaaS provider needs to create and publish web services API's and RESTful interfaces. Any other advice or resources would be most appreciated.

PS: I realize saying "need to integrate with various enterprise systems" is incredibly vague.

Answer 1

There are generally two big pieces to the "integrating with enterprise services" puzzle: single-sign on and data.

SSO can be the easier piece, depending on what the client institution has in place.

For instance: I work at a large institution with strict SSO requirements. We have an OpenID provider in place for authenticating to our SaaS vendors, and OAuth is in the works. If your customers can do one of these identity services, that takes one issue out of the way.

Data integration can get much, much hairier. Especially with hospitals and universities (due to HIPAA and FERPA compliance), data security is often a reason SaaS offerings are rejected in favor of on-site solutions, whether COTS or in-house developed. Although you could just provide a REST API and let the client handle their end of the data, the best way I've seen this done is to have some sort of agent software that lives inside the firewall and communicates with the cloud application over TLS.

Even in this case, however, it often requires heavy customization on a per-client basis, so if integration with client data is necessary, you will either need to provide consulting services, or have clients with an extremely skilled and competent technical staff. Probably both.

The advantage of this approach, however, is that it allows you to keep your API consistent, on both the server and client side, and to always design to an interface rather than an implementation.

My main advice is to keep anything intended to run on client hardware for integration as platform-independent and database-agnostic as possible. There's nothing worse than telling a Unix shop you require Windows Server, or a Microsoft shop you require RHEL.

Answer 2

Jason Lewis is spot-on regarding the two significant issues of single sign on (or user management issues) and data integration.

+1 for ...heavy customization on a per-client basis. Depending on what you are offering, your integration options will vary dramatically between clients, and often even between departments at a single client. I'm at a SaaS vendor, and we see completely different requirements from the clients' side on integration: "Give me a web form where I can manually upload our data export." or "Dedicated circuit to your facility, please." or redundant automatically verified PGP-encrypted SFTP transfers. (Yes, a lot of our integration is simply batch transfers.)

If a customer is considering a SaaS solution, then they are open to outsourcing, and they may have outsourced other key bits of their IT, often to multiple vendors. You'll need flexibility to accomodate those.

A deal with a client who is not particularly security sensitive may be dead in the water if the client-side development required is hefty. Or vice versa, a client with stringent security requirements may not approve a solution that can't pass compliance audits. We make sure that we can easily develop client interfaces for our customers as well as support them if they want to design their interface.

This is all from the point of view of a small shop, focused on our offering's quality over quantity of sales, so your mileage might vary, but SaaS deals are often big elephants, and I think most providers are going with flexibility over sales volume.