Process of the Month – Platform Identity Process

Best practice

Process of the Month – Platform Identity Process

We are not yet at that stage with inventory systems where they can tell us what classification or type of server a particular machine is.  Development, Test, Academic, Training or Evaluation installations of software should be isolated to devices dedicated to those roles.  Throw into the mix the concept of High Availability and Failover/clustering etc. and the landscape can look pretty tawdry when it comes to deciding what you are happy to pay for, and what you are happy to argue about with a software vendor.

My top tip in this sphere is where possible, try and leverage your naming convention – if a machine name states that the device is Dev (or has the Dev annotation somewhere in its Machine Name) then you know that it is a Development device, and so software that appears from one inventory sweep to the next isn’t as high on your investigation list as it might have been before.

Platform Identity Process

Primary Objective

1. To classify server devices appropriate to their role in the company; aiding the definition of software classification wherever possible.

Secondary Objective

1. To review the worth of server roles to the business and so understand whether or not they should stay in their current configuration/role, or be re-allocated or even disposed of.

Assumption

1. N/A

Function Step Overview

1.10	This is a straightforward activity – the Inventory Manager is required to capture the inventory of all devices in scope.
1.20	The Inventory Manager is then required to filter devices based upon their server capabilities and roles.  Higher end SAM suites can offer such a capability by taking the serial number of a device and comparing that to manufacturer’s lists of devices – some massaging may be required here, you may have desktop servers performing fairly critical services that could be missed purely because a SAM suite hasn’t classified that as a server.
1.30	The HAM Manager is required to take the list of servers, and start to categorise the role(s) those servers play.  Clearly, the first time this process is run the amount of time dedicated to such a task might be better handled by splitting it up amongst a team.  Providing that team have a decent knowledge of the server roles, then this isn’t a problem.  However, I also suspect that the HAM Manager may be seeing devices on this list for the first time that he/she is not aware of.
1.40	Having gone through the classifying of server roles by the HAM Manager, he and the Sam Manager and wherever possible the server owners (i.e. those folks who called for the server to be deployed in the first place)  sit down and review the server roles and assess whether they are still needed.  From here, two list are created:  Servers to be retained and Servers to be removed.
1.50	For those Servers to be retained, the CMDB is updated – highlighting what the role of the Server is, and the date of last review.  For those servers that are to be removed, the process splits out into two options – The Hardware Disposal Process (if the physical device has reached its end of life) and the Software Removal Process (if the server in question is Virtual, and needs to be removed via Systems Management means).  Equally, it could be that a decision has been taken to recycle the software on a hardware device, so an AND/OR switch is offered to exit the process.

Service/software dependencies:  Do not throw caution to the wind and arbitrarily switch or delete servers – I would always investigate dependencies of the services the server provides – is a particular server part of a wider distributed deployment of software?  Or perhaps there is a legal/regulatory requirement for a server to be sat their apparently doing nothing? Always address the business case, and consider the wider context.

Switching off Servers and seeing who complains first/loudest is not recommended!

Other Process of the Month Articles:

• Software Re-harvesting Process
• Software Change Mangement Process
• Corporate Governance Process
• Maintain a Supported Software Catalogue
• Software Rationalisation Process
• Joiners, Movers and Leavers Process
• Scope Verification Process
• Named User Verification Process

Upcoming Process of the Month Articles:

• Software Request Process
• Software Removal Process
• Process Review Process

Image Credit

The process kit by Rory Canavan is available from SAMcharter.com

Can’t find what you’re looking for?