More on licensing - business continuity - and governance - issues

I recently blogged about the importance of considering licensing (and configuration management of licenses) as part of a business continuity strategy. At a recent online BCS CMSG (British Computer Society Configuration Management Specialist Group) committee meeting, I met an old friend and practitioner in this field, Ian Preskett, MIET C.Eng. MBCS CITP (a SAM – Software Asset Management – process consultant and MD of IP Associates Ltd) and asked him for comments on my article. It is always good to check what one thinks one knows with real practitioners!

Thankfully, Ian didn’t raise any serious issues with the piece and my key points. However, he did emphasise a few things that are worth repeating: “Business continuity is a plan to ensure continuous operation and this often means that the product is installed in three environments. 1) production 2) standby and 3) development,” he says. “How many of these require licenses depends on the product, the vendor, whether it is a hot or cold standby, etc. but it is not just losing the ‘machine running the licensed product’‘ [as I mentioned] that matters; standby servers are likely to require licenses long before any disaster just because software is installed on these servers”. Moreover, “as some licences are dependent upon MAC address, IP address, etc., this must be considered during change management when deciding whether to use a product, and when building the business continuity plan for that product – i.e. even before negotiating the purchase“.

Ian then provided a useful summary in the context of ITIL, which is still an important IT service management framework, even if some of its detailed good practices have been outdated by advances in technology. “To relate this to the phases of the ITIL framework,” he says, “disasters happen during the ‘operational’ phase and should be handled by processes set out in the Business Continuity Plan. It is too late to consider licensing issues when a disaster occurs. Business Continuity must be considered during the ‘strategy’ phase and the plan finalised in the ‘design’ phase, even before the product is purchased. This ensures that licenses, costs and other issues are fully understood at the beginning,” he continues, “and it also helps to ensure that standby/backup and other environments are fully licensed throughout their lifecycle (even before disasters occur). License conditions should be documented in the vendor agreement”.

This may sound a bit old-fashioned but it is still something that even Agile developers in DevOps environments need to consider – what happens when things go wrong. Nevertheless, Agile developers might well be concentrating just on rapid delivery of business benefit to working environments without considering contingency over-much. Everybody is encouraged to “accentuate the positive”.

However, continual delivery isn’t going to count for much if the delivered software isn’t resilient in the face of disaster and when an operational system can’t be restored in a properly licensed state after a contingency. Such issues used to be the concern of Operations and organisations employing DevOps processes mustn’t forget that the “Ops” end of “DevOps” is just as important (and needs to be as Agile) as the “Dev” end.

And, again, don’t overlook the licenses. Being responsible for bringing up an unlicensed system after a contingency can be career-limiting, especially if you then face a swingeing fine for licence non-compliance.

If you want to talk with someone knowledgeable about Agility and license management, the 2017 BCS CMSG Conference will be advertised soon.