Take Your SAM To The Next Level By Implementing A Supported Software Catalogue!
Never fear! I will not be writing all the blogs on this website, it’s just that Kylie has done most of the work to get this site set up so I have to do something to justify my existence!
We’ll shortly be kicking off The Supported Software Catalogue Practicum (I can’t tell you how much fun we had finding the word “Practicum”) but before then, I thought it would be useful to highlight 10 observations to consider when looking to construct your Supported Software Catalogue.
- Understand the role of a Supported Software Catalogue: catalogue establishes the boundary of your SAM scope but at a software-title level. Not only is this the software that SAM says it will manage, it is also the list of software that the business says it needs to run the business.
- You will not own the Supported Software Catalogue: As a SAM professional, you will be considered a contributor as other staff within IT will have a greater call on the data within an SSC than SAM.
- Use-cases, and why they are important: Everything has a lifecycle, and the SSC lifecycle needs modelling so that use-cases can help identify when data is created, modified, read and ultimately deleted.
- Deconstruct your use-cases: Having modelled the use-cases, acknowledge which processes comprise those use cases, and which engage with the SSC lifecycle
- Know your data/ data owners: Having fleshed out which elements of data are required in your SSC through the use-cases and processes you have crafted; it will quickly become apparent that not all SSC data resides in a SAM Suite.
- Know your systems/ system owners: You’ll rapidly find that your SSC is a composite of data elements that are stored elsewhere – so your SSC is not a golden source. This means that maintaining the accuracy of your SSC data involves integrating data stored in systems/ databases etc, that require specific permissions to retrieve it.
- Know where you’re storing your SSC: An obvious choice might well be your SAM suite, particularly if you are sticking to the ‘keep it simple’ principle and have just a few lifecycle status (eg approved / unapproved). However, what these tables don’t often account for are those custom fields that need to address non-SAM use-cases (see #3, above). It’s more likely your SSC will form part of your CMDB.
- Your SSC should be fluid: Change is the enemy, and so with the novelty of products that get produced in the software space, building in that degree of flexibility to add, promote, relegate or even archive software titles should mean that an SSC team needs to be one step ahead of the change curve.
- Don’t forget about “views: If your SSC is supporting your request process, then user-defined roles could influence which titles are presented to which members of staff: do end users really need to be seeing Oracle Enterprise Edition as a request option?
- Review your SSC: Take the time to periodically review your SSC for sprawling versions and editions of software; and also, software by classification: just how many variants of a Linux OS does your company need? How many databases? The greater the selection, the greater the complexity of your estate, with all of the disadvantages this brings.
I hope the points above have given you a start on what to think about around creating and maintaining a Supported Software Catalogue, and that we will see you on our inaugural course starting on 4th Nov.
