Not having a software policy could spell disaster as falling foul of licensing rules can bite hard. Our client had an idea about it, but no sound policy.
Investigate the situation regarding software, and create a policy which covers all the different types.
The place to start with this task was to look at the software library. It was comprehensive, but badly managed. Different naming conventions, the same software listed multiple times, no version control, and a difficult process to get software imported.
We began with sorting out the processes for importing software. It was long-winded and difficult to track. The software management team got too involved with the process, but none of the management. The library needed a refresh and additional attributes adding to give greater guidance.
The first part of the policy would direct the integration of deployment and the library. If software was deployed, then this should be reflected in the library. It doesn’t matter where, but knowing it is in the environment somewhere is key to controlling duplication and proliferation.
The second part refers to version control. Having multiple version in the library is useful, but unhelpful. Teams can select any version, even unsupported ones. The policy directed towards using the latest version available from the vendor, and if this happens to be in the library, then they are good to go. If not, the latest version must be imported and put in the library.
Next, we looked at the support side of software use. No software must be used which is over three years old. As a system ages, it must be kept up to date. Cloud-based systems are straight forward to update (build a new image, test, and deploy using auto-scaling for example) but on-premises takes more effort. However, this effort has to be expended to keep up with patching.
The policy also had to include how the library will drop off software which is two major versions behind. Any software flagged as deployed, will trigger an Epic to create work to weed it out of the environment, and updated to the latest version.
The major message of the policy was no system should be on old software. There are circumstances where this might happen, but these are rare.
One area of concern was the licensing issue. The client had good monitoring systems that can deliver inventory of software, but in many cases there was massive under and over reporting of software. This is where we needed to make someone responsible for keeping the licensing up to date. The Product Owners were given this responsibility as part of their job description. Twice a year they were required to update the number of licenses against each of the software under their control.
We looked at the different software types: COTS, GOTS, Open Source, FLOSS, and so on. In sensitive areas, Open Source software needed additional checks, and if there is a lot of development going on in risky locations, they can’t be used. We developed a simple set of checks that would determine the acceptability of using software.
To get a piece of software into the library, the policy directed the use of checking suitability such as ability to integrate with assistance tools, adherence to WCAG standards, and suitable user configuration.
Once in the library, the software management team were given a greater role. The library was to be kept more up to date. Each quarter, the library is updated and vendors contacted to see if new versions are available. This would bring the latest versions into the library, making it easier for support teams to perform updates.
Finally, the process for renewing annual licences was created. This was included in the policy to ensure developers using this type of software can be sure their system will continue to function beyond the project’s end.
The library can be used as a trusted source, and will have the latest software available for deployment.
The whole organisation now knew where it stood when it comes to software.
With the import processed made simpler, it gave rise to more efficiency. Removing the software management team from the selection process allowed them to concentrate on keeping the library up to date.
Coupling the library with the asset systems and Product Owners, enabled the software team to keep a more accurate track of the licenses in use
More control over the licensing, saving money, and renewing licenses for systems which actually have the software involved.
By having a policy which has a country black list, means there is less risky software in the library.
Any software in the library can be pulled and deployed quicker and with less fuss and unnecessary involvement.