Downsizing From Sites

clip_image002We are currently upgrading our Internet facing SharePoint server to SharePoint 2010. We’ve done this drill before; in fact, since we started out with a WSS 2003 site; we have done this drill more times than I care to remember. When we were discussing how to go about this upgrade, we decided not to upgrade at all. We decided not to “migrate” either; we decided to build a new server and rebuild all of the content. What made us decide to take this approach? Simply put, our past caught up with us.

In 2005, when we installed our first WSS server inside our firewall, I built a couple of example sites, demonstrating a few cool features, and then I showed it to my coworkers. Very few of them were as excited as I was, okay, most of them weren’t excited at all, but my boss asked “could we let our members use this?” Of course the answer was yes (see my AIIM blog from several months ago to know why the answer is always yes). After considering all of the possibilities, we decided that a separate Internet facing server was the best solution for us. To my surprise, we started finding more uses for SharePoint on the external site than we were finding internally. We built sites for our members, for the outside attorneys we work with, for various vendors, consultants and business partners, for our annual charity golf tournament, and of course, for our customers. The key phrase in the previous sentence is “we built sites” – in fact, we were site building fools back then.

Sites seemed like the perfect solution for every need; they were easy to build, easy to “brand” (although we do very little branding) and it was easy to set permissions for sites. On the other hand, creating sites for every business partner was like giving houses to college freshmen; in a word, overkill. We have a couple of partners that like the idea of having a calendar, a set of useful links and a few document libraries, but most of the people we are working with simply want to share documents, lots of documents. This time around, the freshmen are getting dorm rooms, in other words, we are creating document libraries in a common site. Some of our partners, the ones using more of the features SharePoint has to offer, are getting sites, but very few. I like this solution for many reasons, but here are my three favorite ones:

1) Simplicity – It is so easy to add a Document Library to an existing site, establish the permissions for a new user and send them the same instructions you have sent everyone else on that site. I realize that sounds like the form letter approach, but sometimes, simple is better. When all you want to do is browse for documents, an uncomplicated site that has your document libraries is really all you need.

2) Navigation – The biggest complaint we get about SharePoint dissipates quickly when we remove an unnecessary level from the trail of breadcrumbs. Go to our server, go to the type of business partner that you are and open your library. Since everything is permission trimmed, that’s all the user sees anyway. We urge them to bookmark the site level, rather than the server, but we like them to know that the server main page is always a functional starting point.

3) Appearance – Nothing makes SharePoint look worse than blighted Team Sites with empty link lists, old announcements and a calendar devoid of events. By contrast, a rich page of content carefully chosen for a group of business partners is easy to fill and easy to change over time.

As we move our existing content into its various new homes, I am really getting happy with the results. We are going to end up with a clean, minimal server that meets everyone’s needs. Since this is built on SharePoint, if those needs grow, we can accommodate them. Until then, we are giving everyone what they need.

3 thoughts on “Downsizing From Sites

  1. Dan:This is an excellent story. Learning and adapting should be a part of all "living systems" and technology-based ones should be no different.I expect that if you had certain people read this post, they would point out all sorts of deficiencies with your logic. The admins (and probably many developers) would talk about your content databases growing too large. They'd explain that permissions will be impossible to manage and your users will screw them up. They's explain that separate Site Collections would create stronger safety and hard boundaries which couldn't be crossed accidentally. At some point later in that conversation would come the requests for more hardware to support their scenarios, then more test and integration environments, etc.I know you and your team well enough to know that you aren't embarking on this redesign without putting much good thought into it. Sometimes the conventional wisdom isn't, well, all that wise. You know what your requirements are (and have honed them over the last 6+ years), you know your user base, and perhaps most importantly, you know what you yourselves are capable of implementing and managing well to support the business.Understanding how to adapt and evolve without seeing a defeat as part of the process is quite a rare skill. Kudos to you and your team for seeing what you've seen and making the decisions you are making. I expect that if you spot flaws in your logic over time, you'll embark on more changes which make an equal amount of sense at that time. And so it goes…M.

  2. Thanks for the comment Marc. One of the reasons I have this blog, is to air our laundry and see what people think of it. Given that we are the admins, and the developers, we run the risk of telling ourselves we are right and believing it. As my boss puts it, “then you’re flying up your own arse.” The good news in this case, is we did think about the issues you raised. For example, our legal partners represent the largest volume of documents, and the people most likely to use Calendars and Links. As a group, they are in a separate content database and individually, they remain in separate sites. Our members represent a much smaller volume of documents, divided among various committees, so they have been moved into Document Libraries under a single site.Our customers ended up being a mixed bag. Some are multi-unit sites (yeah, they use that word too) and some utilities own multiple generating stations. Spreading documents across libraries in individual sites that corresponded to units resulted in a cumbersome solution. We still create sites at the highest organizational level, but then we drop into libraries. If they want more delineation, we can accommodate them. Again, the customers will be in a separate site collection, possibly a separate content database.The key factor for us is volume. In terms of what’s insured, we are large, but there aren’t that many insured locations, operating utilities or claims.

  3. Team site blight is something I'm trying to eradicate! And if I see that default picture of the three minorly ethnically diverse office workers leaning over a desktop one more time…And removing all those superfluous breadcrumbs is a great idea!

Comments are closed.