December is always that time of the year where we take a step back to see where we’ve been and look forward to what we’d like to do in the following year.  So I thought this would be a good time to take a short look at the history of BigFix and the IBM License Metric Tool (ILMT), and think about improvements I’d like to see next year.

BigFix Inc. was initially founded in 1997 in Emeryville, California. It’s flagship product was a patch management tool that came out around 2002, and back then, patch management was considered a particular pain point for enterprise IT departments.  Between 2007 and 2009, BigFix’s scope was expanded to IT infrastructure challenges, and then again to protecting endpoints from web threats.

In July of 2010, IBM acquired BigFix and integrated it into its Tivoli Software portfolio under the Tivoli brand, and it was re-christened as Tivoli Endpoint Manager (TEM).  In March of 2013, IBM renamed Tivoli Endpoint Manager to IBM Endpoint Manager (IEM).  Finally, in July of 2015, due to “customer demand”, IBM renamed the product back to IBM BigFix.  (IBM followed a similar path with the products it purchased with the acquisitions of Databeam {web conferencing} and Ubique {instant messaging} back in 1998.  The combined products were merged into one called Lotus Sametime, which then became Lotus Instant Messaging & Web Conferencing in the 6.5 release stream, and then it went back to Lotus Sametime in the 7.x stream and a short time thereafter, IBM Sametime.)

The history of the IBM License Metric Tool isn’t quite as clear.  The earliest reference to it that I can find is version 7.1, released back on August 1st, 2008.  I am not certain if there were versions prior to this under a different name.  The 7.x releases were all based on Tivoli technology, and included not only the Common Inventory Technology (CIT) scanners, but also the actual agents that ran on the individual machines and reported back to the ILMT server.  (See, now you know what “CIT” stands for.)  For all of the 7.x releases, ILMT was all-inclusive – it had everything you needed to deploy and run the product.  However, it was also slow – painfully slow – when recalculations of license usage were necessary.  Sometimes these recalculations would take over 24 hours for larger enterprises.

After IBM acquired BigFix, they leveraged the BigFix architecture for the release of the ILMT 9.x code stream.  All of the computer management, networking and scanning would be handled by BigFix.  You’d deploy a BigFix infrastructure and build on top of that.  ILMT’s focus became much narrower – it focused on the extract, transfer and load of computer data from BigFix, and the management of bundling decisions made by the SAM team to confirm, exclude or reassign components to products.  The decision certainly made sense – it leveraged the strengths of the BigFix platform.  You would deploy the BigFix platform and then you could later deploy other BigFix products as your infrastructure grew.  ILMT is just one of those products.  However, this also made the deployment of ILMT as an infrastructure more complex – now you had to deploy BigFix with all of its prerequisites, and deploy ILMT as a “fixlet”.  (Well, normally that’s how it would be deployed – there are other ways to do it.)  It also makes troubleshooting more difficult – there are a large number of logs to go through, and sometimes it isn’t clear where the problem lies.  Examples:  The ILMT software scan widget might report that a scan was not uploaded but it might be BigFix that isn’t getting scan results in its UploadManagerData folder.  Or, you use the VM Managers page from the ILMT UI to create and test connections to virtualization technologies but behind the scenes this process creates and submits a “Configure VM Manager” task to make configuration changes to “properties” files on the BigFix server.  Where to start looking becomes a difficult question to answer.

ILMT troubleshooting improvement.pngSo, looking forward, the area I’d like to see the most improvement upon is in troubleshooting.  Getting more guidance regarding where to start and what to look for would be a great thing.  Maybe IBM can create some virtual labs to which we could connect and actually troubleshoot a “real” problem, along with an optional script to use when we’re stuck.  There was an Open Mic session several months ago on troubleshooting which was supposed to have been recorded, but when I inquired about it, the recording seems to have gotten lost.  Why not repeat the session and walk us through scan troubleshooting again.  Somehow, reduce the complexity between the two products so it becomes easier to resolve problems.  That might give ILMT a better reputation and become more accepted in the marketplace; right now, its deployment is a contractual obligation to use Sub-capacity pricing.  A product of less complexity would probably make this medicine a little easier to take.

What about you? What would you like IBM to focus on next year as ILMT evolves?

 

 Similar Posts: