SharePoint as a Purpose-Built Application

January 31, 2007 at 4:46 pm | Posted in Microsoft SharePoint | 1 Comment

I’d like to start out today with a thesis:

  1. When designing a product a vendor decides where they want to be on a continuum from capability-driven (starting at the list of capabilities and features a product should have) to purpose-built (starting at use cases)
  2. Those two extremes distinguish an application vs. infrastructure mindset
  3. The choice made on this continuum is subtly noticeable in the finished product

This thinking came out of my investigations for a report I’m writing on building portal sites in the new version of SharePoint (Windows Sharepoint Services 3.0 and Microsoft Office SharePoint Server 2007, henceforth known here as SP2007).  I have covered SharePoint since its 2001 incarnation and have spent quite a bit of time over the years with clients trying to use it and behind the scenes in Redmond. The more I look at SP2007 the more I get the underlying feel that it is a purpose-built application.  An analogue for developers would be that a purpose-built app is the equivalent of a 4GL language where a capability-driven app is like a 3GL.  It’s solution building as opposed to just solution selling.  On the contrary, Websphere Portal (or ASP.NET for that matter) feels more weighted towards capability-driven.

Note: this is a continuum, not a binary choice. Even starting with a pack of use cases the vendor will take the time to think what the infrastructure needs to provide to support them.  And vice versa – a vendor would develop use cases to test a set of capabilities and features they assembled.  For a product like an intranet builder, the difference is whether you start with templates and then build the required services underneath or start with the services and then build the templates later.

My theory is that infrastructure products and application products are developed in fundamentally different ways.  To develop as infrastructure (or 3gl) you start with the set of capabilities and then features you want to provide and design upward from there.   To develop an application (or purpose-built app or 4gl app) you start with use cases and design your product around them.  Microsoft develops using Scenarios, which I am told includes use cases as well as a higher level idea of who the developer is and what they are trying to do.  Like 4GL development tools, purpose-built products seem to flow and demo easily around the tasks it was meant for, but you notice inconsistencies.  These inconsistencies can take the form of inconsistent nomenclature, why you can take certain actions on one screen or object but not another, lack of a “view all” or holistic views of environment, or inconsistent fit and finish from one area to the next.

4GLs were famously difficult to use if you veered too far off the path of what their designers expected you to do.  At a recent local SharePoint User’s Group meeting I attended, a consultant presenting on SP2007 strongly made the point that SP2007 is a tool for doing specific kinds of things and you shouldn’t try using a hammer  to do things other than pounding nails.  Of course that’s true for any app, but the problem arises when its not clear at the outset exactly what it’s meant to do.  It’s pretty clear that the animation functionality in PowerPoint is not appropriate for building Space Invaders.  But should I guess that building a web site with 4 columns instead of 3 should require outside assistance?  The consultant strongly recommended that a technical resource be present when doing requirements gathering and doing mockups to make sure users don’t have a lot of expectations for things SP2007 can’t easily do.  That’s crossing the line for me – once I need to interfere with the business telling me what they need I’m going too far to shoehorning business requirements into what I can do.

To some degree I’m just musing here.  I’m not saying one side of the continuum is better than another.  Each has its benefits and pitfalls, and both can overcome their pitfalls with care.  And the more I look at SP2007 the more I’m impressed with the forethought that went into it and convinced it will have a strong impact on the market for building portal-like sites.  I do believe that collaboration has to be thought of as infrastructure rather than applications at this point and an infrastructure mindset (capability-driven) would do the best job of making sure a set of reusable services are developed that are consistent and comprehensively support unforeseen scenarios.


1 Comment »

RSS feed for comments on this post. TrackBack URI

  1. […] the more formal terms, Capability-driven Designs and Purpose-driven Designs in the following blog:   And I think this is also the point: SharePoint is MOSS: Microsoft Office Server (System). […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at
Entries and comments feeds.

%d bloggers like this: