Being prepared for an Oracle license audit is not easy, but proactive software asset management for Oracle can be an effective bulwark. 

For most Oracle DBAs, administrators and engineers, “software asset management” tends to be an amorphous concept from another realm. In most organizations, though, such administrators and technical personnel can, and often do, play a crucial role in effectively managing Oracle license compliance across the organization. 

While mature IT departments may have a formally defined “software asset management (SAM)” function, in my experience across companies of all sizes, formal SAM functions all too often do not formally exist. 

DBAs and applications administrators end up being relied upon to provide crucial assistance to the organization in helping with important activity around software asset management (SAM) for Oracle.

The general topic of SAM can easily consume several articles and still leave plenty to talk about. In this article, I will present a high-level overview of Oracle software asset management and Oracle license compliance. 

I will provide a general introduction to SAM and its importance, important concepts and considerations for Oracle license compliance and optimization.

What is SAM?

There are several definitions of SAM. Two popular ones are:

According to the Information Technology Infrastructure Library (ITIL), SAM is:

“Software Asset Management (SAM) is all of the infrastructure and processes necessary for the effective management, control, and protection of the software assets within an organization throughout all stages of their lifecycle.”

According to the International Association of IT Asset Managers (IAITAM), SAM is:

“The practice of integrating people, processes, and technology to allow software licenses and usage to be systematically tracked, evaluated and managed. The goal of Software Asset Management is to reduce IT expenditures, human resource overhead, and compliance risks that are inherent in owning and managing software assets”.

The key point to keep in mind is that effective SAM is a combination of people, processes, and tools. Additionally, SAM is a subset of the broader topic of IT asset management (ITAM). ITAM would include software and hardware asset management.

Before moving ahead, it’s worth noting the relationship between SAM and “software license compliance”. It’s best to think of software license compliance as a subset of SAM. When we talk about license compliance, we are essentially focusing on the aspect of reconciling usage of software licenses (the deployed quantities) against the number of licenses owned by an organization. 

From an Oracle customer’s perspective, software license compliance can be a key driver of SAM (“Are we prepared for a license audit by Oracle?”). In fact, for every client I have assisted with Oracle license management and procurement, Oracle license compliance was a key, if not primary, driver for SAM. 

Oracle shops with weak or non-existent Oracle SAM run two very material risks:

1. License non-compliance. The organization’s use of Oracle software may exceed its license grant (for example deploying Oracle Database on more processors than licensed), or may not have licenses at all (common with Oracle Database Options and Packs), or may be violating usage limitations (for example Oracle Database Standard Edition Two deployed on a server with 4 sockets.).
2. Over-spending on Oracle licenses. A common and expensive reality for most Oracle customers is having a large number of unused Oracle licenses on annual support. This happens often due to lack of planning prior to procurement or changes in business need.

Without effective Oracle SAM, the above risks can have outsized impacts on an organization. In fact, in my experience, Oracle SAM ought to be implemented with pursuit of “audit” grade certainty. The cost of Oracle non-compliance is potentially too big to be taken lightly.

It’s worth mentioning that SAM has many other crucial roles to play. For example, increasingly, SAM is playing an important role in IT security and data protection. SAM is also crucial in an era of rapid IT transformation and cloud migration. 

On that note, a common misconception these days is that cloud technologies will obviate the need for SAM. That’s far from true – we’ll save that discussion for another long article.

Who’s responsible for Oracle SAM?

Having C-level buy-in is crucial for a SAM program’s success. From there on, ideally, there should be a dedicated SAM function. Of course, the size of the environment and the overall materiality will drive this. Finally, everyone in an organization’s IT function should be well versed in at least the basic concepts of SAM.

In my experience helping companies with Oracle license management, I have had small clients where the IT manager and Oracle DBA practically managed Oracle SAM, while my Fortune 500 clients have several people dedicated for Oracle SAM alone. Unfortunately, I have also had Fortune 500 clients with no SAM function at all.

Invariably, though, I have seen Oracle DBAs and Oracle application administrators playing important roles in any Oracle asset management and Oracle license compliance, including preparedness for a formal Oracle license audit.

The Documents that define your relationship with Oracle

I will briefly discuss the important documents that govern your Oracle relationship. It’s important for the Oracle SAM practitioner to have a clear understanding of this, even if the company has a separate contracts and procurement function to handle these.

