What is it about "SharePoint" as a platform that is so difficult? I hear this almost every time that you get more than zero SharePoint people in a room. Quite possibly the most frustrating thing about SharePoint for me is the way that companies (not all, but some) view the SharePoint platform as well as staff and train for an operating model around SharePoint itself. A lot of companies are somewhat inadequately staffed or at least inadequately skilled for a full on SharePoint implementation, so I have a list of thoughts that I see out there in the trenches.
First Question: "SharePoint IS built around a bunch of technologies that we already have in house (referring to ASP.NET, C#, IIS, SQL Server, etc.). We have these skills...it's just about learning another object model, so let's just send our people to class and then they will be SharePoint people too."
NO, NO, NO, NO, NO, NO!...This is quite possibly the first and easiest mistake that is made with a SharePoint implementation. Yes, you are likely to have ASP.NET and C# skills in house, but that's not all that is required. SharePoint is a platform that builds on top of ASP.NET. This means that your teams will need to be proficient in ASP.NET before beginning to learn how to develop SharePoint applications (yes, I’ve actually talked with people who think that they can just jump into SharePoint development with no prior web development experience).
With the SharePoint platform, there are MANY disciplines in development, so pick one or two development areas to begin with and then expand from there (TIP: start with web parts, event receivers, and FEATURES). Design for performance and scalability is an essential skill with SharePoint, especially when developing for lists that contain a lot of data.
You will still need to staff for operations, support, usability (e.g. screen designers, which could also be developers), architects, etc. Rolling out SharePoint is a big deal both technically and organizationally (once your users get a taste of the platform, it WILL take off like wildfire). Point of this question...GET YOUR PEOPLE THE PROPER TRAINING!!!! There are several companies that offer training and I would like to highlight 4 of the best: Ted Pattison Group, MindSharp, Combined Knowledge, and SharePoint Solutions. All offer a great lineup of classes with world class instructors, so don't be afraid to reach out to these guys for help, it just could save you a lot of time and effort later on down the road.
So Exchange is a platform and SharePoint is a platform, why can't we just build out our infrastructure like we did for Exchange and be done? Well, technically the first part of the question is correct in that SharePoint and Exchange are both platforms...That's about it. Mind you, they are two different platforms. Exchange is a fairly static platform in that (in most cases) you are basically managing email and calendars for a relatively fixed set of users in your organization (yes, user count will go up and down, but it's not a major deal to capacity plan for users and their mail/calendars/public folders/etc.). SharePoint, on the other hand is a very dynamic platform in that you can have many users and at the same time, those users can have the ability to create sites (which can contain sub sites, documents, lists, workflows, etc.). This means that whatever your SharePoint infrastructure looks like today will not be what it looks like tomorrow, and will definitely not be what it looks like a month from now.
Comparing the operating model of SharePoint to Exchange is very bad, even though it's done a lot. Let's step back a little bit...Shouldn't we really be somewhat comparing the operating model to a product like SAP (not on as large of a scale with much different disciplines, of course)? I think that the SAP guys have it right. With SAP, there are developers that are specialized in a module of SAP (HR, Finance, etc.) and a configuration team that help “customize” or configure each module. There is also very specialized support staff, as well as administrators; all of these people are dedicated resources to any platform.
Arguably, the SAP model this is a correct approach for the SharePoint platform. Developers should specialize in a discipline of SharePoint development (BDC, Excel Services, Web Parts, etc.), you can also have configuration experts that are experts in setting up and operating the platform as well as administrators that are responsible for the platform governance. My point in answering this question is that SharePoint is a very large platform and no one can know it all very deeply…you will find little pockets of expertise with the platform, but at this time people just can’t be an expert in all things SharePoint.
What about Development tools for SharePoint? I love this one, actually because it somewhat highlights something that I have seen building up over time as the development tools get better and better. Let me start off by saying that I think that Visual Studio 2008 is the best IDE that the world has ever seen, hands down. This yields both good and bad results, though. Good results are better developer productivity (and so on...too many to list, VS2008 really rocks). Bad results are developers are not always required to understand what is happening behind the scenes. Yes, Visual Studio does a lot of stuff for you. For example, When was the last time that you compiled a project using the CSC.EXE command-line tool? You don't really have to understand what is happening during compilation because Visual Studio takes the pain out of this process. Developer productivity has never been at a higher level.
So if Visual Studio 2008 is so great, why does development suck for the most part for the SharePoint developers? As bad as I hate to say it, the out of the box Visual Studio development experience for SharePoint is somewhat lacking. Out of the box, there just isn’t a lot of cool SharePoint dev stuff that ships with Visual Studio. We all know it and Microsoft has heard your feedback on this topic. We will just have to see what happens in the Visual Studio roadmap to compensate for this need. So if there is a need for a tool for Visual Studio and developers are the primary users of Visual Studio, you’d better believe that tools will start to pop up to help us out.
Two of such tools to get you started (there are > 200 on CodePlex alone!) are WSPBuilder and STSDev. These are both tool that will help you develop features in Visual Studio and I have used them both extensively. While you are on CodePlex, search for SharePoint and see what you get returned. At the time of this blog, there are over 200 tools that are out there specifically for SharePoint! Granted these are open source projects but don’t be fooled…a lot of these things really rock and can save you a lot of time, so go check them out now (after you finish reading this blog of course!).
Ease into your SharePoint implementation. Another common mistake that companies make with SharePoint implementations is that they want too much too quickly. Start out slow with a base SharePoint deployment and slowly make your way into the custom development stuff. You might consider rolling out out of the box features such as Team Sites, My Sites, and Search to your users first before you start into your first custom SharePoint application. Trust me, your operations folks will thank you for waiting so that they can get their arms around MOSS before developers start chunking there newly developed DLLs at the platform.
These are only 4 (really) random thoughts to consider when creating an operating model (administration, operations, development, etc) for MOSS. Please let me know your thoughts, challenges, and successes by implementing SharePoint in your enterprise. We can all benefit from more of these types of conversations.