However, the perennial question regarding this process is… who owns it? It’s really the role of enterprise architecture, who own the Enterprise Technology Framework (ETF) to decide what software they want in the organisation, but they are focussed (rightly) on the big stuff, the software that is required to operate the business, such as ERP systems, the document management system, or key manufacturing management systems.
So, while SAM people don’t own this process, we do have an important role to play. Because we work down in the ‘nitty gritty’ and detail of what software is on the estate and who is using it, we see all the other software titles that, while maybe not strictly necessary to run the business, are certainly helpful… or were helpful once upon a time… or which were downloaded as an experiment to see if it was useful (but it wasn’t)… or was upgraded, but the old version was never uninstalled, or …
You get my gist.
These additional titles that can be found across the estate, even the useful ones, cost the business money through licensing and support. They also increase the number of potential ‘attack vectors’ that the organisation is leaving open to cyber-criminals who are very happy to take advantage of vulnerabilities in outdated or unsupported software.
Another aspect to consider when considering whether or not software rationalisation is worth your time, is that of support. Multiple iterations of software that perform the same task requires nuances of knowledge for incident and problem resolution. By letting your IT estate acquire “technical debt” in the form of old and unrationalised software, you are, by default, placing an additional knowledge-load on service management.
Most technologists would agree that a lean estate, where software installed is fully aligned to the ETF, should be the goal for any organisation. However, getting there consumes precious time and resource, even beyond the obvious challenge of getting everyone to agree which software to use, and then uninstalling the legacy version.
For example, if you have multiple types of software being used by different groups, these titles may have been integrated with other systems, integrations which will need to be replicated with the preferred software (costing time and money). There will be training implications for the teams asked to move and a productivity hit as the teams involved in the transition adapt their processes to the new software. Transitioning from one title to another may also require the purchase of additional licenses for the
preferred title, before the contracts for the legacy title can be cancelled, requiring the expenditure of cold, hard cash.
This is all way beyond our pay grade! So, what is a Software Asset Manager to do?
Our role is to work with support organisations, information security and enterprise architecture to help identify opportunities for rationalisation and build the business case for change. The business case shouldn’t only be focused on costs, either. ‘Free’ software such as web browsers can provide a rich vein of vulnerabilities for cyber-criminals to exploit, for instance. If we can provide information about what is out there and where in an accessible, easy to use format such as dashboards, this can become a powerful catalyst to drive software rationalisation of the riskiest software.
We should also work with other technology teams to take advantage of opportunities arising through programmes and projects, such as operating system upgrades to standardise and simplify the software titles in use. Again, by being able to provide the baseline information about what is out there, who is using it, and the costs associated with the software, we can support and influence broader efforts to standardise software across the organisation.
So, my advice is to not to try and bite off more than you can chew with this process and feel like you should be going it alone. Success with the process requires coordination and teamwork across many stakeholders, although the role we play is an important one.
Good luck with it!
