On Gardens and Governance (4th post)
This is the last in a series of posts that uses the analogy that looking after SharePoint in your organization is a little like looking after a garden. Without some form of control over it, it will quickly deteriorate and end up as something that is neither a pleasure to use nor something from which you derive benefit.
Without being expert gardeners or professional horticulturalists, we've simply stated that maintaining a garden consists of three core elements:
- Maintaining what's already there
- Planning for the introduction of new elements
- Removing that which is no longer needed or wanted
The first post that provides the introduction can be found here: On Gardens and Governance (Post 1)
The second post that discusses the need to maintain the existing state can be found here: On Gardens and Governance (Post 2)
The third post that discusses the need to cover the mechanisms for introducing new elements: On Gardens and Governance (Post 3)
This post is going to discuss the removal of content, sites, and people from the SharePoint farm(s).
I think that this aspect of governance is the one that marks out those companies and organizations that are truly focused and serious about keeping their environment running smoothly. Why so? Well, it's because this area touches on the delicate relationship that can exist between business departments and IT as well as vendors and outsourcers that might be in play. Taking something away from people is more likely to make them suddenly become very vociferous. As such, when we take things sites or content away from the business, we need to ensure that we do it with much collaboration and consultation.
So, why is it important to make sure that data and sites should be stripped out from the SharePoint deployment? It's because the uncontrolled proliferation of data and sites within your SharePoint implementation can negatively impact the information architecture, operational performance, and platform stability. This, then, can undermine the capability to provide a viable platform that can respond to new business needs. If the farm is full of stale sites and content that is no longer in use, it will soon become impossible to create new sites or to find one’s way to the freshest content.
Removing Content
When removing content, the use of Information Management policies becomes a great asset. At the very least, the use of Site Quotas will stop sites from getting too big and unwieldy. Organizations can have a very great many site collections deployed. Additionally, the management of these site collections is often delegated to business-unit or departmental administrators and this can lower the overall burden on the IT staff. Without Site Quotas in place, site collections can continue to grow in size until they consume all available disk space capacity. Alternatively, they can grow beyond the limits of the architectural designs for the farm and they can then have an impact on the overall performance of the system. All this can be negated by the simple use of Site Quotas.
Site Quotas allow you to specify the storage limit for the maximum amount of data that can be stored in a site collection. In addition, triggers can be used to send e-mail alerts to the site collection administrator and these can be used to take preemptive action before a disaster occurs (such as disk space being completely consumed). Rather than applying individual quotas to each site collection, it’s a good idea to use Quota Templates. These can then be applied to any Site Collection and this introduces simplification and consistency into the management and governance of the SharePoint farm.
The use of Retention policies are another useful mechanism to make sure that content is removed from the various sites as quickly as possible. The Information Management Retention Policy is used to make sure that content held on a site is not kept for an unnecessarily long time. And because these can be automated, it becomes a great way for getting rid of content that has become stale.
I find that the Retention policy can be very powerful as it lets you define a series of stages with associated actions. In this way, you can define something that will fit the precise needs of the business. In this way, it is not IT simply dictating to the business. Rather, IT is able to serve the wider organization by making sure it complies with relevant legal and business mandates.
The actions that can be performed at each stage include moving the content to the Recycle Bin, permanently deleting the item, transferring it to another location (by way of the Office File web service), starting a (possibly custom) workflow, declaring it a Record and deleting previous drafts/version. In addition, it is possible to simply skip to the next stage in the Retention Process.
For example, a three-stage policy could be defined that applies to a certain content type. This could delete all previous versions of the document after one year, declare it as a Record and leave a copy in the site after two years, and the permanently delete the copy after three years.
Removing Sites
Now, as well as Content becoming stale, it is also possible for Sites to become stale and be no longer needed or used. For the overall health of the farm, it is essential that these stale sites get removed.
You can help to free resources that are used by sites that are no longer needed by making use of the Site Usage Confirmation and Deletion capability. Site collections can be deleted automatically after a specified period of inactivity or it can depend on the Site Collection Owner’s response to a notification. In this way, subject to interaction with the Site Owner(s), site collections can be automatically deleted after a certain period of time. This always involves Site Administrators and it provides them with an opportunity to override the deletion process, if needed.
When you set this up, you need to think about how long you should wait before you consider that a site is no longer being accessed. If you make this too short, you will simply annoy Site Owners by constantly asking them if their site is still needed. However, if you make this too long, you will run the risk of stale sites still being available when they really should have been removed.
You then need to think about how frequently you send these automated emails about the impending deletion of the site. Although you can send out daily emails, it might be better to use the weekly or monthly option.
The email notification that is sent to the Site Owner includes a link that can be used for them to indicate whether the site is still in use or whether it can be considered inactive and no longer needed. Indicating that it is still active simply extends the certification date and SharePoint will no longer send email notifications until the next period. Alternatively, they can delete the site and they will no longer be sent the notification emails.
Periodic emails are continually sent, as defined by a Site Administrator, until the number of times to notify the Site Owner has been exceeded. At this point, the Site Collection can be automatically deleted.
It must be pointed out that things can go wrong with this approach. For example, imagine that the Farm Administrators have specified a set of four weekly notification emails. And imagine that the Site Owner has the opportunity of a lifetime to go on a month-long holiday. They are going to be very upset when they return from their holiday to find that their site has been deleted.
There are a few things you can do to avoid this situation. Firstly, it is most important to have more than one Site Owner. This ensures that the email notifications are sent to more than one person. This means that even though one person might be away for the whole duration of the notification period, the other person should be able to respond to the emails.
Another option is to make sure that the site is backed up before it is deleted. Whilst there’s no mechanism to do this “out of the box” there are a number of open source code projects and vendor tools and utilities that implement this capability. If I was running a SharePoint farm, I’d certainly make sure this was something I made sure was in-place!
People
Within your organization, there will be a continual changing of people from one role to another as they take different jobs or are given increased (and maybe decreased) responsibilities. As these people move about, you will almost certainly need to ensure that they are given access to new sites as well as being removed from having existing sites.
SharePoint pushes this responsibility to the Site Owner role. As such, you should make sure that your Site Owners have sufficient training and understanding of this matter. It is, in fact, quite crucial as not removing people from certain sites could lead you to exposing information to which they should no longer have access.
I would expect that this action could be one that Site Owners overlook. After all, they lead busy daily lives and does it really matter of they don’t remove someone from site access? To this end, you might like to consider a regime of spot-checks in which a Site Owner needs to confirm that all the people who have access to the site really do need to still be allowed to do so. And this could form part of your regular governance meetings.
In addition, when people leave your organization, it is most important that they are removed from having any access to your systems. This is crucial if you have some form of extranet or remote access solution. After all, if they no longer work, why do they need access to your systems and materials?
We call this the “joiners/movers/leavers” or JML process and the SharePoint Governance that you are responsible for will need to link into a larger control mechanism used by the organization. The HR Department will be the best place to go to for this information. This is because they get deeply involved when a person joins, moves or leaves.
Summary
Hopefully, this series has given you a different perspective into SharePoint Governance. By taking an analogy, it can help you think about the various tasks that you will need to be implementing. The reason for using an analogy is that the picture that is painted can be stark and clear and obvious.
Good luck with the gardening tasks for your SharePoint farms!