Proactive Software License Compliance

A consistent theme of business service management (BSM) is getting typically separate IT functions to work better together using a common understanding of business context as the bridge. For example, with a BSM approach event and incident management are linked so that certain infrastructure events will trigger a faster and more precise service desk response than waiting for a business user to experience a disruption and submit a ticket. The common business information shared here is how infrastructure components inter-relate and impact upon business services.

Software license management may not spring to mind when we first think BSM, but it can similarly benefit from a cross-functional approach using a common business context. Here, the common business context is the ITIL Definitive Software Library (DSL) and the linked processes are change management, software configuration management and asset management.

Horses out of the barn

Think about how software license compliance has been done traditionally (note: when software guys like me say ‘traditionally,’ we don’t mean Victorian times, we usually mean just a few years ago).

Many companies start with a discovery-oriented approach that simply reports on deployed software. These snapshots can show how many deployments of software you have so you can determine if you are within contractual entitlements. If your contract with Adobe entitles your company to 100 installations of Adobe Acrobat Professional, you at least want to see whether or not you have 100 or fewer deployed instances. If you see significantly fewer than 100 and don’t see requests on the horizon for many more copies, you can sleep well that night. If you see much fewer (say, 20 deployments), you may curse the day someone bought too many licenses and wasted the budget, but at least you’ll be compliant.

But what if you have 105 deployed? Your discovery tool has notified you (after the fact) that you are non-compliant. Assuming you have only a discovery tool, you are faced with three courses of action:

Let’s call this phase of maturity, ‘Hey, the horses are out of barn!’ This is at least better than a lot of companies who have no compliance approach at all. They often find out their compliance profile the hard way, after they’re audited, penalized, fined, tarred and feathered.

But shouldn’t you automate some response to more optimally rectify out-of-compliance situations? A true asset management tool with an integrated procurement function could help you efficiently true up and buy more licenses. This is kind of like buying a new barn and putting it wherever the horses happen to be.

Maybe your end-user deployments were telling you that you really needed another barn. But this can become an expensive way to manage compliance. Let’s say there is no business desire or justification for more licenses. Then what?

Re-barning the horses

The next phase of maturity could be called, ‘Hey, get the horses back in the barn!’ Here, the idea is to automate reactive enforcement to a non-compliance situation. If you have a tool that can report on software usage, i.e. which desktop installations of Adobe Acrobat Professional haven’t been used in the last six months, you can automatically generate a list of candidates for deinstallations, also known as ‘license harvesting.’ This can be a fair gauge of business demand – those who aren’t using it have demonstrated a lack of demand for it – rather than an all-or-nothing approach where everyone in a certain group gets and keeps a software asset whether they use it or not because company policy says they are to get it.

If you have some integration with software deployment tools, you can go further and automate de-installations. This is more efficient than running around from machine to machine and doing uninstalls. And it’s certainly better than leaving it to the end user to take this action (in which case DLLs or other remnants could be left behind and counted as an installation during an audit). Just remember to consider and communicate a corporate policy of when and how software may be uninstalled, in case end-users are surprised at what they may perceive to be a heavy-handed Big Brother approach to compliance.

Taking action based on thresholds rather than waiting until you’re truly non-compliant is one way to make this reactive approach a bit more proactive. If I set a threshold of 90 percent deployment against contract as my ideal and regularly monitor the situation, I can set 90 percent or 95 percent as a trigger for evasive maneuvers such as true-ups or true-downs. The threshold gives you headroom for quick growth in demand and a margin for error in case growth came between reporting intervals. You are still reacting, but you have a better chance of doing so before you are non-compliant.

Keeping horses in the barn

Now we get to the BSM approach to software license management – more specifically in the case of desktop software, a Closed-Loop Client Management approach. Rather than making software license compliance a sporadic report-and-react activity, with BSM it becomes an integrated part of a continuous process for managing desktops, laptops and PDAs – clients. (Note: the benefits of closed-loop client management go far beyond software license management.) The key is weaving license management into the process of maintaining desktop software configurations. And as I hope to briefly explain, the keys to that are a DSL and CMDB.

