Sitecore Fetch Squad

(Version 1.0 - January 19th, 2009)

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)

Integration with Developer Tools

In the last part of this series I examined features and tools both framework offer in terms of customization and web designer support. This part of the series is diving deeper into the world of web development with SharePoint and Sitecore.

One of the main reason for an organization to invest in enterprise-class Content Management Systems is to build extended functionality on top of those frameworks. At netzkern we have several customers that made significant investments into their IT infrastructure to enable enterprise application and business process integration, especially using open standards like XML (SOAP, REST, POX). Because of that, extensibility and integration are critical parts of Content Management Systems today and both SharePoint and Sitecore have various integration features and extension points. The question is, however: How easy is it to use those features and interfaces as developer to plug in my own code? Do I need to change the way I’m used to work? And how does the system support me?

As SharePoint comes as part of Microsoft’s server family, the tool to develop SharePoint functionality is of course Visual Studio. So, how do we get started? Well, as developer with some experience in the Microsoft space, you might expect the following procedure: Install SharePoint, install Visual Studio, download “the SDK” (in this case the so called “Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions”, formerly known as “Visual Studio extension for Windows SharePoint Services” -or- “Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2″), take a short look at some API samples, write three lines of code, hit “F5″ and see your first shiny “Hello World”. Unfortunately, that’s not the way it works with SharePoint.

Developing custom SharePoint solutions is surprisingly complex and terrifyingly underwhelming - at least if you’re used to the .NET world. First of all, to install either MOSS2007 or WSS 3.0, you need a Windows Server operating system. It is not possible to install one of them on WinXP or Vista. As developer you usually choose one of the following solutions: Install Windows Server on your workstation, use a virtual machine (VMware, Virtual PC, etc.) with Windows Server or use a central Windows Server with Remote Desktop for development. Although you can use Visual Studio on your WinXP for local development, you need to deploy your code on a server machine for execution and remote debugging (which, by the way, is not that straightforward in most scenarios). Annoying? Absolutely… but it even gets worse.
The by far most disappointing limitation in SharePoint is the fact, that even if you have a Windows Server with VisualStudio and all necessary extensions installed, you cannot just create a new “SharePoint Project”, write a few statements in your IDE, hit F5 and see the results - it’s a long and difficult path to get to that point. But let’s start at the beginning…
As I briefly described earlier, the way to add functionality to SharePoint is by developing so called “Features”. Features can be deployed manually by copying all necessary files into the “12hive” folder and executing a few commands on the command line -or- by using a so called Solution package (a “WSP”). A Solution is basically a .CAB-File (Microsoft’s ZIP format) with a specialized internal file structure, additional configuration files and a .WSP extension. The problem is that there is no built-in functionality to create a WSP file using Visual Studio, neither in the 2005 nor in the 2008 version (this will hopefully change in VS2010 as we will see). We will take a look at how to create such a solution file later in this article, but let’s for the moment focus on how to deploy such a package in a SharePoint environment.
After you have created your Solution file, the next step is to install it using the command line utility stsadm.exe. There is currently no way to install a SharePoint Solution using the SharePoint Central Administration website or Visual Studio, so using stsadm.exe for that task (and some others) is mandatory. That means, you need to have access to the command line on your Windows Server installation and all necessary permissions, which in most cases means those of a server administrator. If the installation is successful you need to open your SharePoint Central Administration website and deploy your solution to all servers in your farm using a certain admin option. At this point you might ask yourself: What farm, for heaven’s sake? Well, your local SharePoint development sever is a farm in and of itself, so deploying your few lines of code for debugging purposes locally is basically the same thing an administrator would do in a huge SharePoint installation with several servers (there is another, slightly shorter way, but it has some additional drawbacks and it is not recommended by Microsoft).
Now that your Solution is deployed on every server in your farm, you need to activate the included Features by executing the stsadm.exe command line utility or by choosing the right options on a particular admin page within your SharePoint installation. Depending on the scope of the Feature (which can be Farm, Web Application, Site Collection or Site), you have to activate it using the Operations Tab in the Central Administration, the Application Management Tab in the Central Administration, the Site Setting of a Top-Level Site (be careful not to confuse the Site Collection Feature setting with the Site Feature setting) or the Settings of all individual Sites. Okay, pretty exhausting, but we’re not finished yet. Remember, that I said “After you have created your Solution file…”? Well, let’s see what goes into a Solution file and how to build it.
First of all you need to create a separate DDF configuration file for the MakeCAB.exe command that is being used to create the CAB archive (which will be renamed to .WSP). I will not go into detail here as nearly every SharePoint development books covers this process in discrete chapters (which is necessary because you can virtually not do anything without knowing how to perform that task). Then you have to create a file named Manifest.xml. This file is called the Solution Manifest and contains information about all contents of the WSP and directives about how to deploy the contained Features to a SharePoint farm. A Solution file can contain several Features in separate folders and each of those Features needs to have a Feature Definition file (named Feature.xml) and an Elements file (usually named Elements.xml). Those three files have at least a couple of XML code lines each but they are usually much larger and contain dozens of statements.
Now it’s time to write your code and create additional entries in the appropriate XML configuration files (Manifest.xml, Feature.xml, Elements.xml), which you can by used to create SharePoint artifacts during the installation (Lists, Libraries, etc.), react on certain events (like Feature activation) and register resources and assemblies in the GAC. When you’re done, you create the WSP file using the MakeCAB.exe command with the prepared DDF file and install the Solution into the server farm using the stsadm.exe command utility as described above. (I strongly encourage you to automate this tasks using MSBuild, NAnt, Automise or another build utility.)
Now its time to deploy and activate your feature as described above. At this point you should make sure that the Solution Framework has “whitelisted” your code in the appropriate configuration file. This security feature makes sure that no “bad code” is executed in the system, but SharePoint sometimes fails to handle that situation correctly for you, so to be sure you better check.
Finally it’s time to test your code. Got an error? Oh sorry, please start from the beginning (or at least, repeat most steps of the whole process). If you want to debug your code (which is most likely the case), you have to attach your Visual Studio to the IIS Worker Process (w3wp.exe), presuming that you have all necessary permissions. (I hereby strongly suggest that you develop SharePoint customization using an administrator account.)
So, why on earth is it so lengthy to install and run a very simple example in SharePoint? Seriously, I have no idea… As Software Architect with experience in several enterprise projects, I can understand the intention behind the package mechanism, the multi-step farm-wide deployment model and the feature activation process when running SharePoint in a large server farm, but it is a mystery to me why it has to be that complex and confusing during development and in simple scenarios.
There are, however, a couple of advantages using a complex deployment system like the SharePoint Solution Framework. One of which is the possibility to “rollback” the installation of a package completely, but we will cover this in the next part of our series.
To get more details about how to develop custom solutions for MOSS 2007 and WSS 3.0, I recommend reading the following articles on MSDN (part 01, part 02) and to take a look at the WROX SharePoint Box, which I would have chosen for myself if I hadn’t ordered every book right after the initial release separately (Damn… ;-)!).
A couple of weeks ago, Microsoft released a statement to the press that they are going to enhance the support for SharePoint development in Visual Studio (VS2010) significantly in the next release, which is expected to ship in the end of 2009 (hopefully, click here to read more). I for myself can absolutely not understand why Microsoft would wait for more than six years to announce full support for their primary office collaboration framework in their primary integrated development environment VisualStudio, especially as SharePoint is even set to replace functionality of Exchange and Access / Excel / SQL Server. They put so much effort in developing and selling SharePoint as the number one web platform and today there is only half-baked support for customizing the system.

