Branimir Valentic Recently, I was taking part in a panel discussion dedicated to Software Asset Management (SAM). A few facts came out as certain: it’s a hot topic, everyone has requirements towards SAM (or is already working on it), and very few people know how to approach SAM in real life. I gave an example of how ITIL could be used for SAM and, I have to admit, I was surprised with the positive feedback. Later on, while resuming my impressions from the event, I was happy that my thesis (which was the foundation for my presence at the event) that ITIL can significantly contribute to the SAM – was correct.
To become familiar with SAM, and to act as an introduction, refer to Part I of this blog post, “ITIL and Service Asset Management Part I – Growing Importance”. In this second part of the blog post I will go through the service lifecycle (remember – Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement), pointing out some processes and the way they influence SAM.
Service Strategy
Financial Management process – each of three aspects of Financial Management (Budgeting, Accounting and Charging) contribute actively to SAM. Budgeting ensures that funds needed to procure and maintain application assets are available. Accounting gives the foundation for charging, which will ensure that the organization can collect the money needed to survive. IT management (e.g., CIO) will be interested to know the costs of applications licenses that are used, how the costs are distributed, etc.
Service Design
Information Security Management process – contemporary IT services contain applications of many different origins. Without managing information security at a high level, it’s a question of time (I would rather say, minutes) until a security breach happens. Therefore, procurement and usage of applications must be considered in the information security policy, the controls that are implemented, and related processes (e.g., Access Management). For example, the Information Security Policy can define:
- only software from trusted resources can be implemented (to avoid suspicious software distributed as freeware)
- users can’t install software themselves (they should send a Service Request to the Service Desk)
- security mechanisms built into the application must be activated (e.g., to prevent developers from installing a database without a password)
Supplier Management process – this process manages suppliers and ensures that we get what we paid for. To manage procurement of applications that are implemented in the scope of our services means that we know what are we paying for, how much, and to whom. This gives us the possibility to negotiate price or other options, such as maintenance. We have to make sure that conditions that are agreed and guaranteed in the Underpinning Contract (or Service Level Agreement) are met. In such a way we can guarantee a certain level of service for our customers who are using that application.
Service Transition
Change Management process – this process manages changes throughout their lifecycle to prevent unauthorized changes. Applied to SAM, by applying Change Management we will ensure that only authorized copies of software are implemented. This will help us to manage information security (remember, unauthorized software can include software that contains malicious code, e.g., spyware or malware) and legal compliance (usage of illegal software has financial consequences, as well).
Service Asset and Configuration Management process (SACM) – SAM is, basically, part of the SACM process because applications are service assets and SACM manages all service assets. SACM will identify and manage all software assets. This means that the SACM policy will define software as an asset, how it should be identified, and how it should be managed once it is recorded. Usually, I see that organizations are using tools for such purposes.
Service Operations
Request Fulfillment (RF) process – this process will help to manage requests regarding software assets. In practice, only a valid Service Request (which is handled by the Request Fulfillment process) can be used to require software. Additionally, RF defines process, i.e., activities, to fulfill the Service Request. An important step is authorization, meaning that software procurement can’t take place before management (who is usually responsible for funding, i.e., budget) approves it.
Application Management function – this function is the custodian of the application knowledge inside the organization and is active in all parts of the application’s lifecycle. This will enable management of software assets, as well as helping to decide “make or buy” when we consider new functionalities (i.e., are we going to develop a new application by ourselves, or we are going to buy an existing one on the market?).
Continual Service Improvement
By having Continual Service Improvement (CSI) in place, we have an opportunity to measure and improve. In such a way we are an organization that learns and avoids mistakes made previously. For example, if we develop our own software and have CSI in place, this will ensure that experience gained once the software is operational is always “transferred” or built into new developments. Or vice-versa, mistakes in existing software will not be implemented in new developments.
Negligence could be painful
Software is an important service asset. When neglected (no matter in which phase of the lifecycle), that could hurt – functionally, legally, or financially. And it’s hard to pick the least or most important reason to implement SAM. Knowledge and experience that ITIL provides shrinks the space for excuses when applying SAM.
Download here a free sample of the Service Asset and Configuration Management Process.
