Summa

No man (or woman) is an island - we cannot thrive alone.  Similarly, no application is an island.  In the same way that people across the globe have become intractably interconnected by technology, so have applications and the data that they thrive on.  SaaS applications can become dangerous islands of process and data if you are not careful in planning from the start.  Finding value in integration is easy.  SaaS applications are increasing in their rate of adoption due to both their inherent value and acceleration caused by the economic situation and capital investment posture that most companies are in. SaaS solutions offer many benefits to business:

• Implementations can be very quick and inexpensive compared to the cost, complexity and time to get started with on-premises packaged applications. This is especially valuable for gaining efficiency around common operational functions (for example CRM and HCM/HR) that do not differentiate your business.
• SaaS solutions can be easily be rolled out to users in a lower-risk and phased fashion (perhaps one department or business unit at a time). You only pay for what you use and avoid the big investment or risk in up-front packaged application implementation and their associated servers, licenses and installation/configuration. SaaS applications only require a web browser on a desktop or laptop computer.
• It is easier to include outside participants (e.g. channel sales, suppliers, business partners, BPO organizations) in your SaaS based business process. While information security and policy is still required and supported, firewall/VPN issues are avoided.
• Similar to packaged applications, SaaS solutions allow quick access industry best practices within the processes that they implement.
• Long term TCO for SaaS applications can be much lower than self-maintained applications and associated infrastructure.

Something is frequently lost in the rush to get to realizing these commonly advertised business benefits.  SaaS salesmen will often dismiss a discussion about integration during the acquisition planning with a technical whitewash of “we support standards…”. While this statement is true, we should be thinking ahead about a few important factors that are important to get it right from the beginning:

• How will I tie this new SaaS application into my existing business processes, operations, data and people? The toleration for 10 different login IDs and UIs is fading.  The cost of training and retaining staff to deal with the diversity of systems is high.
• How do I minimize the amount of effort and cost of errors due to re-typing of data across internal and external systems?
• How do I ensure application data quality and consistency with my other systems (e.g. catalog of parts to order in CRM, department codes in HCM.)
• How do I architect my environment to deal with the inevitable upgrade or replacement of this SaaS solution? (No SaaS provider  is to bring this up during the sales and planning phase.)

If we apply a few SOA principles such as loose coupling, use of standards based interfaces and focus on business services we can achieve a lot of benefit with small up front investment of planning and design.  SaaS vendors realize the value of integration and typically make integration with their product easy.  You probably don’t have the same story within your legacy applications… Some examples scenarios of SaaS integration and its value:

• Synchronizing company master data from ERP to a CRM system to populate drop down boxes in the UI, cross reference tables for data constraints. This could be organization information (department IDs), product data (master part list), account / customer data and more.
• Initiating orders from a CRM system to the ERP system.
• Providing  internal systems (employee directories, custom application IDs, provisioning of access to services) with key employee data maintained in the HCM system.

Some of the concerns that we deal with in our SaaS integration  work include:

1. Considering and understanding the trade-offs of using of real-time  versus  batch oriented interfaces. Sometimes both are necessary for different transaction and data categories.
2. Understanding what is exchanged in each direction for each type of data transfer.
3. Designing in good performance and scalability for the longer term roadmap (if not designed correctly, one department integration of 1000 data records may work fine for a while, but somewhere during the phased roll-out to 20 departments the design may cause the system to fail under load.)
4. Understanding where and how to use integration tools and products vs.  custom integration development. The approach depends upon the complexity, volume, operational concerns and long term vision for the SaaS application and SaaS in general. Solutions can range from small batch scripts, to integration appliances, ESBs or ETL tools.
5. Coordinating with IT department standards, policies and proper use of existing infrastructure.
6. Understanding security implications beyond the user/password used for access - including the lower levels of network and communication layer. And most importantly within the business processes and associated data access layer (e.g. prevent users of SaaS from unintentionally having access to records or fields from integrated systems where their access is restricted.)
7. Maintaining data consistency and quality across multiple applications.
8. Providing a robust approach to dealing with data validation and other errors that you will have.
9. Right-sizing the solution to fit the organization’s current and future application needs. What makes sense for a multi-billion dollar organization requiring coordinated integration with 10 separate backend and SaaS solutions is different than what makes sense for a 100 person business with one legacy application requiring integration.

In summary there is a lot of value to integrating SaaS systems with your existing and future environments. Vendors may drive you to take a short-sighted view - but to get the most value from your systems, you need to plan and design for integration. The SaaS island needs to have a bridge, ferry dock or airport to be useful. Understanding your vision for its use and the factors outlined here will help you decide.