Bridge Painter Needed… The Importance of Inventory Control to Manage your Software Estate
“It’s like painting the Forth road bridge” is a phrase you may not have heard If you are not from the UK. It essentially means that as soon as you finish the job you need to go back to the beginning and start again because, by the time you’ve finished, the paint you first painted will be aged and need refreshing all over again.
That exact sentiment is often applied to the SAM concepts of ELP or baselining. Gathering the correct information can take so long that by the time you get to an answer which you consider to be correct the data which underpinned the answer has changed.
Even if you have tools deployed which claim to assist the process, the sentiment still holds. When producing a baseline or ELP you are essentially recording a state in time that is historical as soon as you publish it and every day that passes after the publication of that ELP sees you and your position drifting away from that position, like an unanchored ship at the mercy of the winds and currents.
Instead of constantly re-calculating the compliance position over and over again, why not create your baseline and then track the deltas in inventory to produce a position ?
Done correctly, this is by far the most effective method of software management and is known as Inventory Control.
Inventory Control
Inventory Control is predicated on the presence of three conceptual structures to control a software estate effectively, these three areas can be defined as follows:
- Policy and Governance (L&P Policy)
- Demand Management (Software Request and Consumption Monitoring)
- Variance Management (Deviation from Accepted Policy)
Each of the concepts to Inventory Control are equally important and will not function alone
Let’s discuss these concepts in more detail.
Policy & Governance
An effective SAM programme is predicated on the presence of a central controlling policy document known as a License & Procurement policy (L&P). This policy is the heart of any programme and must serve as a reference for any systems so they implement the policies and procedures described in the customer L&P. The systems and rules they implement should be an embodiment of the control methodology
An L&P defines the scope of the software asset management processes, and how the policy will be implemented on a granular basis.
An L&P is the core of any successful SAM programme. Around the L&P a number of conceptual and physical elements need to be in place to deliver on the promise conveyed by the model. Your L&P is a living document that should be subject to change control and is the reference for any and all ITAM related activities within your organisation. You can start small and then expand the focus as the concepts become standard practice. You will fail if you try to encompass everything in the first release.
A key component will be the technologies selected to deliver the methodology and process control platform. Note that I said technologies, there is no single tool that will do this for you. It is feasible to create an L&P in a word processor and manage the metadata associated with the policies in a spreadsheet. It’s not pretty but it can be done !
Demand Management
Demand Management is monitored through two sub-processes, the Software Request and Consumption Monitoring.
Software Request
A Software Request is the sole mechanism by which deltas to the SAM inventory should be triggered. Software requirements may be satisfied through the allocation of a full license, a short term license rental, or transferring an existing asset.
The driving principle of the software requisition process is to capture all inventory deltas, be they positive or negative. Remember, a positive delta occurs when a device is decommissioned, handed back, lost etc.
The submission of a requisition does not automatically trigger an associated purchase of software it simply logs the demand in the inventory. The decision to procure software happens at a different time triggered by alternative processes and, hopefully, at a time beneficial to you when all positive and negative deltas have equalled themselves out.
Consumption Monitoring
Consumption monitoring is the process whereby information about the software that is actually ‘installed’ on any given device is reported back to the control systems. The process for this reporting will depend on the software under scrutiny, the data collection mechanisms available and any requirements for compliance with resident security and data privacy requirements. You should assume that consumption monitoring will collate data from many data sources. Once again there is no single solution to this function.
It would be reasonable to expect data sources from one or more of the following list : SCCM, ADDM, SCOM, TAD4D, CMDB
Variance Process
Deviation from Accepted Policy occurs when software is deployed or used not in accordance with the tenets of an internal L&P policy aka “Shadow IT”. The process for controlling and correcting this situation is known as a “Variance Process”. It is this Variance Process that provides the policing of the L&P.
A Variance Process must provide
- Nightly audits: matching all known consumption items in the system inventory to the reporting of available asset monitoring tools.
- Reconciliation: matching the devices with a specific Authority to Install (A2I) queue to the installed products for the same server. Reconciliation is the matching of the A2I Planned implementation with the Actual implementation. (plan vs actual)
- Orphan/Unknown device reporting: Using the reporting output from available monitoring tools look to identify devices reported which do not have a reconciliation against a valid inventory item. Identifying potential un-licensed or unreported software consumption.
- Management Reporting providing KPI’s that measure the summary risk of any being held in each queue. (A queue is a definable state of variance)
- Active recycling: Where a requisition has been received to notify the service of a system decommission or intent to decommission allocated licenses are actively harvested from the inventory. Through this process, we identify systems that appear to be no longer in use, yet have an allocation of license through the inventory. A device is defined as no longer in use if it is given the status in a CMDB (or alternative system repository) of decommissioned (status) or disposed (environment) or if it has ceased reporting through the monitoring and discovery data received.
Summary
With the 3 tenets of Inventory Control in place there is no need to produce ELP’s or baseline ever again. Every moment of every day you know what your compliance position is.
The abstract nature of these three control concepts allows them to be applied equally to desktop software as well as server or enterprise software.
Imagine if you could apply that to bridge painting? It would be like knowing when any piece of paint was faded or flaked off and when it had been repainted. No need to ever start from one end and paint the whole thing...
If these theological concepts have piqued your interest, drop me a line and I’ll be happy to explain how you actually implement these things in the real world.
About the Author
Jason is Head of SAM at Version 1, with our independent licensing consultants (covering all aspects of enterprise licensing) providing expertise to customers globally, ensuring customers get the best value from their assets. If you would like more information about mitigating against the cost and risk of License Audits, get in touch with the independent licensing experts at Version 1 today.
