True story: About one year ago I went to Microsoft TechEd in Berlin and attended all types of sessions. I was there to learn about technology, and I somewhat accidentally attended a session on SharePoint governance. I didn’t really know what that was, and frankly I couldn’t have cared less. I am a techie, and this was some sort of new fad that the global companies were all raving about. Some sort of corporate mumbo jumbo that was useless when it came down to doing some real work. Not a single line of code in the entire talk, just a bunch of Visio.
Does that sound familiar? Can you identify yourself in that story? If so, I will try to explain to you why this governance thing is being discussed so much, and why you actually do need to be aware of it, even as a hard core techie.
Let’s talk about traffic. I don’t mean network traffic, I mean the kind most of you get into on a daily basis out in the streets. When you get into your car, or I on my bike, there is a lot that goes on between leaving home and getting to work. First, there are all the roads we need to navigate. Then there is the weather that can cause the road conditions to change. Lastly, there are all those other people out there on the road who are also trying to get from point A to point B. It is fair to say that the traffic on our roads today is a complex system, and no one really has a grasp of the ‘overall plan’ for the day. Somehow we all make it to where we need to go most of the time, and when something does go wrong, it usually degrades in a way that is acceptable. By this I mean that fatal accidents are fairly rare as opposed to fender benders, and fender benders are rarer yet when compared to being late due to congestion.
So why am I on about traffic? Because I think this extremely complex system that is used by a huge number of human beings at the same time could not work if it weren’t for governance. There's that word again. Let’s see what I mean by governance in terms of traffic. Those of you who have driver’s licenses should know a good deal of traffic governance, by that I mean your local traffic laws. Every new driver is taught that red lights mean stop, what a yield sign looks like and what it means, and how fast a vehicle may travel on a given road. These rules are what ensures that we all behave in a given way on the road, and thus don’t run into each other very often. Being human means we don’t always get it right, but that’s another story.
There are other rules that the average driver doesn’t know that are just as vital to the success of our daily drive. What type of road surface is used? What is the minimum radius of a turn on the expressway? These are rules the road engineers need to be aware of.
There are also specific situations that warrant their own set of rules and behaviors. When something does go wrong, the emergency response teams have a very well defined protocol to handle that event, ensuring the best possible outcome for those impacted and the quickest possible return to normal conditions.
Lastly, I want to mention the massive differences in how traffic operates in different locations. Compare rush hour in Bangalore http://www.youtube.com/watch?v=0cdUPOvSXOo with rush hour in Berlin http://www.youtube.com/watch?v=6jUc6dHcbCo and rush hour in Utrecht http://www.youtube.com/watch?v=UlQYP4WN-5w. You immediately see there are some localized differences. Some places drive on the right side of the road, some on the left, and some have dedicated lanes for bike traffic. Some places have a visible order and structure to the driver's behavior while others exhibit what looks like chaos to the outside observer. Nevertheless, each is designed with a single purpose to get everyone from point A to point B as safely and quickly as possible.
So what does all this have to do with SharePoint, and specifically SharePoint governance? As mentioned, the traffic system is very complex. What makes it complex however are not the roads or vehicles but all the individual people that interact with it at any given point in time. Each with a different goal in mind, and each not aware of the needs of the others in the system. What makes it work, is the adherence to the rules and guidelines that belong to that system.
If we compare the road system to SharePoint, we can see that there are many similarities. I would argue that the bits provided by Microsoft on the SharePoint DVD are the equivalent of concrete, asphalt, vehicles and traffic lights. They represent a possibility, or opportunity to create a useful (and complex) system. When we start a new SharePoint project, it is vital that we decide on rules and guidelines with which we will use all the components available to us. We may not even want or need all the components at all places. Just because there are thousands of road signs available to a road designer, doesn’t mean it is useful to use each and every one. How helpful is this scenario?
The first step we need to decide is why we are building our SharePoint system to start with. A road crew generally needs to build a road to connect two places, to improve traffic flow in a congested area, or to upgrade a broken down old road. Our SharePoint project needs to be just as clear in purpose. Replacing an old intranet that doesn’t work anymore, connecting two remote offices so they can share information. Those are very clear and simple reasons that make it easy to understand why we are starting a new project. Saying that we need to “improve collaboration in the enterprise” is simply too vague and would be the equivalent of saying that we need to build a road to “enhance the citizens driving experience”. I’d like to see a city allocate budget to that project.
Once we have a purpose, we need to decide on the rules and guidelines that we will follow so that we can achieve our purpose. There will be different types of rules for different scenarios. Some will be very hard and some quite flexible. Road crews can choose which end of the road to start at, or even which sections to work on at what time. They can't however just decide to route the road through a nature reserve because it makes it easier.
The rules will also not be the same for all organizations. We may have a different set of goals and a different culture. In road terms, the Netherlands sets speed limits that are quite absolute. There are many speed cameras and getting caught gong just a few km/h over will result in a fine. In the Toronto area, going 20 km/h over the limit on the expressway will generally not raise any interest from the police. As a matter of fact, I remember it being somewhat rude to go any slower. Culture has a huge impact on the rules we follow and how.
In SharePoint projects, we will have to determine the rules that work for our organization. Some hard rules will need to be set, such as access rights for instance. More flexible rules may include good practices with respect to metadata use and version control. We also need to determine the rules and guidelines for different target groups and different scenarios. Our end users will not be interested in the rules regarding database maintenance, but our IT department will need to be very aware of these. We also need to consider special cases such as system failures, and the procedures that need to be followed in order to respond to these. In the traffic scenario we can think of the highly organized Emergency Response Teams. In SharePoint we can think of disaster recovery plans. How often do you think the EMTs practice their routine, and how often does your project practice their disaster recovery?
Having determined these rules, we should have a good place to plan our project in terms of specifics. How will we build what is needed and who will be involved. This activity happens on most projects today, but it’s critical to know that this plan should be a derivative of understanding why we are building something, and what the desired behavior with that something is. In road terms, we can plan the best roundabout out there, but we need to know that it’s purpose is to slow down driver’s top speed but at the same time not forcing them to stop completely. If our goal was to purely increase traffic flow, an underpass may have been a better solution.
Once we have a good idea of the rules we think we should be following, we need to create a strategy that will ensure all the people interacting with the system will understand these rules and guidelines. Think how much effort is spent training new drivers. We may find this annoying when we go through it, but ask the average driver if they would prefer that people ‘learn by getting out on the road’ and I think most would think this a terrible idea. There is a reason we have drivers licenses. In the SharePoint project this translates to training. We need to ensure that our users are shown what hey should and shouldn’t do. This includes explaining our general purpose for the existence of the system as well as the specifics of how to perform certain actions. If you only know how to drive the car, you are not yet ready to get out on the road.
Lastly, we need to know how well our system is doing. One of the most famous and successful traffic solutions on the planet are the German motorways, known throughout the world as ‘the Autobahn’. A key ingredient to this complex system is monitoring. There is an entire team constantly monitoring the situation of all the roads in real-time and adjusting the speed conditions etc. to ensure most optimal operation. Our SharePoint projects will generally not have the luxury of such monitoring, but that doesn’t mean we can forget it all together. We need to define measures of success, and keep an eye on our SharePoint solution to see how it is performing. This includes measuring technical data such as bits and bytes but also more human data such as user satisfaction. We can then react to our measurements and tweak the system or the rules and guidelines around the system to improve the overall performance.
So what about Governance? We’ve somehow lost that word in the last few paragraphs. Governance is a collection all the rules and guidelines that get our project from the initial vision to a operating and continuously adapting solution. Governance is everything from the hard rules of how often we perform a backup to the soft guidelines that let our users know which content type they might want to use for a given document. It also includes the rules of the project itself, such as what type of user training do we perform, and how do we measure success. There are many facets to Governance in a SharePoint project and each of them is crucial to the overall success.
I hope you now have some understanding of what this Governance thing is, and why you should care about it regardless of what your role on the SharePoint team. It comes down to you and your team, do you want to build the autobahn, or are you ok with spending a lot of time, money and effort on this:
PLUG: I have to give credit to the SharePoint Information Architecture and Governance Master class since the idea for this blog post originates from discussions during that class and I would not have written this if it wasn’t for that fantastic course. If you want to know more about this topic, I highly recommend attending.
Also thanks to 21 Apps and the work they are doing on Governance in the SharePoint space, awesome work guys, keep it up.
Friday, November 04, 2011
Tuesday, November 01, 2011
One thing that all sites (SharePoint or not) need is some form of navigation. This is true for all sites, not just public sites. There are plenty of types of navigation elements, but if we stick to public sites, there tend to be the following few types:
- Contextual navigation. This navigation can manifest itself in many ways, sometimes as a tree view, sometimes as a flat list. In any case, the content of this navigation is usually different per page, or at least per section of the site.
- Reverse Navigation (Bread crumb). This is some type of path allowing the user to see where in the site they are, and to navigate back the way they came from.
In SharePoint, we have out of the box elements that provide all three types of navigation mentioned. They may not work exactly how we need them, but they are there for the most part.
On projects I was involved in, we never ended up using any of the built in navigation controls. Even thought they have been improved for SharePoint 2010, they still render html that never happened to fit the html we needed for the site. So how did we solve our navigation needs? There are a few options that I have used, I’m sure there are others out there:
- Static, hard coded links. This scares the crap out of some people, but I argue there are still plenty of scenarios where hard coded navigation is perfectly acceptable. As an example, take the apple.com website. How often do those links across the top change? Almost never. And when they do change, it is likely due to a very rigorous change management process. This is a case where I would advocate a hard coded solution. On the rare occasion the links change, update the master page.
Advantage: Best performance, Easy
Disadvantage: Potential for dead links
- Custom navigation controls based on SharePoint navigation providers. Just because the web controls that SharePoint delivers may not suit your needs, the navigation information they contain may be just what you want. In this case, use one of the providers that SharePoint offers. See MSDN on how to get started. http://msdn.microsoft.com/en-us/library/bb897657.aspx
Advantage: Dynamic, Flexible
Disadvantage: Can be hard to get right, Usually lots of work
- Navigation that has nothing to do with navigation. What do I mean? Show a list of the published pages from the pages library of the current site. That has served us as a viable navigation strategy on a number of sites. Usually best suited for the contextual navigation category. There is a strong potential downside of using this approach. It is very simplistic and doesn’t implement any performance optimizations or security trimming. So if used in an incorrect scenario, it can have nasty side effects. For me this method has generally been useful when there are a number of content pages that need to be shown for a certain category, etc, and if a page was published, it should be visible for everyone.
Advantage: Relatively easy to build, Dynamic
Disadvantage: Only suitable for simple cases
- Search. Yes, you can use search as a viable navigation method. There are ways that you can prepopulate a search result set and display this as navigation. We used this on a project for a “Related Items” type of navigation.
Advantage: Very dynamic
Disadvantage: Depends on good search results, Can’t always know what will be in there
So as usual with SharePoint the right answer for whatever you are doing is “it depends”. I would however stress that whatever your choice of navigation solution for a public site, don’t forget that you are building for the end user and make sure you are sending friendly HTML, etc to the client.