The Value of SharePoint

(or, when all you have is a hammer, everything looks like a nail)

I was 6 years old when I learned about abstracted models. 

Of course I didn’t know that’s what they were called at the time.  I like to think I am smart, but I was no child genius.

I started learning music much like most other kids: in primary school, playing the recorder.  Badly. 

I thought I was the cat’s whiskers.  I could play Three Blind Mice with the best of them.  Boy, what a musician I was. But then teacher blew my burgeoning career as a recorder wheelding David Bowie to pieces. The simple ABCDEFG notation we had been using to begin our musical career could only score the most basic tunes. No concept of time, only one octave, no way of denoting the duration of a note.  We had to learn a whole new way of reading music.  And suddenly I sucked.

What teacher knew, and I didn’t, was that a simple highly abstracted model could be massively valuable in shortening the learning curve, and accelerating the time in which learners can accomplish basic tasks.

Abstracted models come up time and again in IT: from programming languages to network architectures; varying levels of abstraction away from the physical base layer afford greater productivity at the cost of flexibility and raw power.

And therein lies the value of SharePoint as a platform: It provides a powerful, abstracted model for developing your own collaborative web applications. Just so long as you play by its rules!  Like the abstracted model for music notation, it provides rapid payback for simple scenarios. But that payback degrades as complexity increases.

Compared to custom-building your application from scratch, you can look at it like this:

Key points to think about are:

• You can rapidly create no-code collaborative apps in SharePoint, for very little cost
• As you start to add code the curve flattens
• For custom web-apps the effort/cost invested before you start to get payback is much higher – you have to write all the plumbing that you get in the box with SharePoint
• But there is an an intersection point.  This occurs at the point when you start pushing against the boundaries of the SharePoint framework – trying to make it do things it wasn’t designed for.
• And here’s the killer: You need a thorough knowledge of the SharePoint platform to make sensible decisions about tradeoffs

I can’t give you a silver bullet for knowing when that trade-off occurs.  What I can tell you, is that once you have SharePoint in your organisation, that doesn’t mean you should write all you intranet apps in SharePoint! 

Evaluate each potential solution on whether it is a good fit for the platform.  Put another way, are you going to make use of enough of the platform capabilities to make it worthwhile?  In what ways might a custom app be better? Would a hybrid approach work?  A custom database and business logic tier, with presentation in SharePoint say?

If you do decide you need to write code in your SharePoint app, always use good n-tier design principles.  E.g. don’t put your business logic in the presentation tier.  This makes it easier to move to a custom solution should you need that power in the future.

And finally, be pragmatic. Be prepared to compromise on requirements to keep within the SharePoint sweet-spot.

Dan McPherson summed this up nicely in his post about SharePoint pragmatism:

…make sure you build solutions that work with SharePoint, leveraging every bit of out of box functionality you can, and avoiding wheel reinvention wherever possible
…help those who define the requirements understand just how best to map them to the platform. It means not just taking a requirement on face value and mindlessly building it out, but deciding if small compromises can be made which result in bigger long term cost savings.

Related articles:  (the ones that inspired me to write this post)

• Mary Jo Foley: New Studies Highlight Potential Downsides of SharePoint
• Computer World: SharePoint challenges IT as the Excel, Access of the day