In a SharePoint Governance Plan, it’s easy to get carried away and build a 500 pages document that no one will ever look at. Don’t worry, most of us went through this already in the past. That’s why I decided to write this Sharepoint Governance blog series, to show you that it can be achieved and that it does not necessarily need to be complicated.
In my previous post, I went over details like « What is a SharePoint Governance Plan? », « Who writes it? » and how to start writing it by establishing Roles and Responsibilities alongside a Governance Committee. I invite you to start this series from the beginning:
- Part 1 – Building a SharePoint Governance Plan in the Real World
- Part 2 – You need a logical architecture in your SharePoint Governance Plan
- Part 3 – Designing Site Requests in your SharePoint Governance Plan
- Part 4 – Site Template Definitions in the SharePoint Governance Plan
- Part 5 – User Training and Agreement in the SharePoint Governance Plan
Remember one thing though, it does not have to be a Word or PDF document. In fact, due to the nature of this ever evolving document… In some cases, it makes even more sense to build it as a Wiki. The goal of a Governance Plan is to be accessible and most of all, read. Therefore, always choose the medium in which it is most likely to be consumed.
What is a logical architecture? And why do we need one for SharePoint?
The same reason you build a physical architecture of your servers before actually rolling out your infrastructure, you’ll need one for the logical objects that make up your SharePoint. One of the main reasons we build a SharePoint Governance Plan, is to set policies and rules on how to use and interact with the SharePoint Platform. And as we build this, it’ll be a lot easier to assign these policies to things in SharePoint we have already « logically » grouped.
In my own words, the logical architecture is where I group things that will share settings, configurations and policies in my SharePoint at a high level.
And of course, this brings me back to one of my first points in the previous article: You need to know where you’re going with SharePoint. We can expect things to change in the future, so it’s important not to drill down into details in this architecture too much. For example, I usually stay at the Web Application level and sometimes go as far as defining some Site Collections in it as well when mapping it out.
Organize your architecture to help future Governance rules
As mentioned, we’re here to build a SharePoint Governance Plan that will actually be useful, but most importantly…read. Our ultimate goal, is to help people like our Power Users situate themselves and know what they can or cannot do in our SharePoint Platform. For example, if they know they need a site to manage a community for a charity at the office. Then the Governance Plan would help them know exactly in which Web Application this would go as well as possibly which Site Collection, depending on the scenario. Once in this « logically organized location » a set of policies, rules and settings would apply. On the other hand, it would also help us know what to give this person based on the needs. We then look to see in which tower does the user’s needs fit best. This will become clearer as we continue building our Logical Architecture as well as our entire Governance Plan.
Think of our logical architecture as the creation of « groups », « silos » or « towers ». Here at the office we have called them towers since I can remember, so that’s what I’ll use. We will create these towers to organize what we know will be managed similarly in our SharePoint. Here are some common examples:
- Intranet
- My Site
- Extranet
- Internet
- Collaboration
- Project
- Applications
- Search
Depending on what you are trying to accomplish with SharePoint, some of these may or may not be needed. You could even have some very different ones there. Most of them are self explanatory, I will need a Tower for everything « Intranet » or everything « Collaboration » and put my Web Application(s) within these towers. In many cases, I like to create one for what I call « Applications », which represents any sites that will need custom development in it.
I think you get the idea, if I think I will need to configure a different set of rules, policies and settings for something, I look to see if it can fit with another and put it in a « Tower ». Otherwise, I create a new Tower. Don’t confuse a Logical Architecture with an Information Architecture either, this is not where we will be identifying Content Types and navigation for our sites. It just makes it a lot easier later on as we build this SharePoint Governance Plan.
Here is what it can look like when we begin:
As we continue our Governance Plan, we will define things like « Site Templates », « Retention Policies », « Site Management » and many other things. I usually keep coming back to my logical architecture to update my towers with some of these things we will define. For example, if we later on decide that we will have 6 different Site Templates and that two of them will be for Collaboration and will come with 100GB Site Quotas; I will take these two and put them in the appropriate « Tower ». This way, when I am closer to the finished SharePoint Governance Plan, I can quickly gander at the Logical Architecture and know what in entails.
Over time, you will see your logical architecture grow into something a little more detailed:
It’s a great way to get a quick overview of your logical architecture and how things relate to each other as well as what paths you are using. Anyone opening or viewing the Governance Plan will see right away what your SharePoint looks like. In my actual plan, I tend to expand each « Tower » and write a summary for it. The diagram is very useful of course but we still need a little more information than that. I find it very useful for my users to be able to « select » one of the towers and get a summary of the rest of the Governance Plan, but applied for this particular tower. Say my Power User or Administrator looks into the Collaboration Tower, the diagram will show him a quick overview and the summary will quickly tell him the policies, rules and settings that automatically apply to this.
Building your SharePoint Logical Architecture for Governance
Personally, my favorite tool to build this is Visio, nothing beats Visio when it comes to Technical diagrams in my opinion. However, there are other tools out there like XMind and Mind Manager to help you build it. What’s important is that you can easily create and manage these « Towers » we’ve built to organize our SharePoint’s logical architecture.
And take it one step at a time, there is no need for you to overthink or put too much details into the logical architecture on day one. Things will change as you build this Governance Plan and even after that, I guarantee it. You might split Collaboration into Ad-Hoc and Project alongside one called Community. But thankfully, you’ll have a SharePoint Governance Committee to make sure you don’t build all of them at once. I won’t lie though, you do need to know SharePoint to be able to successfully complete this step of the Governance Plan. It would be almost impossible to properly split objects into « Towers » if you do not know the impact it will have in the future. You need to know what a Web Application is and what kind of settings can be applied at what level in SharePoint.
- Part 1 – Building a SharePoint Governance Plan in the Real World
- Part 2 – You need a logical architecture in your SharePoint Governance Plan
- Part 3 – Designing Site Requests in your SharePoint Governance Plan
- Part 4 – Site Template Definitions in the SharePoint Governance Plan
- Part 5 – User Training and Agreement in the SharePoint Governance Plan
