March 2009
M T W T F S S
    Apr »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

When CMS Licensing Shafts Architecture

Now, there’s a woman on my block,
She just sit there as the night grows still.
She say who gonna take away his license to kill?
- LICENSE TO KILL

Just come back from a nice Brick Lane curry and a few beers with my old colleagues from Accenture. Just enough beers, in fact, for a minor rant. Before I start, I’d like to say that there is nothing I dislike more than someone that complains about problems without offering a sensible solution. Which is exactly what I’m about to do.

Here’s my problem. My day job involves me drawing many system architecture diagrams. This poses many challenges: How do I ensure that the solution is fit for purpose, reliable, scalable, extensible, performant, resilient and more? How do I select the best-fit third party products? What colours should the boxes on my Visio diagrams be, and should they have round corners? And how do I say my clients money?

Don't want to do this

Don't want to do this

It would be ideal if the vendors’ licensing models allowed us to harmoniously achieve all the goals stated above. The sad reality, however, is that the licensing model sometimes means that we have to sabotage our architectures in order to save a fortune on licensing. Some examples situations are given below:

  • A per site or domain cost – Many vendors will charge you per “site”, the definition of which isn’t clear. Sometimes this is an IIS site or Application pool, but more often than not it is based on domain. So, if I have a global presense and use domains such as www.globalcorp.com, www.globalcorp.co.uk, www.globalcorp.jp and so on, I can get hammered with a 60 site license. Whereas, if I go with www.globalcorp.com/en-GB/ or www.globalcorp.com/jp/ instead and place simple redirects on my top level domains, I have a single site license. I prefer the first option, but not if it is going to cost the client tens of thousands of $$$/£££’s. Which means we sometimes reluctantly go for option 2. That said, option two does have it’s advantage in that single domains can be easier to manage (SSL certs, SEO and more), but I still prefer a domain per region.
  • A per machine / CPU cost for a very small component – There are some vendors which will charge extra for each machine on which a component is installed. My pet hate here is a deployment listener, which is most often seen in a CMS that operates a decoupled publishing model. If, for example, I publish a news story from my content staging environment behind my firewall to my load balanced production environment on the other side, two things normally happen. The content is published to a remote database cluster, and the associated static files (images, for example) are remotely copied to the file system of each in the cluster. If the CMS employs a baking model, the content is normally also deployed as a static file. Now this is all great, until my web tier server farm gets large and I have to pay a ridiculous license fee for each box for the priviledge of having a file copy. The workaround here is simply to install the deployment listener on one server in the cluster, and run some free file system synchronisation tool (for example rsync) that copies that content to the other machines in the cluster. Another workaround is expensive hardware (like a SAN) which may be overkill.
  • A cost for each named CMS user or editor - I believe it is extremely important for each user of a system to have a unique username and password, mainly for security and audit trail reasons. However, I’ve seen cases where a single login is shared by multiple editors purely to avoid a per login license. I wouldn’t be surprised if this arrangement violates the licensing terms, and it isn’t something we’ve ever done. I think this model is rare these days, normally replaced with a concurrent user limit.
  • Vagaries around inter-, extra- and intranet use – Some licensing models depend on which part of the Enterprise use the system. I think the difference between an internet site and intranet site is still fairly well defined, but an extranet can cause enormous grey areas. Falling foul of this can have massive implications on licensing and needs to be considered when designing the architecture.
  • A per hit cost for an Analytics products – Now this is off topic and more a question than a statement. Some of our clients use a free service (you guessed it, Google Analytics), but most use a larger commercial product such as Omniture or WebTrends. The licensing model is often based on the number of hits received by the tracking server. And this is what I was wondering: If I have an extremely high volume site, what happens if I only sample the visitors by, for example, tagging 1 in 1000. This sampling is a bit like an exit poll in an election. It would be quite expensive to ask everyone who they voted for when leaving the booth. Asking a small subset is much cheaper, and yields reliable results if the sample is truly random. This could potentially save a significant amount on licensing, and all I need to do is read my reports in terms of 1000′s of users. Of course this is a terrible idea when using advanced techniques such as A/B Testing or Multivariate Testing to increase the value per user. But it might be a good idea if you’re simply tracking behaviour. For the record, I’ve never tried this and don’t know if it would violate the licensing agreement. Does anyone have any thoughts on this?