Advantages

1. SharePoint provides a Visual Studio extensions packages that helps the user by adding project and item templates, references and some documentation to Visual Studio. However, it does not help to ease the burden of deployment which remains overly complex.
2. SharePoint provides a full-features deployment system called the Solution Framework that developers can use to deploy their code within a SharePoint farm. We will cover that in more detail in the next part of the series. Unfortunately you cannot really bypass the whole deployment system during development (although you can bypass the Solution part and install Features without a WSP package “by hand” by manually copying your files to the “12hive” and running some additional stsadm.exe commands).

Drawbacks

1. SharePoint is not integrated with Visual Studio at all. It is not possible to hit “Run with Debug” (F5) and see your code executing. Instead, you need to describe your code using various XML files, pack it into an archive with specialized tools (MakeCAB.exe + a DDF file), move the resulting WSP package to the runtime environment, install it using the stsadm.exe command line utility, distribute it within the farm using the Central Administration web application, activate the appropriate Features in different locations within SharePoint (depending of the scope of your Features) and attach your Visual Studio manually to the executing process (which may execute on another system).
2. It is not possible to use Visual Studio for all development tasks, so you regularly need to switch to SharePoint Designer (which can be used to access SharePoint directly, which in turns makes trouble with Source Code Management), the command line and the SharePoint browser interface.
3. SharePoint can not be developed completely on a usual WinXP or Vista workstation because it is at least necessary to use Windows Server with an installed SharePoint as runtime environment. To have a reasonable development lifecycle, using Windows Server as development platform (be it native, in a virtual environment or on a central server) is strongly recommended.
4. Even very simple tasks like deploying a custom web part (which is in this special case possible without the whole Solution mechanism by deploying it “locally” to the IIS site into the physical /bin directory) is not straightforward, as you need to create at least one additional deployment file (for registering the WebPart within the web application) and you need to “mark” your code as trusted using the SafeControl directive in the application’s web.config file, sometimes in combination with additional directives to manage permissions.
5. The packaging mechanism is not able to handle all update and rollback tasks correctly, which is really odd as it has been designed for exactly that purpose.

As you know, Sitecore is based on .NET, and so the tool to develop extended Sitecore functionality is of course Visual Studio as well. So, let’s see how to get started here? Again, as developer your expectation might be the following: Install Sitecore and VS2005 (or VS2008), download “the SDK”, take a short look at some API sample, write three lines of code, hit “F5″ and see your first shiny “Hello World”. And guess what? That’s exactly the way it works.

From the perspective of .NET, Sitecore is just a well integrated ASP.NET web application with advanced functionality and you can even run it using the WebDev.exe development server that is coming with Visual Studio, regardless whether you’re running WinXP, Vista or Windows Server 2003/2008. You can also use the local IIS coming with those operating systems (yes, even IIS 5.1 in WinXP), it is totally up to you.
This means you get all the things you’re familiar with: Debugging .NET code (and even XSLT code) without any additional tasks, deploying additional assemblies to the /bin folder, using source code management tools and experience no limitations while doing your job. The integration of Sitecore and ASP.NET is really seamless. Another great thing is that you’re not limited to Visual Studio, but you can even use Microsoft Expression Web to run Sitecore and choose every external editor (e.g. for editing your XSLT files) to change Sitecore solution and resource files.

In contrast to SharePoint, Sitecore provides you with a couple of additional developer tools within the system that can dramatically improve the quality of your results and your personal productivity. By using the integrated debugger tool to debug your web pages, you get a lot of useful information about your code, your renderings and your design, right where you need it. You can also use the Sitecore Developer Center to edit your XSLT code, your layouts and even your .NET code, so you don’t need to use Visual Studio for very simple task like a short bugfix or minor update. Sitecore’s Package mechanism makes it ease for you to deploy the code you created in your local or central development environment to integration, test and production environments (more about that in the next part of the series) and you can use the integrated log4net to trace the flow of your application without configuring and maintaining a separate logging framework or the Windows EventLog. While creating a reusable content type usually involves a lot of XML hacking, deploying, installing, activating and configuring within SharePoint, using the Template Manager in Sitecore to create your own information structures is a breeze.

Advantages

1. Sitecore is 100% .NET, not only at the code-level, but also on at the development and the deployment-level. There are no surprises whatsoever when starting to work with the framework.
2. Developing for Sitecore is exactly like developing with any other .NET library, as it is fully integrated with Visual Studio and the WebDev server. You can even use the free editions of Visual Studio or Expression Web - or any other tool you prefer as long as it runs on the Windows platform.
3. Sitecore offers additional developer tools as part of the distribution and in form of additional tools through the Sitecore Developer Network.
4. Visual Studio is your one-stop place for developing Sitecore features, there is no need to switch to any other application, except you want to.
5. Sitecore can be used with any Source Code Management tool without any problems.
6. There is nothing more to say here: It just works.

Drawbacks

1. For the time being it is not possible to rollback Sitecore package installations. This would be a very, very nice feature for the future, although I’m aware of the complexity of that request.

So let’s draw our conclusion here. Regrettably, developing custom code for SharePoint is neither fun nor productive. It is - sorry! - a pain in the ass. There is no real support in VS2005 or VS2008 and we all have to wait until the release of VS2010 to get a more optimized development lifecycle (and hopefully the “F5″ experience) when developing extensions to SharePoint.
Developing Sitecore on the other hand is a breeze for every .NET developer. Of course, no framework is ever complete nor perfect, but Sitecore has managed to create a great developer experience and a pretty great framework.

Sitecore: +10 points = 34 points total
SharePoint: +3 points = 20 points total

See you soon for part six…

Hey guys,

a pretty theoretically and interesting article or better: comparison of Sharepoint and Sitecore. I think it’s worth reading, but I’m a friend of creating my own opinion

Enjoy… cheers chris

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)

Blog Article

(Version 1.1.1 - 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)

Customization and Designer Experience

The term "customization" is used in SharePoint to describe the work of creating solutions without actually writing code or using the API. The work can either be done using features of the SharePoint Browser Interface or the Microsoft Office SharePoint Designer application. The result of this work is stored inside the content database of a SharePoint site collection, it is not deployed in form of compiled DLLs and additional resources.
In Sitecore, a similar kind of work is performed by a Sitecore XML Developer (sometimes referred to as Sitecore HTML Developer or SCD1, in contrast to the Sitecore API Developer, sometimes also called Sitecore .NET Developer or SCD2). Sitecore XML Developers create conceptual artifacts (Layouts, Templates, Renderings, Items) using the Sitecore Client (a superior Desktop-like web-based UI) and external XML Development Tools of their choice (e.g. Notepad, UltraEdit, Dreamweaver, Altova, VisualStudio, Expression Web, etc.).
This article refers to this content-centric development process in both products as "customization" - real "development" using the API by writing code is covered in a later part of this series.

SharePoint provides a lot of customization functionality out of the box. As stated earlier, both WSS 3.0 and MOSS 2007 come with a couple of ready-to-run features for endusers. Most of these features are based on Lists, one of the main building blocks of SharePoint. Nearly everything related to content in SharePoint comes in form of some kind of lists or as an extended version of this concept, be it calendars, document libraries, task lists or even webpages. Users can create lists with the SharePoint Browser Interface, define fields, attach basic workflows, versioning and use other options. Developers can go a bit further and create so called "site columns" and "content types" which are basically global definitions of fields and (partial) list types. To display contents of lists, there are several options. I will not cover all of them here but I’m going to mention some of the most common approaches.
But before I do that, there is another functionality I want to mention briefly. It’s called the Web Part Framework and should sound familiar to every ASP.NET 2.0 developer. In fact, Web Parts are essentially the same in SharePoint as they are in ASP.NET (actually, the Web Parts concept has been introduced with SharePoint 2.0 and was adopted by ASP.NET 2.0). The main difference is that Web Parts in SharePoint are placed in Web Part Zones on Site Pages, which are located in the SharePoint content database, not in the file system. To learn more about Web Parts click here.
The first and simplest option to store and display structured data in SharePoint is to create a list, add some content and create additional views using the SharePoint Browser Interface. Views can be created using pre-defined templates and by specifying filters and other options. They can afterwards be placed on customized Site Pages and page layouts using the Web Parts Framework. SharePoint provides a couple of customizable Web Parts to display data from lists. These include the Content Query Web Part, the Data View Web Part and the XML Web Part.
A second and more advanced option is to use the customization settings the Content Query Web Part. In this approach developers use the existing XSLT capabilities of the CQWP to render the content of a list based on a XSLT Stylesheet. This can be done by creating customized XSLT Stylesheet and upload it to the Style library of a SharePoint site, which in turn makes it available for the CQWP settings dialog.
In addition to this structured approach (data is stored separately in lists, presentation is configured using web parts), the Web Part Framework does provide some Web Parts creating unstructured, discrete content, for example to place a styled HTML text and an images on a web page. From my perspective as Software and Information Architect, I have to strongly advice everyone against adopting this approach. It does not only intermixes content and presentation, but it also creates volatile content which in turn will lead to an unmanageable mud of information islands, detached from the overall information architecture.
Unfortunately, these content Web Parts are not the only way to create "sloppy" pages in SharePoint. Using SharePoint Designer, you can also create simple Content Pages (at least they are based on existing Master Pages, which define the overall layout of several pages in a Site) that can contain Text, Images and other HTML elements. Sounds familiar? Of course, it’s only "unmanaged" HTML, hopefully at least based on central styles and encapsulated by a MasterPage. This approach violates the same principle as the way mentioned before and I strongly discourage everyone from using it.
A much better way is the possibility to use the Web Content Management capabilities of SharePoint by using the Publishing Site functionality of MOSS 2007. To utilize its features, a developer has to create site columns and content types, which define a basic content structure for information that are going to be processed within a SharePoint Site. Having done that, he can create list items based on those content types and display them using SharePoint Page Layouts. Page Layouts are basically ASPX pages with controls. "Pages" (which are essentially list items based on Content Types in this case) use them to display their field values by "filling" the controls in those Page Layouts. SharePoint automatically combines them with one of a few pre-defined MasterPages, managed as part of the Publishing Site to ensure a common look and feel across pages.
This is by far the most structured approach to create web pages in SharePoint, but unfortunately there a couple of drawbacks.
Every list in SharePoint can also be accessed using RSS and other defined protocols, for example using Microsoft Access or web services.

SharePoint comes with a couple of out-of-the-box Features. Most of the configuration necessary to use those Features is performed automatically when a user creates a new Site based on an appropriate Site Definition (not to confuse with a Site Template… *urks*). The Site Definition activates certain Features right after it has been provisioned in the SharePoint Content Database. These Features do not only create additional functionality, they also change the behavior of the whole SharePoint Site, add pre-defined content and structures, extend menus and perform several other tasks.
This behavior is essentially a good idea, except for the fact that in some cases, there are no "clean" Site Definitions available for certain kinds of Sites. That means, you often get a couple of sample content, pre-defined lists and a couple of unnecessary customizations with every Site.
Unfortunately, one bad example for this situation is the "Publishing Portal" Site Definition (often just referred to as "Publishing Site"). It automatically activates all WCM (Web Content Management) Features in a SharePoint Site, but it also creates a couple of useless and even annoying things inside your newly created project workspace. Well, there are two options how to deal with that. The first option is to delete all that stuff by hand, hoping that you do not destroy any of the necessary functionality of a Publishing Portal (e.g. the TasksList and the WorkflowHistoryList which are necessary for certain automatic workflows activated by Publishing Site). The other option is to create a minimal Publishing Site Definition yourself - and it’s not exactly a pretty easy task.
This problem is so common that some SharePoint authors devote complete chapters to the creation of Site Definitions, just to have a "clean" starting point for their sample projects (e.g. "Professional SharePoint 2007 Web Content Management Developement" by Andrew Connell, Chapter 5: "Minimal Publishing Site Definition", WROX Press, 2008).
Another main drawback in customizing SharePoint is the integration with existing SCCM infrastructure and release management procedures - basically because it is not possible. Using either the SharePoint Browser Interface or the SharePoint Designer application, changes are generally performed directly in the SharePoint content database, which makes it difficult (if not impossible) to use it with source code management tools and in staged testing environments. Of course it is possible to create deployable SharePoint Features as part of "Solution Packages" (more about that later) which can contain all those things (lists, list templates, site columns, content types, page layouts, XSLT Stylesheets, etc.) in VisualStudio, but this is really a pretty heavy development task just to create some structured content that can be managed using Subversion or TFS. Nevertheless, that approach makes it possible to use source code management tools, although it is much more complicated and it lacks the nice usability that is provided by the SharePoint Browser Interface and the SharePoint Designer.

Advantages

1. SharePoint delivers a lot of relatively easy-to-use out-of-the-box features. Some of them can be customized using the SharePoint Browser Interface, others using the SharePoint Designer.
2. Using pre-defined Site Definitions, SharePoint users can easily create new SharePoint Sites based on a list of pre-defined Features and containing several customization.
3. Structured pages in SharePoint can be customized using either the Web Part Framework or by defining Page Layouts, Content Types and creating Site Pages based on list items.
4. Some Web Parts provide additional styling and customization options using XSLT and settings.
5. Developers can use most of their knowledge about MasterPages and WebForms to create a common look and feel, although they need to be aware of certain limitations.

Drawbacks

1. From a developers perspective, customizing SharePoint is not a consistent experience. There are several levels of customization with certain limitations, as well as different approaches and tools.
2. Using a combination of the SharePoint Browser Interface, SharePoint Designer and some external tools, customizing SharePoint basically means re-arranging pre-packed snippets of functionality. Sometimes this pre-defined features are even getting in the way of the developer, for example if he wants to start with a fresh and clean project.
3. The development task itself is a mix of using features of a web-based browser interface with some editing controls (SharePoint Browser Interface), a desktop application (SharePoint Designer), writing some XSLT (maybe using Expression Web), defining some CSS classes and creating HTML pages with placeholders. There is little guidance about where to start and no continuous workflow for creating content structures and presentation elements.
4. SharePoint has some features that support the creation of unstructured content, without separation of content and presentation, bypassing the overall information architecture and decreasing manageability and maintainability. Unfortunately by not disabling these features (which is not that easy), users tend to use them a lot, primarily because they are easier to find and to understand than most structured approaches in SharePoint.
5. From the perspective of this article (which is focusing on "customization" and not on "development"), SharePoint is limited to create page-driven content, which means that most data can not easily be re-used in the same Site or across Sites. This often leads to inconsistencies caused by duplicate information. The introduction of Site Columns and Content Types is an important step forward from SharePoint 2.0 and demonstrates Microsoft’s efforts to integrate functionality of MCMS 2002 into MOSS 2007. But the fact that site pages can only (or at least without additional development effort) be created based on the fields of a single list item is still a huge drawback. Although lists can have relationships to other lists, using those relationship during customization (again, we’re not talking about development here) is not trivial.
6. SharePoint Designer and the SharePoint Browser Interface perform their changes always directly in the SharePoint Content Database. Besides some other drawbacks there is currently no support for SCCM tools. At the moment it is also not possible to use SharePoint Designer with files in the file system without creating some strange side effects that can even kill your complete SharePoint installation (hint: you should never open and save an application-level MasterPage in the "12 hive" with SharePoint Designer).

In contrast to SharePoint, Sitecore does not aim to provide a handful of pre-defined "content snippets" and a relatively fixed site design for immediate user activities right after the installation has finished. From an architectural point of view, there are several good reasons for that.
First of all, building an information architecture and a decent taxonomy is not anything you should do lightheaded. Even if you have a pretty small site, you should definitely give some thought to what you want to present to your users and how do you want to do that - at least, if you want to create something, that is built to last.
Secondly, how can anyone else know how your users and customers are going to work? Of course there are several "common features" on a website or in an intranet project, but the question is: Do you want pre-defined functionality, limited to a specific solution based on a pre-defined perspective of a common problem -or- do you want a flexible eco-system with everything you need to rapidly build everything you want?
Thirdly, I don’t know any developer who really likes it to re-arrange stuff someone outside of his own team created. Human brains do not work the same way and to follow the line of thoughts of someone you don’t even know is not only complicated, error-prone and inefficient - it is also not much fun.
What Sitecore gives you as a developer or as information architect is intentionally not a bunch of tools and features to create a bunch of inflexible web pages based on "pre-packed" pieces of code. Instead it provides you with a full-featured framework for building a web based structure of your information, your processes and your organizational reality, enriched by an API that makes it a fully-fledged web application framework.
Heaving said that, there are some folks out there that might say: But that’s exactly what I want, I need some things right out of the box. Does that mean, Sitecore is not for you? Absolutely not… In fact, you CAN use existing functionality, modules, information structures and even content, built by experienced Sitecore partners and Sitecore itself. Go to SDN, download a predefined site package (packages are deployment units in Sitecore, like an MSI package for Windows) and install it into your fresh Sitecore system: Tadaa. If you want to, you can get a complete website with design, structure, additional functionality and sample content. And it’s your choice to select which demo site, starter kit, intranet package or whatever else to use as basis for your site.
The question is: If you are more and more becoming and experienced Sitecore developer, to you really want to start your projects by deleting and re-structuring demo content? I wouldn’t…
What you can do instead is to build your own "starter kits" and "toolboxes" right in your own Sitecore and use the package mechanism to move it to your next project. And that is really powerful. So powerful that we will talk about this in-depth in a later part of the series.

Sitecore’s architecture is one of the best-designed software architectures in terms of Content Management Systems I’ve ever seen. The main concept of the architecture is an universal piece of structured information, named Item. This concept is simple, but very powerful. In fact, everything in Sitecore is based on Items - even Sitecore itself. Sitecore Items live inside a hierarchical structure named the Content Tree. In contrast to SharePoint where you can take a look at your Site Collection in a hierarchical view called the "SiteManager" (you can find it at different locations under the name "Site Content and Structure"), Sitecore’s Content Tree is not only an aggregated view of database content, re-arranged to get a comprehensive view, it is really the way the whole system is structured. Browsing Sitecore’s Content Tree using the Content Editor (Sitecore’s "Windows Explorer") as administrator gives you the ability to see and access every piece of information within the application.
Sitecore’s XML development features (which we call "customization" in this article series) are based on a so called "content-driven" approach to content management. "Content-driven" means, you are goind to structure your information first and then you decide, how and where to display it to your users.
To define the structure of the data used in your site, a developer defines a couple of blueprints for the data, similar, but more powerful then Site Columns and Content Types in SharePoint. To be honest, these blueprints have a very misleading name. In Sitecore terms they are called Templates. A Template is the definition of a certain type of structured data within Sitecore, like a class in OOP or a table definition in SQL. It contains definitions for various fields based on certain types, similar to properties in object-oriented languages like C# or columns in a SQL Server table. This concept has something in common with content types, lists and list items in SharePoint, although there are several differences. I will not go into detail here, but here are some important distinctions:

1. Sitecore Templates can be chained and they allow "multiple inheritance".
2. Sitecore Templates allow additional options per field.
3. Sitecore Items are hierarchically structured and can have complex relationships to other Items or complete structures of Items.

After you have designed the structure of your data and some content, the next thing to do is to present that content to your users. In Sitecore, this procedure is called "rendering". There are several options how to render content in Sitecore as it comes out-of-the-box with a bunch of technologies for that purpose. The one we are going to talk about is named "XSL Rendering" and it is by far the most common way. The rendering framework of Sitecore can be extend and at netzkern we are currently discussing a couple of ideas how to do that (e.g. providing support for Ruby on Rails-style templates, for XQuery, HAML and MVC Views).
I’m not going to explain exactly how to develop with XSLT in Sitecore, because that topic is covered in-depth in several tutorials on SDN and (of course) in every Sitecore training. What I’m going to do is to give you an impression of how customization works with XSLT in Sitecore (remember, it is not the only option for customization) and why it is so powerful.
In an earlier article I described the way Sitecore handles requests and we are going to extend the explanation here a bit further. After Sitecore has dispatched the request to ASP.NET, the .NET framework opens the requested ASPX and (if necessary) compiles it together with its code-behind file (actually, in Web Application Projects, there is also a second partial code-behind file that is merged with the ASPX markup file). The result is a HTTP Handler component, which receives and handles the request by executing a combination of framework code and custom code hooked into the processing pipeline using events (PageLoad, PreRender, OnClick, and so on).
This ASPX file usually defines the overall layout of a Sitecore page and of course you can use MasterPages and all other ASP.NET WebForms features. In Sitecore terms, this file is called a "Layout" and it is also managed by Sitecore. The Layout can contain a couple of Sitecore controls. Again, in contrast to SharePoint that handles controls on customized site pages a little different than pure ASP.NET, Sitecore controls are just powerful .NET components, completely in harmony with the ASP.NET WebForms framework.
Depending on the architecture of your site, you can choose whether a Sitecore Rendering is placed directly on the Layout or if you want to use the Sitecore Presentation framework to load it dynamically into a placeholder. I will not go further into detail here, but please don’t hesitate to consult your local Sitecore partner, the forum at SDN or to drop me a line.
What I want to mention is a feature this article will refer to as "layout composition". In Sitecore, you can dynamically combine different Layouts, based on the page or type of pages being delivered. In Sitecore, you can create independent parts of Layouts, called Sublayouts. Sublayouts are basically ASCX controls, derived from a special base class. The rendering engine of Sitecore uses placeholders in to dynamically arrange Sublayouts, Renderings and Controls on a Sitecore Layout and merges them together, even with MasterPages. That way, you can dynamically assemble your pages which dramatically reduces the number of Layouts necessary and by that means the amount of work to create and maintain a consistent look and feel. For example, to build 5 slightly different designs, accessible not only using a Desktop browser but also a mobile device, you need to build 10 Page Layouts in SharePoint. You achieve the same result in Sitecore with two Layouts and two Sublayouts.
This feature alone increases your productivity significantly and it is one of the main reasons, why Sitecore was appointed "cool vendor of the year" by Gartner.
At some point, Sitecore calls your XSL Rendering with the structure of the Sitecore Content Tree as parameter. You can now use the whole power of XSLT and additional Sitecore Extension Functions to transform your content into HTML or - if you want to - into some other kind of XML or non-XML structure. XSLT is in its capacity as functional, transformational language a perfect fit for the Sitecore Content Tree, the Items Concept, the way humans think and (most importantly) nearly all information architectures and websites are structured.
If you have not worked with functional programming languages or transformation DSLs before, it might at first feel a little strange, but XSLT is known for a very steep learning-curve. If you are not comfortable working with XSLT at all (although you should at least try to), no problem! As I mentioned earlier, there are several other rendering technologies already available and more to come (especially using the ASP.NET MVC View template language is in my opinion a very promising candidate for the future).

As you can already see from the way this part of the article has been written, creating Sitecore-based sites and applications is pretty straightforward and your course of action is based on a defined process with additional guidelines. Pages in Sitecore are essentially the combination of layouts as dynamic containers for information coming from the Content Tree. Page Layouts and MasterPages provide a common look and feel as well as advanced functionality, if necessary (we will cover that in a later part of this series). But let’s summarize what we have learned.

Advantages

1. Sitecore provides a simple, well-integrated and very powerful Software Architecture with a universal concept named Sitecore Items.
2. Developers can use the Sitecore Installer to install pre-defined Sitecore packages to use as starting points for your development -or- to create their own toolbox.
3. Sitecore provides strong separation of content and presentation. In fact, creating presentation artifacts is also separated into designer responsibilities (MasterPages and ASPX Pages) and developer tasks (Templates and Renderings), so each group can work usually work without influencing the other groups work.
4. The Sitecore Item concept is much more flexible and advanced than the SharePoint list concept. It is additionally easier to understand and to use, if explained properly (e.g. by reading the documentation or attending a SCD1 or a SHD training).
5. Developers are presented with a clear guidance on how to create Sitecore sites.
6. As Sitecore Renderings are living in the file system, a developer can select his tool of choice and orientate oneself by the nature of the task at hand. It also depends on the type of rendering being created.
7. Sitecore’s Content Tree usually reflects your individual information architecture.
8. Sitecore is completely "content-driven" which makes it possible to re-use content across pages and sites without any additional effort.

Drawbacks

1. Sitecore does not provide the same amount of out-of-the-box functionality as SharePoint, therefor It is not a plug’n'play system. It is up to the developer to install a complete pre-designed site, partial site templates or additional features using the Sitecore Installer within the Sitecore Client web interface.
2. Sitecore is more developer-centric than SharePoint. You have to learn about the Items concept and you have to learn at least one rendering engine, preferably XSLT.
3. To provide all the table-centric features of SharePoint lists with all filters and options, a Sitecore developer has to create a certain amount of customizations, especially templates and renderings. This might be a good place for future improvement, especially for intranet scenarios (and yes, we’re currently working on a concept).

This article covers a lot of features in both products and should provide a pretty complete overview of the customization a developer usually performs in both platforms. Unfortunately for Microsoft, SharePoint lacks the transparency and clarity of Sitecore and makes it difficult for developers to use all the pre-defined SharePoint features productively. Sitecore also surpasses SharePoint in terms of flexibility and it is better integrated with the ASP.NET framework. Because of that, working with Sitecore feels much more natural for a developer. SharePoint provides more out-of-the-box features, but developers often stumble upon the complexity of these pre-packed components. Sitecore, on the other hand, can be easily extended with additional functionality and even complete sites.

These facts lead to the following verdict from a developer perspective:

Sitecore: +8 points = 24 points total
SharePoint: +5 points = 17 points total

Looking forward to see you soon in part 5.

(Version 1.1 - October 11th, 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)

Configuration

SharePoint and Sitecore both are platforms built with extensibility in mind to allow organizations to create their own functionality and integrate them into the product. This article will cover one aspect of this process by giving an overview of the way a developer has to configure different settings during the setup of a new project within an existing SharePoint or Sitecore installation. Of course there are several other "configuration tasks" a developer has to perform within SharePoint and Sitecore to develop additional features, for example to configure individual lists (SP) or to change what Rich Text options to show in an Rich Text Editor (SC), but those topics will be covered in a later part of this series.

To configure SharePoint, you usually have to take a couple of steps in different locations all over your server to setup a new project. Usually your journey starts in a special SharePoint site called "Central Administration". It is installed by the SharePoint installer and provides you with a task-oriented web interface to perform several operations: Configuring farm options, creating and configuring new "web applications" and "site collections", changing server parameters and so on. The settings that can be changed by Central Administration are either settings in one of several config files on disc (some of them in the "12 hive", some others in local config file of the selected SharePoint site collection) or in different SharePoint databases (global settings are stored in the administration database, other settings are stored in the content database of the selected SharePoint site collection).
Central Administration is also the main entry point to jump to another configuration portal for configuring so called "Shared Services Providers" (SSPs). SSPs are special SharePoint applications providing features that can be shared across multiple SharePoint web applications and site collections, like global search, user profiles, audiences and so on. Although it is relatively comfortable to reach, it is not always clear whether to look for a particular setting in the Central Administration web or in the configuration web of a particular SSP. As that configuration web is really a separate SharePoint site at its own URL, we have to count it as separate interface (which makes two places to look for settings in total).
When the administrator creates a new web app and a new site collection within a SharePoint content database, and before he (or she) can connect it with an appropriate SSP, SharePoint creates a new IIS web and a folder in the file system. This folder contains the Web.config responsible for configuring a lot of "local" options for the site collection - it is that file which tells the ASP.NET ISAPI module of the IIS Worker Process what to do with a request to this web application. Although you can change some options of that Web.config file using the Central Administration web site, there are other options you may have to configure by hand in the Web.config file. For example, you can change the way authentication works for a particular SharePoint site collection in Central Administration, but really fine tuning it is a task you should perform manually in the Web.config file. Makes three so far.
Now that you have created your SharePoint site collection you can access it at its own URL. The first site in the site collection, called the "root site", has an extended settings page. You can use that settings page to configure various options for the site collection and the site itself. Four.
Every site that you create underneath the root site using one of several site templates has of course its own settings page. It has not as many settings as the root site, because it cannot change site collection options, but some settings you changed at the root site do not influence other sites in the site collection, so you have to change them in the settings section of the particular site. That’s number five.
I already mentioned in the introduction that SharePoints functionality is packaged into deployment units named "features". Features are configured and deployed by the server administrator and can afterwards be activated for the whole farm, the server, the web application, the site collection or an individual site. To configure features and some other advanced options there is currently no web interface and no configuration file available. The only way to do this is using a command line utility named STSADM.EXE. This command line utility can in addition change a lot of advanced configuration options that cannot be changed using one of the web interfaces or configuration files, which makes it number six.

Okay, let’s wrap up this summary. SharePoint is targeted towards mid-sized and large organizations. In those organization there are theoretically several levels of system administration and that is what the SharePoint team tried to consider when they created different kinds of configuration interfaces. From that point of view it makes sense to have settings for the local site in a configuration panel at the local site, so that the site collection administrator (in contrast to the server or even the farm administrator) can configure some settings for his own people. Unfortunately in reality this concept is a little edgy. First of all, in practice there are seldom "administration levels" - usually there is a group of administrators and developers responsible for operations and maintenance of a SharePoint farm (or even a single server) and they perform the majority of work in terms of configuration and customization (We know that from enterprise customers like Siemens and others). Secondly, the concept is not consistently implemented. There are still features that need to be activated manually in config files somewhere over the server or by using some "external" utilities. Thirdly, I have to ask the question: Why not make one single well-designed web interface for all configuration options and use the security subsystem to decide, what option to show to or hide from the current user?

Advantages

1. A lot of features and settings can be configured using web interfaces.
2. SharePoint has an "administration hierarchy" which allows server- or farm-wide administrators to configure other options than site collection or site administrators.
3. SharePoint Central Administration handles all server-wide (or "global") configuration options as well as some individual settings for every SharePoint web application or site collection.

Drawbacks

1. Different places for similar settings make it sometimes difficult to know where to search for a particular option. It is even more confusing for non-administrators who has been granted some permissions to change certain options.
2. Although most features can be configured using one of several web interfaces, it is sometimes necessary to change some configuration files manually or to use the command line utility STSADM.EXE.
3. The intended separation of administrative levels is seldom reality in most companies. Because of that, administrators have to switch between several web interfaces to complete one operations request.

If you are a .NET Web Developer or an administrator who is familiar with IIS 7.0 on Windows Server 2008, configuring Sitecore is pretty straightforward. After you have installed Sitecore, there is basically one file where you can configure each and every aspect of the system: The Web.config file in the root folder of your Sitecore web.
Sitecore’s Web.config is a really big file with literally hundreds of settings in dozens of sections - but it is surprisingly easy to understand. There are several ways to learn about the Web.config: You can take part on one of several Sitecore Trainings (for example at Germany’s Top Sitecore Training Center) or you just take a look at the Sitecore Developer Network (SDN), but you can even just open the file and take a look for yourself. There are of course a lot of things you may not fully understand at first, but these are usually the options you won’t need in the beginning of your Sitecore journey.
As the Web.config has grown to some extend in the past, the developer team at Sitecore has started to move some settings from the main Web.config file to some smaller config files in the configuration directory named /App_Config (as intended by the ASP.NET 2.0 framework). The reason for this is basically to provide a better overview of all configuration options by grouping similar settings into separate files instead of one large file -and- to make it possible to switch between different configurations by just pointing to another file in the /App_Config folder.
Although Sitecore has only one single configuration file with some external extensions in the /App_Config folder, you can configure nearly every part of the system. It is even possible to extend, change, remove and replace core components, as well as to add your own. I will explain more about that in a later part of the series.
Well, that’s basically all you need to know about configuration in Sitecore.

Advantages

1. Configuring Sitecore is a very familiar task for .NET Web Developers and Windows Server 2008 Administrators.
2. There is only one place to look for configuring settings in a Sitecore installation.
3. Each Sitecore installation can be individually configured.
4. It is possible to point to central configuration files from more than one Sitecore installation.
5. It is possible to manage the configuration with SCCM (source code management) tools, and to copy it in a whole or in parts as necessary.

Drawbacks

1. Configuring Sitecore is indeed a developer or administrator task because there is no configuration web interface.
2. To provide a hierarchy of "administration levels" where some administrators can change more settings than others, you have to write custom code that enables changing options from the Sitecore UI -or- you have to split the Web.config into several configuration files and use the security features of the Windows file system to provide different levels of access.

Again, this article demonstrates two very different approaches. SharePoint tries to play nicely with organizational hierarchies and to provide web-based user interfaces to simplify tasks that would otherwise be very complex, because the settings that are changed by various configuration pages are indeed distributed over half a dozen files and databases. Sitecore, on the other hand, is very well integrated with the way ASP.NET handles configuration and provides a familiar interface for developers and administrators in form of XML-based configuration files. It has, however, no web-based administration interface to handle certain those tasks. As this is a series that covers both products from a developer perspective (and not from an administrator or an endusers point of view), Sitecore’s way seems to be more transparent and consistent.

Sitecore: +7 points = 16 points total
SharePoint: +6 points = 11 points total

For the next part of the series covering customization just click here.

(Version 1.1 - October 11th, 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)

Installation and General Architecture

Sitecore and SharePoint both come with a lot of out-of-the-box functionality but the main reason for choosing one of them as platform is extensibility of the core features. Both products are based on .NET, SQL Server and Windows Server / IIS. They both are basically also additional layer of functionality on top of ASP.NET 2.0, but this is already the first big difference in the overall architecture.

SharePoint is automatically installed by the SharePoint installation package (MSI) into the "Programs" folder of the system hard drive, some levels inside folders named "web server extensions" and so on. Because of the name of the last folder hierarchy level, developers usually refer to it as the "12 hive". All assemblies living somewhere in that directory tree are registered with the GAC (Global Assembly Cache), so every application in the system does not need to have a copy in their local /bin folder. When installing a first web application, SharePoint creates usually a new web inside IIS and places a few files in the related file folder on disc. It also registers several virtual directories linked to folders underneath the "12 hive". When the ASP.NET worker process (w3wp.exe using ASP.NET ISAPI) is starting up, it reads the contents of the Web.config in the configured IIS web folder. The Web.config refers to several assemblies available from the GAC which are loaded and initialized during startup (HTTP Modules, HTTP Handlers, some lifecycle components and so on). When a user requests a URL from SharePoint, a component named SPVirtualPathProvider is responsible for fulfilling the request as it has been registered as VirtualPathProvider. The component either ignores the request if it targets one of the virtual directories or "redirects" it to a HTTP handler that reads pages from the SharePoint content database.

Advantages

1. Multiple SharePoint sites are using the same assemblies and functionality. Simplifies updates and development of global features.
2. SharePoint pages are located in a central location on the file system or in the SharePoint content database. This enables an optimized handling of customized pages (SharePoint refers to pages that were changed by users and stored in the content database as "customized" pages) within a SharePoint farm where more than one web server is handling the request as the pages are instantly available to all webfarm servers by accessing the database. It also enables versioning and integration with other SharePoint features (workflows, etc.).

Drawbacks

1. Multiple SharePoint sites are using the same assemblies and functionality. Running different or more than one highly customized versions on the same server is nearly impossible.
2. Administrators cannot choose the location SharePoint is installed in. Complicates separation of responsibilities on the server with respect to security.
3. SharePoint pages are located in a central location on the file system or in the SharePoint content database. This may lead to some confusion if developing new features for SharePoint or customizing existing pages, because it is different from the usual way developers interact with the ASP.NET WebForms framework. It also complicates integration with VisualStudio, but we will cover that later in this series.
4. SharePoint heavily customizes the ASP.NET pipeline to integrate its database-centric concept. It also dynamically decides based on several parameters where to look for the requested resource (in the local IIS web folder, in the central SharePoint installation directory or in the content database), which is not trivial and at first not easy to understand.

Sitecore can be installed in two different ways. The first way is to install it using the Sitecore Installer, a MSI package that needs to be executed on the server, similar to a SharePoint installation. The installer asks you a few questions and is doing all the work for you, including installing the database and creating a new IIS web. There is, however, a second option: You also can install Sitecore "by hand". I will not go into detail here as the documentation at SDN (Sitecore Developer Network) provides you with all necessary information. Generally speaking, you can upload and install Sitecore even with a simple FTP account and remote access to your database.
That means, from an ASP.NET perspective, Sitecore is just like any other ASP.NET application with no special treatment or "special" IIS configuration. Any Sitecore installation creates some additional folders that are usually placed outside of the configured IIS web folder, but - if necessary - you can move them everywhere you want.
No matter which way you choose, you can have multiple installations of Sitecore on a single Windows installation. In contrast to SharePoint, you can even install Sitecore on Windows XP and Windows Vista, and you can not only run it using IIS, but also using VisualStudio’s WebDevelopment server - but we will cover that in more detail in a later part of the series.
Of course no one can keep you from moving all Sitecore assemblies from the /bin folder to another location and register them in the GAC, so you can share the assemblies across multiple Sitecore installations. I for myself have actually never done that (because updating Sitecore is pretty easy), but it should be no big deal.
Every request to the application is handled by Sitecore using a lot of customized components (especially HTTP Modules and HTTP Handlers) that are registered in the Web.config file. The current version of Sitecore (6.0) performs a lot of initialization and routing operations before it hands off the request to the ASP.NET PageHandler, which then in turn opens an ASPX page with several Sitecore controls from the file system. It is no problem at all to replace the PageHandler with another HTTP Handler and store all the ASPX pages in another location (for example a database), or to do something totally different, but as far as ASP.NET is concerned, a request to a Sitecore application is just an ordinary HTTP request with some rewriting and an extended lifecycle.

Advantages

1. Two possible installation routines, Sitecore Installer and Manual Installation.
2. Multiple Sitecore installations CAN use the same assemblies and functionality.
3. Administrators have full control over where to install Sitecore.
4. Installing Sitecore is even possible with simple FTP und SQL accounts (although in a corporate environment, that may not be the most productive way).
5. Sitecore Layouts (Sitecore refers to ASPX pages as "layouts") are stored in the file folder of the IIS web. This makes it easy for developers to extend and customize pages as well as develop additional features as this way of handling files is aligned with the way the ASP.NET WebForms framework works. It also enables a nearly perfect integration with VisualStudio (see a later part).
6. Sitecore uses advanced ASP.NET features to extend the request pipeline and other components, but it does not change the way the framework is basically working that dramatically. This enables easy integration with other frameworks (e.g. Spring.NET) and libraries.

Drawbacks

1. Sitecore layouts (Sitecore refers to ASPX pages as "layouts") are stored in the file folder of the IIS web. In theory, this may lead to some problems with multiple Sitecore servers (content staging) and when it is necessary to extend layouts with versioning and workflows. In practice, there are several simple mechanisms available to handle those situations very effectively.

Okay, let’s wrap up part two. Both frameworks are essentially ASP.NET 2.0-based, but SharePoint ‘07 changes the way the ASP.NET WebForms framework usually handles things pretty dramatically, although it is much better integrated with IIS and ASP.NET than its predecessor (SharePoint 2.0). Sitecore is more or less a simple ASP.NET web application with advanced functionality, deeply integrated with the .NET Web Platform. Especially from a developer perspective, Sitecore definitely deserves some extra credit for transparency and architecture.

Sitecore: +9 points = 9 points total
SharePoint: +5 points = 5 points total

The next part of this series covers the topic Configuration.

(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.