Do you have what it takes to survive the Bermuda Triangle of SAM?
We’ve all experienced it, even though we might not recognise the name!
This month we’re doing a deep dive into another corner of the triangle – the software deployment process.
The Bermuda Triangle of SAM is that gap between request, procurement and deployment where software gets requested and deployed, but not purchased, resulting in nasty compliance gaps and even nastier conversations with finance teams and auditors if the worst happens.
We’ve already tackled 2 of the three corners of the Bermuda Triangle of SAM previously. For the software deployment process, what we are seeking to validate is: that the software that was requested is what was bought, and what was bought is what was installed.
If we work in an IT organisation that is led by the nose to stand up software regardless of oversight, then this only embellishes the problems that lie in following the ITIL-recommended manner of requesting, purchasing and deploying software. Increasingly, complexity around virtualisation, cloud and indirect usage means that skimming over the T&Cs of licensing will result in eye-watering fines for improper use. Indeed, we should be advocating that IT service designs get locked by the time they reach the deployment process, so that last minute tinkering of designs doesn’t jeopardise a roll out… or if we work in an agile organisation, we need to provide guardrails that allow engineering teams freedom of action within certain boundaries, but once those boundaries are crossed, they need to come and talk to you to make sure they’re not putting the organisation at risk.
At no point should a deployment team assume that the requested software is what was purchased. The bountiful variety of versions and editions of software means that a mismatch could be all too easy to realise.
At this point, I would like to thank Scott Keatinge for his review of this process. Working for a company that creates deployment software, he was ideally placed to guide us on the idea of a pilot roll out. Creating processes that address every eventuality is hellish at the best of times, so having a step in place that tests a portion of a larger/ wider scale roll out made perfect sense.
And this is where we can engage with our SAM suite. If the deployment in question is part of a large-scale roll out of many software titles, then make sure your SAM suite has created a folder for the projects to reside in alongside your regular business departments. That way, when a project moves from project status to business as usual, the management of funding and IT ownership within the SAM suite becomes that much easier to implement.
In large organisations, this process will be automated through single-sign on (SSO) and the use of sophisticated deployment and packaging tools. Each application and licence option will have its own AD group and deployment is triggered simply by adding the user or machine to the appropriate AD group. Removing the software or removing access to the application should be as simple as removing the user or machine from the AD group. Couple this with a good SaaS management tool and software metering to spot when an application or software is unused, and a lot of your day to day BAU management simply disappears. You can start getting a real grip on the Bermuda triangle of SAM, managing these processes to make them all work better together, rather than simply turning the handle day after day!
The software deployment process is part of our Software Lifecycle Management Certificate. To receive credit, buy the process template from our store and use it as the basis for your own process that works in YOUR organisation. You’ll get an hour of one-to-one time with us to discuss how to improve your process, and once it’s looking good you’ll get a certificate of completion and credit towards the Software Lifecycle Management certificate.