The practice of closed-loop client management gets its name from closed-loop processes tying together planning, executing and verifying changes made to client devices. This is accomplished through integration across change management, software configuration management, asset management and discovery, and ultimately, identity management. The two lynchpins in this integration are

1. Workflow integration across the various tools that manage desktops (e.g. change, service desk, asset, software provisioning, discovery, identity)
2. A common business context; more precisely, data shared by these tools that agree on
3. • - Which desktops are deployed with which configurations today (CMDB)
   • - Which software is authorized for distribution (DSL)
   • - Who is using which desktops, and what are their roles in the organization (Identity Management)

The workflow, DSL and CMDB integrations work together to ensure that software configuration changes are executed only as authorized by the change management process. Change requests, for example, include targets (configuration items, or CIs) from the CMDB that are to be changed, and locations for software (from the DSL) that is to be deployed or changed. Once the change request is approved, the software configuration management tool can automatically execute the change because it understands – from the same CMDB and DSL used by change management – exactly what software changes to make to which desktops. When discovery and CMDB confirm that the actual state of the CIs in question matches the desired state as approved by the change management, the change request is closed and an audit trail of the entire process is recorded.

So what does this have to do with software license management? We’re almost there. The idea is to take software license usage into account when creating policies and approving distribution of software based on user roles. That requires change management, software configuration management and asset management to have a common view of software license information, which is the function of the DSL.

The DSL is a reference of all ‘golden master’ software authorized for distribution. ITIL isn’t descriptive on how a DSL should be automated, so for our purposes let’s consider that the DSL perform three key functions. First, the DSL should tell us where golden master software is located, whether on an auto-deployable package or CDs in a filing cabinet. Second, the DSL should include some mechanism for normalizing software title descriptions, so there is agreement among tools and decision-makers on which software we’re talking about at any point in the process. So rather than having four different records of the same deployed software recorded in the CMDB as Word.exe, MS Word, Microsoft Word XP, and Microsoft Office, we should see four instances of Microsoft Office XP.

Third, the DSL should indicate which software is licensed from third parties. This is the heart of software license compliance. Software deployments added to the production environment by change and software configuration management are discovered, their descriptions normalized by the DSL, recorded in the CMDB, and then recognized and counted against contractual entitlements in asset management. Because change, asset and software configuration management all share the same software information and deployment results, tracking is automated.

But we’re not proactive yet.

The shared DSL, CMDB and workflow integration allow change managers to easily see the software license status for a given title before they approve a change. If the proposed change would result in a non-compliance situation, a task could be created to purchase more licenses prior to approving the change. Or the change request could be denied and modified to a smaller list of targets that would maintain compliance. This is one aspect of proactive management of software licenses.

Another is the use of automated policies. If I have information on which user roles are entitled to which software (which the asset management should know), and know which users actually have what software deployed (which discovery and the CMDB can tell me), I can create automated policies in my software configuration management tool to continuously enforce this desired distribution. I can be notified of exceptions (especially where a user has software they are not authorized to have) and decide how to handle, or if I’ve clearly communicated a policy, I may automatically remove the software whenever the exception is found. Such policies can be submitted through change management for approval, to better coordinate and understand the ramifications of a proposed automated policy.

If I find myself with a software license count approaching or exceeding some threshold, I may propose the removal of that software from some specific set of targets. If this software is in the DSL and my software configuration management tool is familiar with its components, I can automatically remove all traces of the software, leaving behind no stray DLL or other content that could be counted against me in an audit.

These are just some of the ways that software license management can be conducted more efficiently, effectively, and proactively using a BSM approach: tying together disparate disciplines and tools through a common business context.

And a way to keep the horses in their barns.