After the Ignite in Zurich, there came Ignite in Chicago, where our American customers, prospects, partners, and Day staff met to share information, experiences, to network, and simply have a very good time. The event itself was slightly bigger than the event in Zurich, both in terms of number of participants and available room.

Ignite was hosted by Day customers, in more than one way: by the City of Chicago itself, and by the grand Intercontinental Hotel, of the IHG Group, on Chicago's famous shopping avenue, the Magnificent Mile.

Again, we had a lot of great presentations, panels, Q&A sessions, as well as informal chats. And the Foreigner concert at the end was the icing on the cake.

Be sure to check out the conference hashtag was #dayignite and here are some Ignite pictures on Flickr, with lots of new coverage from Chicago:

Looking forward to next year's Day Customer Summit!

Ignite in Zurich was a blast. Lots of good presentations (which I will hopefully be able to share later) and excellent discussions on content management. My favourite quote was from Newsweek's Meshach Jackson. Their editors on the CMS selection process:

If you don't select CQ we're all quitting.

I also enjoyed what David Nuescheler had to say about separation of content and layout. The standard CMS architecture thinking goes like this
a) we need to separate content and layout
b) therefore, the user interface for the authors cannot look anything like the rendered pages and we will make it look like a database entry mask

David demonstrated that a) simply does not lead to b). Or in his own words:

Separating content and layout does not mean you have to confuse the authors

To get a taste of the event: The conference hashtag was #dayignite and here are some Ignite pictures on Flickr:

So, in case you missed Ignite Zurich there is still Ignite Chicago coming up...

CMS analyst Janus Boye has blogged about the expected lifetime of a CMS installation, i.e. for how long an installed CMS can be expected to be in production. His guess is a lifetime of 3 years. On the blog's comments Janus and I got into a discussion about the accuracy of that guess where he asked Day to publish actual real data about this topic.

I like this idea because publishing this data provides a benefit to our potential new customers: a reliable indicator (without any hand-waving or gut feelings) of the CMS's lifetime that can be used in business plans.

The data

The data I have used is taken from Day's support contracts. Only customer data from outside ouf Europe was used (simply because it was available to me). This selection is likely to bias the results towards shorter lifetimes as Day's oldest customers are based in Europe. The basic assumption is that the life time of the CMS is equivalent to the duration of the support contract. The used end point of each contract period is the date up to which the contract is paid for as of today.

You might argue that there could be customers that have a contract but do not actually use the product anymore, which could in fact be the case (I do not know of any). On the other hand, I am aware of customers that still use the product and have terminated their support contract. Therefore, in order to reduce selection bias I did not remove any data points due to this particular consideration.

Each customer was counted once for each product he purchased, i.e. a customer that has two distinct support contracts for CRX and CQ was sampled twice. I discarded all OEM contracts because they are of their different nature (they would skew the result towards longer lifetimes). Finally, I also dropped a data point where the support contract was cancelled because the customer went out-of-business alltogether.

I believe that this data set is reasonably unbiased to provide meaningful results with respect to the question of the lifetime of a customer's CQ/CRX installation.

The Method

Luckily for Day, the data is what is called "right censored". That means that it is unknown for how long an existing support contract will go on - actually the majority of the available data points are right censored.

The scientific discipline that is concerned with analyzing data of this kind is called "survival analysis". One is interested in the survival function which maps a set of events onto time. The survival function is a property of a random variable, i.e. it needs to be estimated (in the statistical sense of the word).

One well know estimator for the survival function is the Kaplan-Meier estimator (which is non-parametric, i.e. there are no underlying assumptions about the distribution of the data). In a nutshell:

The Kaplan-Meier estimate of the survival function, S_hat(t), corresponds to the non-parametric MLE estimate of S(t). The resulting estimate is a step function that has jumps at observed event times, t_i. In general, it is assumed the t_i are ordered: 0 < t₁ < t₂ < · · · < t_D. If the number of individuals with an observed event time t_i is d_i, and the number of individuals at risk (ie, who have not experienced the event) at a time before t_i is Y_i, then the Kaplan-Meier estimate of the survival function and its estimated variance is given by:

The quantity of interest is the mean survival time (and its respective estimate) which is given by:

Because S(t) may not converge to zero, the estimate may diverge. Therefore the integral is only taken up to a finite number. A reasonable choice of is the largest observed or censored time.

Results

Resisting a geek's urge to implement the estimator myself I used the freely available R to calculate the results. Here is a plot of the Kaplan-Meier estimate for the survival function with 95% confidence bounds (time is in days):

And finally, the estimated value for the mean survival time, i.e. the estimated lifetime of a Day CMS installation is: 2453 days with a standard deviation of 154 days. That's about 6.7 years. Mind you, this result is likely to be lower than if the whole customer base had been analyzed.

Today's Link Of The Day is Joerg Hoh's excellent Communique blog "Things on a content management system - Tips and tricks for Day Communique".

In his latest post Joerg publishes a little Perl script to help determine average response times (and provide a visual indicator of the system's performance status).

Although the blog started only recently there is already a good number of performance-related posts. All of them are worth the read since they clearly reflect Joerg's first hand experiences in tuning CQ (so do his hands-on sys mgmt topics like: how to lock out the users).

@davidnuescheler you might want to check out Joerg's take on your 5 rules for performance tuning.

Happy new year... And here's the bunch of links that have piled up in my inbox during the holidays: David Nüscheler has uploaded his presentation about CQ5 to Slideshare (embedded below)... There is a new tutorial on the Sling website on how to use Groovy in Sling... David Dossot has been interviewed about Mule's JCR Transport (he also was on dev.day.com)... I stumbled across a new blog concerned with Day Communique... Hippo CMS has published a tutorial how to access content through JCR... Shane Johnson looked at JBoss DNA's JCR implementation... and finally, Roy's post about the hypertext constraint in REST led to an article on InfoQ

Introducing CQ 5.1