On the 27th of March 2021, there were events around the Internet to celebrate the 20th anniversary of our beloved SharePoint.
Having worked with almost all versions of SharePoint, allow me to share my thoughts about where SharePoint came from and where it is going.
A bit of history on the infrastructure’s side
I remember that the early versions, such as SharePoint Teams Services, had no database. It was easy to export and archive entire SharePoint sites with all their documents. Just copy the files from the file system. All the metadata were hosted in text files in each sub-folder. Guess what was happening if a user was deleting those files…
Then came the 2003 version, SharePoint Portal Server, with content hosted in SQL Server’s databases. I was told back in 2014, that the Content Database schema has not changed since then. I am unsure about the latest SharePoint Online version but I bet this has still not changed a lot. This move still bring performance challenges even nowadays.
MOSS for Microsoft Office SharePoint Server, the 2007 version, added a better architecture with Service Applications.
With SharePoint Server 2010, came multi-tenancy, a term that we are still using in Microsoft 365 to designate the capacity to host different tenants, a.k.a. organisation, under the same farm.
SharePoint Server 2013 is actually a sort of kernel/genesis from all futures versions of SharePoint.
SharePoint Server 2016 and 2019 have brought a new and much sexier interface with the “modern experience”, also hybrid scenario was better supported. In the 2019 version, a lot got deprecated, such as Workflow Manager, the 2013 workflow engine, Infopath used to make forms, and SharePoint Designer used for all sort of customisations, including forms and workflows.
The first version of SharePoint Online came from the 2010 version. Then all farms were migrated into a new SharePoint Online built upon SharePoint 2013.
For a full explanation, refer to my post “Release road-map of SharePoint 2016 On-Premise and SPO“.
Developing and migrating applications
Since 2004, I have spent my fair share of migrating SharePoint on-premise farms from one version to another, or from one AD or Windows Server version to another.
Migrating content databases and Service Applications was still OKEYish, however the real pain was the custom developments.
Back in 2007, Microsoft pushed the DotNet developers to use SharePoint as THE next development platform. Quite a lot of them hated it as they were locked into a box with obscure bugs and technical limits.
This was the starts of the WSP nightmare. WSP (Windows SharePoint Package) is a solution package which can be deployed at site, web application or farm level, with DLL (Dynamic Link Library) files in the GAC (Global Assembly Cache) for the latest. Full trust solutions were often used by developers which was not the best in term of security.
WSPs were hosted on the SharePoint servers, which was not ideal when migrating, so came a need to get them out of those servers.
From the 2013 version, the SharePoint “App Model”, later renamed “Add-in Model” was supposed to help externalise applications with hosting options. This never really caught up for several reasons. From an infrastructure point of view, the security requirement for installing the SharePoint app store was just a nightmare and costly too (needed a separate domain name with a separate SSL certificate).
From the developer’s side, SharePoint Add-ins were added to subsites that had their own unique URLs, and as such there were not treated as existing sites. Updating existing developments was difficult. Finally, the learning curve was quite steep.
From the SharePoint 2010 version, Microsoft had already introduced the beginning of SharePoint REST API as well as the client-side object model (CSOM). Over the years, developers started to take things by their own hands by using JavaScript injections helped by a few webparts and the vastly improved REST API of the 2013 and 2016 versions.
SPFx (SharePoint Frameworks) answered the developer’s needs by providing full support for client-side SharePoint development based on JavaScript. It was released in May 2016 and was made public in 2017.
The tendency now seems that maintaining complex developments based on any JavaScript frameworks such as Angular, React, Knockout, Handlebars or Vue.js, can be resource consuming. You need ideally in-house knowledge as external developers may take some time and money to dig in back into the code when a simple evolution is needed.
With SharePoint Online, now come PowerApps for the forms and PowerAutomate, previously known as Flow, for the workflow engine. Those are supposed to be low-code / no-code technologies. Having starting developing with it, we can see that it is not as low-code as Microsoft would like to sell us and you still great expertise to work your way around the limitations.
With OneDrive For Business being revamped to look more like its customer version OneDrive, and with the services Teams and List using SharePoint Online to store documents, wiki pages and data, we can see that SharePoint is seen more and more just as a backend storage.
This is also true when developing applications where the PowerPlatform is used to develop front-end forms and back-end workflows, and where a SharePoint site is just here to store the application’s data. Most developers do this for the simple reason that a SharePoint site is free compare to the expensive database hosting on Dataverse, previously known as the Common Data Service (CDS).
SharePoint development governance challenges
I always thought that using SharePoint lists as a relational database system was a bad idea. Now with developers and Microsoft using SharePoint as just a back-end storage, it becomes even worst to manage.
Security
Imagine a database’s table where all users can start creating, updating or deleting any row.
Changing the permissions of a back-end SharePoint site, disabling the search indexing of the lists used to store data, are just 2 simple examples of best practices which should be done by default but are often missed. Ideally a workflow should change every single item’s permission of the lists depending on its status, but this is not implemented in most applications as this require quite a lot of work.
Application proliferation
- Teams’ owners can easily break the back-end SharePoint site of their Teams.
- Team’s members can create entire applications just by going to this back-end.
Just like in the old days of the 1990s and 2000s, Microsoft allowed anyone to start developing applications on Office using VBA. The upgrading of Office of one version to another became then very difficult with unknown and unmanaged business critical applications resurfacing all of a sudden.
Here we go again. Savage, uncontrolled proliferation of less than average quality “applications” is bound to happen with Microsoft 365.
I hope to write another post on my view on how to control this.
So now what’s next?
- By putting an end of support of both SharePoint on-premise 2016 and 2019 for 2026, Microsoft is showing us the way out of on-premise farms to the cloud.
SharePoint 2022 will have an even shorter life span of only 5 years, which should lead us to what? 2026 or 2027 before being out of support?
Basically, if you wish to carry on using SharePoint, start thinking moving to SharePoint Online. - Finally, if you are really onto security for your business-critical applications, do not use SharePoint Online as a back-end storage. Not that it does technically lack security, it’s just that most PowerPlatform developers won’t bother implementing even the simplest best practices. Use Dataverse instead, it may be costly but at least you’ll have full control of who can do what.
