The ‘P’ in ‘SharePoint’ Stands for ‘Platform’

Last week we had a chance to do a friend a favor and talk to a university IT staff about SharePoint – what it is, what it does, and why they need it (and yes, just for Adam, the meeting started with them asking ‘What Is SharePoint?’).  Our standard answer goes something like "SharePoint is Microsoft’s next generation collaboration, communication, and application delivery platform".  The last part is usually what gets people’s attention, which is what we want, being in the the custom development biz and all.

 

But this really is a deep subject.  Sure, we can talk for hours about what SharePoint does out of the box but to me the real magic fairy dust is what the SharePoint platform does for the .NET developer without having to write any code.  It’s more than just lists, libraries and search – it’s a rich application framework that enables rapid deployment of critical line-of-business applications.

 

Take your average, one-off .NET web development project as an example.  The application is usually comprised of several common components: data storage, data access, security, presentation, navigation, etc.  For most projects, all these pieces have to be written from scratch (with some portability from an established code base if such a resource exists).  In most of the projects I’ve worked on or been exposed to, it is not unusual for these common components to consume 30% – 40% of the entire development effort.  That’s a tremendous amount of time spent creating a supporting structure before you can even begin to integrate the business logic and features.

 

Enter SharePoint.  As a platform, it provides all the common components required for just about any web project – navigation and structure via sites, data storage and retrieval via lists, security via site groups, AD integration and the profile database, and presentation via the SharePoint UI.  The rich object model and extensive web services deliver a flexible API that can meet just about any requirement.  This frees up development time to focus on what really matters – business logic and features – and not all the ‘glue’ that holds it together.

 

Granted, learning to develop in SharePoint is no picnic (and don’t even get me started on debugging).  But once you get over the initial learning curve, banging together some secure web parts that store and retrieve data in SharePoint lists is a no brainer.  SharePoint is a RAD platform in the truest sense of the word – it enables developers to quickly deploy applications with the least amount of code. 

 

By way of analagy, and often because our meetings tend to occur around lunchtime for some odd reason, I liken the process to making a sandwich.  If .NET developers were in the business of selling sandwiches, they would go broke constantly baking bread, growing tomatoes, pickling cucumbers, mixing up mayonnaise, and generally doing everything EXCEPT putting meat on the hoagie, which is their real job in the first place.  No sandwich shop does all that, they outsource those compnents to someone else and just put it all together to meet the customer’s demands.  That’s exactly what we do with SharePoint – we let the platform handle all the ancillary (but still important) stuff while we concentrate on the meat.

 

So the next time you come across a customer, partner, vendor or fellow developer who works in a SharePoint shop and is still writing one-off .NET web apps, stage an intervention and start talking platform, platform, platform.  Sure, you may have to buy them lunch if you use my sandwich analogy too much, but isn’t it worth it to spread the SharePoint vision?