We don’t talk about ITAM (no, no, no)

At the recent ITAM Forum Leadership Summit a group of industry leaders and practitioners discussed strategies for growing the industry over the next few years. Two key and linked themes emerged: that we need to think about what ITAM means for our stakeholders, and that we as a profession need to pay closer attention to how we “market” what we do.

The debate was sparked by two leading end-user organizations stating that in order to be taken seriously at a strategic/senior level they never talk about ITAM. In a world where awareness of identity is increasingly important, are we hiding our true selves? Should we be bolder and nail our ITAM colours to the mast? Or is it really the fact that we’ve actually changed who we are and what we can be without realizing it?

Now, I’m conscious that this is a debate we’ve been around the houses on many times before. Getting buy-in and senior stakeholder engagement is as vital to ITAM success as having trustworthy data is. ITAM is an agent for change, and if you’re making big changes you need a mandate to do so.

What can we learn from others?

At the event there was also a good deal of discussion of the new kid on the block – FinOps (read our free Guide to FinOps here)  – and I think therein lies a pathway to changing how we present ourselves as an industry. As one tool and service provider commented “FinOps is about the business managing technology, ITAM is about IT managing the business’ usage of technology”.

The subtle difference here is that FinOps uses business/commercial language to report on the effectiveness of cloud computing in terms of financial return and commercial risk management, whereas ITAM uses technical language. For FinOps it’s not really about the fine detail of which instance size we deploy for a workload, it’s whether that workload is performing in a way that maximizes the business outcome of the activity.

For ITAM to progress do we need to adopt a similar approach? Rachel Ryan of Danske Bank* explained her team now never talk about the fine detail of metrics and similar things to external stakeholders, and that it’s always about tying what they do into business value, using business language. We might feel comfortable in the world of metrics and license terms but we have to step out of that comfort zone because no-one else cares. To do that I think the key is to look at what ITAM is, and in doing so to look at what it could be.

So, what is ITAM?

To paraphrase multiple definitions, ITAM is a set of processes and practices designed to ensure businesses have effective control of their assets in terms of cost, risk, and lifecycle. At the event we explored this a little in the context of other business disciplines’ interactions with technology. For example, ITAM is already closely aligned with IT Security, particularly following the latest releases in the ISO 27001 standards family, which now directly reference ISO 19770. I wonder if this presents a way forward which enables us to address some of the negative views and perceptions of what ITAM is?

ITAM as a set of processes and practices

If we never talk about ITAM to senior stakeholders, how do we start a conversation with them and make progress on our goals? I think the answer may well be to look at the processes we control and ensure that they’re optimized and designed to plug in to the processes owned by other stakeholders. To speak in software engineering terms, do we perhaps need to package what we do into services? Do we build ITAM as a service-oriented architecture, or even as a set of microservices?

Currently, ITAM can be somewhat monolithic in its approach to the asset lifecycle. We seek to manage and control every stage of the lifecycle. Increasingly, as businesses go through a new and openly accepted wave of employee and department-led innovation, that monolithic approach won’t work and will negatively impact the reputation and standing of ITAM. We will become the team that says “No” and we’ll get bypassed or lobbied against for getting in the way of innovation.

However, as Julia Veall from Vodafone* commented, if we start with data quality, we can start to have a conversation with other stakeholders who also need trustworthy data to deliver their goals. We know that we’ve got great data. We know that we have a holistic, rich, estate-wide view of our assets. Most importantly, we have detailed trend information which is vital to senior stakeholders tasked with strategic planning. Should our goal be to be that data custodian that provides trustworthy data to everyone else, as well as for our own direct benefit? Yes, but that’s not all.

It’s not just about the data. There are processes which we rightly own and are directly accountable for. In the services-based approach we continue to manage those as experts. But that doesn’t mean that we need to guard them from outsiders. Instead, we should look at those processes and see how they can be enriched with data and transactions from other stakeholders. In software engineering terms we need to make them open, extensible and accessible. Build a way to allow those other stakeholders to bi-directionally exchange quality data and transaction information with us. Have a way to automate processes and deliver outcomes across governance domains. Provide users with the workflows they need to operate efficiently.

Practical examples

Back in 2018 we saw the first inkling of what this can lead to with ServiceNow’s launch of the award-winning License Change Projections component of their Software Asset Management Pro (SAMPro) product. This functionality brought together the ITSM Change Management process with ITAM entitlement and usage data to provide Change Managers with immediate insight into the licensing impact of a proposed change. In a similar vein, several SaaS Management tools provide the usage trend & forecasting information which enables Procurement professionals right-size SaaS deals at renewal time.

These are just two examples. As ITAM process engineers I think there’s an opportunity to step away from what we’re called – make it irrelevant – and instead focus on what we can deliver to our organizations. Look at the entry and exit points for our processes and package them up into services which make sense to other stakeholders in the business.

For example, provide services such as Software Investment Intelligence, Software Regulatory Assurance, Asset Lifecycle Planning, or Sustainable Technology Advisory Services. Those are all things mature ITAM teams are doing as part of ITAM, but no-one really knows about it because we wrap them up in technical language, not business language. Build the services and sell them to the stakeholders who need them.

Improving our tools

For tool and managed service providers the opportunity is also clear. Build the APIs and permission sets which provide access to key ITAM data such as entitlements, usage trends, and lifecycle information for the tools and services used by over governance stakeholders. Historically, ITAM tools have been great at ingesting data from a wide variety of sources but perhaps have been less good at making it available to others. Whilst trying to break down siloes in other functions, we’ve been busy creating our own. Investors have big money waiting for companies building ecosystems, platforms, APIs, and workflow. Now’s the time to start building those things in the tools we use.

Conclusion

This is just one possible approach to delivering growth for our industry. Expect to see further initiatives from The ITAM Forum as they digest the findings from the summit. Alongside this subject we also considered how ITAM is perfectly placed to deliver on corporate ESG goals, which, despite Elon Musk’s view of them, are here to stay and only going to grow in importance during the rest of this decade.

To hear more from Julia and Rachel, be sure to attend their sessions at Wisdom EMEA on June 15^th & 16^th at Twickenham Stadium. Tickets available here.

* NOTE: All trustees of The ITAM Forum are members in their personal capacity. Any quotes attributed to ITAM Forum trustees are their own personal views and do not explicitly represent the views of their employers.