Earlier this year, I had a conversation with Andreas Gieseke and Ragip Aydin of Raynet about software asset management and the specific value of generative AI there.

Now, I spent some years at one of the largest US banks as the consulting architect for software asset management (SAM). I had a broader responsibility as the lead architect for all things “business of IT,” including service and portfolio management, but SAM had become a crisis due to issues that had arisen with large vendor licensing and penalties for not handling virtualization correctly.

It was an eye-opener. I had seen and worked in many IT management processes previously, but software asset management was at a new level. In fact, to this day, I tell clients that it is the most difficult operational IT management process. Now, obviously, software development is hard, but I consider that a research-and-development process. Operational processes are supposed to be repeatable. SAM? Well, let’s just say it’s not exactly easy to achieve repeatability.

We use a wide variety of tooling. We scan large digital estates with sophisticated discovery tools. We aggregate the data into various data stores, including configuration management databases. There are endpoint management systems. There are patch management tools that are adjacent and relevant. Yet enterprises still struggle.

Why?

Because knowing what software you have the rights to use is stipulated in legal language contained in contracts and vendor policies. Drawing a line of sight from the discovered technical reality to the commercial reality remains difficult. I often start conversations by saying that it is still surprisingly difficult to know, beyond a shadow of a doubt, whether a given software entitlement is or is not consumed by a given processing node in the general case — presence of bits ≠ entitlement consumption.

There was much industry conversation in those earlier years about the information asymmetry. Rob Preston, then editor-in-chief of InformationWeek, noted customer frustrations at “sifting through licensing models that vary wildly and inconsistently based on access method, number of users, and CPU size” and commented that “it’s hardly in a vendor’s long-term interests to base its business model on complexity and obfuscation.”

So organizations would acquire SAM platforms and then still need niche consultancies specializing in keeping their discovery and analysis software up to date with the latest wrinkles in whatever Oracle was doing with its contracting. Every company had to develop a stable of experts with deep understanding of the nuances of Oracle, IBM, SAP, Microsoft, Adobe, and other licensing models. Even then, issues could arise from improper usage by well-intentioned engineers.

So the idea Raynet is pursuing is not simply contract summarization. In Gieseke and Aydin’s view, SAM’s fundamental challenge has always been the dependence on scarce expertise. Their effort was aimed at combining licensing knowledge, customer data, technology catalogs, policies, and contract interpretation into a more operational form or, as Haertwig described it, moving beyond “expert systems for expert users” and making that accumulated expertise more broadly accessible through natural-language interaction.

As Gieseke noted, “[SAM] customers get promised, ‘Hey, there’s just one little button and you will get all contracts in and you will all have your compliance.’ That’s the promise. And it has not happened … the technology wasn’t ready.”

The trouble is the sheer scope of the line of sight, top to bottom.

Coming from the top down, we’ve got software contracts and entitlements that, while drafted by lawyers, aren’t necessarily deterministic in a computing sense. Then, coming from the bottom up, we have raw scanning and telemetry information from the estate. Getting the two to meet in the middle has been an ongoing headache.

This is where you run into terms like fingerprinting and profiling and the emergence of vendors such as BDNA, which was later acquired by Flexera. BDNA (to my knowledge) provided the first full commercial library of fingerprints that allowed you to map from messy discovery (has anyone ever looked at a report out of the Red Hat package manager? I have … ) to a normalized commercial catalog. Even then, you still needed a lot of human beings with a lot of experience to make sense of it all.

The terms and conditions themselves were and are another challenge. Let’s just say that there is no standard data model for a software asset management contract. I’m sure people have tried, but ultimately these agreements are negotiated by human beings. To borrow the canonical example from the open-source world, you may find a clause that says you need to buy the developer a beer if you should meet them. Commercial contracts aren’t quite that whimsical, but it illustrates the degree of variation that one can encounter.

So how does AI help?

AI is very good at taking high-variation information and reducing it to a smaller output space. This predates large language models. It is the basic problem of classification, and we’ve started to use it to good effect on complex documents. A software asset management license is, of course, a complex document.

Now, the LLM by itself is not magic. You must provide a great deal of additional context. (Hey, that word “context” again. Have you been hearing about context graphs lately?)

In this case, the context includes the technology catalog, the universe of software that might exist, knowledge of common contracting patterns, curated policy repositories, quality controls, and customer-specific information. All of it needs to come together. And then the LLM can start to supplement, not supplant, human expertise in making sense of this messy and complex set of data.

Again, the point is that this is not LLM magic. It is the use of an LLM, with harnesses and context, to supplement expensive, hard-to-source, and hard-to-maintain human skills.

One of the perpetual problems in software asset management is that when you get somebody who is good, someone who truly understands the nuances, they tend to get hired away by the software company or a consultancy. Now, instead of relying exclusively on that hard-to-find, hard-to-retain expert, more junior or generalized procurement analysts, sourcing managers, and even IT leaders can interact through natural language. There is still risk. There is risk of inaccuracy and even hallucination. Although, when LLMs are firmly grounded in a context graph, I think hallucination starts to diminish to acceptable levels. (It is never completely gone, but that’s why we have controls in the first place.)

Ultimately, SAM is an archetype. It is a specialized instance of a broader problem. Organizations depend on accumulated expertise that exists primarily in human minds and in messy human language. One of AI’s strongest value propositions is helping organizations gain better control over that accumulated expertise. The reason why I am even telling the story right now is that I think it shows the direction for concrete, specific, and valuable usage of generative AI in complex business situations. The same pattern appears in many areas of IT management: cybersecurity and vulnerability management, technology lifecycle management, IT finance, observability, and even enterprise architecture itself.

Share