The convergence between IT service management (ITSM) and software/IT asset management (SAM/ITAM) is getting ever closer. Several tool vendors in the ITSM space have entered the ITAM marketplace with bolt-on SAM modules that integrate with their existing ITSM suite. Additionally, one of the few objective guiding lights on how to practice ITAM (ISO 19770-1: 2017) was redrafted as a Management Systems Standard – thereby making its alignment to ISO 20000 that little bit easier.
But what else is going on that might make this union stronger?
3 factors driving the ITSM/ITAM (SAM) union
- Cloud. Many companies have now got over the prospect of having to engage with the cloud, as much because software vendors are not giving them the option of installing their software on site. Therefore, compliance is starting to take a backseat in acting as a driver for SAM – but value for money is rising in priority. Because SaaS is purchased as an operational expenditure (OPEX) item and OPEX appears on the Profit & Loss sheets of company reports. Previously, software was often ear-marked as a capital expenditure (CAPEX) item which does not appear on the Profit & Loss sheet. Why is this important? The Profit & Loss reports on company profitability – and thus software/SaaS costs are now hitting the corporate bottom-line like never before. And to the point concerning compliance – while being license compliant should be a governance goal of all companies, software vendors view audits as a tool to drive clients to the cloud “You owe us $XM, but we can make this go away if you sign our shiny new cloud agreement.” So, compliance could be rebadged as audit defense.
- Indirect usage. Granting users of one system access to the features of another system – this technological marvel often flouts license terms and conditions and is a big stick with which to chase organizations for additional SAM licensing revenue.
- Real-time configuration management database (CMDB) management is still a nightmare. Change is the enemy! It’s often a Herculean feat just to be able to align all the elements of an IT service stack around a common cause, and then to populate a database to accurately reflect this. IT flux then consistently erodes at CMDB accuracy.
CMDB: What’s the issue we’re trying to solve?
Strangely enough, the task at hand is more focused on our view of the data that represents our IT estate: “Perspective is subjective.” SAM will view the IT estate in a monochromatic fashion – with IBM, Microsoft, or SAP being their respective shade of choice. ITSM, on the other hand, will zone in on a service-based view of the IT estate. No one view is more valid than the other, but if we can pool efforts around the request, packaging, and release processes then we have the chance of being able to have our cake and eating it!
Understanding our technology weave
If we start to list the IT services we have to provide, then by extension we could then list the technologies that form the stack for those IT services. These could be viewed as the north/south strands in a weave of cloth.
However, SAM will be focused on looking at those technology stacks laterally – to pick out the software installations that need to be aligned to a purchase to demonstrate rights to use (and then optimized against an overarching contract and the architecture that defines the installation parameters). This east/west perspective is ambivalent toward which IT services a vendor’s technology will support.
The Bermuda Triangle of SAM
Many organizations will have adopted an ITIL approach to aspects of IT management, and so will have a software request process, a procurement process, and a change management/release process. If though, these processes are not joined up, then we create a fluid basis on which foundation-level SAM data is created.
Have you ever found yourself in a situation where the software requested, wasn’t the software that was purchased, and the software that was purchased wasn’t the software that was installed. And to top it all off, the software installed wasn’t the software requested? This scenario doesn’t just apply to end-user requests, this nightmare also impacts major projects and programs that call upon IT for their critical technology stack.
If any one of the interdependencies between request, procurement, and release is missing, then you are in the Bermuda Triangle of SAM – and setting yourself up for the perfect storm of a software vendor audit.
CMDB: The proposed solution
We need to adopt some SAM regimen to the top of this triangle, namely the software request process. First and foremost, we should be looking to enforce ALL software requests via a central point; if that central point splits to accommodate end user requests and project/program management requests then so much the better. The request concerned should capture as a minimum:
- A unique ID for the business service the software addresses
- A unique ID for the IT service the software addresses
- A unique ID for the software request itself.
Why? Because as business services come and go, we need to know which instances of software to stand down or uninstall. The same goes for IT services – if a corporate-level decision has been made to shut down an old ERP system, then the install footprint for the ERP system itself will be fairly evident; but the software installations that have been deployed by end users to accommodate the data transfers in and around the ERP system warrant further scrutiny.
Why the value for the software request? Have you ever been in a datacenter where finite resources are under pressure to be apportioned to new projects or programs only to find out that a server can’t accommodate the latest installation request because installation X or Y is taking up valuable space? But installation X or Y has no owner – and so we don’t know who to ask about whether or not it’s safe to remove this software.
Where? Where is this SAM information being stored? ISO 19770-2: 2015 oversees the structure and creation of Software ID tags and these XML-based human and machine-readable tags can be customized to accommodate the details/Unique IDs above then inserted into installation packages in support of the software deployment. In an ideal world, software publishers should be providing these tags at source, however their adoption is not mandatory – but we can create our own by using the guidance from ISO 19770-2: 2015.
How? Once tags have been installed alongside the instances of the software they represent, SAM suites that support -2 tags are able to use SQL reports based on the inventory of the XML tags. And using the unique IDs embedded in the tags we can start to tap into the business intelligence (BI) goldmine that your SAM suite could be.
Providing we have financial data aligned to the software installs, we can offer an accurate (and dynamic) total cost of ownership (TCO) for an IT service. Our east/west view of the IT estate no longer holds sway, as the SWID tags offer us a bridge to take a SAM perspective on an IT service.
Once we have a TCO value, a short hop allows us to offer value-chain analysis on that IT service. More importantly though, because we have the governance and operation firmly established around the request activity, the change that bedevils a configuration manager’s life is no more! Real-time updates on the growth of a service are maintained as new requests come in.
“What about SaaS and SAM?” I hear you cry
We’re not in a position to install a tag against a SaaS-provided software title, but we can place that tag data within Active Directory (AD). So, providing we have a feed from AD into our SAM suite, we can then see when services were switched on for end users. This is doubly helpful when staff move or leave, as a permanent record exists to shut down services if a new post or a departure from the company mandates this course of action. A good Joiners, Movers, and Leavers (JML) process should be plugged into any housekeeping activity for AD.
NB: Clearly this proposed solution is modeled on tackling the software elements of an IT service. I would always advocate that additional steps are taken to address the other elements of an IT service by benchmarking against the OSI seven-layer reference model, aligned to your appetite to include the elements you feel will give you a complete picture of your IT estate via the CMDB.
Structured CMDB: The benefits
We’ve already touched on being able to dynamically produce SAM TCO reports, but further benefits ensue:
- Untagged software can be scrutinized: If it’s not tagged, what is it doing on the IT estate?
- InfoSec: Rather than InfoSec presenting an estate-wide list of software to be patched or updated, they can prioritize certain installs that support business/mission-critical IT services
- JML: No longer is the flux of people joining and leaving exposing a company to financial liabilities when it comes to software expenditure – particularly around SaaS
- Shadow IT: This becomes a legacy concept
- Accuracy: If installations have been incorrectly aligned to IT or business services, then a simple editing of the tag can resolve this error.
This approach is evolutionary, not revolutionary, as the buildup of your CMDB via this method will be made based on the roll-out of tags. Over time though, you’ll be keeping step with the organic growth of your IT estate, and not having to retroactively chase data to help keep your CMDB accurate. You can find out more in the accompanying SAM and CMDB whitepaper.
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 asset management. This experience has been gained in both military and civil organisations, including the Royal Navy, Compaq, HP, the Federation Against Software Theft (FAST) and several software vendors. Rory is the founder and owner of SAM Charter, a process-driven SAM solution company and Committee Member of ISO/IEC JTC 1/SC 7/WG 21.
One Response
Very useful pointers on the connect between SAM and CMDB…