During a recent recent CMS vendor selection exericise I took a step back and realised how much time and effort was being spent on getting a firm price on the cost of each CMS product. CMS licensing is complicated as it depends on so many variables e.g. number of users, sites, servers, cpu’s, environments etc.  CMSWire posted on twitter

cmswire_cms_licensing

To help me write this article I enlisted the help of the folks on twitter, so why is CMS licensing so complicated?

Twitter feedback

Jon Marks (@mcBoof)  has written an excellent article titled When CMS Licensing Shafts Architecture , where comprises have to be made to the CMS solution architecture due to how products are licensed. Jon’s article states that a CMS may be licensed :

  • A per site or domain cost – the vendor should clarify about what constitutes a “site”
  • A per machine / CPU cost – some vendors which will charge extra for each server a particular product is deployed.
  • A cost for each named CMS user or editor or a concurrent user limit .
  • A cost depending on the environment e.g. development, test, staging, production and disaster recovery.

Useful replies from @scrump & @proops below :

scrump_cms_licensing

One size does not fit all

proops_cms_licensing

twitter post regarding Modules and maintenance

scrump_aftersale_cms_licensing

scrump_requirements_cms_licensing

When buying a CMS what are you buying ?

To try to answer why it is complicated let’s look at what you are actually purchasing :

Product Description
Core product This is usually the CMS server. As above the price of the core product will depend on the number of sites, users, servers etc.You will want to ensure that as many of your requirements as possible are covered in the core product.If you need additional functions then you will need to look at the availble modules.
Modules Any number of modules may be required to meet your requirements, this is an area where you could very quickly blow your budget! Possible modules include: Personalisation, dynamic delivery, social media tools, digital asset management, e-commerce catalogues, integration with third party products like Sharepoint, CRM systems etc.Modules may be licensed similarly to the core product and will attract additional costs on for each environment as well as ongoing support.
Databases & Application servers This will need to include licenses for Oracle/SQL Server database and applications servers etc.
Hardware Architecture You have to factor in the architecture as the number of Servers & CPU’s may affect the final price.It can be difficult to establish the architecture at the outset as with a dynamic CMS it depends on how the CMS has been implemented and how it will scale. Usually a sizing exercise is required which looks at the traffic levels now and into the future before a recommended architecture can be arrived at
Non production Environment licenses Non production environments also attract a cost though this is usually at a fraction of the full price. These could include Test, development and disaster recovery environments.
Maintenance & Support This is an annual subscription cost which is usually around 18-20% of the list price, and not 20% of the discounted price you may have managed to negotiate!

In summary :

Buying a CMS is fairly complicated as it involves buying software as well the hardware, hosting and support. Having a complex model may be necessary because:

  • One size doesn’t fit all. Why should you pay for functions that you will never use? You will not have the same numbers of users or sites as the next client.
  • Modules provide the flexibility of including additional functionality at a later time. This allows clients with a lower initial cost to get started. However modules can significantly increase the CMS license cost as they may also be licensed by site and users, there is also the additional support & environments costs to be considered.

What I would like to see is:

  • Openess and transparency in pricing. A fixed price list, with same prices for all customers. I regularly see quotes provided to more than one client at the same time, and know what is each
  • Simplified pricing. As above a standard price list so that clients know how much each and module costs, and what would happen if they changed X. We all know the price of an 60 GB Ipod classic.
  • A definition of what is a site. Clients may need to implement microsites for marketing campaigns under specific domains, are these sites? Even if they are shortlived ? What about subdomains?
  • Serious thought given to CMS scalability and performance as part of CMS selection & licensing, how will the architecture scale to cater for additional content and site visitors? Architectural changes further down the line could impact on the licensing e.g. additional servers and CPU’s usually mean additional license costs.

What I would welcome the end of :

  • Highly inflated “optimistic” list prices which are then heavily discounted.
  • Pricing by
    • CPU core, dual core are now more expensive the quad core.
    • Registered public user
    • CPU Megahertz (I think this practice may be dead, but is related to CPU cores).
    • Content Editor, concurrent editors make more sense.
  • Additional costs for commodity functions such as blogs, forums, surveys, polls, accessibility checking, link checking etc. Clients expect do not pay extra for these functions.

What has your experience been when pricing CMS systems, has it been straightforward or are you having to go back to the vendor every time a change is needed?

Advertisements

This is one of the questions I ask potential clients and usually the response is:

  1. “don’t know” or
  2. “our site can support up to x hundred/thousand concurrent users and there are a number of issues we are trying to iron out”

I was surprised to learn that most prospective clients *don’t know* the capacity of their website or service and have no effective plans in place for when there is a sharp increase in site visitors and it crashes (and “to panic” or “reboot” is not a plan)! It is usually after events like a site crashing regularly that web managers begin to consider what they should do about it, of course by which time it is too little too late as the reputational damage has already been done with those visitors affected.

What do we mean by website capacity?

The website capacity is the number of visitors that it can support with each visitor performing representative tasks (browsing, searching, navigating etc.) within specified Service Level’s.

When is it important?

Sites grow in two directions, with increasing visitor numbers and with the amount of content, both of these increases affect the performance of your site. Increasing the number of visitor could slow down the user experience and your visitors won’t hang around if your site is slow or irresponsive, it takes just seconds to arrive at a website and even less to leave it! Increasing the amount of content could also mean that your website doesn’t scale well and page rendering performance is inadvertently affected e.g. bread crumbs and navigation systems may not be generated as quickly.

So *before* launching your next site ensure that you are reducing risk of service failure by specifying and testing a robust, resilient, scalable and redundant architecture. Knowing that your web site is able to support 100’s of users concurrently and also knowing where the bottlenecks are will inform you:

  1. how and when the service is likely to fail, you will recognise this behaviour when and if it reoccurs
  2. mitigate and reduce risk of service failure, and
  3. allow you to build an appropriate business case to improve ongoing service delivery.

What can you do?

It useful to set a benchmark so you can demonstrate what effects any performance improvements your investment produces, there are usually some quick wins that can make a huge difference to your website capacity and in turn the user experience.

All of our clients now perform “stress testing” and ongoing capacity planning for their projects where service delivery within acceptable parameters is crucial. However this hasn’t always been the case.

Even with baked pages generated by some CMS systems there are a number of opportunities to improve your site capacity, e.g. by optimising your client side cache settings and will significantly reduce the number of connections that a user has to make to download each page.

Do you know the capacity of your website? What would you do if your visitor numbers due to a breaking news story suddenly increased 10 fold? 1000 fold? Could your website cope? Could you cope?