The Cost of Automation
The SharePoint platform has gone through some major changes over the past decade, from a loosely tied collection of disparate tools (Tahoe), to a limited product implementation (SPS2001, 2003, and 2007), to a dynamic and powerful platform (2010) — and even now it is evolving in response to the changing world of BYOD (bring your own device) and cloud-based infrastructures and services.
My first experience with SharePoint was in 2005. I had friends at Microsoft who talked to me about it prior to then, but 2005 was my first real experience playing with it, and, more importantly, deploying it for a customer. (WSS 2.0 and an early version of Project Server. It wasn’t pretty.)
At the time, SharePoint was a much more limited offering , with specific use cases and limited options (I’m being nice) for enterprise content management and line of business application integration. Most folks took what came out of the box and chopped it up to meet their intranet needs — which caused problems later down the road when time came for upgrade, but that’s a different story. Think of it as one of those weird machine screws that requires an allen wrench, but instead you try to force it in with a phillips screwdriver, only to strip it bare. It works fine for now, but when you find you need to remove the screw, the head breaks off and you spend hours digging into the hardwood with needle nose pliers trying to get to it and remove it.
Yes, there is some personal pain behind the machine screw story. But my point here is that SharePoint was much simpler then (albeit less functional/powerful), with more clearly defined uses. Jump forward 7 years, and we now have a robust platform that provides an exponential number of solutions compared to that earlier version.
One of the more common "best practices" shared with SharePoint newbies is to use out-of-the-box capabilities first rather than jump straight to customizations. It goes back to the adage that a .Net developer does not equal a SharePoint developer. Yes, technically you can do what we did back in the 2003 days: utilize the basic SharePoint framework, but break the model and build over SharePoint a complex .Net-based website or platform. Because it’s just a website, right? You do this, however you’ll experience the same problems that we had back on the 2003 version — you’ll create a one-off, a custom website/portal, and potentially lose many of the core benefits of SharePoint, such as permissions inheritance and management, centralized management of web parts and other solutions, as well as consistent look and feel.
The SharePoint community has been pretty vocal on this one — I think most people "get it" that you can do a lot with SharePoint, both out-of-the-box and through customizations that stay within the guidelines. But what is changing now is a focus on productivity solutions. Many organizations are quickly moving from spending the bulk of their administration time and effort to keeping the platform up and running, and instead are focusing on delivering more value to their end users. My question is: as organizations seek to improve productivity through automation, will they once again fall into the same trap of over-building SharePoint to a place where it will become difficult to manage, upgrade, or migrate?
End users often ask "can we do this?" But administrators and developers should also be asking "should we do this?" Fundamentally, it comes down to asking questions about what you are trying to deliver, both in the short-term (productivity solutions) and the long-term (supportable, repeatable, scalable). In your desire to automate your end user workloads, are you thinking about how you’ll migrate to wave 15 in the next 2 years or so? Or does the short-term benefit outweigh that long-term (and possibly unknown) cost?
I think there is another aspect of making the choice between OOTB and custom development – that is the business users motivation for the need. Many requirements that seem to automatically lead to development come from somebody assuming something for the whole population of end-users (like usability or productivity) or unwillingness to solve the problem step by step (is has to be perfect from the start) or unwillingness to adapt to a certain way of doing something etc etc –
I often draw a comparison to boxed (Word 2010) or saas applications (salesforce) – why is it that these tools can be successfully used without the business drumming up requirements? So a big part of requirements that drive custom development come imho from the simple fact that it is possible to do so – the excuse is productivity or usability, while user adoption and training should be the first interest – just like it is when organizations upgrade from Office 2003 to 2010..
Agreed — IT’s job is to enable the business. The problem I see is that many decisions are made for short-term benefit without attempting to understand long-term impacts. My point is to ask the question, own the decision.
Very nice article! Marc brings some valid points as well. Should never forget that we are here for the business first.
Keep it simple – Keep it out of the box as long as possible
I’m with you as long as the utility of “can we do this?” isn’t trumped by “should we do this?” at the expense of business productivity. It’s a fine line, and IMO if there are big gains now that may cause a little IT pain down the road, then that’s good and something to just plan for. These solutions aren’t *for* IT: they are for the business. They exist to improve performance, accelerate innovation, and broaden communication. When we lose sight of that, it’s just another crappy Intranet.