Lots of companies have been running SharePoint systems for many years. Some have built up a lot of expertise, some even have dedicated support professionals and teams in place. Yet even for these very mature organizations, ‘governance’ can still be a bit of a mystery.
Any company running SharePoint needs to think about governance and what it means to them. According to
Microsoft, the definition of governance is:
"Governance is the set of policies, roles, responsibilities, and processes that control how an organization's business divisions and IT teams work together to achieve its goals."
Failing to think about these things means a SharePoint portal can become disorganized, users can get confused, people don’t know where to go with questions, and there is no clear plan around the future direction of the system.
Whilst many companies struggle with governance, the SharePoint community is particularly good at trying to help. Besides a lot of good articles on Microsoft TechNet, many posts have been written about governance in SharePoint projects, for example:
Codeplex even hosts a SharePoint Governance tool
by Bill Baer
, Senior Technical Product Manager at Microsoft, to make the process easier (please note it is currently in alpha status).
However, all these articles are usually focussing only on IT Management
and Information Management Governance.
One topic that is nearly always missed in any governance conversation is that of Application Management & Governance of the custom code.
Microsoft explains the application management for custom solutions in it's governance poster (PDF)
and TechNet article
for SharePoint 2013.
But what are the controls and processes in place around customizations?
Let us look into this area in a bit more detail.
No, I don’t know who wrote that code, but it seems to be working!
Without proper governance in this area, it can become unclear who wrote customizations, what exactly each one is doing, and what the dependencies are to keep them working. People come and go, requirements change, and without proper governance it can become impossible to understand the status or impact on your farm. If something goes wrong, it could feasibly cost the company time and money, so something needs to be done.
As I have discussed previously
in my blog, substandard customizations can have a negative impact on a SharePoint environment, both on-premises or cloud hosted:
Farm solutions can have a negative performance impact on the entire SharePoint farm, so not only on the web application they were deployed to. For example, a malfunctioning timer job can block other timer jobs.
As the name “Full trust farm solutions” suggests, they have almost unlimited access to the SharePoint farm. Code can run under the web application pool account and timer job code runs under the timer service account (in most scenarios the farm account). Therefore it’s really important to check every full trust farm solution before trusting it, especially with third-party add-ins.
But also the new app model poses an entirely new security risk, now that a lot of code is running on the client side in a maybe uncontrolled environment. The risks of XSS (cross site scripting), SQL injections or other security vulnerabilities have been there before, of course. But now when running more and more code in a shared environment hosted in the cloud, like in SharePoint Online/Office 365, suddenly these security gaps are exposed to the public, making it easier for perpetrators to gain access or even modify your data.
- Dependencies and stability:
An important part of any governance strategy is to understand what customizations you have, what they do, and exactly how they have been implemented.
How can we write good SharePoint code?
Quite a while ago (in 2009) Microsoft published 10 best practices
for SharePoint farm solutions. Even though the blog focuses on SharePoint 2007, much of it is still valid for farm solutions in SharePoint 2010 and 2013.
The problem with it and similar guidance on blogs is that a lot of it became obsolete with the shift to SharePoint Online. Pay attention to the requirement to prepare your code now for future updates and migration if you are still developing for SharePoint on-premises. Even worse, thousands of SharePoint developer-focused blogs and forums on the internet are full of false or at least questionable guidance and code solutions. Sadly, many developers tend to just copy & paste code snippets of a solution without even giving it a thought or thorough investigation if this piece of code should be really used. This might minimize the costs and time to finish their projects, but in the end, the customer will pay the bill when realizing that poor code caused high maintenance and operational costs, or needs to be re-implement entirely when upgrading to a new SharePoint version.
Here are a three examples that might make you reconsider your current practices and show pretty clear how hard it is to get the right up-to-date guidance what to do and what to avoid:
- Use WebTemplates instead of Site Templates when creating custom templates.
While this is per se true for full trust code, the recommendation nowadays is to avoid as much declarative code as possible, including List definitions, Content Type definitions, Site Column definitions and List Instance definitions. These are only partly available in SP Online (e.g., through sandboxed solutions) and cause major maintenance problems when changes need to be applied. To see how to code these types of SharePoint artifacts with CSOM instead, I highly recommend you to take a look at the Microsoft Office Developer Patterns & Practices open source project on GitHub, which comes with plenty of samples and common usage scenarios.
- Never increase the throttling settings above recommended settings, even if it seems to cause no obvious issues
This advice is more relevant than ever! Not only should you not increase the throttling on-premises, you just can't do this in the cloud. So it is wise to just plan your application architecture accordingly so that you don't run into the risk of hitting the limit. This could mean, for example, using a custom database in a provider-hosted app instead of SharePoint lists.
- Run SPDisposeCheck regularly to check for memory leaks
Checking for memory leaks in full-trust SharePoint code is very important to avoid unexpected behavior of the solution or crashes of IIS. Unfortunately the guidance to use SPDisposeCheck is extremely misleading! SPDisposeCheck had its last release for SharePoint 2010 in 2010. At this time, SharePoint was still running on the .NET Framework 2.0 and hence SPDisposeCheck was built on the same framework. But with SharePoint 2013, the framework version got updated and suddenly SPDisposeCheck cannot analyze the assemblies anymore! Even worse, it is not warning the user, but rather give you a false sense of security by not reporting any issue at all! That is why Microsoft finally removed the download of SPDisposeCheck, but there are of course many places on the web to get it anyway.
Just these examples show you already how hard and complicated it is to make sure your SharePoint Code is of high quality, secure, performant, upgradeable/future-proof and follows best practices. Even harder is to govern this code when it is running and used in your production environment or needs to be migrated to a new SharePoint version.
Don’t forget custom code in your governance strategy
Governance is essential for a successful SharePoint implementation. While most governance strategies focus on business processes, rules, audits, and strategies, custom code is nearly always forgotten. By following the best practices above, and using automatic tooling, custom code can be made part of the governance strategy.
Companies can go even further and record individual features and customizations, the business requirements behind them, a version history of changes, and even the author’s names as part of formal SharePoint governance documentation.
Governance, around custom code or more business-focused areas of SharePoint, can be hard to implement at first and difficult to keep going in the long term. But you will certainly be glad you put the effort in when the day comes to update or rework the system.