Is there more to Software Asset Management (SAM) than counting pennies?

It’s hard to believe that anyone can question the need for SAM (Software Asset Management). After all, businesses run on software these days and if you don’t know what software you have, how it’s configured, who’s running it and where and when, how can you possibly claim to be in control of your business?

There are two aspects to “today’s economic climate” affecting this, it seems to me. First, governance and risk management are seen to be out of control. It’s not that we didn’t have risk management in, for example, the banks that have just crashed and burned, the real issue is that business managers were allowed to ignore what they were being told about risk. Someone at Sybase told me recently about giving a seminar on counterparty risk management to a bank in London. Afterwards, the senior manager present got up and said, in effect “thanks for explaining that so clearly—you’re absolutely right about the cost of counterparty risk but if we factor that into our charges, no-one will do business with us—so no thanks…”.

However, the credit crisis probably means that there is going to be a new focus on effective software-assisted governance and risk management; which also means that you had better be able to believe the reports you’re reading and sending to the regulators. If you don’t have effective SAM it will be hard to keep a straight face while doing this—unlicensed or unauthorised software may or may not be fit for its purpose (depending on how and where you got it) and it may even be corrupted so as to support criminal intent—you can’t really trust the reports it produces.

Luckily, there’s a more immediate driver for SAM too. Whether software licensing is a self-inflicted rod or not (I self-provision a multi gigabyte email system myself, from Google, and don’t even have to worry about paying for it—although I still have to worry about (non)SLAs and business continuity, both issues SAM should help with, of course) it does concentrate the mind wonderfully. For years, major software companies have made profits partly out of customers who cheerfully over-provision, buy “comfort” shelfware and duplicate software provision. Now, with money being tight, there’s a real incentive to get rid of redundant licenses and consolidate on one “best of breed” software product. SAM can pay for itself several times over just by making sure you only pay for what you use—although perhaps you should be thinking whether you really need what you use too. Nevertheless, don’t forget that there will be a, possibly expensive, cultural change to manage as part of this, since your existing culture got itself into this expensive mess of unmanaged software assets in the first place.

These thoughts were prompted by a FAST roundtable I attended this week, which collected most of the expertise needed to solve the SAM issue in one place, with representatives from vendors like Microsoft, the SaaS (Software as a Service) community, SAM auditors, automated software discovery vendors and so on. The trouble is, that the users of unmanaged, unlicensed software weren’t particularly well represented—there were none of of them present (or, at least, none of us would admit to any such thing). Staff&Line may claim to have more SAM customers than HP, for instance, but the scary thing is that the sum total of their customerbases is a tiny fraction of all the commercial software users out there. Scary? Well, as I said, I believe that without effective software asset management you can’t effectively manage your business automation and the risk associated with it; which means you aren’t effectively managing significant business risk.

So, what answers did the roundtable come up with? Well, primarily, that you need to get SAM onto the board-level agenda. Not by peddling fear (although a board that encourages use of pirated software does face some risk of legal action) but by pointing out that you can save a lot of money for the organisation by getting rid of licenses that you aren’t using or rationalising away from licensed software products that you don’t really need (why license Acrobat, for example, when all you need is Acrobat reader and the PDF converter in your word processor).

The Microsoft representative thought that this was good news—money freed up from shelfware would be ploughed back into buying more (presumably) Microsoft software to do even cleverer things. Others of us thought that the elimination of income from shelfware (which needs no maintenance and doesn’t even have to work properly) and unnecessary software in general might be a nasty bottom-line shock to vendor revenues—and even share prices. We shall see.

There was, in fact, quite a lot of talk about software cost and cost savings from removing unnecessary licenses. However, perhaps we also need better ways of formally assessing software value. Otherwise we risk a vicious SAM-based software cost rationalisation actually impacting business value delivery. To adapt Einstein, “Lord, let me pay for as few licenses as possible – but no fewer…..”. And, of course, perhaps one might expect a serious discount on the license cost of software so buggy as to not be “fit for purpose”—if it doesn’t deliver the measured value it promised—and, by the way, one of the attractions of SaaS is that if a SaaS package doesn’t work properly it is easier to stop paying for it than is the case with a conventionally licensed, badly-written, software package.

Somse useful technical points were made around the cost of implementing SAM. Many software products were naturally hard to audit, leaving unidentified files lying around all over the place. Surely, software should have license management and discovery features or interfaces built in? That’s something for software developers to think about. And, effective Web security management makes maintaining license compliance (don’t overlook this, SAM isn’t just a one-off thing) very much easier, as the Web is a major vector for unauthorised or pirated software these days.

However, discussion kept returning to the necessity for communicating financial and business-level messages, not technical messages, around SAM. Afterwards, I asked Bloor Analyst Ian Richmond about his take on how Configuration Management (CM; which is a superset of what SAM should be) plays at the board level: “Config management never figured high on the agenda of my clients (the user companies) all the time I was at Gartner—to CIOs it was perhaps something that had to be done but too far back in the technology to be seen as directly linked to business benefit, business needs and cost saving. Something a CIO’s tech team gets on and does. A CIO may get grief about outsourcing from the external board members but not config management. I did some 200 engagements in 13 years and covered anything the Research side wrote about—but not one CM job or lead. I see that the agenda [for the BCS Configuration Management Specialist Group conference] has links in the titles to business benefit etc. but [I doubt if a CIO] would see CM as a solution to a pressing problem that he currently has or will have over the next few months. Only my experience rather than saying the CIOs are right…”.

My take on this is that it confirms the necessity for selling SAM to top management as a source of business benefit rather than just a compliance cost, before starting a SAM initiative. In reality, many of the issues round SAM are cultural issues which top management should be managing, the roundtable thought. If an organisation has an immature “blame culture” for example, people will hide overspends and unused software (they certainly won’t admit to buying shelfware) rather than admitting their mistakes and doing something to address them.

Another part of the problem is that IT is still siloised—and responsibility for SAM can fall between silos; while the business is starting to think holistically, about business services which cut across silos. So, we need SAM tools which aren’t restricted to particular silos—but, more importantly, we need to assign responsibility for SAM. One SaaS benefit is that responsibility for SAM is just another part of the service taken on by the service provider (who knows where his/her software is and who is using it, if he/she wants to stay in business); although it is unlikely that all software in a company will be on the SaaS model, of course. In a conventional licensing model, the vendors seem to expect users—licensees—to take responsibility for license management and SAM.

As regards to the future, your guess is probably as good as mine! Here’s a tip: lots of people predict the future; ask them to nail their colours to the mask as to WHEN… My tuppence worth is this: the focus of IT governance is moving towards the business and business service delivery so SAM will probably have to become Service Asset Management and include SaaS. Cloud Computing and Open Source automation assets—but that is probably further out than 18 months except for the innovation leaders. And perhaps thinking about SAM will encourage people to think more about Open Source solutions (which still needs licence management) and SaaS (which needs SLA management) as a replacement for conventional COTS (commercial off-the-shelf) software.

In the short term, in order to improve understanding of SAM we need C-level buy-in and training—which will probably be more effective with interactive, informal face-to-face workshops rather than formal courses. In the medium term, however, we need a culture built around business outcomes and business service delivery, built on a foundation of effective Configuration Management (of which SAM is but a part). Dare I suggest that ITIL v3 will be the catalyst for this; and that this will become generally accepted 12–18 months out?