How can our IT department integrate a software as a service (SaaS) application with the ones we already have running at our business?
Those companies leveraging SaaSs are often small- to mid-sized organizations that simply cannot afford what it costs to purchase and install software from SAP or Siebel. Instead, they find it much more convenient and cost-effective to purchase their software on demand. Smaller organizations therefore may leverage several of these types of applications with very little internal application infrastructure. For our purposes, we can call this pattern inside-out.
The integration objective here is to bring together all of their SaaSs — whether they are processing customer, inventory or employee information — and make them appear a single application framework, with both service visibility and information visibility between the applications, perhaps with common schemas and transactions. Thus, you may have SaaSs that function similar to the way many Web sites share content through RSS or other mechanisms. You leverage a common standard that all can agree upon; the rest is just a matter of execution.
Creating an integration strategy and a service-oriented architecture (SOA) for this type of domain is essential. (A service-oriented architecture is a collection of services that communicate with each other. They are self-contained and do not depend on the context or state of the other service.) Indeed, many, if not all of the same SOA and application integration principles apply, including:
- Definition of interfaces
- Schemas and records
- Common transactions
- Transformation and mapping
- Security principles and governance
However, you must deal with issues that are specific to the use of SaaSs. These would include:
- Firewall management
- Federated security and identity management
- Leveraging Internet-based integration services
- Leveraging standards
Definition of interfaces
Not all service-provider application interfaces provide the functionality required to create and operate architectures (such as Web services) for SaaS integration. Also, SaaS interfaces are always limited by the capabilities of the interfaces that the source or target systems provide. You need only look at how your company interacts with Salesforce.com or NetSuite to see that the interfaces are very different. When dealing with SaaSs, define interface types that your applications and databases provide that will fit with service- or information-oriented SaaS interfaces.
Schemas and records
Another identifying component of information existing within SaaSs is data structure (the design of both the schema and records). How information is structured, including the properties of the data elements within that structure, can be gleaned from knowledge of the data format. Likewise; length, data type (character or numeric), name of the data element, and type of information stored (binary, text, spatial, etc.) are additional characteristics of the data that may be determined by its format. Different structures and schemas existing within the SaaSs must be transformed, as information is moved from one system to another.
Common transactions
Once the enterprise data is understood and baseline information (such as the metadata model) has been created, a decision must be made regarding how to approach the enterprise business model (the common transactions shared between the enterprise and the SaaSs). As mentioned earlier, identifying transactions that exist within an enterprise is a difficult task, requiring the analysis of all the applications that exist in the problem domain. It’s even more difficult when you consider the possibility that many entities embrace numerous types of applications over a number of generations of technology.
Transformation and mapping
With an understanding of the data and application semantics that exist within a SaaS integration, it is good to get an idea of how the data moving between systems will be transformed. This is necessary for a couple of reasons: first, data in one system won’t make sense to another system until the data schema and content is reformatted to make sense to the target system; and second, it assures the maintenance of consistent application semantics from system to system. Once the above steps have revealed all the information available, it is time to map the information movement from system to system. In other words, what data element or interface is the information moving from, and where will that information ultimately move?
Security principles and governance
When leveraging SaaSs, identity management is critical. Since the advent of Web services — and other distributed computing standards, for that matter — we’ve been wrestling with the notion of identity and how to manage it. Standards are needed to better define this space, and they must all aim at binding together identity management systems in an organization into a unified whole, allowing for everyone to be known to everyone else, securely.
David Linthicum is president & CEO of BRIDGEWERX and is an internationally known enterprise application integration (EAI) and e-business integration expert. BRIDGEWERX helps SMBs integrate popular mid-market applications and those offered by on-demand service providers.
Contact the editor