I could probably go on a bit more. There are considerations around physical machines versus virtual machines, active-passive Disaster Recovery configurations and the definition of a staging/pre-production site. If anyone could add to the list above I’d be interested to hear from you.

I wish I could end this post with a suggestion for the perfect licensing model for the vendors, but sadly I have no answers. The vendors are all well aware of the short-comings of the existing models and people a whole lot wiser than me have been trying to find logical and fair ways to repair these. If any major vendor does think their price list avoids all these issues, I’d love to see it.

Until these issues are properly addressed, we will have to continue to consider vendor licensing models when designing our system architectures. But it depresses me enormously when a quirk in a pricing matrix makes me do something that I know smells a little bit like horseshit.

  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Digg
  • LinkedIn
  • StumbleUpon
  • Technorati

8 comments to When CMS Licensing Shafts Architecture

  • chrisregan

    …and then of course there are the implications of a per-proc licensing model should the client choose to look at something like Azul or a similar java server appliance.

    I can’t think of many people who would enjoy paying 864 times the license cost!

    Ah, the many perils of life with an enterprise CMS… You have to love it.

  • I have this issue in daily life too. What often is the case is that there is no one size fits all scenario that is to the best advantage of all customers. And whilst most vendors have a single license model, it has often changed over time as trends change. Years ago, many customers just had a single site running from their CMS, now we are in the territory of multiple brands covering many, many websites. Everything is just more complicated.

    As to analytics vendors charging per hit… well it might be why many organisations stopped using WebTrends…

  • I just do not think the “perfect licensing model” exists. It all depends on who you are and what you want and who the vendor is and what they want. Let’s face it, the vendor is there to make money but hopefully make money fairly. If we have to design around license restrictions then we either have chosen the wrong model (or someone chose wrongly for us) or we need to accept that for the best technical solution we need more licenses. From my experience, most US companies seem to buy unlimited everything so that solves that one right there :)

    Maybe the only perfect licensing model is free… :)

  • I am sure someone will point out the flaw(s) in my naivety – but here goes – what about a tiered repository size model? ie < a MB = Free, < b GB = $x/yr, < c GB = $y/yr and so on. Basing it on repository size would remove most if not all of the architecture issues – want more users, cpus, projects etc? Go for it! Tiers would make it simpler to manage and budget (from both a vendor and customer). In combination it would promote content re-use and repository spring cleaning – which can’t be bad things. Assuming repository size is a good indicator of users, cpus and projects – it probably won’t make much difference in licensing fees either. Also works well for a combined self install / SaaS license. Only negative I can think of off the top of my head (other than implementation!) is customers with large content files (video, hi-res images) – in which case possibly measuring repository size in terms of documents rather than bytes may be better. A “pay for what you use” as opposed to “pay for what you think you might use” system – without the architectural handicaps. Thoughts?

    • Interesting idea, Adrian. I’ll think about it some more. I’m not convinced that your assumption “repository size is a good indicator of users, cpus and projects ” holds at all. I can think of some fairly complex projects that I’ve done which relatively small repositories. And some simple ones with a hundred thousand PDF files.

      The negative you mention regarding large assets is also very true. Similarly, people might start introducing compression to save themselves a fair bit. Maybe, as you say, number of “documents” might be better.

      I wonder what others think.

  • [...] 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 Marks

    So on the licensing front, is there simply no good answer? I can’t think of one and it seems the vendor can’t either.

    Kas just slammed Per Seat as an option.

  • I think if there’s “a good answer,” it’ll be found out when we ask customers directly. Someone needs to ask customers what THEY think is a good way to pay for software.

    The Alfresco guys know a thing or two about this because John N. and Ian H. have seen and heard (from previous lives working at certain well-known companies) what all the licensing tricks are in this business, and which ones customers hate. They created Alfresco’s licensing model in direct competition to the Big Boys’ model, as a selling tool! Day is involved in the same kind of learning arc, and their CRX repository is now sold on a subscription basis (unless you twist their arm and insist on paying some other way). CRX is $18k per year per server-instance (regardless of CPUs or cores; it’s per-motherboard, kind of).

    I’d be happy (as I think most buyers would be) with something Simple, at this point.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>