Using SAM Tools for Oracle Licensing — Introduction: Entitlement

Photo by Wesley Tingey on Unsplash

When working closely with clients on optimising their Oracle license estate, we are often asked for our view on software asset management (SAM) tools for managing license compliance.

• Firstly, as a technology-agnostic provider and independent license consultants, we would never endorse a particular tools vendor.
• Secondly, and perhaps more importantly, if you are considering buying a SAM tool to manage your Oracle license estate, we would always encourage vigilance. Why? Read on.

SAM tools often claim to simplify Oracle license management with the promise of reduced administration and seemingly helpful graphs and charts displaying your compliance position. In reality, using a single tool to manage your Oracle software estate’s compliance is typically unattainable and unrealistic.

With that being said, SAM tools do have their uses: it’s important to be aware of those and their limitations before investing in one. This post will compare the manual license management process focussing on entitlement vs using a tool and highlight the areas where tools have limited capability.

Part II of this blog (“Usage (Discovery)”) is available here

Managing your Oracle license estate without a tool

There are a number of elements to consider for managing licensing; it’s best to consider what you’d do without a tool first:

• Entitlement — this includes the manual collation of entitlement, gathering all relevant order documentation, determining what licenses you have and collating all this information into one central location such as a spreadsheet. This is what we are looking at in this post.
• Server Usage — for example, the Oracle Server Worksheets style view of overall server deployment and licenses required for each.
• Manual interrogation — this may involve running a script (consideration needs to be given to which scripts): this can be quite a time-consuming task!
• Process Script Output — How do you read and interpret what the script output is saying? Sometimes hundreds of thousands of lines of output are produced and need processing?
• Apply Oracle Policies — Once you have the script output combined with your server usage information, you need to then apply relevant Oracle policies to the data, this will include applying core factors and working out processor amounts so that you can turn the data into license requirements.
• Storage of data — Where do you collect this? Almost always a big spreadsheet!

Very simplistically, ultimately, you need to have a view of your entitlement minus your usage giving you your license position. Drilling down a bit more into usage, which can be broken down into ‘discovered data’ (by running scripts) and the application of rules to that data to constitute license usage.

Focussing on entitlement; this is detailed in several different documents as follows:

• Entitlement — detailed in your ordering document, which contains your legal terms and conditions, product metrics, quantities, full/restricted usage etc.
• Order specific terms and conditions — such as customer name and definition, territory (where the licenses can be used) and any restrictions on use etc.
• OLSA/OMA Documentation — overarching principles which must be adhered to and are part of your contract(s).
• Amendments — updates to your original documentation as your business evolved over the years.
• Assignments — details of license re-assignments between businesses or business name changes.
• Certifications — for Oracle ULA or Pool of Funds contracts.
• Annual support renewals — bill for the annual support and maintenance of Oracle software.

Generally, when trying to establish entitlement, clients focus on the annual renewals; rather than ordering documents. Which, as illustrated above, excludes important metrics, amendments and terms.

Excluding elements of your contractual terms can impact the accuracy of your entitlement view, possibly creating a risk of undiscovered license non-compliance.

Using a Tool for Gathering Entitlement

• Documentation — Use the original ordering document. Do not rely on your renewals documentation alone for the reason mentioned above.
• Data Input — Be very careful about the data that you enter into the tool. How the data is captured, modelled and transcribed by the tool is critical. Depending on the tool’s provider, they may provide resource to do this for you. If the tools vendor is going to do this for you, then make sure you provide them with as much information as possible to ensure data accuracy. Finally, ensure that a QA process is undertaken by someone familiar with your contracts and the tool to verify accuracy.
• Terms and Conditions — make sure that the full terms and conditions are captured within the tool so that these can be easily played back for future inquiry, for example, understanding why there is a particular restriction and where this has originated. It is also crucial to understand which original paperwork underpins a particular piece of data within the tool. It’s important to be able to go back to the original paperwork to validate what you can and can’t do with a particular license. In the absence of original paperwork, reasonable assumptions will need to be applied and make sure that assumptions are marked as such and that any compliance calculation is considered in conjunction with these assumptions.
• Be Careful! — Entitlement information can still be very complex, even if it’s just for one product. Be careful not to make the mistake of thinking that your estate is simple.

Contracts are complex; tools often over-simplify them. If you are thinking of buying a tool, ensure that you receive a demonstration of the tool’s capabilities to prove whether it’s going to work for your software estate.

The next step at this point would be usage detection. An important consideration is how does a tool know what to measure? Without understanding your entitlement and metrics, there is no point in measuring the usage. This will be covered in detail in my next post.

Manual v Tools for Entitlement

So, if we wanted to use a tool for entitlement, we need to keep in mind the following:

• You will still need manual collation of entitlement — a tool won’t do this for you.
• Entitlement can be very hard, if not impossible to accurately model in a tool — you will need to maintain this manually and verify its accuracy. You may need to consider modelling your business entity hierarchy accurately in your tool.
• You should seek a QA review from another knowledgeable individual.
• Assumptions used should be captured and highlighted whenever a view of compliance is considered.

Conclusions

1. A tool could work well for you if you have a small estate, with minimal metrics and a good view of contracts. Make sure you have a thorough review of the data and its representation in the tool.

2. Ensure you know your entitlement, the critical terms and how to model it and your business in the tool.

3. Validate tool vendor claims with a thorough demonstration and trial: challenge the vendor on their knowledge and their proposal on how to model your entitlement.

4. Question the content and QA your tool's data output.

5. Never assume a tool will fix all your software license problems: it won’t.

Our recommendation (for entitlement and usage) would be to make use of the best features of a tool whilst fully being aware of the limitations at all times.

Now we’ve discussed entitlement, we now need to consider how a tool can discover data relevant to Oracle licensing. See my next blog post “Using SAM Tools for Oracle Licensing Part II — Usage (Discovery)” here

As Oracle license experts, we have a deep understanding of Oracle license considerations and cost optimisation opportunities covering a broad range of technology platforms and are happy to help with any Oracle license queries you may have.

For more information, watch my webinar on SAM Tools for Oracle, go to our website or contact us with any questions.

About the Author:
Paul Bullen is Principal License Consultant here at Version 1.