This site uses cookies and by using the site you are consenting to this. We utilize cookies to optimize our brand’s web presence and website experience. To learn more about cookies, click here to read our privacy statement.

Mobilizing SharePoint Applications

One of the biggest challenges facing our clients at the moment is how to extend current systems to support mobile apps. Legacy systems are often difficult to extend or enhance and, by their nature and age, were not built with mobility in mind. This is especially true for systems built without mobility in mind. However, there are ways to extend and enhance your current systems that don’t involve starting from scratch.

A client of ours invested in building an extensive SharePoint 2010 web application. The application makes finding and sharing product content easy for their global sales force. Shortly after the application launched, analytics revealed unexpected usage patterns. The data indicated that the SharePoint application was used from mobile devices during the work day, and that mobile users focused on only two tasks: searching and sharing. These tasks were limited to only a few types of documents. It became clear that an experience tailored for the mobile user would make their sales force more productive. What was less clear was how could they do it without starting from scratch.

When integrating systems — in this case, a mobile app and a SharePoint application — there are usually two options. The first option is to connect directly to the systems. This exposes one system’s domain modeling to the other, creating a strong coupling between the systems. Additionally, the tooling available on each system is often ill-suited for interoperation with the other system, so signficant effort may be needed to parse and process the data; for example, a system exposing SOAP-based Web Services is hard to use from a mobile devices with limited memory and processor power. The second option is to place a third system between the two original systems to act as a facade. The new system presents the client a customized interface tailored for its toolset and domain models. It handles the hard work of transforming between the client’s and server’s domain models and communication protocols. This decouples the client from the legacy server.

Our integration target, SharePoint 2010, has a REST API so mobile apps could be developed directly against them but doing so comes with a cost. First, the apps would be taking a hard dependency on SharePoint and the specific version that is deployed. If the client was to upgrade to newer versions of SharePoint or replace the content management system all together, the apps would need to be revalidated and tested. At best the regression testing finds no bugs and requires no further work but at worst you might find that apps would need significant rework to address any breaking changes introduced by the backend system update. Secondly, when you’re using the SharePoint APIs directly you are forced to describe the system in the language that Microsoft uses to describe SharePoint applications instead of language that makes sense for your domain. Ideally, someone developing an app that is familiar with the business and domain should not have to know about SharePoint and be familiar with Microsoft’s idioms in order to use the backend system.

Instead of integrating directly against SharePoint, we chose to develop a middleware component that we called a “hub”. It provided a simple and domain specific collection of web services to our client’s product information. The hub allowed us to abstract away the messy details of interacting with SharePoint and managing authentication to various internal network resources. The platforms that the apps are built upon are changing rapidly and the needs of the apps may change quicker than larger platforms like SharePoint. Using a facade like the hub gives us the flexibility to respond to any changes and new features which generally occur more frequently on the mobile platforms as opposed to systems like SharePoint.

Legacy systems present challenges when being extended to support newer technologies and platforms like mobile. However, employing the right architectural approaches to extend and enhance your current systems can breathe life into existing systems and modernize them for your current business needs.