If only someone would give me a dollar (or at current rates preferably a euro) each time a customer asks us for a ‘SharePoint expert’. That’s like asking for someone who ‘knows about SAP’, or who ‘knows about technology’: it can have a myriad of meanings.
Why is this important to customers and system integrators (like Capgemini) alike? Well, because a mismatch in the understanding of the required skills will at the least cause disappointment for all parties involved. Even worse, it could seriously delay your project. Allow me to explain.
In the first versions of Microsoft SharePoint (2001, 2003), this was essentially a product aimed at team collaboration, built around the mother of all site templates: the Team Site. Sure, there were many things to be configured, but the core functionality dealt with online collaboration around documents, announcements, meetings and core data stored in lists. Customization of the UI was difficult (to say the least); you could always recognize a SharePoint site when you saw one. If you would have asked me for a SharePoint expert back then, I would have known what you meant.
Then came SharePoint 2007. This was a whole new ball game. All of a sudden you could create internet-facing web sites with any look & feel, custom site templates, external data connections, all this using mostly out of the box functionality. Already this meant that we had a few types of SharePoint expertise, which roughly were:
- SharePoint infra expert: the IT Pro that knows every corner of the Central Administration page;
- SharePoint developer: expert in creating customizations by writing .NET code in Visual Studio. Basically a .NET developer, but you definitely need some additional knowledge about the SharePoint object model and how to properly deploy your customizations;
- SharePoint functional consultant: expert in configuring SharePoint through the browser (and sometimes with the help of SharePoint Designer).
With the arrival of SharePoint 2010 though, that has really become too much to ask. We now have a basic platform which already has a ton of functionality. On top of that you can add several pillars of functionality (Microsoft calls them Workloads):
- Enterprise Portals (think intranet and extranet, LOB integration)
- Social Computing (things like social content and feedback, finding people by expertise)
- Web Content Management (authoring and publishing, branding, multilingual and site variations and Internet search)
- Enterprise Search (searching web, file system, LOB systems, with the ‘standard’ search engine or FAST Search for SharePoint)
- Reporting and Analysis (Dashboard and Scorecard services, Excel Services, PowerPivot)
The good news here is that Microsoft consistently uses .NET as underlying technology. This means that the SharePoint development expert can still be one and the same person, who can find his way around customizations for all of the SharePoint platform services and additional workloads.
The problems start with the SharePoint IT Pro. The required skills for implementing the Platform Services compared to the Reporting and Analysis workload are fairly different. Depending on the workload you are implementing, you might need to configure and maintain things like SQL Server Analysis Services, Forefront Unified Access Gateway, FAST Search, or the Outlook Social Connector.
And finally it’s the SharePoint functional consultant who is in real trouble. There is so much to know and configure for the Platform Services and for each additional workload, that it is virtually impossible for a single person to know it all. And if you as a customer need someone to configure SharePoint LOB integration, you will have no use for a web content management expert.
The mere size of the available documentation for SharePoint 2010 is witness to this (tons of whitepapers, templates, checklists, etc.). It has to be said that on the one hand there is more documentation because Microsoft was more thorough in creating the necessary SharePoint 2010 guidance early; right after the product was released, instead of gradually adding the necessary documentation over the course of a few years (the way it happened for SharePoint 2007). On the other hand though, there is simply a lot more functionality in the 2010 product to be described.
Let’s look at the comparison with SAP one more time: no customer asks for ‘a SAP expert’, instead they ask for a ‘SAP FI/CO’, ‘SAP BW’ or ‘SAP HR’ functional consultant, or a SAP ABAP specialist if they need a developer, and so on. What’s happening for SharePoint is that people still need to get used to the idea that SharePoint, like SAP, is moving in the direction of distinct areas of expertise within the product. What’s interesting is that SAP is actually trying to move away from using module names too much. Instead they talk about ‘solutions’ like ‘Product Lifecycle Management’ or ‘Financials’ (even though customers still often use the module names). I think SAP has the right idea: customers have business problems which require integrated solutions, not 'implementation of modules'. This is also why I hope Microsoft will not split up future versions of the product into actual modules. They should stick to using an integrated product where the different workloads represent solutions - as they are doing right now.
SharePoint nowadays covers so many business areas that you really cannot deploy SharePoint without a business strategy to go with it. This also implies that there is no longer such a thing as a general expert who knows everything about the entire product. I doubt if even people with Microsoft's highest SharePoint certification (Microsoft Certified Master - there are only a handful of those worldwide) can claim this, although they probably come close. For a company deploying SharePoint, this means that you will likely need not just 'a SharePoint expert', but a specialist that knows about the specific SharePoint pillars in your environment.
So next time you need a SharePoint expert: do please call us, but keep the above in mind. You’ll be helping us to help you.