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
- Start building a SharePoint Governance Plan – Real World by Benjamin Niaulin,
- The SharePoint Governance Manifesto by Ant Clay and
- a plethora of articles by Christian Buckley
- and many more by well-known SharePoint experts.
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 its 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 we have discussed previously substandard customizations can have a negative impact on a SharePoint environment, both on-premises or cloud-hosted:
- Performance:
Farm solutions can have a negative performance impact on the entire SharePoint farm, so not only on the web application they were deployed to. E.g. a malfunctioning timer job can block other timer jobs.
In the brave new app world, bad performance is usually exposed on the users’ side and often caused by unnecessary requests to the servers and inefficient JavaScript code (I highly recommend reading the SharePoint JavaScript Context Development blog series of my colleague Hugh Wood to learn more about coding JavaScript the right way for SharePoint). As you can imagine bad performance can not only cause problems in the infrastructure but also a lot of frustration for the end-users and eventually it slows down or prevents the adoption of SharePoint as a business platform.
- Security:
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 3rd 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/Office365, 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:
Farm solutions and apps depend on many other components, which may have an impact on stability (e.g. 3rd party assemblies or JavaScript libraries, resources, etc.). The dependencies may not be clear from the documentation and are often only visible by trial and error.
So 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 has published 10 best practices for SharePoint farm solutions. Even though the blog focuses on SharePoint 2007, many of it is still valid for farm solutions in SharePoint 2010 and 2013.
The problem with such and similar guidance on blogs is that a lot of it became obsolete with the shift to SharePoint Online but also the requirement to prepare your code already now for future updates and migration if you are still developing for SharePoint on-premises. Even worse, the 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-implemented entirely when upgrading to a new SharePoint version.
Here are 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 on 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, 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 do 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 gives 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.
For this reason, we have created the SharePoint Code Analysis Framework (SPCAF) that helps you to analyze all the server-side (SSOM), client-side (CSOM), JavaScript (JSOM), and all declarative (XML, HTML, CSS, ASPX) code of SharePoint solutions (.wsp), apps (.app), executables (.exe) and assemblies (.dll). It allows you to choose between pre-configured or your customized rulesets for different target SharePoint versions and development models, detects code issues, memory leaks, security risks, etc. and generates reports on dependencies, calculates metrics, documents the application, and analyzes the ability to upgrade a farm solution to the app model.
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, 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.
Find about more about how SharePoint Code Analysis Framework (SPCAF) can help as part of your governance plan.
