Using Sharepoint as a corporate website?

I’ve done a lot of development work using Sharepoint 2007 (MOSS) and some Intranet development using Sharepoint 2010. I’m not going to out right tell you that using Sharepoint is a bad idea, or even Sharepoint doesn’t work for a front facing corporate site. I’m going to explain some of the pros and cons that I’ve found and you can decide from there.

Firstly I would say Sharepoint in my opinion is good for building team collaboration sites, in which you share documents, calenders and other team related stuff. Setting up Workflows can be quick and easy using Sharepoint Designer to do basic tasks. I have setup some corporate Intranets using Sharepoint, and they were ok but not without issues.

Sharepoint is not really designed to be a CMS for public facing websites. The core of the problem is centred around authentication and permissions. Sharepoint is happy when all your users are logged in, and it can run webparts and features without problem. Obviously a public website needs to be accessed by anonymous users who won’t be logging in. Typically you’ll need to setup an admin version of the site where authors/editors log in, and forms based authentication (FBA) for the public side where everything is accessed against one preset account for anonymous visitors.  You can setup these different areas in Sharepoint’s Central Admin interface, using Alternate Access Mappings. Normally the admin site should run under SSL so the traffic is encrypted.

The Cons of using Sharepoint as a CMS.

– As you start to develop Webparts in c#, or utilise out of the box features to get things done, it’s generally fine on the admin site, but some features will not run on FBA due to bugs or design limitations. Any custom webparts you build will need to get more privileges using combinations of impersonation and altering Security settings in config files. Even to access a list or page library from a custom webpart won’t work without extra configuring and coding.

– You’ll need to develop a lot of custom Sharepoint Webparts to deliver additional features and to replace features which simply did not work well due to bugs or limited un-flexible features.  For example Page libraries can be exposed quickly and easily as RSS feeds in Sharepoint 2007 but the information put into the RSS feeds is quite fixed and rendered in a way that makes it unusable. To get over this I developed a .NET Controls to render more useful RSS feeds.

– Permissions and the security model. You can setup custom security groups, instead of the default 3 level groups. This feature would be really useful, but in our Publishing site using MOSS we found permissions using custom levels didn’t inherent down to sub sites. This renders the feature unusable in most scenarios. Sharepoint’s permissions aren’t that finely grained. Sometimes you’ll want to separate what users can do, but too many rights are lumped together into permission groups.

– Some aspects are black boxed, so are not accessible to developers (No hot fixing). It’s not like an open source CMS where you access every line and see what it’s doing. Sharepoint can be mysterious and behave in unexpected ways, sounds exciting but it’s not!

– Rendered mark-up was not W3C standards compliant. (Better in 2010). For example a lot of the navigation controls use Nested tables, or non standard attributes. You can rewrite things like menu controls from scratch, to make things more compliant and better for accessibility but then you’re sinking further and further into what I call Sharepoint Quicksand!

– Webpart development/deployment was more time-consuming than standard .NET Pages

– Numerous bizarre bugs often intermittently occurring in stable environments. The Reuseable content feature which worked fine with authenticated users would often cease to play ball on the front end FBA site.

– Sharepoint does a lot, it’s complex, it’s powerful with many different ways to get things done. But a platform this complex is prone to bugs, contradictions, and has more weaknesses. You’ll face a steeper learning curve to do anything really useful and there will be significant amounts of functionality you’ll never use but still litter the system.

– Webparts developed in one version of Sharepoint can’t be used directly on another version. For example I couldn’t just install a MOSS 2007 webpart for producing dynamic forms on a Sharepoint 2010 site. If you’d written something in .NET framework 2, it would still run in a framework 3.5 or higher .NET site.


– .NET developers will see familiar things, Sharepoint uses Master Pages for templating, Webparts can be written in C#.

– Workflows are useful, quick and dirty simple ones with Sharepoint Designer, or more powerful custom workflows built in Visual Studio

– There are plenty of Sharepoint / Microsoft skills out there, so finding developers to work with Sharepoint won’t be too bad.

– It’s reasonably mainstream, and there are many blogs, examples and tutorials about Sharepoint.

– It has a good set of built in webparts and features (when they work). Like the Content Query Webpart (CQWP) which you can use to display auto generated menus from tagged content through flexible filters.

– There are lots of free and cheap third party webparts or controls you can download to enhance Sharepoint. Telerik’s RAD Editor was much better than the default WYSIWYG editor. And Codeplex has loads of useful downloads.

– You can get a robust, feature rich, flexible CMS based site but it takes a lot of work.

– Custom lists, content types and page layouts are easy to get to grips with and webparts and webparts zones I still like.

Ok, remember the bit where I said I wasn’t going to tell you whether you should consider Sharepoint or not, I lied.

A lot of these points to be fair are levelled at MOSS 2007, and Sharepoint 2010 is an improvement, but generally I would be (personally speaking) reluctant to use Sharepoint again for a CMS.