Australian Software Asset Management Association




Software Asset Management Product Life Cycle



The requirements for managing software products as part of the Software Asset Management (SAM) lifecycle can be defined into a number of complex and intertwined issues. The approach and the timing of the required actions to address these issues will depend on dependencies on other actions being completed or commenced; thereby some actions need to be executed in a pre-defined order, whilst other actions should run in parallel with others. Some issues or parts of issues may well be managed or decided upon by other areas within your organisation, if this occurs there is extra emphasis on your communication and coordination skills in keeping all of the lifecycle categories aligned.

Software should be procured based on a business requirement. Often in IT we have people aligned to technologies and their consideration of available software products is limited to a vendor or a small subset of vendors. The reason for this is that due to the highly specialised nature of IT, people learn a particular technology platform and a range of similar technologies and in the majority remain with these technologies. At times some people can forget who they are employed by, this is noticeable when they undertake actions on behalf of vendors, which they should not be doing. The vendors also seek out the people aligned to their technologies, to push forward the vendors argument on why their product should be purchased over another vendors product. As a Software Asset Management professional you should have no such alignment to any vendor, your role is to be totally independent and to represent your organisation to the best of your ability.

Architects, application and infrastructure solution designers should be seeking advice on the  software licensing costs, over the software lifecycle. Virtualisation solutions have become one of the major issues facing software licensing in cost and compliance management. Too often architects, application and infrastructure solution designers seem to be in total denial of the costs of software in a virtualised environment. They continue to have the simplistic view that it’s cheaper because less hardware is required, without considering the software cost. Hardware in itself has very low margins and is these days assigned as a commodity item. The flow-on cost reductions in computer rooms floor space, utility costs and operations that is usually attributed to virtualisation, could also be achieved if architects, application and infrastructure solution designers, co-hosted systems rather than run them independently. Unless the IT department in your organisation is a highly well tuned machine where the architects, application and infrastructure solution designers do seek the guidance of the costs of software licensing over the software lifecycle, you will have to be pro-active to implement the necessary policies, processes and procedures for Software Asset Management.

You should undertake a scan of your IT Department and understand what are the processes and procedures that already exist for the architects, application and infrastructure solution designers, your purpose should be to imbed software licensing as one of the key decision items in their considerations. The use of policy will always corral the people that do not want to involve software licensing in the decision making process.

In imbedding software licensing requirements into policy, process and procedures, your role is to provide information that includes the costs, the terms and conditions of the licence and the possible licensing models for the various options under consideration. One of the main goals of a software asset management team should be to continually attempt to achieve product standardisation.  Any reduction in; complexity, the number of licensing models, the number of vendors and variations in the terms and conditions will improve the Software Asset Management capability in your organisation.

Software that is required for projects should have funds identified in the project.  Good project managers will have these software costs included in the projects budget. Unfortunately there are many bad project managers that would not have done this and the most dangerous ones of all, are the project managers that have not provided the full costs of the projects, in order to gain business signoff at project initiation stage. Usually when software funding hasn't been budgeted for, there is an attempt by some project managers to shift the issue to you. The ownership of these funding issues remain with the project manager, they do not belong to software asset management team.

The software asset management team role of providing costs, licensing models and the terms and conditions for the various options under consideration, also includes the responsibility that the software asset management team actually have the capability to undertake this advisory role. It is extremely important that your team does not fail at this point; otherwise the whole Software Asset Management program could be placed at risk through non-performance. If your team is not at this level of capability then you should be considering how can the skills, knowledge and experience be acquired quickly. Usually a short term and long term approach is undertaken. In the short term external people who have the required skills, knowledge and experience are bought into the organisation to quickly provide the required capability. The longer term approach is to use these external people to provide knowledge transfer to the existing organisation staff over a period of time. This will enable the organisations staff to be self-sufficient and to provide the required capability to the organisation. 

When the architecture has been determined but the solution design is reliant on industry proposals, this is an advantageous position to be in. With vendors competing against each other, the use of market tenders can place your organisation in a good negotiation position. Whether these market approaches are very broad or limited to just a few vendors, your bargaining power on the terms and conditions, and the cost of licences is greatly enhanced.

One of the conditions for purchase that you place on the vendor is the responsibility that the vendor provides the products identification signatures for your software asset management tool and/or the management processes and procedures that their software requires to ensure effective compliance management. These management processes and procedures cannot be burdensome on your software asset management team and if they appear they would be, then different arrangements should be negotiated. You do not want to expose your organisation to a high risk, if the software cannot be managed that ensures compliance to the licensing terms and conditions.

Usually software licensing is purchased with maintenance and support costs each year, which usually ranges from 18% to 24% of the licence purchase cost. This payment entitles your organisation to version upgrades and support for the software product. The issue your software asset management team will need to manage throughout the software lifecycle is the licensing requirements for the version upgrades. The yearly cost of maintenance and support should have been identified in the budget, therefore this should be a straight forwarded payment process. The terms and conditions of the EULA, which can change between software versions, needs to be closely managed. Prior to implementing a version upgrade, a review of the EULA that applies to the new software version being implemented needs to be undertaken. The whole process of review and follow-on actions from the review can take quite some time to complete, as you will find that you are either negotiating with the vendor on changes to the EULA or a change in the management approach of the software. In order to give your software asset management team the time it needs to undertake its various roles, you will need to be well aware of the work plan for the infrastructure and application teams to identify software version upgrade plans. For software licensing that was purchased without maintenance and support, this introduces additional management responsibilities for your software asset management team, as they now need to manage multiple versions of software, that usually means multiple versions of software EULA’s. If you have software without maintenance and support, then your organisation does not have the rights to upgrade that software to a later version to the original purchased version.

