The last couple of weeks there has been some turmoil in the world of SharePoint with a couple of postings (like this recent one) arguing that SharePoint is not really a good solution for companies. It is interesting to read these stories and even more interesting to read the passionate comments of both the pro- as well as the anti-SharePoint visitors.

I have been talking about this quite a number of times the last months trying to explain to people the following:

• SharePoint is not the holy grail. In some companies I visit, management has the assumption that introducing SharePoint will solve all of the problems with regard to collaboration, enterprise content management, search, business intelligence and more. This is of course not true. SharePoint is not the holy grail. It is an enabler for delivering excellent solutions that will increase the productivity of the individual information workers, the teams and the enterprise. I agree with the already mentioned posting, an organization that does not have these processes worked out before introducing SharePoint will likely fail and has no right to blame SharePoint for this failure.
  
• SharePoint is a development platform. For me (and many other people), WSS is your development platform for building solutions for the information worker. MOSS is an extension of that platform with new APIs and new services that aim at delivering more enterprise-wide solutions. If you think that the out-of-the-box experience with both WSS and MOSS will solve your problems (and then we are again talking about the holy grail misconception), then you'll fail. I see great usage of SharePoint within companies that have made the switch. SharePoint is ASP.NET++. ASP.NET is a great framework that is used all over the world to build powerful and rich Web applications (both internal and external). WSS and MOSS add to this layer more object models, more infrastructural pieces and more services that developers can use to build more dynamic, people-oriented type of applications. And these solutions are build in the same way as other software. It requires a bit more discipline, but SharePoint developers can leverage all of the unit testing, source control, and other pieces that support a professional, enterprise-level software development cycle. Anyone who thinks differently, should really start reading books like the one my buddy Ted Pattison has written.
  
• SharePoint is not easy. I would not say complex because that has a negative sound to it. Since SharePoint is a platform (you can also compare it to an operating system - see it as a virtual file system stored in a database), you have an infrastructure that is very often quite overwhelming in the beginning. It reminds me of the early days of the Windows operating systems. They were regarded as complex too. But over the years, even my mother and father are able to share pictures using their Windows Vista Home edition. Things have become easier. Why? Developers have build ready-to-be-used solutions on top of this. Building these solutions is by no means easy, often a challenge, but over the years it has improved considerably. This will happen with SharePoint too. I know the product teams in Redmond are making a lot of efforts to make SharePoint a better development platform, easier to program against, more tools and better support within the professional development environment of the .NET developer. SharePoint is not only difficult for developers, it is also difficult for the administrators and can be difficult for the users. However, administrators very often get the task of maintaining, configuring SharePoint farms as one more additional task on top of what they have as daily tasks. WSS and MOSS are complicated server-side infrastructural pieces that need to managed like you manage other server-side platforms and services (like DNS, firewalls, networking in general, Active Directory). Proper training and more dedicated SharePoint administrators will be beneficial here. The same for the users. If you simply drop SharePoint as something to be used within the organization, you'll fail. Users need training, just like they need training to work efficiently in the Office products or any other software. You can achieve a level without training but a one to two day training (in whatever form) will change the perception of the users and they will be more productive in utilizing what's there in SharePoint.
  
• SharePoint is about building or buying. Yes, SharePoint is a platform. You get powerful APIs for supporting collaboration, document management, content management, records management, document conversions, information management policies, reporting, dashboards, and I can name 15 other types of APIs that are there. Small OOB Features give an impression of what these can do for you. But dudes... if you want to go forward you either have a bunch of dedicated SharePoint developers or you buy. You want workflow? Build or buy stuff like K2, Nintex, Captaris, ... You want records and compliance management? Build or buy stuff like Meridio. You want better search experience? Build or buy stuff like Ontolica Search. You want better offline experience? Build or buy stuff like Colligo. And I could go on here a bit more. Microsoft delivered the platform. Partners and in-house developers build the solutions on top of it. If you don't get that message, then you are back to the holy grail misconception.

I am sure that not everybody agrees with the above. But for me this is the reality and thinking about SharePoint this way makes it easier to accept the many holes and missing things we currently have in SharePoint. You know that you can always build something that will help filling these holes. Is it easy? No way. Is building extensions for the Windows Explorer easy?

Now if you are coming to TechEd Barcelona, Ted and I are hosting two chalk-talks (or interactive theaters as they are called now I think) on all of this:

Best Practices for Developing, Deploying and Maintaining SharePoint Solutions - Q&A (OFF01-IS) - 7 November 2007 Start: 10:45 Finish: 12:00 Room: Room 133

Ted Pattison and Patrick Tisseghem have worked the last 3 years very closely with the SharePoint product team to write and deliver course material targeting a developer audience who want to learn the best ways of building and deploying SharePoint solutions. In this session you’ll have the chance to engage with them in question and answer conversations regarding all of this.
Topics we can discuss are:

• The best way to set up your development environment.
• Working with Features.
• Visual Studio Extensions for WSS 3.0.
• Construction of SharePoint Solutions.
• Deployment options.
• The various scenarios for maintaining solutions that are in production.

SharePoint – the How’s, Why’s, When’s and What’s for Successful Development and Deployment (OFF08-IS) - 8 November 2007 Start: 15:45 Finish: 17:00 Room: Room 116

Join this Interactive Discussion if you are looking for answers to questions like:

• "When is it appropriate to use SharePoint within an organization?"
• "What are the weak and strong points of SharePoint?"
• "What are the pitfalls?"
• "What kind of resources do I need, the level of infrastructure and also people (both administrators as well as designers and developers)?"
• "What are the options to make SharePoint do what why business wants it to do?"
• "What effort is that going to take?"

Drop in I would say and let's have a heated discussion about all of this. I am pretty sure Ted will have some interesting opinions to share with you too.