For an initial deployment of SharePoint 2010 how about saying:
“We will not do anything that involves custom code. We will restrict ourselves to what we can do with out-of-the-box SharePoint and associated tools”
This is somewhat controversial. I can already hear rumblings of discontent from distant IT strategists. IT strategy should be derived from business strategy, right? An IT strategy should put in place systems and practices that support the business in achieving its objectives. If we say “we won’t do any custom code” this is surely a classic case of tail (technology) wagging dog (business). Why should the constraints of a technology be used to tell the business what they can and can’t have?
That is perfectly true. But, and it’s a big but, SharePoint also gives us the following to consider:
- The number of things that SharePoint can potentially do for a mid-size to large organisation is pretty large. It encompasses collaboration, intranet, document and content management, social features, search, business intelligence, and business application delivery. Deciding where to start can be a challenge.
- As soon as you start custom coding within SharePoint (or anything else), the cost and risk both go up considerably.
- For almost all organisations there are some real “quick wins” that can be delivered without custom code. For example, we often build one or two form and workflow driven business applications. These can be delivered in a matter of days and provide tangible value. The appropriate use of third party products such as those from K2 and Nintex can also facilitate the delivery of more complex workflows without custom code.
- Users and stakeholders want to see something. Custom coding projects can take months. A no code approach gives them rapid visibility of where all that money they spent on licencing has gone.
I should make it clear that I am not advocating that custom code should never be used. If for example you have a requirement with a compelling business case that can only be delivered with custom code, then make the case and go for it! However if you are looking at SharePoint, and have numerous possible projects under consideration, then an initial no code approach will allow you to derive some quick benefits at low cost and low risk. You can then revisit your strategy later once users have got used to the system. At this point you’ll probably find that business requirements have changed anyway, as once people have started using and benefitting from SharePoint, their thoughts about where they need additional functionality almost inevitably change. So when you decide it is time to crack open Visual Studio and start custom coding, the chances are you’ll end up with a better custom coded solution than you would have had if you’d done the custom work up front.
Comments welcome as always!
Ian
I’m looking forward to talking about quickly delivering business applications on SharePoint 2010 at The International SharePoint Conference London 2012 in April. I’ll be co presenting with one of our customers.
