Scaling #SharePoint – A Project Perspective (Part 2)

By | August 6, 2013

In last weeks post I began to outline some of the observations I had made during successful large scale SharePoint projects from the perspective of “the project” as opposed to my usual position of the technology.

I have had several interesting conversations since the post, with a handful of folks asking me to expand further on a couple of my bullet points.

Well, you lucky readers, your wish is my command. I won’t dwell on all of them in detail, I’m pretty sure many of you will readily and totally understand that big solutions are expensive and that getting the platform and infrastructure bang on are core and key requirements so I won’t insult your intelligence by expanding further on these points.

Governance
I’ve said it many times before, I am not a governance expert, so speak to Symon Garfield, Christian Buckley or Sadalit van Burren if you want input on how to do Governance. What I do know is that you. cannot escape the G word, no matter how hard you may try. With large scale implementations of any software solution, you need to manage the implementation, the deployment, the operation, the usage, the evolution, the revolution and the disposal – without all the fancy wordy wrapping, this is what Governance is. At a macro level it’s the management of the solution end-to-end.

I’ll be first to whisper quietly that with a small implementation of a software solution you may get away with little or no Governance, but once you get big; no governance will equal no success. Period.

The bottom line is that governance (regardless of how implemented) is a major part of the implementation and a major determining factor in the success of an implementation of SharePoint.

Microsoft Boundaries Are Being Pushed
With larger and larger implementations of SharePoint, the boundaries that Microsoft prescribe are being pushed. What do I mean by this?

Short version is that a “limit” within SharePoint is something that is (in one way or another) capped in SharePoint – you can’t have more than 2,083 characters in a URL for instance (this is a limitation of Internet Explorer which is based on the limit defined in the RFC for the HTTP protocol) but a “boundary” is a figure defined based on testing. If it has been tested and successfully proved to work that you can have 32 billion webs in a site collection (ahem!) then this would be published by Microsoft as a boundary.

A limit is a set, presrcibed limitation and going beyond either would not work or would be totally unsupported. A boundary is more along the realm of “we’ve tested to this level so we’re comfortable stating that SharePoint works to this boundary”.

With larger and larger environments, these boundaries are being pushed as customers, partners and consultants are pushing the envelope and using real-world scenarios to test feasbility of operation – thus pushing up the boundaries.

Microsoft Limits Prescribe IA
This is something I have personally seen. Certain limits (and boundaries) set down within SharePoint have an impact on design.

Sites per site collection, site collections per web application, nested terms per term store, etc. can all place limitations on how we can define what could (and in some cases should) be a more expansive or expressive IA.

Hammering organisational requirement into software isn’t ideal, but also isn’t new or unique to SharePoint. I guess it just is what it is.

Custom Code Becomes Necessary
In some cases custom code replacing out-of-the-box features becomes necessary. We know that we don’t like chopping up lots of custom code. It’s cumbersome, hard to manage and tricky to support – especially when partner implemented, and we want to avoid it as much as possible.

A handful of the OOTB pieces of SharePoint don’t scale massively thus introducing requirements for other approaches to be employed either as custom code or perhaps in PowerShell.

In recent times I have experienced issues with Content Syndication, Site Creation and MetaData management when these features of SharePoint are flexed to breaking point – resulting in broken functionality, misbehaving functionality and lots of head-scratching to fix it all up, not ideal.

Clearly there are other elements of a SharePoint implementation that do or don’t scale well – those can wait for another post.

more to follow…

Leave a Reply

Your email address will not be published. Required fields are marked *