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?