To take advantage Sub-capacity licensing and its inherent value, IBM customers are required to: 1) Install either the IBM License Metric Tool (ILMT) or BigFix Inventory (BFI). 2) Produce audit reporting on at least a quarterly basis, and 3) Retain such reports continuously for 2 years. However, while IBM mandates the use of these tools for Sub-capacity license owners, it does not contractually require that they be used to their optimal capabilities. This is where many customers miss an important opportunity to start down the road toward formalized Software Asset Management.
IBM requires the use of these tools only where sub-capacity software is installed, but if the BigFix agenting is installed elsewhere, organizations can discover other non sub-capacity IBM software instances (and in the case of BigFix Inventory, over 40,000 other software titles from over 9,600 other publishers).
Like many IBM customers, the last company I worked for installed ILMT, and struggled with it initially. Early versions of the tool were hardly perfect, and this gave it a “bad rep” with the IT staff. With perseverance however, we were eventually able to stabilize the application and begin to extract some value from it in the form of software discovery reporting and the requisite audit reporting.
We quickly realized, however, that the value of software discovery data (on their own) is extremely limited. To make sense of the data that were captured, more background information was needed.
Specifically we required a complete understanding of the IBM licensing inventory we held; without which we were unable to accurately bundle products within ILMT or produce even the simplest reconciliation to our Effective License Position.
Once this was compiled however, we found that we were able to better control our software estate, and as an unforeseen secondary benefit, found ourselves well on our way down the path of Software Asset Management (all because we were using a contractually required IBM tool.)
If you are interested in understanding how ILMT can provide additional value and be a ‘Gateway to SAM’ for your own journey, please read the complete article at: //itak.iaitam.org/ilmt-gateway-sam.
Perhaps the most important aspect of fully utilizing IBM’s ILMT (or Big Fix Inventory) tool is to be able to accurately create bundling relationships. For those that are unfamiliar, bundling is the process where users confirm the specific IBM Product that each discovered software instance relates to. In a generic sense, each confirmed bundling creates a record in the database that specifically identifies which purchased license is used to cover each discovered software instance.
Sometimes, however, a software signature is discovered, that is identified in some way as “inappropriate” – as bundling it to a product would falsely increase the amount of licensing required to cover that product.
Reasons for this inappropriateness are varied, and new scenarios can be identified at any time.
Some examples include:
• Products that have already been uninstalled – but certain registry or XML signatures continue to scan
• Components of an IBM product that are used and licensed by third party software developers as part of one of their products (e.g., Cognos, DB2, etc.)
• Components that are discovered on servers that are used exclusively as code repository file systems
• Components that are misidentified or in some other way disputed – where an IBM Service Request ticket has been submitted and addressed with no effective remediation recommendations provided.
• Certain cases where software installations are in place as Disaster Recovery backup*
In these and similar cases, something needs to be done to avoid potential over counting; and there are 2 options available: Exclusion and Suppression.
The function of Exclusion allows the software instance to continue to scan – and show up on reporting, but as a No Charge instance. Suppression on the other hand, effectively removes the instance from being considered for bundling or other tool analytic functions. So, the question really is: which process to use?
Regardless, it is up to the ILMT/BFI tool user to control the implementation of these options – to avoid inappropriately undercounting their software.
To do this, I suggest the following Best Practice rules for use:
1) Use these options only as a last resort. If signature files continue to scan – after uninstallation, investigate and remove them manually (if possible). If you have code repositories – confirm that the software versions are still current – if not, then uninstallation is preferred.
2) Only use the Suppression functionality for the limited case where the discovered signature is truly a “False Positive” – Otherwise, stick to Exclusions.
3) For both functions, you can enter a comment to explain the reason why these actions were taken. Do this for every exclusion or suppression, but do so in the following manner:
a) Identify who executed the Exclusion/Suppression and the Date when it was invoked
b) Briefly state a reason – and include the IBM service request ticket number if appropriate.
c) If you were able to research online, any “evidence” for your conclusion that the instance should not be counted – include a URL link to that information as well.
d) Keep a list of any reasons that will “pop up” again in the future, so you can reuse the same text for future Exclusions/Suppressions
e) Take advantage of the “rules definitions” functionality if appropriate
DMGILBER – 01/08/2018: Per T10007005 Based on rules confirmed by IBM – this instance of IIB does not require licensing.
By creating a policy for the use of these functions in a uniform manner, users will maintain control over their ILMT/BFI data and reporting. Also, note that both functionalities can be reversed – in case they were applied in error.
The Exclusion and Suppression functionality in ILMT and BFI are there to make your reporting and bundling as accurate as possible, but if used haphazardly or inappropriately, they can be a source of confusion, risk and error. If you keep these well controlled, they are valuable functions that will serve you well.
* See IBM documentation for complete rules regarding Backup licensing
If you’d like to learn more about bundling best practices contact us!
An internship is a great opportunity to get real-world job experience that you can’t get in a classroom. At CleanSlate, our software engineer internships allow you to work alongside experienced IT professionals who will show you what it takes to work at a fast-moving technology company.
As an intern at CleanSlate, you’ll work on individual and team projects that will teach you problem-solving skills and how to adapt to the challenges of an IT job. You’ll have access to help when you need it, but we’ll encourage you to solve difficult tasks on your own. Not only will this help you learn—it will also lead to a more innovative solution.
Before taking a full-time job at CleanSlate, I worked here as an intern. One of my first assignments was fixing several bugs on a website that had just gone through a software upgrade. That one project taught me PHP, MySQL, HTML, CSS, Apache, NGINX, and Linux command line—so you can see just how valuable an internship here can be.
Along with the tech stack, I learned how to host a website and database on Amazon Web Services, and how to use version control while upgrading. In many ways, I learned more at my four-month internship at CleanSlate than I did in my first three years of college.
I continued to work for CleanSlate part-time after my internship, and once I finished school I became a full-time employee. The transition was seamless since the team here was already treating me like I had a full-time job, and the types of projects I worked on were very similar, too.
CleanSlate is a partner with the Xtern Program, which pairs college students with paid internships at Indy’s top tech companies. Xtern is a great resource for helping with housing and connecting you with exciting events and opportunities all over the city. It’s also a great resource for learning more about all the companies in Indy’s fast-growing tech sector.
If you’re in school to be a software engineer and you’re looking for an opportunity to work with lots of different technologies, you can’t beat an internship at CleanSlate. We work in a fun, laid-back environment full of people who truly enjoy their work, and who are more than happy to help you become the best software engineer you can be.
If you’re interested in becoming a CleanSlate intern, email Chris Konow. And if you have any questions about our internship program, be sure to contact us.