|Brien M. Posey|
When considering SharePoint governance, remember that an organization is not static. The volume of enterprise content stored in SharePoint's lists and document libraries is almost always going to grow exponentially over time.
The number of SharePoint sites created by individual departments in your organization is likely to grow steadily as well, so make sure that the SharePoint governance plan you create today will still be viable tomorrow as the scale of your organization's SharePoint deployment increases.
Setting quotas for the long term
One way to plan for SharePoint scalability is to determine whether the quota limitations you have set in your governance plan are going to remain practical over the long term.
Because the volume of data that's stored in SharePoint's lists and libraries increases exponentially over time, users will eventually reach the quotas you have established. When this happens, users typically end up having to purge old data to make room for new data.
How can you know for sure whether the quota limits you impose are going to force users to delete documents that they need for their jobs?
The answer is that there is no way to be sure the quota limits that work fine today are always going to be appropriate. So design your governance plan in a way that allows you to adjust limitations as business needs evolve.
There's not a good rule of thumb for SharePoint capacity planning that works in every situation. History has shown that as new versions of the applications used to produce various documents are released, the document format also tends to evolve and become more bloated.
You can start by making a basic assumption that your volume of data is going to double every two years. The reality might be that the data may increase much more rapidly if your company is growing.
|Factor in Compliance in Your Scalability Equation
If your company is subject to compliance regulations that mandate the long-term storage of certain documents, you need to consider the impact on your back-end SQL Servers. Your best bet might be to create a SQL Server dedicated to the long-term storage of seldom accessed documents. SharePoint has several ways for figuring out how recently a document was used. By offloading those documents to a different database on another server, you can help keep your primary SQL Server databases performing well. Many organizations also use a document-archiving mechanism to ensure that even if a user does delete a document to make room for more documents, there is always a way to get that document back should the need arise.
Or it may increase a lot more slowly if the company decreases in size or if it doesn't adopt new applications or produce many documents.
If you are serious about planning for SharePoint governance, then you should be vigilant about your databases.
It's easy to forget that the documents stored in SharePoint lists and libraries actually reside in back-end SQL Server databases. As the volume of data in the lists and libraries increases, database performance typically decreases.
So plan ahead and budget for additional or higher performance SQL Servers. That way, you can keep SharePoint performing well, even as the volume of data stored in the various document libraries increases.
Setting criteria for mandated upgrades
At what point should you expand? Make sure your SharePoint governance plan covers that too. Come up with a set of criteria that defines when it is necessary to add resources to an existing SharePoint server or when to purchase a new server.
Technically, this is capacity planning, not governance. But making capacity planning part of a governance document gives SharePoint administrators the ability to perform any necessary upgrades, because the "rules" in the governance document say that they have to.
Getting top managers to sign off on upgrades is always easier when it isn't going to cost them anything in the near future. So if you define the conditions that warrant an upgrade or a new server in the governance document– and can get management to sign off on that document–then it should be easier to get new storage capacity when you need it.
As you draft this portion of the document, keep it open-ended enough that it will remain relevant as technology changes. For example, you shouldn't say "additional storage needs to be purchased when the available storage falls below 50 GB." A statement like that might be fine for today, but five years down the road it could be that having 50 GB of space remaining would represent a critical condition.
Consider wording in your governance document that uses percentages instead of defined amounts to give you more flexibility. For example, you might say that additional storage is required when the available storage space falls below 10%of the total capacity. Each SharePoint deployment will be different, so figure out which numbers are appropriate for your own organization.
So what do you do if you already have a governance document in place, and it doesn't make any provisions for planned scalability or other types of capacity planning? One option is to scrap the document and start over, but you probably won't have to do anything that drastic.
The first thing to do is explain to management that although the governance document is fine for today, it doesn't address the issues that the IT department will face in the future as the organization grows. Once you have received management's blessing for updating the document, then it may not be a bad idea to survey the department heads on how they plan on using SharePoint in the future.
Although hearing from department heads might be valuable, it may also prove to be a waste of time. After doing this, I've found that managers have a tendency to say one thing and do another. Even so, I have had at least two situations in which asking some basic questions up front kept me from making some major mistakes in my capacity planning efforts.
Assuming that your governance document is in fairly good shape, you will probably be able to easily amend the document by adding your new capacity planning and scalability policies to it. At least be sure to review the rest of the document to see if you need to make any other changes.
You don't want to have to repeat this process a year or two down the road. Still, you should include a provision in the document that gives your department the right to revise the capacity planning and scalability section in the future, should the need arise. That way, you won't have to seek permission from management every time you must revise your scalability plans.
|Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.|