This article is the third of a four part series by AJ Witt of ITAM Review and Josh Brazee of Aspera. The series explores concepts & practical advice for managing Cloud deployments to minimise cost and risk whilst maximising value.
to be followed by
These articles are also available as a whitepaper, downloadable here (no registration required)
The first two parts of this series looked at the opportunities for managing cloud consumption using ITAM techniques. Digging deeper, this article looks at the people, processes, and tools you’ll need to turn cloud management opportunities into significant wins for your ITAM team.
The good news: the ITAM lifecycle still applies. If you already have a mature ITAM practice, you will have the resources to be able to deliver on the promise of cloud optimisation.
Here’s a common approach to the ITAM lifecycle – assets are specified, acquired, sometimes developed, released, deployed, operated, and retired:
This lifecycle still applies to cloud management; the difference is that there are more stakeholders involved at each stage, and in general, central IT’s role may be smaller compared to their role in managing perpetually licensed software.
For example, in the Operate phase, SaaS management stakeholders include:
The order of importance runs from left to right; in this phase, Vendors are undoubtedly the strongest stakeholder because they’re providing the software as a service. That means they’re solely responsible for maintaining the software – patching it, upgrading it, releasing new features. Third parties have a role to play here because they may well be providing functionality to the vendor via code libraries or plugins. End Users and Departments are also stakeholders. They may be submitting bug reports directly to the vendor or making feature requests via direct support channels. It is not uncommon for SaaS apps to be managed by the users/departments, leaving IT out of the loop. IT’s role is undoubtedly diminished for all cloud deployments, but particularly SaaS.
I’ve mapped out the influence of each key stakeholder at each lifecycle stage. The following Lifecycle Influence graph ranks the stakeholders in order of influence at each stage – from Specify to Retire.
Here we see that across the entire lifecycle, Users and Departments have the greatest influence – 56%. Next is the vendor with 21%. At 77%, three-quarters of the influence across the lifecycle lies outside the traditional channels of IT & Procurement.
This shift in influence is the reason that stakeholder engagement becomes so important for ITAM teams working in cloud-first organisations. It also is a strong signal that the future of the ITAM department doesn’t necessarily sit within IT. End-users and the departments they work for hold the cards, not IT. If we are to gain control of cloud spend and build a cloud ready ITAM practice we must start with stakeholder engagement. The software and technology stacks are no longer under IT (and ITAM’s) direct control. Let’s look at what that means for your team members.
In this section we’ll look at some of the key roles in a cloud management team.
The skills required to manage SaaS deployments are somewhat different to those required for managing perpetual on-premises deployments.
A SaaS Subscription analyst will work with a large volume of bills and contracts monthly. This is high cadence work, so it will require strong prioritisation skills to focus effort in the areas where the greatest savings can be made.
SaaS analysts will also conduct longer-term studies of the applications and capabilities in use at an organisation. For example, they may discover that your users use a mix of Dropbox, Box, OneDrive, and Sharefile for file storage and sharing. Can this be standardised? Dealing with a single vendor could potentially lower costs, improve productivity, and simplify management.
Along with optimising providers, there is still the more traditional task of identifying, co-terming, and optimising vendor contracts. Multi-year deals and co-terming can often bring discounts and additional benefits, discounts and benefits that also apply to SaaS deployments. I’ve written previously about the frictionless nature of SaaS procurement, and it is clear that committing to a longer-term deal with a SaaS provider can yield significant cost savings. For example, committing to a 12-month plan for collaboration application Slack saves you 20% – effectively you’re getting 12 months for the price of 10. Easy savings if you’re willing to commit.
To summarise, what does a SaaS Analyst role look like? Limited technical licensing knowledge, strong vendor management, good stakeholder engagement, strong prioritisation, and an ability to work at a high pace. You may find your future SaaS analyst outside of IT, perhaps in Facilities Management or Procurement. Equally, from within IT, this is a potential career move for a Service Desk Analyst.
In contrast to the SaaS Subscription analyst, your IaaS-focused team will need to be more technical. Their key stakeholders are Infrastructure, DevOps, and those departments running their own cloud stack – teams such as engineering or data science may be prime stakeholders. They will need to speak the language of IaaS – cores, CPUs, instances, and so on – and understand how the various cloud services work. In the previous article, I highlighted how cloud sprawl and over-specifying can lead to significant wastage. The per-minute pricing of IaaS means that unnecessary spend can mount up very quickly, and there are usually no refunds. For an example, see Rich Gibbons’ article on Netflix.
Your IaaS analysts may therefore be your current technical licensing specialists. People with an attention to detail and the ability to ask probing questions of technical teams. People who are able to influence technical teams to do the right thing rather than the easy thing. If you have an analyst who has been instrumental in tidying up on-premises VM sprawl, they will be well-suited to this role.
Cloud Subscription Managers are responsible for setting up and reporting on the management framework for cloud. They will create and track KPIs, prepare forecasts, and work at the strategic level to optimise cloud capabilities and spend. CSMs will need to have excellent stakeholder management skills, particularly in establishing new processes to gain control of cloud spend and deployment practices. They will need to be able to work with stakeholders in departments who have until now managed their own cloud spend, budgets, and forecasts – and demonstrate how the Cloud Subscription Management Team can save the department money whilst ensuring they still have the right tools for the job.
These three new roles are just the beginning. As your organisation’s use of cloud grows so do the opportunities for your cloud subscription management team. You will need additional people in these roles plus some further roles to deliver a strategic approach to cloud management. These include:
Many cloud services provide a huge amount of data which can be a goldmine for innovative reporting. AWS provides guidance on how to ingest this data and manipulate it to meet your reporting requirements, and ITAM tool and service providers can do this for you too. Dedicated reporting, budget, and forecasting analysts will be able to assist budget holders to accurately forecast spend for the coming years, and also enable architects and business analysts to calculate the NPV & IRR of proposed solutions.
Some organisations with highly centralised IT functions have used business relationship managers (BRMs) to improve the relationship between IT and “the business”. Their role is to understand departmental or functional requirements and either match them to existing services or help with project submissions for new ones. With the business now being IT, both in terms of being the means of production and building their own solutions from commoditised cloud servers, the focus should change to ensuring that the applications in use are the right ones. This is the purpose of the Relationship Manager role.
Relationship Managers will work with stakeholders to determine opportunities for standardisation. They’ll work with employees to understand which apps they like, and which they don’t. They’ll report on the lifecycle of applications within the organisation. With up to 39% of an organisation’s SaaS stack changing annually, this role is vital in ensuring that the benefits of long-term commitments are aligned with employee sentiment. We don’t want to plough ahead with a 3-year deal for Webex if everyone prefers Zoom. Relationship Managers will also be experts in SaaS, being able to recommend the best application for a particular requirement.
This role may be necessary in larger teams to take some of responsibilities assigned to the Cloud Subscription Manager. They will ensure everything the organisation does in the cloud complies with both internal and external finance, risk, and compliance requirements. This role doesn’t necessarily sit within the ITAM team – it will depend on the maturity of both ITAM and the organisation. Think of this role as an internal audit function – and one that can be applied to traditional ITAM activities such as generating ELPs and maintaining risk registers.
In this cloud-first world there is still an important role to play for people with detailed knowledge of tools. Increasingly there will be a requirement to pull together multiple sources of discovery and inventory data into a single view. With no standard at present for IaaS & SaaS reporting, APIs and functionality, tool specialists will be the data cowboys, corralling all the many moving parts of cloud deployments into a unified view.
The following is an outline for a cloud ready ITAM team. Of course, you will still be managing everything you manage today, but there will be opportunities for your team members to shift their focus to new challenges. As highlighted above, your licensing specialists may be well-suited to the data-driven analysis of IaaS spend, whilst your generalists will get to grips with vendor and stakeholder management. Having the right people is only part of the story though – and the rest of this article looks at the tools and processes.
In order to start thinking about tool requirements it is useful to think about what those tools need to help us manage. The key themes I see are:
In a perpetually licensed on-premises world, the tendency was to commit to a single vendor for hardware and similarly find strategic partners for software. So, your server hardware would have been from IBM, Dell, or HP and you’d have selected either MS SQL Server or Oracle Database for your strategic database deployments. This was easy when IT spending was centrally controlled by IT. Now that departments and individuals are specifying their own IT solutions there is a lack of standardisation, meaning your tools need to be able to consume data from a much wider variety of sources. This requires a flexible approach to discovery and inventory and puts a greater focus on the normalisation & reconciliation capabilities of a tool.
Digital Transformation projects represent a significant increase in the scale of technology deployments. There are no longer physical constraints placed upon your use of technology by the size of your datacenter, the cost to run it, or the number of employees required to maintain it. Your footprint can scale rapidly – literally at the click of a mouse button. Tools therefore need to be able to cope with this scale. Are your inventory agents up to the task? What about database updates?
The scale and diversity of cloud deployments is further reinforced by an accelerated lifecycle. Your datacenter hosts may have had a 5-year lifespan, and you may have purchased MS Office and used it for the full ten years of extended support. The life of cloud infrastructure is sometimes measured in minutes, and rarely in years. Tools need to be able to continuously monitor cloud usage in order to optimise cloud spend and minimise risk.
My view is that tooling for managing cloud deployments, particularly from an inventory and discovery perspective, is currently fragmented and incomplete. There is no silver bullet here at present. The best approach we can take is to pick the right tools for our use-cases, and this will take careful analysis. Approach your potential cloud tool vendors with a detailed use-case and set of desired outcomes. Look to have an extensible toolset providing normalisation and optimisation capabilities by taking inventory and discovery data from a wide range of sources.
The final part of the puzzle is Process. Are your existing processes fit for purpose? What new processes & policies might you need? Conduct a review and close loopholes. If you have robust processes for controlling on-premises spend, software deployment, and an Acceptable Use Policy (AUP), you may just need to add processes specific to deployment scenarios – e.g. SaaS & IaaS. Start by thinking about what it is you want the process or policy to achieve. That should link back to the business case you made for managing cloud.
For example, if you’re seeking to manage costs, have policies that control who is authorised to spin up services in the public cloud. Perhaps mandate that non-production environments are automatically shut down out of hours. For SaaS, consult with your stakeholders to determine the level of control you wish to apply, balancing the needs of departments with the needs of IT governance. For an example of a “light touch” SaaS Policy, see this document
In this article we’ve outlined the People, Tools, and Processes required for successful cloud management. We’ve seen that our existing teams are well-equipped to handle the challenge, and that cloud provides opportunities for growth. Tools remain challenging due to the complexity and scale of cloud environments, meaning that we need to be careful in our selection, and recognise that for now we may need more than one tool to deliver. And our processes and procedures will need enhancing to cope with the challenges of cloud. With that in place, the final article in the series will explore practical optimisation techniques for common cloud services.
For more on cloud consumption and optimisation, see “Software Asset Management for the Cloud: Consumption Management & Optimisation take centre stage“