The important documents are as follows:

1. Master Agreements. Your relationship with Oracle is defined by your Oracle license agreements. These include the Oracle Master Agreement (OMA), Oracle License and Services Agreement (OLSA), Oracle Cloud Services Agreement (CSA), other Oracle agreements. These documents are contractually binding. Anything referenced by these documents, like the Processor Core Factor Table, or the Cloud metrics and service definitions, are also contractually binding.
2. Oracle Order Documents (ODs). These define the specifics of each purchase and may contain additional terms. These are also contractually binding. Along with a clear record of the license type, metrics and quantities purchased, the ODs also record the license rules as and when they were agreed upon.
3. Oracle Support Policy. This is referenced by your agreement(s) and is contractually binding. The Oracle Support Policy is a critical document as it defines important concepts like Matching Service Level, Support Repricing, Support Reinstatement and the overall Oracle Support Policy. Understanding the Oracle Support Policy is also critical because of the long-term cost impacts due to limitations on reducing support, as well as Oracle’s annual increase in their Support renewals (recurring annual Support Uplift).
4. Oracle Policies. These include the “Licensing Oracle Software in the Cloud Computing Environment Policy” and “Oracle Partitioning Policy”. These, and any other policies not referenced by your agreements, are not contractually binding. You can ignore these and should not allow Oracle Sales or LMS to bring them up in discussions and negotiations. A detailed discussion of these is beyond the scope of this article.

Diving into Oracle SAM

Now that we’ve introduced the concept and importance of Oracle SAM, let’s dive into practical considerations. To limit this article’s scope, I will focus on the technical aspect of Oracle SAM and minimize discussions around organization and procedures. I will split the discussion across Oracle Database, Middleware, and Oracle Applications. I will then go over SAM tools for Oracle asset management.

A general concept to keep in mind is that Oracle SAM has two important components:

1. Discovery. As the name suggests, discovery involves identifying the presence of the Oracle program components. It’s worth remembering that generally, the mere presence of Oracle software requires licensing, irrespective of whether it’s actually being used – or even powered on. Some organizations use SAM tools to detect the presence of Oracle programs; other use spreadsheets to track what Oracle software is installed on which server. That’s right – spreadsheets! It is an inadvisable reality.
2. Measurement. Almost universally, merely detecting or discovering Oracle software on a server is insufficient for assessing the full licensing requirement. Additional measurement steps are typically needed. For example, Oracle Database Enterprise Edition may be installed on a server, but additional measurement steps will be needed to identify usage of Options and Management Packs like Diagnostics and Tuning. Similarly, Siebel may be installed on a server, but detailed, multistep measurement is needed to correctly map the users to their licensable modules.

Oracle SAM practitioners that rely on discovery alone, and do not perform the appropriate measurement steps assume a significant risk of having an incorrect and incomplete picture of their Oracle licensing requirement. This leads to a license compliance risk for typical Oracle customers. 

For Oracle ULA customers, this poses a significant risk of lost value and ULA underperformance, followed by license compliance gaps once the ULA is over. For customers planning a transformation, like moving to the cloud, an incomplete SAM picture can adversely impact the benefits to be gained from moving to the cloud.

SAM Considerations for the “Processor” Licensing Metric

One of the most basic measurements relates to gathering necessary server model and CPU model details for programs with “Processor” metric licensing. Of course, this gets more involved when we are talking about measuring CPU requirements in cloud environments or partitioned environments like VMware, IBM LPARs, Nutanix, etc. 

The intersection with hardware asset management is inevitable. We have covered Oracle license compliance in cloud environments in a different series of articles.

SAM Considerations for User-Based Licensing Metrics

For metrics like Named User Plus and Application User, the full user population accessing the Oracle programs needs to be accounted for. It’s important to keep in mind Oracle’s “multiplexing frontend” concept here. This has contractual implications. 

In short, Oracle licensing rules state that for user-based licensing, the full “frontend” user population needs to be included. 

For example, suppose we have an Oracle Database supporting a customer web portal. If the Database is licensed by “Processor”, the licensing requirement is simply based on the number and model of CPUs the Database is running on. 

