The way we build SharePoint customizations is changing. Are self-contained solutions still the best practice or is there perhaps a better way to build SharePoint customizations?

Because having everything in one place is a good thing

SharePoint 2007 introduced Solution Packages - WSPs. Together with the Feature framework they offered developers a structured and repeatable way of packaging and deploying SharePoint customizations. Using everything that the SharePoint platform had to offer, developers would build Timer Jobs, Site Definitions, Workflows, Web Parts and more to extend SharePoint’s capabilities beyond what was available out of the box. Using the different Features administrators could enable the different pieces of the SharePoint solution.

At that time the recommended approach was to integrate with SharePoint as tightly as possible. Rather than reinventing the wheel, developers should reuse building blocks provided with SharePoint: from Fields, Content Types and web controls to Timer Jobs, web services and even registering custom databases with SharePoint. Because everything would integrate with SharePoint, custom solutions would more standardized. This would make them easier to monitor and maintain.

Contained - in a container

SharePoint 2010 brought one change to how developers could build SharePoint customizations. Microsoft was operating SharePoint in the cloud - first as BPOS and later as Office 365. Because the service was running on SharePoint Farms shared by multiple organizations, allowing customers to deploy custom code was not an option. But the need to customize SharePoint remained and customers were used to it from their on-premises environments. To compromise, Microsoft came up with a new model called Sandboxed Solutions - a restricted version of the solution model introduced in SharePoint 2007, yet capable of executing custom code.

Despite the promise, organizations quickly discovered that Sandboxed Solutions were too limited for their needs. Eventually most of them kept using farm solutions as the approach for building SharePoint customizations.

Apps, now also in SharePoint

When SharePoint 2013 was about to be released, the world was all about apps. We had them everywhere: from mobile devices to Windows, so why not in SharePoint?! And apps we got, later renamed to add-ins, in SharePoint.

SharePoint Add-ins introduced us to the idea that SharePoint customizations, particularly the more complex ones, shouldn’t be running on SharePoint servers. Instead they should be hosted separately and use remote APIs to interact with SharePoint. At some point this even lead to a debate whether SharePoint is a platform or a service.

Although this new model came with its own set of limitations, it was for the first time that customizations needed to request specific permissions to perform their operations. Administrators could verify if these permissions are according to specifications and what the particular customization should have access to.

Because the integration layer of SharePoint Add-ins shrunk to remote APIs, more complex customizations, that needed custom components, had to take care of them by themselves. In a way, that liberated architects to choose components and services they wanted to utilize. But it also increased the complexity of the solutions as each solution built by a different vendor could potentially work differently and have different dependencies.

The anatomy of a modern SharePoint solutions

Fast forward to today, Microsoft has a number of years of experience hosting SharePoint for their customers on a global scale. Parallel to the growth of Office 365, Azure has evolved and become a powerful cloud platform offering turn-key components for building scalable cloud applications. Just recently Microsoft announced SharePoint Framework - a new model for building SharePoint solutions. So what are SharePoint solutions today?

Remote is the new black

In the past architects strove to have their solution leverage as much of SharePoint as possible. Today, while often requirements are still the same, SharePoint solutions integrate with SharePoint primarily through its remote APIs. Whenever solutions require specific SharePoint artifacts, like Content Types or Lists, they create them using remote provisioning techniques which are also based on SharePoint’s remote APIs.

The keys to the kingdom

Before remote code is allowed to communicate with SharePoint it needs to authenticate. There are a few ways in which this can be done.

First, you could use credentials to authenticate with SharePoint. There are a number of ways in which you could store them securely and retrieve in your application. From the administrator point of view it would be like there was a user connecting to SharePoint.

Second approach, is to register the application as a SharePoint Add-in and specify which permissions it exactly needs to operate. Administrator can then install the application and grant it the necessary permissions.

Finally, the application can be registered as an Azure AD application and use OAuth for authentication also by requesting a specific set of permissions. In contrary to the first two approaches, using OAuth works only with SharePoint Online in Office 365.

Whichever approach you choose depends on your specific requirements, but it’s good to keep in mind that they are at your disposal.

If SharePoint then that

Many SharePoint solutions subscribe to events in Lists and Document Libraries and react to them. In farm solutions this has been implemented using Event Receivers. In the Add-in model, proprietary Remote Event Receivers were the suggested approach. The announcement of the modern SharePoint UX and the SharePoint Framework also includes support for webhooks on Lists and Document Libraries.

Just like Remote Event Receivers, webhooks are web requests to remote APIs. Webhooks however are much simpler without the complexity of SOAP services required by Remote Event Receivers. The great thing about webhooks is, that many cloud services support them, so you could implement webhooks in dedicated web applications built using ASP.NET Web API but also as more lightweight services hosted as Azure Functions.

Working on it…

Often, when processing large amount of data, SharePoint solutions implemented Timer Jobs. This not only allowed for scheduling long-running operations but also to offload them from the application pool hosting the web application. Additionally it freed resources for processing web requests and increased the stability of the operation in an event an application pool would crash.

A common, cloud-based approach to implementing long-running operations for SharePoint is to use a SharePoint List or an Azure Queue as a queue of tasks to be executed and then have a separate process to pick up the task from the queue and process it. The implementations vary from Windows services or scheduled tasks in on-premises environments to Azure WebJobs in the cloud. Recently Azure Functions have been released which also support scheduling and which make a good alternative to using Azure WebJobs.

It’s all about the process

In many organizations certain things need to happen according to a specific process. Whether implementing a business process or just having a structured execution flow, SharePoint Workflows were often used as a building block of SharePoint solutions. Throughout the years the technology behind workflows changed but the demand remained the same.

Organizations that need powerful workflows to support their business processes, often rely on workflows engines provided by specialistic vendors. For simpler scenarios, for which we used to use SharePoint Workflow in the past, there are new alternatives available such as the recently announced Microsoft Flow.

Forms

There isn’t probably another part of SharePoint that has as turbulent history as forms. For quite some time InfoPath was the solution for organizations to build forms. There were a number of ways for working with InfoPath forms in SharePoint: from using the InfoPath client application to filling forms in on the web. And then the discontinuation of InfoPath was announced. Although InfoPath is still supported until 2020 it won’t be further developed. Since the announcement a number of alternatives have been discussed publicly such as Forms on SharePoint Lists (FoSL). So far however, the situation hasn’t changed much and we are still to see the successor of InfoPath.

Many SharePoint customizations need interface for structured data entry. Depending on the requirements these vary from custom-built applications to specialistic forms solutions. With the ever-increasing usage of mobile devices, Microsoft recently released PowerApps. PowerApps are in no way an InfoPath replacement. Yet many believe, that, thanks to the easy integration with SharePoint, PowerApps offer great experience for working with structured data on the go.

The future is now

How we build SharePoint solutions has been steadily changing over the years. Never before Microsoft offered us so many building blocks that we can use to build rich solutions on the Microsoft cloud.

For quite some time now we have been building SharePoint customizations that integrate with SharePoint using its remote APIs. But for the first time we can choose whether we really want to custom-build everything or if we want to benefit of the building blocks offered by Microsoft instead. And while using them shortens time to market it also increases governance complexity.

SharePoint solutions are no longer self-contained. Instead they are made of client-side technologies for the user experience and a number of cloud services for process modelling and data processing. These solutions offer great added value to organizations using SharePoint but they also require proper architecture and governance to fully deliver on their promise of increased organization efficiency and reduced costs.