Nov 26, 2018 9:57:16 AM
I was recently fortunate enough to travel out West to the many stunning canyons in the Escalante Staircase formation. These are areas of unspeakable beauty, but also tremendous amounts of information about the geological history of the area.Their vast bands of alternating colors, flowing layers, and abundant fossils tell geologists stories about how these areas formed, reformed, uplifted, and eventually exposed their secrets over millions of years.
It got me thinking about the corollary between these layers of stone and the “layers” of data that tell SAM professionals about the history of their IT estates. It also brought to mind our very human tendency to focus on the first few inches under our feet, and ignore the deeper layers, which we are tempted to see as remote and irrelevant.
In the world of ITAM, it pays to think like a geologist and look closely at the “geological record” of legacy software!
As we know, discovery tools (let us hope) pick up huge swaths of information about software titles throughout an enterprise. Our challenge is to map these discovered software titles to our current entitlements on our publisher contracts, and determine how many entitlements are being consumed by the discovered environment.
If we consider the first few “layers” of discovery data, these may be the software titles which easily normalize or map to the titles on contracts, POEs, or other forms of entitlement. We are all probably fairly familiar with the past few years’ evolution of software titles, versions, and even bundling, for publishers with which we have regular exposure. Thus, with a few twists and turns, we are generally able to map these products to their contractually-named equivalents.
But what about legacy software? These are the deeper, more aged layers of the discovery “rocks’. Are we being careful to look for what information resides in these ancient striations? Or is it too easy simply to write off older titles as “legacy” and pass them by?
Legacy software is important because, in many cases, they have a migration path that leads them to the current product on a contract. Often, they are no longer supported and may be far removed from the current contractual products. It may be enticing to say, “well these are just old and don’t matter anymore.” But here are some ways in which legacy software should draw your attention:
- The publisher may no longer offer support for the old products. This may be important if the product is deeply ingrained in an application or process in the company.
- Does your IT team have dependencies on unsupported products?
- If they are aware, what plan(s) do they have to address this unsupported situation?
- If they are not aware, be sure to raise the question with them and encourage them to adopt a mitigation strategy.
- If you have a newer version of the product on your contract, this may not guarantee that legacy versions are entitled to migrate to the newer version.
- If you want to migrate to the newer version, would there be requirements to reinstate coverage to cover the gap in support? If so, many publishers impose financial penalties when doing so.
- It’s common to see multiple versions of software titles discovered on one machine.
- Are all versions still in use on these machines?
- If not, all unrequired versions should be uninstalled where they are no longer needed
- If multiple versions are being used, explore the reason why. Can consumers of the older product be migrated to the newer, and the old version retired and uninstalled?
So, in your day-to-day work in the SAM canyons, what kind of geologist are you? Are you careful to read all the layers of software data to form a full of the past and present? Share your tips and experiences from your SAM expeditions!
Subscribe to Email Updates
- IT Asset Management
- Software Asset Management
- Data Analytics
- IBM License Metric Tool
- Storage & Computing
- Data Protection & Security
- Asset Tagging
- Change Management
- Hardware Decommission
- Legacy Software
- Software Decommission
- Workforce Solutions