Setting some context
Like on almost everything in life, there are different opinions on using site collection quota.
In his blog post “Controlling Sites Sizes with Quotas” Michal Pisarek proposes to use Site Collection Quotas and they should be one of the first things to be considered in your SharePoint Governance plan.
I do agree with him, but I also firmly disagree.
Why don’t I agree with the obsessive (IT) need to implement Site Collection Quota?
During a workshop I was delivering to the business key stakeholders for a SharePoint project (it was a workshop to gather business requirement for a SharePoint implementation) the topic of quotas presented itself. Without telling or asking anything about quota, the business representatives came up with this question. Technically it is not a question because the is no question mark in the sentence, it was more like a proposal or even a requirement.
“If our Enterprise IT strategy directs us to use SharePoint and use this tool to share files between countries and continents then we don’t need (read want) quotas.”
(They were at this moment not able to share information on file shares easily between different countries since file share servers are hosted in the office or country where the files were primarily stored)
Now, from an IT perspective this is a NO-GO because IT wants to (draconic) keep control on disk space consumption and storage capacity planning.
So my response to that was (I was also surprised of this statement, but understood exactly what they meant) asking them on how they can assure that only relevant information will be stored in their sites.
That old, outdated content will be removed. You know, people tend to start cleaning up disk space when they run out of it. And how can we make sure they will not have (too much) duplicates in their sites. And that’s for me the part where governance enters the discussion.
So what is a possible solution?
My solution is not just 1 solution. It is a combination of different solutions that can fulfill the business requirement (the need for “unlimited” disk space and freedom just like they now have on their file share) is not to use Site Collection Quota (or use a very big quota) and define content types (something you should always do on your SharePoint sites)
After defining the content types, you can configure retention policies on these content type. Just to make sure that legal documents don’t get deleted, after 2 years. And you probably don’t need to have your minutes of meetings available for 7 years in the production environment.
An extra step (and maybe a highly recommended one, although I’m lacking real life experience with this as we speak (Jan 2012)) is that this retention policy actually moves files out of the SharePoint SQL database into another system. Like a tape or a BLOB. There are tools available on the market where you can do storage optimization and create rules that will move documents (or versions of documents) to a BLOB. So you offload these document from the underlying SQL database to alternate tiers of storage like a SAN. This will benefit the sizes and numbers of content database, but it is also a good thing for search and indexing. If you can keep the relevant content in your content databases lower, by off loading these files to BLOB, the overall performance of your database will not decrease (or decrease less) compared to when you keep all these files in the database.
Delivering Business value or loosing control over disk space capacity?
My point of view is that these solutions provide value to business users. Even though IT people will most probably freak out on the thought about not defining a quota, when you define the technical governance correctly and have the proper tools (like Docave Storage Manager from AvePoint and Storagepoint from Metalogix) you’ll be able to provide a trustworthy solution.
Defining and configuring site collection quota requires less effort then defining enterprise wide content types, retention policies combined with offloading the SQL server.
But I think it is worth it.