A month ago I invited people to attend the Washington, DC Web Content Mavens meeting for March to hear a Microsoft partner explain how SharePoint could be used for Web Content Management. Well, that day was yesterday then you missed a great presentation.

Before I dive in, I want to thank Rob Garrett of Portal Solutions, LLC for answering my questions and being, or at least appearing, honest regarding the ability of SharePoint to provide Web Content Management. He shared areas that weren’t perfect and agreed with me on some of the limitation issues with SharePoint when dealing with large enterprises. If I had to deploy a public facing website with SharePoint, I’d bring him on board to help out.

Of course, I’d probably never use SharePoint for such a purpose.

The Architecture and Features

To use SharePoint for a website, you need the full featured Office SharePoint Server (MOSS) and not the free SharePoint Services. In general you would setup a SharePoint Farm, consisting of one database server/cluster, multiple SharePoint/Web servers, and some sort of load balancer in the front.

Inside of this environment, your Site is the website. When you create a site, there appeared to be three templates specific for publishing. Only one really reflects WCM practices, and that is the one with Workflow, which allows for content to be approved before publishing (a required WCM feature in my book).

Each sub-site that you create in your site, create a level in your URL. Take the link for this post. The first sub-site would be “2008”, the second “03” and so on. One of the sub-sites by default is Search, which provides advanced search functionality.

All content is stored in Document Libraries, such as Pages, Images, and Documents. The top-level site also has libraries for page layouts and style sheets. Content itself can have, and needs to have, several pieces of metadata to support publishing. The Content types are hierarchical in nature, so you can define the base structure and have sub-types with specific pieces of data. This concept should be familiar to some of you.

There is a lot I’m not covering here to keep it “short”, some of which is outlined in the presentation. Many things I am passing over features which I consider “standard” in WCM systems that SharePoint supports. If you have questions about specific things, feel free to send me a comment.

As for cost, it does actually compare favorably with some of the big-time WCM players. Outside of the obvious Windows and SQL Servers for infrastructure, a public facing site will need approximately $60,000 (price subject to change) for an Enterprise license for MOSS 2007 to allow the world to access the site anonymously. This is in addition to any named users within the actually Enterprise that need to use SharePoint to either work on the Web Content or collaborate internally.

The Catch(es)

Rob provided the following definition of Web Content Management. He also said that he had never implemented a non-SharePoint WCM system, which is important when trying to compare level-of-efforts.

A web content management system is a content management system with additional features to ease the tasks required to publish web content to web sites.

By that definition, SharePoint does not provide WCM (I view web sites as broader than SharePoint). It is a portal. It can work like a WCM system to publish content to that portal, but the actual web site is just SharePoint. Just like any portal software, when you deploy the content, you are deploying it to another SharePoint Site Farm. You will need three, at least, SharePoint Site Farms. One for Development, Staging, and Production.

You cannot deploy it outside of SharePoint. Well, you can, but it was made pretty clear that it is challenging, difficult, and not worth the effort.

There are also issues to deploying large-scale changes to a website. There is some issue that Microsoft basically punts on when it arises, telling customers that they should just blow away the old site and publish fresh. Not what I would call ideal. My solution, which Rob concurred with, was to setup a second Production Site Farm, deploy the revamped site there, and then change the DNS setting when ready. Ready for more servers? This could be done without double the servers, but it shouldn’t require even one.

Content Deployment was reportedly one of the last things that Microsoft added onto SharePoint to support WCM. It shows.

As for the WYSIWYG editing feature, it is buried in the list of metadata attributes for a piece of content. So while it is there, it isn’t great and be cumbersome to locate. We saw this feature live and I wasn’t impressed. Many other systems that offer comparable WYSIWYG editors (not the even better in-context editing) have the images and text on a page separate from the metadata. Logically, this makes sense as one is data about the content while the other IS the content.

There was also some discussion about it being not overly simple to edit Page Layouts. They are basically ASP.NET pages, so if you have the tools/capabilities to do that, you can do the layouts. I can’t really speak to the whole topic, but I suspect that you will need a developer type to assist your web designer in getting the layouts put together. This challenge doesn’t sound overly different from transforming any portal software into a website that doesn’t look and feel like a portal.

For More Information

Check out these sites for live sites that use SharePoint. The first two where done by Portal Solutions. You can find more, like the other three, at this list of SharePoint Public Sites.

• Conservation International
• Avendra
• Choose Chicago (The Official Visitors Site for Chicago)
• Western Australia Tourism Site
• Microsoft (sub-site English, sub-site US)