Where are we in SharePoint's maturity? While some would say it’s a middle-aged technology in the midst of a mid-life crisis, I think of it more in terms as a teenager in its formative years. The SharePoint platform continues to evolve, from a loosely tied collection of disparate tools (Tahoe), to a limited product implementation (SPS2001, 2003, and 2007 releases), to a dynamic and powerful platform (2010 and 2013 releases), to a cloud-based platform (SharePoint Online as part of Office 365) where features are released on a monthly basis or quicker. My belief is that this next 2 to 3 year phase of development into an online and mobile-first experience is going to be an exciting time -- and will determine what the platform looks like over the next decade.
One of the more common "best practices" long shared with those new to SharePoint (yet often ignored) is to rely first on out-of-the-box capabilities rather than jump straight to customizations. The problem with end-users, of course, is that they adapt so quickly to any app, system, or tool you hand them. Then they come back wanting more. Make it faster. Make it do more. Make everything work together, with a holographic screen and a telepathic interface that knows what I need before I know I need it, and then does it for me in the background.
Every system I’ve ever deployed has quickly been brought to its proverbial knees as end users learned, then mastered their initial capabilities -- and then went on to stretch them beyond their initial design. It's both a strength and a weakness of the software as a service (SaaS) model: a more limited feature set as the vendor needs to provide a supportable, scalable model, but a delivery method that allows that vendor to quickly learn from usage patterns and quickly deliver features that fill those gaps and which provide the highest business impact to their customers.
In an online world where SharePoint is developed as a subscription, the need to build within the allotted tools and frameworks is even more true. What worked for on prem may not work for online, and so how you plan for integrating Sharepoint into your business requires a solid understanding of what the platform can and cannot do -- and staffing your team appropriately. It goes back to the adage that a .Net developer does not equal a SharePoint developer. No longer can you do what we did back in the 2003 through 2010 days: utilize the basic SharePoint framework, but "break" or ignore the model and build over SharePoint a complex .Net-based website or platform. In a multi-tenant world, you can no longer ignore the experts and their advice on best-practices.
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 has changed has been a recognition by most organizations that they are not -- nor should they be -- in the development business. Their focus should be on using the platform, not in reengineering it or maintaining its infrastructure. The focus should be 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, with questionable business value?
End users often ask "can we do this?" but administrators and business owners 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) -- and whether it makes sense to hire full time employees to become experts, or to outsource the expertise.
Next month, my new company GTconsult will be announcing a couple new programs centered around our outsourced SharePoint services, or, as I call it, "an administrator in a box." If you're interested in learning how GTconsult can reduce your SharePoint administrative and development costs while improving both stability and performance, please drop me a line at firstname.lastname@example.org