Integrating Saas with on-Premises Resources

Replacing an on-premises system with a software-as-a-service (SaaS) solution requires careful attention to existing connectors and systems. The original application is part of a complex network of on-premises databases, tools, and other systems and must be maintained seamlessly to ensure the service your employees and customers rely on keeps working as before. Let’s take a look at the technical implications of getting your SaaS apps to play well with your on-premises applications and databases.

Hybrid Means Integration

Most organizations today are approaching cloud in an incremental manner. That means hybrid IT environments that include both cloud and on-premises resources will be with us for the foreseeable future. Consequently, organizations need to connect SaaS apps with on-premises resources.

Connecting with Databases

In my blog “5 Questions to Ask About Data in Your SaaS Environment,” I noted that you may not be able to move all the data that supports a SaaS app to the cloud. Security policies, for example, might require you to keep some of the data inside the firewall. So, you must provide a means to maintain the connections between the cloud-based SaaS app and the on-premises data.

Connecting with Applications and Services

Today’s IT infrastructures include a jumble of interconnections among applications, services, and data. For example, an on-premises onboarding application for new hires may create a workorder in an on-premises IT service management (ITSM) system. That workorder kicks off a series of tasks that gets approval for a computer and access to the appropriate IT apps and services, passes it to procurement so appropriate items are ordered, receives the items, and schedules installation. The ITSM system reports back to the onboarding application when the request is fulfilled. If you move the ITSM app to the cloud, you have to ensure that this complex process continues to work in both directions.

Scoping the Integration Effort

Your on-premises integrations, especially the ones that have been in place for a number of years, may have been created using application programming interfaces (APIs) such as C# or Java direct calls. More recent ones may have been developed using REST (REpresentational State Transfer). REST is a stateless, client-server, cacheable communications protocol that has a higher built-in level of security than C# or Java direct calls.

When you move an on-premises app to SaaS, you have to determine whether you need to replace integrations that use C# or Java. A major consideration in making this determination is protecting the data that flows between the on-premises and the cloud components of the hybrid environment. A determining factor is the direction of data flow; that is, whether the flow is from the SaaS app to the on-premises solution or vice-versa.

Let’s assume that the data flows from cloud to an on-premises app using traditional APIs such as C# and Java calls. Here, switching to the more secure REST for the API calls would protect the information in transit. You also need to open ports in the on-premises firewall to allow authorized traffic, regardless of the API used to initiate the push. That’s because firewalls present a barrier for most APIs.

If the flow is from on premises to the cloud, the SaaS provider may have restrictions that require a more secure API protocol than C# or Java direct calls. In this situation, switching to REST usually suffices.

In some cases, the programmer who coded the initial integration may no longer be available. Moreover, you may not have documentation on the integration. So, recoding the integration might be tricky.

One alternative is to introduce a layer between the on-premises and cloud solutions, such as a client gateway, that allows bidirectional integrations to continue using the current API. Keep in mind that this approach requires opening up secure ports. What’s more, you may need buy-in from your organization’s security team. The security review process could delay implementation, postponing the benefits of the SaaS app. Moreover, the security team may nix the gateway approach entirely.