A popular request for SharePoint consultants is to help their customers build a SharePoint governance document for the organization. There are also references on TechNet, and some consulting organizations and independent software vendors have tools and/or offerings to help build one.
In my role, I mainly work with SharePoint farm administrators that are responsible for maintaining one or many SharePoint farms. At most of my engagements, I see the same challenges that these people face every day when no governance is present.
I also want to point out that many factors can be affected by the addition of other tools to manage SharePoint. I’ll focus on what SharePoint offers out-of-the-box. Feel free to share your personal point of view, but I am trying to help organizations that work exclusively with SharePoint and no additional tools.
You’ll also notice that my views in these articles are primarily based on infrastructure-related concerns. Consultants and developers need to look at SharePoint from a business requirements and application perspective and sometimes are not involved in the infrastructure portion. The farm admins need to insure that the infrastructure can sustain the current and future services offerings.
In many cases, the SharePoint platform was delivered to address a specific service or application. At that point, it is usually easy to maintain. Risks or issues arise when SharePoint is used to address scenarios that were not planned. Because SharePoint continues to have a very rapid rate of adoption, this becomes a somewhat common scenario. The other typical scenario is where SharePoint is let loose in the enterprise and people see its potential and start to use it for many services without proper preparation. Many farm admins are caught by surprise by the volume increase in both traffic and size. I have seen many “pilot” farms become production environments with all the associated issues that arise from such “organic” or ungoverned growth.
The first thing I tell my customers is to think of SharePoint as multiple service offerings instead of an application or platform. It is in the context of these different offerings that I will write my articles.
Like me, I am sure you have seen this SharePoint capabilities pie graph many times and may think of it as a “pre-sale” thing. For me, it’s the base on how I help people manage their farm(s). When you know what services you are offering with SharePoint, you can start defining some elementary rules to help you.
What’s important to understand is that each of the pieces of this pie can require different approaches and governance. These differences will help you build the definitions and rules of your services. So what are the factors that can impact your choice of approaches?
From an infrastructure stand point, your challenges will be:
From an application stand point:
And what will be mainly impacted based on the services and associated requirements? The following:
Typical questions or comments I receive that are related to this:
With all this said, where and when do I draw the line? This is what I’ll attempt to articulate here.
One of common mistakes I see is the mixing of services. A common example I still see is building an intranet and creating collaborative departmental sub-sites to do collaboration or, even worse, document management.
So what are the issues here?
So what are the challenges caused by the mixing intranet and document management requirements? The following:
* Be aware that SharePoint, out of the box, is limited when it comes to backing up a sub-site. The smallest container that can be restored with full fidelity is a site collection. When you backup a sub-site, you are in fact exporting and importing content. This works well for content, but if you have functionality like columns lookups, workflows, recurring meetings etc., your restored sub-site may not work as the customer expected. Also, a site collection cannot be span on multiple databases.
To implement such a scenario with minimal governance:
Now even with this minimal approach to governance, you can still hit scalability limits:
In the case of collaboration, usually the site collection sizes are easily managed, but if we are talking content management with thousands of departmental documents, proper preparation and analysis is mandatory.
Another big challenge is to decide when and why you need a particular container. I designed a graphic a couple of years ago that I’ve used many times since to try show the configuration and limitations of each container. This one is for SharePoint 2007:
The numbers are much higher in SharePoint 2010 and other factors like site collection isolation in a database can affect these numbers. We will cover that in more details in subsequent articles.
In upcoming articles, I’ll also dig deeper on how you can govern and maintain the different services, such as:
I hope this introduction got you interested. Your feedback is appreciated and will help define the focus of this series of articles.