Panel only seen by widget owner
Cortex Consulting
Typically replies within a day
13:26
Hi there 
How can we help you?
Start Chat
 
 
 
15 Jun 2018

As the old saying goes, "East is east and west is west, and never the twain shall meet".  This might seem an unlikely analogy for the relationship between SAM and change management, but you'd be surprised how many times I've worked with organisations where they don't even come close.  Of course, based on the title of this piece, a few of you may well now be thinking of a 1980's sitcom starring Windsor Davies and Donald Sinden.  If you're not, you're clearly much younger than me!

Most of the blame for this division between practices can normally be laid at the feet of the lack of stakeholder buy in.  Often, change managers don't want SAM to be stakeholders in their process because they haven't been shown its value.  I have, during my career, genuinely been told things like "I can't afford to slow the process down just so you can worry about a few licences" or, perhaps my favourite, "I don't see the point of SAM.  Software licensing is like an airing cupboard - you can tidy it up as much as you like but someone will only mess it up again!"

When you consider that change management tends to be mainly centred around the datacentre, which is where your biggest licence costs and risks lie, this attitude is a trifle surprising.  To be fair, however, a change manager's job is more about service protection than anything else.  As long as the application, particularly the production element, continues to run successfully off the back of a change and the change doesn't impact anything it shouldn't, they're generally happy.  That's quite understandable.  A Change Advisory Board (CAB), after all, is where the real decisions are made and change management are simply the facilitators of that process.

The usual process, in most organisations, will follow a flow such as this one - request for change (RFC) is raised; approval tasks are added by the change team, or maybe an automated process; forward schedule of changes (FSOC) distributed to stakeholders; CAB meets to discuss; change executed; post implementation review (PIR).

 

The narrow view of software installs, moves, adds, changes (IMACs), tends to be what governs the changes seen by a SAM team but, as I'm sure most readers will know, there are many factors that can affect licensing in the data centre:

 

  1. Server builds - a fairly obvious one but it's not just about the software installation.  Note should be taken of the configuration of the server and, if you are operating a full asset management solution, this will help you to build a bigger, more complete, picture of your estate.
  2. CPU changes - addition, removal or another change (activation / de-activation of a socket, for example, or re-allocation of processor resources amongst partitions) of a physical or virtual CPU / core in a server.  With the majority of datacentre software licences linked in some way to processors or cores, the risk here is obvious.
  3. Memory changes - less of an issue these days but the licence VMware's vSphere Enterprise editions and below used to have a restriction on the total physical RAM allowed in a host server up until version 5.  There most likely are still some products that have memory restrictions but they are less common now.
  4. Server re-platforms - is a server being virtualised or moved from 1 host cluster to another?  Is there a change in platform technology, e.g. moving from Linux to UNIX, change UNIX platforms, switching UNIX partitions between different types?
  5. Server decommissions - this is obviously one that any SAM team would be keen to know about because it gives them the opportunity to re-harvest licences for future use.

Consider the sample change process diagram below, with the relevant checkpoints I've marked.  As with the PMO process in my previous post, these are my opinion and I'm sure different organisations will find different ways of doing things.

 

Approval tasks (1) should naturally include one for the SAM team, provided the change is relevant; a key point in the process here is how your change team defines who the appropriate stakeholders are.  One client I worked with determined approvers based on the application that was changing.  Clearly, this was not helpful to the SAM team who would have had to evaluate every single RFC for licensing issues - not a worthwhile use of resources.  A more effective approach is to determine approvers based on the type of change.  If the SAM team had already given the change team a pre-defined list of change types they were interested in, it would make it much more likely that they would get a task to approve the change.  Theoretically, this checkpoint gives you the opportunity to evaluate the change and raise any concerns or risks, or determine that additional licensing is required to support the change.

The FSOC (2) is something that is common in most end-user organisations, in my experience.  It is a tool that allows the change team to ensure that all stakeholders are aware of any forthcoming changes happening in the estate and will include pertinent details.  One of the first SAM touchpoints I advocate in a change process is ensuring that the SAM team is on the mailing list for the FSOC.  It will enable you to have a good view of any datacentre changes before they happen, even if you are not in the position, for one reason or another, to be able to evaluate them or contribute to the process.  If you are contributing more fully to the process, being in receipt of the FSOC allows you to check that you have captured all relevant changes where the SAM team should have an input and that you have had sign off tasks.

I'm sure most readers will be very familiar of the function of a CAB (3).  It is the SAM team's opportunity to participate in any discussion around a change where there might be a licensing impact.  It is where you can register any concerns about potential licensing risks or raise the issue about procurement of new ones, if it has not already been taken on board by the change requestor, which is the most likely scenario.  It is also essential that the SAM team has visibility of the CAB agenda when its published as a further check to capture details of any changes for which it may not have received approval tasks.

The final touchpoint, once a change has been either been effected successfully or attempted and backed out, is the post implementation review (4).  In most organisations, this will involve a task from the change management system which a stakeholder will need to sign off.  In the case of the former, the SAM should be evaluating the change to ensure that what was agreed, from a licensing perspective, is what was carried out and that the affected platform remains compliant.  With respect to the latter, it is always advisable to check that when the change was backed out, no other modifications were made which would affect the licensing scheme.  In principle, they should not have been but the whole purpose of governance is to check, double check and triple check.

If all of those checkpoints are implemented and you can achieve it with the minimum of impact on your change processes, then it should put your SAM practice in a much better space when it comes to governing your software estate.  Simple processes put into place with co-operative teams should mean that your airing cupboard remains permanently tidy.  If you would like to explore how we can help you with your SAM practice, please contact us or book a call to discuss your needs.