I attended a great Information Management morning in Perth last week and bumped into a fair few clients that I had engaged with in my previous Pre Sales role working for a Solution Integrator before moving to the dark side working internally in a SharePoint team.
One of the guys asked me a question around "What do we need the SI to actually quote on to get SharePoint up and running?". This question is open to so many different permutations of answers it's not worth starting to try and list them!
This triggered my train of thought from the other day where I found it hard to draw lines in the sand between our SharePoint "development" team and the Internal Service Desk. Much like most organisations, SharePoint is treated as a Platform and as a development team we release various extensions (solutions) to it.
The list below are a few of the things that the platform runs on which is typically setup and maintained by the Infrastructure Team / Service Desk...and not a Development team.
- the network;
- the physical infrastructure;
- the Windows cluster;
- the standard operating environment;
- the SQL cluster;
- the backup procedures;
- the load balancing; and
- the active directory security.
SharePoint is just the tip of the ice berg, underneath are a vast array of things that can go wrong or perform badly for numerous reasons out of the control of our development team. But we still usually get approached first when SharePoint "runs slowly" or someone "can't access something".
SharePoint resources are hard to come by, which is a double edge sword. It means that for the not so distance future, all of us SharePoint consultants will have a chair to sit on. It also means that we also have to wear many hats and anyone good enough to support SharePoint is usually not wanting to sit in support role for too much longer because Recruiters have spotted it on their CV and offering them Junior SharePoint roles at the nearest blue-chip organisation!
This link from SharePoint God, Joel Oleson, goes on further to to elaborate on the skill set required to be a SharePoint expert. Unfortunately, Microsoft has not done a very good job of drawing lines in the sand between the various components mentioned here or provided mechanisms to fully support a SharePoint expert in going up to the Service Desk and asking for:
- 11 domain level service accounts to be added to Active Directory to install the product; or
- DNS setup for various URLs for each Site Collection in each environment; or
- multiple email accounts in exchange; or
- requiring Kerberos security to install SQL Reporting Services capability on a SharePoint farm; or
- multiple OUs with delegation setup for Incoming Email in each environment.
People are very protective of their own responsibilities understandably and after trawling through the pain of not having any control over anything other than being able to install SharePoint on a cluster has been a painful process! It is hard to actually know exactly what you require from the "powers that be" to get your environment up and running until you actually get to that point...especially with a big SharePoint farm to setup. Once you've done it once...ideally you've documented it and it's all down hill from then on!
So what's with the rant? I'm upgrading to CKS:EBE 2.0 on this blog tomorrow and I'd really like to see some anonymous comments on what other peoples experiences are with the "us and them" mentality of working in this kind of environment.
I'd really like to see Microsoft take more care in educating Windows Infrastructure guys with more understanding of what SharePoint is and how it fits in with the areas they are responsible for. From my experience, it's far too overwhelming a platform and work usually gets pushed into the SharePoint Development teams faces. As an aside, Paul Andrew has posted a great set of links on "how to learn SharePoint".