In thinking about the tools I use on a daily basis, the ones I enjoy working with all have one thing in common: They could all be compared to lightning. They are all fast. They are all recognizable; you know exactly what is going on. Most importantly, all of them are powerful. Those three characteristics are important for quality software and any software that aspires to long-term user adoption.

Until recently, I thought that was as far as the lightning metaphor went. Then I found out that lightning does not necessarily come down from the clouds. The ground also plays its part, and the lightning meets in the middle.

I started thinking about it again, and I realized that the metaphor still holds true. All of the applications that I enjoy working with have some connection to the cloud. Word has Office 365, Visual Studio has TFS as a service, Outlook has Exchange, and the list goes on.

SharePoint Online is a good first step in making sure that all of the data is available when it is needed by the end user, but what about all of the on-premise, line-of-business systems? What if we could integrate the two systems?

In SharePoint’s new app model, we have the option of using a provider-hosted remote web. The task of deciding where the remote web lives is up to the developer. It could be hosted on premise and bring data to the user within their cloud experience. The benefit is that we can now use our on-premise data with a system that is entirely cloud-based. We now have on-premise data going up to meet the cloud, much like lightning meeting in the middle.

There are, however, a few snares that need to be considered before going down this path:

1. Offsite availability: In all likelihood, this is confidential data coming from your line-of-business system. Should this data be available offsite? If so, you will need to make sure that you take appropriate security measures within your remote web because the site will be touching the Internet.

If not, I recommend having your app land on an app webpage that verifies connectivity to the remote web before diving into the application flow. That way, if the remote web is not available, you can fail gracefully.
#!
2. Authentication and authorization: Since we are no longer within the permissions structure of SharePoint, we no longer benefit from the built-in security. On the other hand, since we are within the context of an on-premise IIS, we do have Windows Authentication at our disposal. There is no cookie-cutter recommendation here; do what makes sense for your application.

3. User interface: In building an on-premise application into an app for SharePoint, you are creating an interface for which different users are going to have different expectations. Many users will anticipate that the interface will be very similar to the SharePoint interface. Others will expect that the app will behave much the same way the on-premise application does.

Here again, there is no cookie-cutter answer. If you can migrate entirely off of the existing application’s interface, that may be the best way to go. In many cases, that is next to impossible. If that is not possible for you, I recommend staying true to either SharePoint’s look and feel or the look and feel of your on-premise application. Blending the two may result in a disjointed user experience that alienates both ends of the spectrum of users.

So, there you have it. On-premise data going up to meet the cloud. SaaS backwards.

Brian Prigge is a SharePoint Architect with RAMP, where he leads the implementation of RAMP’s suite of video hosting, search and discovery solutions into custom SharePoint integrations.