SharePoint gets a lot of negativity when it comes to utilising it for a public facing website, and many developers and business users alike will dismiss it without a second thought. In this post we look at both the good and bad when it comes to implementing SharePoint as a public website.
- SharePoint has a large amount of on-line support, documentation and code samples across a variety of web sites (including MSDN forums and Stack Overflow). The problem with many other CMS platforms is the lack of help available on-line, which can make it difficult when developing or even attempting to fix a tricky error. With SharePoint there is plenty of help available and you won’t be stuck with no direction on how to implement a given feature of the CMS. There are also many community events available for SharePoint users (both official and unofficial), which makes networking with other SharePoint users possible in person.
- The licensing is cost effective! When it comes down to the brass tax, a lot of organisations can’t afford to pay huge licensing/maintenance fees for the CMS and this can grow exponentially with load balancing and hot disaster recovery servers. SharePoint has arguably one of the most cost effective licensing costs, and it can even be reduced further with Microsoft enterprise agreements (especially education and government).
- The possibility for a modular code solution architecture makes it an attractive option for larger development teams. With the average CMS, generally the code would be in one large project/solution which can make team development difficult (we have all done a monster merge or two). With SharePoint you can separate each feature (containing web parts etc.) into a separate Visual Studio project, which can then be deployed and retracted as required. This allows for logical separation of the code (by task, business unit or project) and means less of a need for branching – and ultimately merging.
- SharePoint as a CMS is very simple to use for the end user and training is not as in depth as other with other CMSs. There is also less material to cover and users/administrators generally do not require multiple courses for additional features like marketing automation etc. As a lot of companies already use SharePoint for their intranets, staff members are more likely to have already used SharePoint compared to other web CMSs.
- SharePoint is very quick to get started. The basic structure is there and defined, as are the template for sub sites (such as a publishing site). All you need to do is plugin a master page, and you can get going. Any custom code can be coded as a web part and imported to pages as required and data can be imported using PowerShell.
- SharePoint is not just a CMS, because it does so much more like document management, workflows etc. Because it was not designed with external web sites in mind, and more for intranets, a lot of developers feel it makes a poor fit. Arguably the vision of SharePoint is not clear: is it going to focus on intranet, extranet or both and this can be a worry for business stakeholders and developers alike.
- It is missing a lot of key components that might be needed on an external web site. eCommerce functionality is an example that is not handled out of the box and that would require significant development time to implement. However there are third party solutions available that can bring these components into SharePoint, although there can be costs cassocked with them.
- The lack of marketing/automation functionality can be seen as a major negative of SharePoint for an external web site. Sitecore for example comes with a lot of support for this via their AIDA platform, and with the way the web space is moving, this can rule out SharePoint for some implementations. There are some third party components available that address some marketing/automation components, yet it’s not the same as an out of the box feature.
- Some people believe that development takes longer in SharePoint when compared to other leading CMSs and that like for like functionality would mean more developer, BA and testing hours when done in SharePoint. Through our experience we have found this not to be true, and that because SharePoint is very ready out of the box, in the beginning you can actually get going faster. In the end, it comes down to the experience of the developer and how long they have used/developed for the CMS.
For the positive reasons above don’t rule out SharePoint as a CMS for public facing websites and we don’t believe the negatives are enough to rule it out. Yes there are cases where it will just not perform (e-commerce or marketing heavy), but the average website would do perfectly well in SharePoint. Some business users have had bad experiences with poorly delivered SharePoint implementations and this is what puts them off. However at the end of the day SharePoint is a tool, and a tool is only as good as the person using it.