There are many changes to a software product during its lifecycle. Most products will be affected by a vendors decision to rename a software product, bundling a software product with other software products, breaking the software products into parts and creating new software products and retiring the software product. All of these changes need to be managed by your software asset management team. The key issues that need to be managed are software licence entitlements, terms and conditions, software packaging and record keeping.

At a minimum your organisations software licence entitlements should allow you to continue to use the software in its renamed state. Whether the vendor bundled the software with other software or broke it down to a range of new products is immaterial. Access to the software to continue to use the capability that it was originally purchased for, is a right you should not give up. Prior to purchasing the software, you should have negotiated the right to access the software capability even if its been re-bundled or broken down into several new software products. If this wasn't previously negotiated, you can still negotiate with the vendor after you have bought the software, its just more difficult to do so. The vendor will make an argument that this is not possible, the new features go well beyond what you paid for and other similar statements, however it’s not your problem that the vendor has undertaken these actions with the software products you have software licensing entitlement to. The issue remains with the vendor.

Another issue that arises from the preceding paragraph is changes to the EULA terms and conditions. Unless your organisation is upgrading the software version, you do not have to accept a new EULA from the software vendor. Stand your ground as outlined in the previous paragraph. The new EULA's terms and conditions is the vendors issue. Compliance is also affected by the changes to the vendors software product. This issue should be raised with the vendor on how they are going to ensure that you remain compliant with the new software changes. This could lead to renegotiation on the vendor providing access to the full software bundle in order to access the existing licensed capability or in the vendor having to supply the software product that your organisation has entitlement, in an unbundled state.

When changes have been made with software products, this usually means that the distribution of the software has changed, particularly with software products that are now bundled with other software products. If your negotiations with the vendor have not resulted in you having entitlement with the full bundle of products, then this may cause a compliance risk. The risk is if the new software bundle is installed for the purposes of using the existing software, the IT staff start to use the rest of the bundled software capability, that your organisation is not licensed for.

Record keeping of all the changes is an extremely important action to undertake. All correspondence with the vendor, including meeting notes should be captured and stored on your organisations record management system. These records will become quite valuable if there is ever a future disagreement between the vendor and your organisation on software entitlements and the associated terms and conditions. Changes to the software products discussed above need to be mapped within your software asset management tool or your software entitlements register to ensure the day to day management of this software can continue and there is a full line of sight of the software since it was first purchased and implemented into your IT environment.

Service management is an important control mechanism for the deployment of software to the approved solution design. A mature service management function in the IT Operations will make the life of the software asset management team just that little bit easier. Most organisations based their service management capability on the ITIL framework. Whilst this framework is only part of the overall requirement for a successful Software Asset Management program, none-the-less it is an important part of Software Asset Management.  

Software received from a vendor should go through a standard process of being checked for malicious code, accepted into inventory, assigned to an owner, the software asset management tool configured and all the accompanied paperwork filed, where it can be retrieved at a latter date. The use of the corporate record management system is important, so that the required reocrds can be found by other authorised people in your organisation. Some records potentially could be required for more than 10 years. During such a long time period it is quite likely that the person who managed the software receipt from the vendor has left the organisation, moved to another role or would not be able to recall by memory any necessary details of the software receipt process. A robust, standardised and repeatable process on software receipting will address these shortfalls over an extended period.

It is quite common that  a software library is available to store and catalog the software. Usually software is downloaded from the vendors web site, however some vendors will still supply software on DVD media. Due to cyber security precautions, software should be checked and tested for malicious code. If the software is found to contain malicious code, the contract with the vendor should include liability clauses against the vendor, to address this situation.

As the software is being deployed into the environment, the software asset management tool should be used to verify the deployment. If the licence model cannot be monitored by the software asset management tool, then processes need to be implemented to make up for this capability shortfall. Either the software asset management tool or the new procedures and/or a combination of both are required to manage the software whilst it is installed in the environment.

All software has a finite useful life and it will need to be removed from the environment when it is no longer contributing to achieving the organisations outcomes. There may be a requirement to write down the software from the financial books. The contract or licence agreement will need to be analysed to determine if any special conditions exist when the software is no longer required. All records that have been acquired during the life of the software need to be centralised and filed for possible use in the future.

The requirements for managing software products as part of the Software Asset Management lifecycle are quite complex, ever changing and need to be undertaken over many years, whilst ever the software is installed in your IT environment. This article has touched on some of the issues that need consideration and what actions need to be undertaken. The requirements for effectively managing the complexity and the depth of issues that these actions will encounter, are not addressed here. The information that addresses these types of requirements will be included in the topic specific articles and in-depth insights articles.  

(IE Printing: - There are known IE printing problems that affect certain printer brands and printer types; Chrome and Firefox have no reported issues.)