Challenges of Modern SharePoint Development from the Business Perspective

15.05.2018
7 min.
title

The face of SharePoint development has changed substantially over the years. SharePoint owners who started their way with the platform in the early 2000s now deal with several SharePoint On-Premises versions and cloud SharePoint Online and Office 365. The latter made companies reconsider their traditional approaches to planning and carrying out their SharePoint development projects.

Working with the server version of the platform, companies aim at transforming SharePoint into a custom solution adapted to their collaboration and business needs. Taking into account the rawness of the out-of-the-box platform, SharePoint developers have to put much effort into turning it into a ready-made intranet, a DMS, or a public-facing website.

As for SharePoint Online and Office 365, Microsoft made them ready to use right from the start. Thus, the platforms require much less effort to develop a solution from scratch, while bringing multiple challenges related to customizing them within a globally available cloud ecosystem. This makes companies shift to alternative development methods.

Entering the Era of SharePoint Add-ins

Overall, SharePoint On-Premises customizations are pivoting on two types of SharePoint solutions: farm and sandboxed ones.

Farm solutions contain code that is deployed to the SharePoint servers and affects the entire SharePoint farm. Farm solutions can exist only within server implementations and aren’t applicable to SharePoint Online or Office 365. For example, they are good for developing custom server-side SharePoint features, web parts, timer jobs, or event receivers.

Sandboxed solutions contain code that affects a solution at the site collection level only. Sandboxed solutions are suitable for designing SharePoint web parts aggregating data from multiple SharePoint lists, creating a workflow in SharePoint Designer, or developing a new ribbon element. Unlike farm solutions, sandboxed solutions can run both on-premises and in the cloud. There is a restriction, though. Only no-code or declarative solutions can be deployed in SharePoint Online.

All in all, neither farm nor code-based sandboxed solutions fit the SharePoint Online logic because they could affect the entire cloud environment, which is inadmissible. For this very reason, Microsoft recommends organizations to smoothly transform server-oriented solutions into SharePoint Add-ins. Add-ins don’t contain custom code that runs on SharePoint servers, which ensures that they can impact neither organizational servers nor the overall SharePoint Online performance. Currently, applying the SharePoint Add-ins development model, SharePoint specialists can create almost all types of custom components, be it a SharePoint page, a web part, a list, or a workflow.

There are two types of SharePoint add-ins: SharePoint-hosted and provider-hosted. SharePoint-hosted add-ins live in the add-in web within SharePoint and can contain only JavaScript code.

Provider-hosted add-ins come with at least one component (for example, a web app or a database) hosted externally from the SharePoint farm or SharePoint Online subscription. Organizations are free to choose hosting frameworks and cloud services to build and manage their add-ins. It’s unnecessary to use the Microsoft technology stack either. Thus, an add-in can reside in Microsoft Azure or in the AWS cloud equally well.

To summarize, let’s take a look at the overall state of SharePoint development. Logically, it correlates with the actual shares of server-based and cloud deployments. As the number of companies preserving their SharePoint On-Premises deployments is still impressive, there is no surprise that SharePoint developers still use farm solutions heavily. At the same time, the abundance of SharePoint add-ins is also easy to explain taking into account the increasing popularity of SharePoint Online.

Accepting the SharePoint Framework rules

To support organizations in their transition from traditional SharePoint server-oriented solutions to the modern add-in-centric model, Microsoft enabled a brand-new development approach based on the SharePoint Framework (SPFx). According to the Microsoft definition, the SharePoint Framework is a page and web part model that provides full support for client-side SharePoint development, easy integration with SharePoint data, and support for open-source tooling. Having this client-side nature, the SPFx enables developers to use a variety of open-source frameworks and technologies. For example, those can be JavaScript frameworks: React, Knockout, or Angular.

But what can this technological freedom mean for organizations?