However, if this deployment were to be licensed by Named User Plus, then the entire population of “frontend” users at the portal will need to be counting, even if the portal web application is using a single ID to connect to the Oracle Database.

Oracle Database, Options and Management Packs

For most organizations, Oracle Database, in its various editions, tends to have the highest materiality and overall financial importance. Complicating Oracle Database SAM is the fact that many valuable and pervasively used Options and Management Packs ship with the product and monitoring and detecting usage is not always easy. 

In fact, it’s possible for customers to use Diagnostics Pack, which requires Oracle Database Enterprise Edition, on an Oracle Standard Edition installation.

A useful and low-cost starting point is looking at Oracle Database Feature Usage Statistics. This is done by querying the dba_feature_usage_statistics view. Note that while this gives some good insight, it’s not definitive. 

Oracle’s own audit script, developed by their License Management Services (LMS), looks at this view, but looks at several other views as part of the audit process. Also, while a feature may not be in use currently, and show up as such, it may have been used in the past. This too should be monitored as it will trigger licensing requirement as well. 

Additionally, it’s important to keep in mind that feature usage needs to be mapped to the licensable product. For example, the AWR report feature needs to be mapped correctly to Diagnostics Pack. Where possible DBAs should consider disabling features that can be disabled using the chopt utility (though this is limited in availability).

Another tool available to DBAs is using Oracle Enterprise Manager to augment tracking and monitoring. They may also use it to limit Management Pack access to users, along with helping with discovery of databases in the first place.

A common pitfall for Oracle SE, SE1, and SE2 customers is violating the socket limitations. Unfortunately, there is no easy fix for this other than coordinating SAM with hardware asset management and ensuring the hardware limitations are respected. 

Sometimes, it’s the IT infrastructure team that manages the hardware provisioning, and/or provisioning of the virtualized environment. It’s very easy to overlook socket limitations or inadvertently not consider the CPU and server tracking needed for Database Enterprise Edition. This problem is common and is not limited to Database alone.

Oracle Middleware Programs

Oracle’s Middleware stack includes many programs like WebLogic, SOA Suite, Identity Management, Business Intelligence, and Coherence, among others. 

The calculations for the predominant metrics, “Processor” and “Named User Plus”, are as describe above for Database. This includes accounting for “frontend” user populations for user-based licensing. 

As in Database, careful measurement is a necessary corollary to discovery. An added wrinkle among Middleware programs is bundling, included components, and Suites. More on this shortly.

Some Middleware programs have identical downloads and installation for the different editions. The licensing requirement can vary depending on the features used. Therefore, correct measurement is crucial. WebLogic is an excellent example of this. The download package for WebLogic Standard Edition and WebLogic Enterprise Edition is identical. 

As is the installation process. What differentiates between the two is the usage of WebLogic features. Notoriously, customers miss the fact that the clustering feature in WebLogic requires Enterprise Edition licensing. Access to and use of the feature is unrestricted. 

It’s common for WebLogic Standard Edition customers to configure it for high availability and use the clustering feature – thus triggering licensing requirement for WebLogic Enterprise Edition. 

For the Oracle SAM practitioner, detecting this is difficult but financially crucial, owing to the significant pricing gap between WebLogic Standard Edition and WebLogic Enterprise Edition. 

In this example, use of this feature needs to be either confirmed through inquiry with the administrators and/or through methodical analysis of the installation configuration files that would indicate use of the clustering feature.

Clearly, it’s very easy to miss this. I have yet to have a client that has navigated WebLogic asset management without trouble. This is just one example of why measurement is important for Oracle Middleware programs.

The other challenge around Middleware programs is their tendency to bundle different licensable features in different product offerings. 

For example, Oracle Access Manager is a standalone, licensable program. However, Access Manager is also bundled with several other programs as either a full use component of restricted use component. These include Identity and Access Management Suite, WebCenter Portal, and others. 

If an Oracle SAM practitioner discovers Access Manager on a machine, should she assess it to need licensing for “Access Manager”, “Identity and Access Management Suite”, “WebCenter Portal”, or something else? What would be the most efficient and beneficial way of counting this for the organization? 

There are several other challenges to effective Oracle SAM for Oracle Middleware programs which are beyond the scope of this article. The key point is that while technical tools may help with discovery of Oracle programs, the human involvement in aligning the license allocations is crucial.

