Whenever a portal, intranet or other specific enterprise application is built, there is usually a project associated with it. That means there’s a specific deliverable expected with specified time frames, guidelines and the participation of a development team and/or a partner. Some boundaries and rules are defined and usually the maintenance is fairly easy.
Strangely enough, in many cases Collaboration does not follow that model. For the lucky ones that did build an application with SharePoint before doing Collaboration, they usually do it the right way. But when an organization starts using SharePoint as a Collaboration platform, this is where I see many misses and improper preparation. At that point, SharePoint is used for anything and everything which creates issues in both the medium and long term. This is also where the confusion resides about SharePoint being a full application that does not require development. It may be true with basic Collaboration, but surely not in application deliveries.
So in this post, I’ll focus on what we do with Collaboration and how to properly prepare. I’ll also highlight some exceptions to the rule.
In my previous post, I talked about the SharePoint services pie graph. Collaboration usually sits in the Sites and Communities slices. It had its own slice in the 2007 version of the chart.
Another very useful graphic, shown below, is the Intranet Pyramid Model. This comes from the Office SharePoint Server 2007 Governance Checklist Guide.
In this pyramid, Collaboration can be referenced in the Projects & Workspaces and Groups & Teams layers.
As you can see, because Collaboration sits in the middle, the rules are often mixed. Manageability may be less rigorous than a portal, life cycle will be a mix of temporary and permanent sites, ownership will vary and type of access will be a mix of read and write.
Governance on Collaboration will be focus on site creation and quotas. In term of security, this is where I will see more variants. Some organization will give real ownership of sites as others will simply lock functionalities and rights. Also, it is the area where decisions about SharePoint Designer are the most difficult.
Before we continue, here’s my latest version of the content organization decision matrix for SharePoint 2010. Resources and details are culled from this article.
Ok, so let’s examine a “bad case” scenario that I’ve seen in some large organizations.
You’ve been ask to install SharePoint and you will be the one that maintains it. You are now the SharePoint Subject Matter Expert who has to deal with everything from the farm setup to the document library creation. At this point, the team is composed of you and maybe another person. Site and resource governance is not on the road map.
You also start to receive site creation requests on a regular basis, and depending on how you work and your organization, you will ask questions or just deliver them.
What you need here, because of the unknown, is to put some boundaries and rules in place. This way, you will keep your options open for the future and will help yourself as much as your organization.
When you deliver the requested site, you should create a site collection and not a sub site. You will also apply a quota to it. Quota size will depend on your available SQL space and size of the organization. If you are unsure, give between 1 to 5 GB.
You may say that isn’t much, but I’ll explain later when and how to increase that size.
By default, it is unlimited and can increase your content size significantly and/or have your organization reach their quotas too quickly.
You might be surprised what a group can do with SharePoint and SharePoint Designer. I’ve seen business critical application pop out of nowhere in what was supposed to be a SharePoint trial farm. Get ahead of this. You will better understand what types of services your organization are expecting from SharePoint when people fill in a form or survey, .
So what type of questions should you ask?
People and Traffic:
Content rules (You don’t have much power here, your IM group needs to be involved)
Because of Site Collection, sites can be moved, recovered or resized more easily. Like I mentioned in my previous post, moving a sub-site can be tricky and limited to content.
Because of quotas and the form, you prevent someone from using your SharePoint application for the wrong reasons. Large departments that do not have content management are more than happy to use SharePoint with its versioning capabilities. The issue with this is that you don’t have an unlimited capacity and your infrastructure was probably not built to sustain a large amount of documents in SQL. Some proper planning is required.
Because of versioning limits, you’ll prevent your organization from quickly reaching their site collection quotas and can also dramatically reduce your storage requirements. By default, there are no limits.
With the form, you can see how content should be categorized. Also, you can see if you need a different web application or not. Let’s say that in Collaboration you do not permit video or audio files but you need to enable it on one site, you already need two web applications as this setting is at that level. Another example would be the maximum file upload size that you would permit.
Other considerations that we’ll now look at:
When you create a web application, you define at least one root URL. For this example, we’ll use http://collaboration. The web application now needs to service one or more site collections. Of course, at the root, you will want http://collaboration to be a site and answer to a request. This is the root Managed Path.
Out of the box, when you create a second site collection, you do not have the option to put it on the root as there is already a collection there. Instead you see a dropdown with the option to add it to sites. This is the second managed path available out of the box. When you create a third collection, you still have the option to create it under sites.
There are two types of managed paths: Exclusive and Wildcard. Exclusive can only have one site collection while a wildcard supports many. You will understand that the root site collection of the Web Application is an exclusive type while sites is a wildcard. You can create more managed path in the web application but you are limited to 20 per web application.
Why would you create more managed paths? I’ll give you two examples here that can be used in a content management scenario.
Let say that you need to create site collections for departments in your organization. Also, let’s say that you put a quota of 25GB per site collection in your content management. The IT department needs to store 200GB content while HR will be fine with 25GB. This means that IT requires 4 site collections while HR needs only one. If you only have a single wildcard managed path like sites you would have something like this.
Not very pretty. Here’s how you can do it with custom Managed Path
Here’s the new look
You’ll understand that the training and support sites are in fact site collections with 25GB each. The only caveat is that if you hit http://collaboration/IT or http://collaboration/sites, no one answers.
SharePoint offers self-site creation of site collections. That means that you can give permission to people to create their own site collection without the need of a SharePoint administrator.
When someone creates a site collection, that person gets automatically site collection administrator rights. That means they can control almost every parameter that belongs to the collection. Some organizations restrict that and do not give site collection administration rights to owners. This is where a good definition of rules is required for self-created sites. It’s okay to let people within your organization to self-create site collections as long as the conditions are well defined.
A good example of self-created site collections is “My Site”. Everybody that creates a “My site” gets a site collection but with some rights limitation, a quota and properly isolated security.
Here are some things that need to be managed with self-site creation.
Mandatory Secondary site collection administrator
Topics that only site administrators can handle
Type of sites that fits well in the self-service model
Improved creation process
Since we are talking about operations, I want to bring awareness on what this solution offers and an operational perspective on it.
Since server side customizations (I’ll talk more about these later on) are used minimally in collaboration, these type of sites are usually very easy to migrate to SharePoint Online. O365 supports Sandbox solutions and Designer customization.
Advantages of SharePoint Online is the complete abstraction of infrastructure management. Microsoft takes care of the servers, SQL, required space, load balancing and fail over. All you have to manage is site collection creation. Depending on your security model, you or the owner will manage the security of the collection. You do not need to do any farm operations.
Microsoft even supports extranet scenarios where you can invite partners to work on sites with Live Accounts. And like all the other O365 offerings, single sign on with your current AD accounts is supported and centrally managed in your organization.
Since this post is already lengthy, please check out my subsequent articles that will cover the following topics: