The challenge

SharePoint solves many problems but often introduces several new ones you hadn’t heard of. As a SharePoint expert your asset is the ability to tell the complex stuff in layman’s terms. One of these is the cumbersome distinction between an out-of-box (OOB) and vanilla SharePoint, a configured SharePoint, a customized SharePoint and a custom-built SharePoint.

These are phrases I often hear during meetings with companies using or planning on using SharePoint:

We don’t want any customization, just OOB. Oh, and can you add a few custom workflows too?

We need a custom feature for news/team sites/custom publishing/<insert functionality here>

The quick launch navigation should look a bit different

It shouldn’t look like SharePoint

How much time is this going to take? I was told it works after running setup.exe

What do you mean taxonomy and Content Types? We just want document management with metadata

Establish the road ahead: OOB (vanilla) SharePoint

I think this one is fairly obvious and self-describing: A customer need is tackled with a plain SharePoint deployment. It can be a small farm, a large farm or anything in between. It might include some language packs and there might even be multiple web applications or at least a few site collections. This is fertile proving ground for future services and increased productivity, since all (or almost all) features are readily available and mostly enabled. There’s the basic configuration for a publishing portal and team sites, My Sites are up and running and there’s even a simple user profile synchronization between Active Directory and SharePoint.

It’s a likable approach and less risky than the other options described later in this article. I think this fits the need for any company wanting to either evaluate SharePoint or not really needing anything custom-tailored. There’s nothing bad if you want a bulk SharePoint: You get good value for the money and there’s a lot of room for improvements when your organization grows to demand additional functionality. I’ll save you with the tired car analogies.

Commit & consult: Configured SharePoint

Some companies preemptively know their needs are beyond a vanilla deployment. They want stuff to be configured according to their specifications, needs and – sometimes – whims. Nothing wrong here. SharePoint is still the Swiss Army knife of collaboration and portal platforms, no harm done configuring things a bit further.

Here’s the hard part: What’s included in a configured SharePoint deployment? As I see it, there’s

• Setting up Service Applications, instead of just deploying them in autopilot
• Configuring search with intricate settings, keywords, best bets and so forth
• Establishing a managed metadata taxonomy and/or folksonomy
• Designing an information hierarchy, with some thought put into it
• Fiddling around with navigation properties, page layouts and similar
• Providing external services, such as extranets for third parties
• Conforming to organizational restrictions, requirements and standards

On the other hand, these are not part of this approach:

• Creating new master pages (with SharePoint Designer, Visual Studio or whatever tool you want to use)
• Modifying any of the OOB files under SharePoint root
• Trying to circumvent some artificial limitation, such as a default button in a view underneath _layouts
• Fixing things to better suit your needs – hacking around the file systems and IIS
• Inventing features that are not there but desperately needed

I always feel when I’m moving beyond a typical configured SharePoint deployment. You get requests that take a lot of time and effort to understand and internalize. You start opening application page files (the .aspx –files sitting underneath 14TEMPLATELAYOUTS) in notepad++ trying to understand how a specific functionality works, or if there’s a shortcut to do things differently. You download Reflector. You hope things will work since there really is nothing on Google or Technet or MSDN or some other discussion board to guide you. White papers fail to mention those small details you stumble on. You feel it’s time to move on to a customized SharePoint approach.

Invent, build and go wild: Customized SharePoint

This is probably my least favorite model when going deep with SharePoint. What it basically translates to is the fact that a lot of the requests you get are really specific and often quite vaguely described. It’s not because whoever is requesting these things for you to do is doing it just to be mean, but rather that they are not deep diving the technical and fundamental aspects of SharePoint. Nor should they have to, that’s why you were called in the first place.

The challenging part of a customized SharePoint is that a lot of your time is spent troubleshooting, guessing and wondering how things should be built, instead of designing the optimal way of crafting the outcome. I’m not going to go into different aspects of project delivery models here, so suffice to say that this seems to happen with all widely-used approaches.

Many a developers I’ve had the chance to collaborate with over the years often despise this approach. They feel it’s not real coding, and it’s a mishmash of both good and bad practices. “Fiddling with tiny xml bits, meh”, they say. It’s like you’re given permission to go wild and forget about the rules and principles of proper craftsmanship and just do it on the go. Keep adding more and more features until you don’t really know what you’ve added and what should be removed.

What should be in a customized SharePoint deployment? This:

• Quite liberal usage of SharePoint Designer with a consistent mindset
• Custom site templates/site definitions/templates in general
• Third party tools to solve tricky issues – these often work, but quite often fail too
• Custom (declarative) workflows
• Custom InfoPath-forms, no code-behind, but rules and views
• Clever mashups and innovations around Access Services, Office Web Apps and other “new stuff”
• Custom Content Types, Site Columns and other SharePoint building blocks
• Sometimes small amounts of custom code, either neatly packaged or just xcopy’d 

What shouldn’t be in a customized SharePoint deployment:

• Overwriting default files on the disk
• Some code you found googling and copy-pasted in CONTROLTEMPLATES, but you don’t really know what it does or why it needs to be there
• Custom functionality that require a plethora of support overhead. Think custom workflows requiring a custom timer job that is executed through a Powershell script from a logged-in console session. Or some similar abomination.
• Inconsistent results with consistent effort. Something is fishy here
• Immovable functionality from development to any other environment (QA/test/production etc)
• Consulting-by-clicking: Spending hours clicking through the interfaces and SharePoint Designer to replicate something that’s been done before

SharePoint deployments often sneak their way from OOB or configured models to a customized approach. The problem to tackle is the fact that most stakeholders still feel it’s a “basic” approach while you are left to solve colossal problems with minimal budget, time and resources. After all, it’s probably something you encounter every day.

Design, develop, deploy: Custom-built SharePoint

This is a tough one. Combining the benefits and wisdom of traditional software projects with the OOB features and restrictions of SharePoint. The recipe for disaster is already there while the opportunity for great wins is written all over it.

The “DDD”-approach is for companies who have been exposed to SharePoint early on and are experienced users. They know tweaking and fine-tuning is allowed, and they can (or at least should) deliver requirements and needs in clear and concise specifications. Regardless of the project methodology being used it all boils down to an iterative approach: Define, refine, test, discuss, refine more, test again, finalize, move on.

I know I’m probably incorrect in assuming that all customers would prefer this option combined with the easiness and cost-effectiveness of the OOB approach.

What should be in a custom-built SharePoint:

• Neatly arranged packaging scheme for all customizations and artifacts
• Tested and working scripts for settings up the infrastructure
• Source control repository (think: TFS)
• Automated tests
• Continuous Integration
• Built-in support for multilingual environments
• Almost anything can be customized, when deemed reasonable and cost-effective: Master pages, Page Layouts, the overall UI, workflows, templates etc.
• Versioning and roadmaps – we’re here, we are getting there and this is what’s going to happen next
• Readable and good documentation. Not necessarily hundreds of pages but something that tells the unitiated reader the what, why and how.

What shouldn’t be in a custom-built SharePoint:

• Anything that can be achieved with SharePoint Designer
• 25 installation packages. You know you are doing it wrong
• Quick hacks to circumvent built-in functionality – either you shouldn’t be doing it, or you are approaching the problem incorrectly
• A lot of clicking. I know some consultants prefer the mouse and the sound of clicking but still, this is more about developing and crafting ingenious solutions than dragging and dropping things on the canvas
• Fully custom-built ASP.NET applications hosted inside SharePoint. The benefit of SharePoint is lost, and all effort goes to maintaining wires between the two systems