Software Recycling in the SaaS world
Do you remember the good old days? When recycling software involved nothing more than removing a user’s name from an AD group and all was ok(ish) with the world? (That’s if recycling ever took place!) And while the compliance drive to “trim our IT sails” was echoed in the halls of IT best practice, the commercial impetus wasn’t as emotionally invested because purchases were made out of CAPEX funding. Throw into this heady mix, that projects and programs were/ are inherently CAPEX funded, and so one-time/ written-off purchases positioned our very best efforts in producing an Effective Licence Position (ELP) on a foundation of sand.
I’ve spent more than my fair share of time at a keyboard writing about SAM & ITAM, but the one phrase that I keep returning to is that “Change is the enemy”. Life would be so much easier for SAM & ITAM if the business wouldn’t keep making demands (of change) on our IT estate.
However, we live in a real-world and a couple of points we have to take on board are:
- IT exists to serve the business
- SAM/ ITAM exists to serve IT
So: if your point on the SAM/ ITAM maturity curve cannot account for the rate of change in your IT estate, then you need to climb that maturity curve until it can (Top tip for a business case seeking further funding/ resources etc.)
Returning to our misty-eyed view at the beginning of the article: Can your SAM solution accommodate the cloud?
First off, we need to examine what should take place:
What activities require us to recycle software?
- Joiners, Movers and Leavers (IT interacting with the HR lifecycle)
- Software Recycling (non-use of software after xx number of days)
- The standing up and standing down of development environments
I’m sure you can think of others – and as a sidebar; let’s highlight the subtle distinction between recycling and removal. While the act of uninstalling/ removing access to software is the same for both activities, removal implies that we are doing something more strategic – i.e. archiving the supporting entitlement, removing installation packages, updating the supported software catalog and generally informing the business that a particular software title is no longer on offer to our employees.
When do those activities occur?
- When staff move jobs, or when they leave
- When non-use of software mandates that software is recycled
- When development instances are not required to be stood up
What triggers these activities?
- HR informs the IT department of a job change or a staff change
- We have an inventory system in place that informs IT of software non-use
- Developers tell us when they don’t need the software anymore (yeah, right!)
On-site software recycling can be automated – just be careful that if you have applications that protect against the integrity of configuration footprints, that one system doesn’t remove software for non-use, and then another one adds the software back on because a “critical” change has been detected after the recycling activity.
Where this can get tricky though, is the cloud. As mentioned before, in the good old days and as it is with Citrix, adding or removing users won’t be enough. This is great for access control, but as far as Microsoft or Salesforce are concerned the service on offer is still “available” – and perhaps just as importantly, still billable.
We need to turn off that financial “leaking tap” – not least because if someone comes into to replace the person that left, I can pretty much guarantee an ITIL-inspired/ feedforward IT provisioning system will be happy to raise replacement instances of services and software for a new staff member, without giving any thought to closing the former services/ cloud instances.
The particular issue at hand is that we could greatly benefit from a central repository/ control point from which recycling can occur. And this could be viewed as an “order qualifier” for any as-a-service title you choose: Can an as-a-service product interact with other SaaS management products to allow for a central recycling process? Some won’t.
A primary takeaway from this article should be that we are required to engage with our HR function – inventory systems will not know that staff have changed job roles or left the company altogether. You could do this via Service Management, or the responsibility could be placed within the handbook of line managers. There is no one right method as to how SAM is informed of such changes, the point is that they are told and can act on such information.
For those who have been operating in the ITAM space for any length of time, you’ll know that complexity comes with the territory. The trick with recycling is to conduct a cost-benefit analysis to arrive at the benefits that could come from automating recycling in the cloud:
How much change do you have to manage?
Are you being given the accurate data you need to make informed decisions?
What does that manual load look like?
Do you have the tools to achieve recycling?
About the Guest Blogger: Rory Canavan
With a technical background in business and systems analysis, Rory has a wide range of first-hand experience advising numerous companies and organisations on the best practices and principles pertaining to software and IT asset management. This experience has been gained in both military and civil organisations, including the Royal Navy, Compaq, HP and Flexera.
Rory is the CEO of SAM Charter, a Software Asset Management (SAM) consulting practice that is focused on recognising your primary business drivers and ensuring all IT assets are in sync with business strategy and operations. All SAM Charter services are ISO/IEC 19770-1:2017 aligned, reflecting IT industry best practices.