Monday, 7 January 2019

Do I really need SaaSset Management?


For many line of business projects, Software Asset Management is considered at best a necessary evil and, at worst, a hindrance. Organisations – at least those with some semblance of organisation – recognise the need to ensure that their use of software is legitimate and compliant, has been procured and licensed correctly and does not expose the corporation to punitive financial penalties from audits. Those companies which are more forward-thinking also see benefit in their BAU bottom-line from SAM. Centralising software acquisition and inventory makes it is easier to avoid duplicate purchases when there is existing unused "shelfware" entitlement; also, a full software lifecycle management process means that assets no longer required can be harvested and either reused for new projects or removed from maintenance contracts if truly redundant.

This type of SAM model has predominantly evolved in an on-premise world. As more enterprise software moves to the cloud, and particularly to SaaS solutions – 45% of all application software spend by 2021, according to a recent Gartner report – then many of the above tenets are often perceived to be obsolete. On-premise software is primarily acquired via capital expenditure and is therefore recognised as an asset that the owner has a responsibility to manage. SaaS software is primarily acquired via operational expenditure; as such, it is not viewed as an asset in the same way, but rather as a service that can be switched on and off as required.

The absence of SaaS cost from the capex budget, meaning that it is neither owned nor managed by the organisation in the same way as on-premise software, has led many companies to conclude that SAM is not as essential in this scenario. If the CFO’s primary remit of SAM is avoiding audit exposure – especially since there is a 65% chance that the organisation will experience one or more vendor audits a year – then the SaaS "pay as you consume" subscription model largely negates this concern. The counter argument is that, while SaaS may reduce or remove potential unbudgeted compliance expenditure, failure to introduce effective management of such solutions is likely to simply shift cost elsewhere.

How? Let’s consider those line of business projects that I mentioned earlier. From their perspective, the simplicity of accessing SaaS solutions is heaven sent. With a cursory wave of the company credit card – or, as I once witnessed, the project manager’s own credit card (no names, no pack drill) – a software solution can be provisioned and accessible for productive use in lightning quick time. Freed from the constraints of SAM processes and centralised acquisition, the project will be more agile and therefore more likely to deliver a business solution faster than via the traditional on-premise route. Of course, this is one of the main benefits of SaaS. To a large extent, it’s rather like:
However, the aforementioned "constraints of SAM processes and centralised acquisition" do not exist only to manage software compliance. A good SAM practice enables an organisation to manage software costs effectively across the enterprise and throughout the entire solution lifecycle. It’s not just about speed; after all, a car with brakes will go faster, and more safely, through a corner than a car without brakes.

Line of business acquisition of any software solution – on-premise or SaaS – outside defined company procedures (and often without any involvement or management from IT) introduces Shadow IT. Shadow IT, by its nature, is obscured, in whole or part, from IT and SAM visibility. In such an environment, without appropriate corporate management and control, escalating ongoing costs are likely.

SaaS, in particular, is designed to make it relatively easy to sign up without IT involvement; however:
Who has signed up? For how many users? For how long? For what grade of service (enterprise, standard, basic, starter, etc.)? Is it a multi-component SaaS offering and, if so, have only the component services required been purchased? What cost profile/terms have been signed up to and do they take account of additional usage by other LOBs and the potential price reduction that centralised "bulk purchase" by the organisation would attract? How will employees signed up to the service who leave the company be managed? Who will manage renewals, especially if they default to "evergreen" – i.e. where the term automatically renews, often at the same or an increased rate, unless specifically terminated (I’m sure many can relate to this if they’ve ever had a mobile phone contract)?
 

In addition to potential cost exposure, the role of IT and SAM in managing SaaS solutions deployed within the enterprise is important from a data and security perspective. The LOB may well have determined that the storage of data in a public cloud SaaS environment meets corporate and mandatory legal requirements at initial implementation, but are they best placed to ensure that this remains so when company and legislative requirements change? Have they considered ownership of the data and, for example, how it can be retrieved from the SaaS vendor (and confirmed as removed from their servers) if/when the contract ends, or how often it is backed up and how easy it is to recover if needed?

In my opinion, organisations are making a mistake when they take the view that SAM is not required for SaaS software. I don’t underestimate the effort that is required to augment existing traditional SAM processes for cloud-based consumption, but as we move more and more into this type of software deployment, it should be a factor that is being considered and designed for ASAP.

Comments and criticism more than welcome; thank you for reading 😃.