(Version 1.3 – October 19th, 2008)
In this series, I’m going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).
This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part 
- Conclusion (Part 9)
Introduction
I already mentioned it before, but I’m going to repeat this here for the sake of clarity: I’m very a pragmatic software architect and engineer and the decisions about my tools, frameworks and products are always efficiency-driven and focused on the task at hand. I would never use a product just because "it is such a great product" and I prefer tools that get the jobs done in a clean, well-designed and sustainable way. There are (from a developers viewpoint) some really beautiful, well-designed products and libraries out there (e.g. the .NET Framework in most namespaces, ASP.NET MVC, JSF, JQuery, WCF, Sitecore, IIS7, Spring (Java EE + .NET), Ruby on Rails, (N)Hibernate, LINQ, Microsoft AJAX Library, and some more), there are some products which deserve the label "okay to work with, gets the job done without causing to much confusing" (like ASP.NET WebForms, EJB3, BizTalk) but there are also some pieces of code that are responsible for a lot of confusion and inconsistency in software solutions (I have to mention WF and Outlook 2007 here, although they are based on some great ideas)…
Over the last 1.5 years I developed several applications and a lot of customizations for SharePoint ’07 (MOSS 2007 and WSS 3.0) and gained a deep inside into the platform. Based on that experience, I have to say: From a developer perspective, SharePoint sucks. That does not mean that SharePoint is inherently a bad product. It isn’t. But there are some things about this really huge piece of information infrastructure that drives me crazy and makes it very difficult for me as Software Architect and Lead Developer to really, really like it.
First of all, the overall software design of the product is at some parts really suboptimal. To really customize a SharePoint installation you need to work with pre-defined folder hierarchies in different locations on the harddrive, a huge content database, VisualStudio, SharePoint Designer, INI files, C# code, XSL, CSS, MasterPages, an inconsistent API, several XML dialects and so on… assuming that you know where to look and what to change. Beside that fact, the whole "naming thing" is really bad – some things are named differently in the API than they are in the Site Administrator documentation and the Frontend UI (because of several changes just before the release of SP ’07), and even if you are aware of those traps, you are constantly struggling with the fact that SharePoint has no consistent "appearance" from a developer perspective. It seems like every "feature" (which is some kind of deployment unit in SP ’07) was developed by an independent group of developers. There are numerous deployment descriptors, extended ASP.NET 2.0 features, config settings in files and databases and (of course) some things that do not work correctly if you change them.
Of course, SharePoint adds value to your organisation. That is because it has some really great capabilities like strong document management features, dynamic lists, workflow integration with WF (even if you have to work with another questionable piece of software here), search, integration with line of business apps, the BDC, record management and of course it plays well with Office 2007.
Everyone knows that a sophisticated Content Management System like Sitecore is the better choice for Content Delivery sites, but for the time being it is often also the better option in many Intranet scenarios, especially as gateway system for heavyweight ECM solutions like SharePoint, in those areas where a lot of structured content is produced and managed as well as in projects where individual features and application development is planned. At netzkern we are currently developing several additional modules to provide some of the SharePoint features mentioned earlier (especially document management and dynamic lists), and we are currently developing concepts to integrate both products as far as possible. This is because we want to leverage all the advanced ECM features of SharePoint without having to deal to much with the unnecessary complexity it adds to our development process. The idea for this series is based on that fact that there are several areas in which SharePoint could learn a lot of things from Sitecore, especially from a developers perspective.
I am a fan of a lot of Microsoft products and the quality as well as the inventive talent is constantly growing since the start of .NET in 2001, but there are some areas where they really could improve some of their products, especially if its such an important and strategic product as SharePoint.
This article series will explain why Sitecore is a really great development platform for web applications in intranet, extranet and internet and where SharePoint has (sometimes a lot of) space for improvement.
For part two of the series click here.
