Follow PFE on Facebook
In SharePoint-Land there are two concepts that people have a hard time separating out: “Collaboration” and “Content Management”. A lot of people like to blend them together, use methods, features, technology, or processes… but the truth is these are separate capabilities, and should be separately managed.
Lets compare…
First, lets look at the communication model that actually happens between the two:
Collaboration
Publishing
When we’re collaborating, we’re all sharing information with others in our group, and those people have an equal opportunity to share information as well. In publishing, there is usually a small group of people communicating to a much larger group of people. Think of it as the difference between working with your peers in a conference room, all working together to get the job done, and your CEO doing an announcement to the entire company.
For example, in a publishing site (such as your company’s “www” site), how you say something matters nearly as much as what you say. It’s all part of one larger message. So the layout, the display, colors, pictures, and functionality are all a reflection of the primary message. In collaboration, we’re not worried about how much the site matches our homepage or that the colors fit with our marketing message… these things have no impact on our ability to share information, exchange ideas, update status, or publish documentation.
Microsoft Office SharePoint Server 2007 has numerous site templates to serve varying needs, but the three that tend to matter the most are the Team Site template, the Collaboration Portal template, and the Publishing Site template.
The big problem I see is people using Team Sites for publishing, and publishing sites badly.
So, how do you know what kind of conversation you’re having, site you’re being asked for, or template you should use? Here are some sample requests:
The last item is one of the most common… and we need to be clear. Yes, we do Web Content Management, including supporting “collaborative” intranets… but we have to reiterate that SharePoint isn’t just a simple website… it’s a complete web application. Would you consider heavily branding Outlook? Does your OS have your branding all over it (except maybe your background image)? Are your ERP, Training, Travel, or HR systems heavily branded? Probably to various degrees… and SharePoint Team Sites can be too… to a certain degree.
Ultimately we need to clearly understand what features we need for publishing vs. collaboration, and what we can and should do to support those needs. Publishing needs heavy branding, high performance read-only access (caching), staging and deployment, while Collaboration needs clear functionality, ease of engagement, consistency between sites and high performance read/write access (no caching, fast servers).
When you talk to your stakeholders, try not to think about how you can bend the product to their whims, but rather how you can effectively translate what they’re trying to accomplish into something SharePoint can support directly. A stakeholder may say “I want the intranet to support collaboration directly.” One approach would be to create one massive site collection with heavy branding throughout… but you don’t really need that. Chances are a main intranet with separate collaboration site collections beneath it (beneath the site directory for example) would be just fine… and if we need to blur the lines a little, search web parts can present content from across the intranet on one page.
…and if you really need to blur the line, you can always custom write something… but that should be your option only after the built in capabilities have been exhausted… and usually they’re not.
So, use team sites for team collaboration… and portal sites for web content management. The less you try to make one act like the other, the happier you and your customers will be in the long term.