SharePoint: Content Management vs. Collaboration

This week, I’ve been attending a gathering of Microsoft technical sales professionals.

This blog is inactive.
New blog:

Blog TOC
In one presentation, I heard the following opinion (paraphrased):

“The most important pillar of SharePoint is content management.  This is the core value proposition of SharePoint.  It is what is driving sales.”

In another one, I heard:

“The most important pillar of SharePoint is social computing and collaboration.  This is what is driving its adoption.”

I think that what this means is that content without collaboration tends to be static, and doesn’t improve and disseminate as it should.  Collaboration without content doesn’t provide a vehicle for corporate/collective knowledge.  In addition, adding collaboration to content enables more effective management of the content – helps with applying policies for things like Sarbanes-Oxley compliance.   We can’t separate content and collaboration.  I think that both presenters would agree that having content management and collaboration baked into SharePoint at a core level lets us work together with fewer barriers.

In other news, Johann Granados (President of Staff DotNet) has recently started blogging.  I have known him for a number of months, and have enjoyed working with him and his team.  He has a unique perspective on the IT world - running a consulting company from Costa Rica.  I'm going to enjoy reading about his set of challenges and opportunities.  Welcome to the blogosphere, Johann!

Comments (2)

  1. int19h says:

    If only SharePoint actually worked well… but as it is, it’s pretty much a developer’s hell when you need to do anything not supported out of the box. The mess with SP IDisposable patterns (when to Dispose and when not to); mysterious COMExceptions thrown with no explanations; extremely poor documentation (so many public API classes and methods have blank descriptions in MSDN); need to rely on outright undocumented features (such as LookupId attribute in CAML) to do even the simplest tasks; complicated deployment (why oh why feature receivers _have_ to be installed into GAC, while precompiled codebehind _must not_ be?); lack of proper IDE support (I’ll consider that done when I’ll have an end-to-end solution on top of VS and TFS which lets me develop, test, build and deploy SP solutions with an automated workflow the same way I can do with plain Web apps these days); etc…

    I love the idea of SharePoint, and we use it here daily for collaboration for the lack of better alternatives, but it really, really needs to be done properly. At present, it holds the title of the worst Microsoft product of those I worked with (again, in terms of implementation and buggyness, not the fundamental idea).

  2. @int19h,

    Thanks for your comment.  I think that people’s passion about SharePoint (both positive and negative) point to the value and potential that companies see in it.  I will be focusing on the core programmability platform of SharePoint.  These are some of the issues that I hope to address on my blog in the future.


Skip to main content