Software Asset Management: key concepts explained

Following on from my last blog, Software Asset Management: the five elements for health, here’s a bit of a deeper dive into some of the licensing concepts and terminology mentioned.

Visibility

In my previous blog, I spoke about needing to find out which products you have. There are a few ways to do that:

• Scripts. This is Oracle’s favored method. You run them on your environments to show how many products you have and how they’re configured. You’ll need someone who knows how to do this and how to interpret the results.
• Reporting. Cloud-based and most on-premises environments provide standard reports on usage. The type of data ranges from users, responsibilities, roles and privileges through to expense reports and order lines.
• Discovery tooling. These are third party products deployed on your network to sniff out instances of software. When fully deployed, these can work effectively. But the key phrase here is when fully deployed. Each customer environment is unique, with firewalls, security issues, the need for correct credentials to interrogate instances of products, the need for products to be up to date… to name just a few of the obstacles. This method is not for the faint hearted.
• Self-declaration. Not all products in your environments are traceable. Even vendors struggle to identify some of them. In these cases, knowing who is accountable for their use is the only way to get sufficient information to track and manage them.

Paperwork

Paperwork for Oracle products usually falls into the following areas:

• Master Agreements. This could be a TOMA (Transactional Online Agreement), an OLSA (Oracle License & Services Agreement) if it’s an older document, a CSA (Cloud Service Agreement), or a document customized to your business.
  
  These are important as they set the framework for who can use the products, how and in which countries. If your organization goes through an acquisition or divestment process, this document also details what you need to do to ensure you remain compliant with Oracle.
• Order documents. These record what you ordered (the product), how much of it you ordered (the quantity), assigns a Customer Support Identifier (CSI), and records how the product is measured (the metric).
  
  These are important as they tell you what to look for in your environment and then how to audit it using the metric. The CSI is normally used for contacting Oracle support, but it’s also an important measure when you’re trying to optimize licenses. This document should also detail who is using the products—since the entity that orders a product is not necessarily the same entity that uses it.
• Support renewals. It’s policy to have all products of the same type within support (providing they aren’t end of life, which is a whole other security risk). Renewal documents prove you’re in support and list the CSI number.  If your product is neither end of life nor supported, you may already be in breach of contract.

Accountability

Accountability is a broad subject with many related tasks and it touches on both people and processes. Here is an overview of some areas it might cover:

• Purpose. Any software supporting a process must have a purpose without which something fails. Consider what breaks if you take it away. The answer is often enlightening and can result in a reduction in deployments as more efficient methods are found and legacy systems removed or migrated.
• Ownership. Whether a department or an individual, someone must take ownership of the environments where products are deployed. They approve new purchases and deployments and manage strategy and budgets. Document who this is and their responsibilities for clear reporting lines, more efficient management, and the ability to provide audit responses.
• Who maintains it. This is the person or team that looks after the system and ensure it’s up to date, backed up, improved and optimized, and who is responsible for fixing it if anything breaks. This isn’t necessarily the same person that owns the system.
• Architecture. Systems have co-dependencies and need to integrate with each other and someone needs to be accountable for this element. What they are, where they are, what relies on them, what breaks if they break… here maintaining architecture diagrams is essential.  
  
  It may also explain why something was purchased in the first place and gives you a thousand-foot view of bigger footprints like virtualization.
• Documentation repositories. Software Asset Management is a cycle that starts with identification of a business need that leads to a request and a product acquisition and then maintenance of that acquisition.
  
  Storing these requests in an easily accessible format means your business can track this cycle. This isn’t just about paperwork but relates to the origin of the request. If, for example, in 12 months’ time the system is failing to meet the business needs, clearly something went wrong. Was it the specification of the product? Is functionality lacking? Or is it about the infrastructure supporting it? These evidence trails lead you to answers that help you improve processes.

For Oracle expertise, AskInoapps

From Infrastructure to Applications, procurement to decommissioning, Inoapps has extensive experience of Oracle software asset management. We were the first partner globally to be approved for the Oracle SAM Program, which means we are vetted and trusted by Oracle to assess your on-premises estate and help you ensure your licenses match your utilization. All in preparation for an audit waiver request, made possible by the program. Download our Oracle SAM Program datasheet to find out more. 

We also provide a SaaS Subscription Service to help our customers stay on top of their Oracle Cloud deployments, and our Oracle License Optimization service is designed to ensure you maximize your Oracle investment. Find out more on our Licensing & Subscription Services web page.