Jon On Tech

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

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.