Scaling #SharePoint – A Project Perspective

This is not a technical or “how to” post, it’s simply a brain dump after I wrote a response to a LinkedIn question about large scale SharePoint environments and what constituted “large”.

In ITPro land, we always talk about “small”, “medium” and “large” in the context of technical pieces and complexity; If you have 2 servers you’re “small” if you have 35 servers you’re “large” etc.

Outside of the IT Group, most organisations don’t think like this, they think about cost, risk, benefit, etc. and there is not always a direct link between ITPro terminology and Business speak.

I know there is a ton of material out there on the intertubes discussing “how to map technical blah-blah onto business jibba-jabba”, most of it developed and posted by smarter people than me, but I wanted to dump down my thoughts as I felt the question thought provoking and (let’s face it) just darn interesting as a subject.

If you are (or your client) is concerned about organisational or decision risk (i.e. are we trailblazing? are others doing this?…) then you may struggle to find really good empirical facts about large scale implementations in the wild.

Most of the companies that use SharePoint in massive scale scenarios are not the sorts of businesses that happily press release or case study their experiences and projects. Anecdotally there is lots of information out there that consultants (myself included) will happily discuss in a client agnostic way but detailed project specifics are few and far between.

I’ve personally been involved in a dozen or so SharePoint projects/environments that exceed the storage scale that was mentioned in the LinkedIn post that inspired this post and in every case I observed the following:

– the client understands the continuum of investment to keep large-scale SharePoint fed and watered
– governance (regardless of how implemented) is a major part of the implementation
– Microsoft boundaries are being pushed
– Microsoft limits prescribe the information architecture
– custom code becomes a factor as some of the OOTB pieces simply don’t scale well
– the core architecture (infrastructure, solution, application and information) of SharePoint is at the forefront of the implementation as opposed to focus on look and feel and other “softer” elements of the implementation
– expectation of performance has been understood, agreed (with the business) and benchmarked to enable close monitoring

SharePoint does scale well when done correctly but it’s fair to say that significant expertise is required to get the best out of all the component pieces and the complementary technologies that SharePoint relies on.