Oracle Applications

For most companies, popular Oracle applications include E-Business Suite, PeopleSoft, Hyperion, Siebel and JD Edwards. Given the importance of application deployments, they tend to be very visible and well known. 

In other words, the likelihood of an Oracle SAM expert being uninformed of the existence of a JDE or PeopleSoft deployment is low – discovery of Oracle Applications is typically reliably done. However, accurate measurement is crucial, with unique complicating factors making that difficult.

Complex Licensing Metrics

The variety of licensing metrics can be confusing, making Oracle license compliance complicated. There are user-based metrics, metrics based on company revenue, the number of transactions, and so on. It’s crucial for the Oracle SAM expert to understand the Oracle contracts well. User-based licensing is the most common. 

In some cases, user reports can be generated easily, for example in Hyperion systems. In others, like Siebel, the user report is only a first step before a complex set of analyses to accurate determine the user licensing requirement. 

In short, you need to map Siebel users to their respective responsibilities, then map their responsibilities to the corresponding application views, and then map the views to the licensable Siebel module. Along they way, you need to resolve duplicate mappings and custom views. 

Seems simple, right? Navigating this carefully during an Oracle license audit can be difficult but crucial in obtaining a favorable outcome.

Module Access and Licensing

There is often module or functionality related licensing. Determining which users have access to which modules and functionalities can be difficult but is crucial for effective Oracle SAM. 

Continuing with the Siebel example, some users may have access to Order Management module, some to Asset Management, while several may have access to both. Unfortunately, it’s very common for Siebel administrators to over-provision module access for convenience. 

It’s common to end up with users having access to many modules they don’t really need. These will require the corresponding Siebel module licenses nonetheless. It’s worth mentioning that in Oracle, a user merely having access to a module or feature will triggering the licensing requirement – irrespective of whether they have ever touched the feature.

Bundled Database and Middleware Risks

Oracle Database and Middleware that are typically included with the Applications products can cause serious compliance problems. 

For example, E-Business Suite includes usage rights for Oracle Database Enterprise Edition and WebLogic Server. However, any modifications to applications beyond very basic design will trigger full licensing requirement for the Database Enterprise Edition and WebLogic Enterprise Edition. 

Few customers understand this, and too many are caught by surprise when the Oracle license auditors quote them a large compliance finding due to this. I am not aware of any convenient, automated way of monitoring this. 

The Oracle SAM practitioner must inquire with the EBS administrators, run the necessary queries and correctly analyze outputs to correctly determine licensing requirement for EBS, its modules, and the underlying Oracle Database and Middleware, if needed.

Software Asset Management Tools

A crucial component of any SAM endeavor is the correct selection and deployment of SAM tools. Typically, these tools cover SAM for many vendors, with varying degrees of quality and coverage across the different software vendors. The leading SAM tools commonly cover software from Microsoft, IBM, Oracle, and a host of other vendors.

Some of the popular SAM solutions currently include:

• Snow Software
• Flexera
• ServiceNow
• BMC
• Microsoft SCCM
• Eracent
• Aspera
• Certero
• Micro Focus/HPE UD
• Many others. 

Some of the SAM tools like Snow Software and Flexera can perform comprehensive, detailed Oracle Database measurement that covers Options and Packs. Some are capable to identifying Enterprise Edition feature usage in WebLogic as well. A comprehensive discussion around the capabilities is beyond the scope for now. 

That said, it’s important to note that I am not aware of any SAM tools that can outright perform full Oracle SAM assessment. Extensive involvement by Oracle SAM experts is always needed, especially when talking about Oracle licensing rules – which none of the tools can apply. SAM for Oracle Applications is also inadequately covered.

Finally, it’s important to note that SAM tools are just one component of effective software asset management. And their success depends more on correct deployment than on the bells and whistles and fancy dashboards many include.

Whether it’s managing deployment quantities, optimizing license usage, or assisting with license audit data gathering, the involvement of Oracle technical personnel is always key. 

Even in organizations without formal SAM functions, technical members who are well trained and informed in Oracle SAM and licensing can, and often do, play a crucial role in helping a company to effectively handle Oracle license compliance, maximize its return on Oracle investment, and be prepared for an Oracle license audit.