The SPFx sets companies free from the traditional .NET development. It means that even those businesses that never cooperated with .NET developers now can deal with SharePoint Online by involving JavaScript, Java, C, and C++ professionals. At the same time, even seasoned .NET developers should extend their knowledge to handle SharePoint Online customizations. For instance, it’s highly recommended to dive into TypeScript, which is, together with JavaScript, the key language for developing SPFx artifacts.

Meanwhile, if you look at the stats, you will see that it’s too early to say that SPFx entered all organizations running SharePoint.

However, if you adopt SharePoint Online for the first time or plan to migrate to the cloud, you should definitely turn your attention to SPFx as a suitable development model to create a custom cloud intranet or complex business solutions.

Addressing SharePoint Online development drawbacks

SharePoint Online performance is a frequent issue for developers who bring in customizations. Obviously, even though Microsoft keeps expanding the geography of their data centers, it’s still impossible to ensure the equal high-quality performance of the cloud suites across the globe, so slow-downs are possible.

Next, come functional and customization limitations that are among key reasons for organizations to stay with their on-premises deployments and preserve the opportunity to customize them as deeply as they need.

Another big issue is constant updates that can affect already deployed customizations. This can result in additional effort and investment into SharePoint development services and brings the risk of custom solutions becoming unavailable for users.

While developing custom solutions, our team often faces SharePoint Online operability issues inherent in the cloud nature of the platform. The SharePoint performance depends heavily on Microsoft datacenters’ location and we, as developers, can’t improve it. We also often deal with SharePoint Online customizations that work inappropriately after updates roll out. However, as we can’t control these changes, we just prefer sticking to the Microsoft recommendations to minimize risks of solutions’ inoperability.

Sergey Korolev

Changing approach to excelling at SharePoint development projects

As we have already mentioned, changes in development approach also suppose changes in knowledge and skills that your team should have to fulfill their project successfully. Additional training might be required to align your teams’ competencies with the latest requirements of SharePoint Online and Office 365.

SharePoint development teams will also have to adapt to a new style of managing their projects. Generally, dealing with SharePoint On-Premises, specialists can manage emerging issues on their own by finding workarounds and modifying the platform’s code. On the contrary, while handling technical issues within SharePoint Online, they can only address to Microsoft to solve them, which can take time and slow down the development process substantially. Moreover, there is no guarantee that an issue will be addressed if it doesn’t make part of the Microsoft development plan.

All in all, to stay tuned into SharePoint Online development, it’s highly recommended for SharePoint professionals to follow the SharePoint Development Community or the SharePoint PnP (Patterns and Practices) community, which is an open-source initiative coordinated by SharePoint engineering. The community elaborates and manages all documentation, code samples, best practices and methods related to SharePoint development.

How can it help? For example, the community manages an issue list on GitHub where developers can report challenges they are dealing with and ask SharePoint experts for advice or assistance in solving them. On the SharePoint Dev Platform, SharePoint pros can also suggest possible improvements within SharePoint. After the suggestion passes moderation and voting, the Microsoft team decides whether to accept or decline it. This is a feasible way to promote your development initiative that can be implemented across the entire suite.

What is the future of SharePoint development?

For over 17 years since its first release, SharePoint has passed a long way and has experienced many changes. Obviously, the cloud version of the platform, SharePoint Online, will continue to evolve, so SharePoint developers and business owners should stay tuned for these updates too.

Analyzing the current state of SharePoint and its growth, I can say that farm and sandboxed solutions will definitely go out of custom development in the near future. I expect further expansion of the SharePoint Framework and modern front-end development tools, as well as the advance of CSOM and REST API. I am also looking forward to seeing an improved support for continuous integration and deployment in SharePoint Online at the API level, which is critically missing these days.

Sergey Protchenko

Finally, major changes are coming to SharePoint On-Premises too. The upcoming SharePoint 2019 promises substantial enhancements in the platform’s UI and development techniques. The professional community expects SharePoint On-Premises to absorb the SharePoint Online capabilities, which will ensure a consistent development experience across both environments.

Tags: