How to Choose a CMS

So how do you currently select a CMS for a project. And I’m asking this more of the people who will be using the CMS to manage their website rather than those that will be doing the development work.

Far too often people assess a CMS platform with giant spreadsheets listing features the CMS should have and score each candidate on each feature. The problem with this approach is that any good CMS will be flexible and extensible and will be able to meet all of the criteria you’ve set out in your spreadsheet. In fact, I can’t remember if I’ve ever responded to this kind of feature matrix with a “no, Sitecore can’t do it”. Sitecore is very flexible and extensible and any feature required can be met, as long as adequate time and budget are available to do so.

So why are these spreadsheets used? This kind of CMS selection tool normally appears early in the selection process to weed out the duds. At the start of any kind of selection process filters need to be put in place to get rid of the candidates that have no chance of ever meeting your requirements. This is why we have potential employees send us resumes and this is why we have to make sure the CMS that is being considered is (as I qualified above) “good”.

But once you filter the duds out it is highly unlikely you’ll find enough differentiation between the CMSs left in the race to make an informed decision. To quote a recent blog post from Janus Boye:

10 years ago when only few vendors supported certain features, e.g. workflow or Office integration, vendors could easily differentiate themselves on features, but today that is different.

Once you get to this stage of selection it is more important to understand how requirements are going to be met rather than if they can be met. One way of doing this is to talk with your developers (whether they be yours or a development house) and simply ask them to describe how your requirements will be met.

Another way many people try to make a decision at this stage is to request a demo of the CMS, often running through a script of a common day-to-day task to see how that task / requirement will be done. This assumes that there is a magical CMS out there somewhere that can meet all of your esoteric requirements with out-of-the-box features and zero customisation. Don’t be fooled, this kind of CMS simply doesn’t exist. But many come close. The key I think to using this selection technique is to not be too specific in your demo script. Bullet points of areas to be demonstrated work better than a comprehensive script.

But the absolute best way to select a single CMS is to use all CMSs up for selection. Let me describe to you the best way I have seen to do this.

A while ago I was involved in a “CMS Smackdown!” that a potential client ran as part of their CMS selection process. This involved several teams all implementing a mini-site using one of the potential CMSs.

Each team of up to 4 was given a room and 3 days to implement the mini-site. The team make up was up to each team but all work could only be done by members of the team. No development was allowed before the event or out of hours. Much of the reasoning with this approach was because the client wanted to understand exactly what it took to develop a site in the CMSs up for selection. We were however allowed to use existing modules and libraries.

Each team was given the requirements for the build at the start of the first day so everyone was starting at the same pace. Then while we all coded like hell, staff from the client sat in the room with each team to absorb how difficult the implementation was. The client’s staff were a mix of developers and content authors.

And after 3 days of intensive development I was proud we were able to deliver a fully functioning website. That’s a complete website in only 96 hours! I’m quite proud of what we were able to achieve…just don’t tell the account managers how quickly we did it .

At the end of the smackdown each build was deployed to the client’s server and they were able to play with each to complete their assessment and make a decision on which CMS best suited the way they work.

And now for some advice for those who might be lucky enough to participate in a CMS smackdown. If you fail to plan, you plan to fail. Careful with that advice, it’s antique . But in this kind of high pressure environment where you only have 3 days to pull together a website you simply cannot afford mistakes or wasting effort on repeating yourselves. You need to make sure you’re organised and each team member knows exactly what to do. My team even went as far as taking a source control server with us to coordinate each of our code edits.

Yes, I know this approach can be expensive, but when you’re dropping a lot of money on a new website build isn’t it worth spending a little more to ensure you’ve chosen a CMS that works for your organisation?

Team Development with Sitecore the Easy way

Most of the Sitecore implementations I’m involved in have me working in a team environment. In fact, this is pretty normal for any IT project. Although a team environment has many benefits, there are also some complexities that need to be addressed in terms of keeping the development environment in sync.

There are two things that need to be synchronised across all the development environments; code and data. The code synchronisation issue has been dealt with long ago by using source control. I wish I could say at this point that I haven’t encountered a team not using source control for a long time, but alas I cannot. Realistically I cannot believe that any professional developer would not use source control these days. This is the number one tool required for easier team development for any project.

I also use source control for 1 person projects. Along with synchronisation, source control provides other benefits such as versioning of the code so you can roll back changes, and providing a central location for all code. New dev comes onto the project? Just get the source from here. Old project needs maintenance? Just get the source from here. Original developer left the company? Just get the source from here.

The other part to the synchronisation issue is the data. I’m a strong believer of putting all database related things in source control. Your development database on a SQL server is just an instance of the structure and data you define in script files. Do not treat the database server as the place where your database lives. It should live as scripts in source control. The database on the database server is just a single instance of that database.

Another benefit of storing your schema and data in source control is the ability for accessing the data without a direct connection to the database server. For example, when working from home or a remote location away from the office. If the database scripts are kept in source control it’s straight forward to get the latest versions of the files and create a local copy to work against.

Although I want my data to live in source control as scripts I also am a strong believer of not accessing proprietry databases directly if an API exists. This is the case for Sitecore. Not to mention the complexity of the data stored in Sitecore.

So when working with Sitecore, how do you get your data to live in source control rather than the database? A common practice for Sitecore projects is to create Sitecore packages of the project specific data. This package can then be put in source control. This can also be seen as common practice through many of the shared source projects for Sitecore. Problem here is the package is a zip file, not text so your source control will not try and merge the package if multiple developers have updated multiple items and updated the package independent of each other.

Sitecore 6 introduced item serialization. This allows you to export item data in a text format at the click of a button to disk. And also to import it at the click of a button. This is a much better approach than the package approach. The only drawback to Sitecore 6 item serialization is that media library items cannot be exported in this way, so you’ll still have to drop back to a package for these.

So now we have the data on disk, we can include it in source control. Well… it depends on your project structure how easy this will be. The item data is placed on disk under the data/serialization folder. I don’t like to write my Sitecore code in the same folder that Sitecore runs. I like to separate my custom code from the system I’m building on top of, so in source control I don’t have the Sitecore root at the same location as my dev root. This makes including the serialized items more difficult.

Now let me step down off my soapbox and confess that although I want my Sitecore items in source control, generally I don’t do this due to the reasons listed above. At Next Digital we normally have a shared development database with each developer running their own instance of Sitecore. This normally works quite well due to the fact that this environment is development and each instance of Sitecore (on the dev’s machine) is restarted due to code changes quite often. This restarting means there are minimal issues with caching of the data.

OK, so now for the easy way. I was privileged enough to be included in the beta program for a new team development tool for Sitecore. I would like to introduce you to “Team Development for Sitecore” (or TDS for short). TDS is developed by Sitecore partner Hedgehog Development in North America. It is a plugin for Visual Studio which allows you to serialize and deserialize Sitecore items for your project directly from within Visual Studio. The items can also be added to source control as the items exist in a custom TDS project as text files. Being text files most source control system should have no problem merging changes.

You’ll notice from the above screenshot that the text format of an item in your TDS project is the Sitecore 6 item serialization format.

TDS also allows synchronising the items in your project with your Sitecore server. You can also select which items to sync and which ones to leave alone.

In general you’ll only want to sync project specific items and leave the Sitecore standard items alone.

There are multiple synchronisation options to determine how TDS should handle such cases as when an item exists in the project but not in Sitecore and when an item exists in Sitecore but not in the project.

Another nice feature of TDS is the item designed. Hedgehog built on the concept of the Visual Studio Class designer to provide a similar tool for viewing the relationship between your templates. This is a huge help, especially as Sitecore supports multiple inheritance through templates which can lead to lengthy investigations when trying to work out which template defines which field on an item.

I find it very useful when designing a solution to design and rework the templates in a UML diagram. The item designer at least gives you the view part of this.

Overall I think TDS is a very good start. There’s heaps of potential there, like making the item designer allow updating of templates and relationships. I’m quite eager to see what Hedgehog do next with TDS. Even so, just having the ability to synchronise Sitecore items across multiple locations is worth the price tag.