Choosing the Right Development Model for SharePoint and Office 365 Extensibility

Posted by Eric Shupps

Long before the cloud became a pervasive part of enterprise computing, SharePoint developers had a fairly straightforward set of options for extending out-of-the box functionality – full trust or sandbox, web parts or application pages, event receivers or timer jobs, web services or server-side API’s. There wasn’t much confusion regarding the structure or composition of projects and the deployment path was determined by the solution type. In many ways it was simplified (if not actually simple) and streamlined, with a well-defined path for application architects to follow.

Fast forward a decade and things have changed quite dramatically. Not only has the ascension of the cloud introduced new API’s and solution types but it has also fundamentally changed the way applications are designed. Before even considering core features and use cases, developers must first determine which development model to use: Full Trust, Add-Ins, Framework or Azure? This is a key decision that in many cases cannot easily be reversed once development is underway, so it is vitally important that the right decision be made up front or a great deal of time and effort may go to waste.

The factors driving model selection are varied and complex, with numerous strategic and tactical dependencies, but they can be separated broadly into three distinct categories: Dependent, Interdependent, and Independent. In most cases there will be a great deal of overlap between these categories (there always has been) but historically the available options for satisfying the requirements were so limited that they became mostly irrelevant; however, in the current state of affairs this is no longer the case. Developers now have many tools at their disposal for delivering features in such a variety of ways that it has all become rather confusing.

To dispel some of this confusion, or at least provide some clarity for the decision making process, let us examine the three feature categories and how they map to the various development models. The first is actually the easiest. If the business and technical requirements demand the use of particular elements which can only found in an on-premises product, such as timer jobs, the publishing infrastructure, advanced content management, event receivers, deep customization or high levels of performance – all of which fall into the Dependent category – then Full Trust, preferably running in a hybrid configuration with some cloud integration, is really the only viable option. This model carries with it additional infrastructure, management and administration considerations but remains a viable option for certain scenarios.

On the other hand, if the feature requirements as they relate to platform capabilities are more mundane (such as the ability to store data in lists, execute search queries, manage documents or access profile information), then they are considered Interdependent and the full range of development models is open for consideration. Making the right choice can be a tricky process in which the advantages/disadvantages of each model must be weighed against specific requirements. For example, an asset tracking system that uses SharePoint lists for CRUD operations could be an Add-In or a Framework solution, as core elements of the platform (namely lists and libraries) are integrated into the overall application and the user is likely to access it “in context” from a SharePoint page or site. In this situation, additional factors must be considered, such as how the user will engage with the application or what additional dependencies are required.

Interdependent applications are the most difficult to assign to a particular model as they can often be delivered in various ways. In some cases, the requirements easily define the outcome, such as a responsive, full-page experience that renders well in a modern context, for which there is only one answer (Framework) due to limitations in other models that are incompatible with the core requirements (in this case, add-in parts being hosted in a non-responsive IFRAME element). But the answer is not always so immediately obvious. If use cases call for single-tenant data input and visualization within a standard list view, then a Framework solution that leverages field and application extensions is the most likely candidate; however, if the application is an ISV offering that will be implemented in many individual tenants, then an Add-In, with its built-in licensing framework, flexible hosting options and a simple, contextual deployment path, may be a more suitable option. Extensive dialog between development and business is often required in such situations and it is important to consider all factors when making a final decision as some sort of compromise is usually inevitable.

Much like Dependent applications, Independent applications can often be easy to identify but it is all too easy to disregard them in favor of an Interdependent solution that may seem suitable at first but in reality is overkill for the stated requirements. If the only API that will be accessed by the application is the Graph, and the user is already authenticated with a cloud identity, then an Azure web application is probably the best answer. This model offers a number of advantages over the complexity of Framework and Add-Ins solutions, not the least of which is the ability to deploy directly to (and manage within) the Azure platform, while still providing a layer of programmatic integration with various cloud services (including SharePoint). This model is usually a very good fit for classic .NET applications to which some level of SharePoint integration is being added but which still stand alone. In the past, a great deal of effort was made to port such solutions to the SharePoint platform when in reality they remained functionally isolated with only a thin layer of interoperability.

Independent applications, accessible to users from the application launcher, are in many ways identical to Teams, Planner, Streams, Flow and other parts of the Office 365 ecosystem. They provide a distinct set of non-contextual functionality that is related to, but not directly integrated with, fundamental SharePoint components. They can play an important role in an overall extensibility strategy but must be approached with full knowledge of how they can (and should) be used. Because such applications take users completely out of any SharePoint context they may be working in, all site or list-level integration must be managed by separate configuration or runtime inputs. If a contextual experience is necessary (even though an Azure app may satisfy most other requirements) then the decision must by necessity fall back to an Interdependent model such as add-ins or the Framework.

In the final analysis, the job of deciding which model to choose may result in a “best guess” effort. Although this may lead to certain amount of confusion, and some inevitable mistakes and rework along the way, the benefit is that developers now have a much broader set of options for satisfying application requirements, which is a far better scenario than trying to fit everything into a single, inflexible model that is no longer suitable in an era of cloud-centric computing. That is not to say that on-premises applications are unviable but rather that they are slowly being replaced by a broader range of options that offer a variety of pros and cons. And that developers should not repeat the mistakes of the past, choosing only one model because that is when they know or are most familiar with, but consider all options when creating new projects and select the one which makes the most sense for a particular set of requirements at any given time. As the models continue to mature, it may very well be that one gains dominance over the others and a majority of solutions gravitate towards it, but for now the best approach is to consider all approaches without preference for any particular one.

Thoughts? Leave a comment: