The challenge of SAP license management

The discussion around indirect use is neither a new nor an SAP-specific topic. From the definition of use from SAP's GTC (see box on page 47), it is clear that not only the users of third-party applications have to be licensed, but that additional rights of use may have to be acquired for the application communicating with SAP.

Indirect use - not an SAP specific feature

If we go one step further, the definition of use can be interpreted to mean that no fundamental distinction is made between direct and indirect use. As already indicated, the tracking of indirect (indirect) use must be considered in more detail, and not only in the case of SAP.

This issue existed more than a decade ago: Microsoft, IBM, Oracle and other vendors have been pursuing this for some time. Among Microsoft customers, for example, the situation is known as multiplexing: a process that uses hardware and software to pool connections to software, redirect information, or reduce the number of devices or users accessing it directly.

Questions in this regard are also repeatedly the subject of software audits. In order to reliably address the issue for SAP licensing, one must also distinguish between a pure and simple license violation and an increased licensing requirement due to indirect use.

Indications such as multiple logons of a user could possibly point to indirect use if a user's account has an extremely large number of parallel accesses, since it would then be possible to draw conclusions about automated accesses.

For example, the account of a software developer working for the company in question could be used not only for the developer, but also for all customers of the web store programmed by the developer, which accesses SAP functionalities.

The same example could arise from the fact that the user can be shown to have a high workload or continuous use (24/7). Or the measurement gives indications about the corresponding cross-component usage. All of these are not necessarily 100 percent valid, but at least possible indications to give reason for a deeper analysis of the connections and usage.

Of course, in case of multiple logons, high workload or long working hours, it could also be a "simple" license violation, i.e. sharing the account or a technical user was mistakenly classified as e.g. a dialog user.

Indirect use can be caused as follows: A user (licensed or unlicensed) accesses SAP functionalities or the information stored in the SAP environment via a non-SAP third-party application, for example.

The upstream non-SAP system thus provides indirect access to data in SAP CRM, ERP or other components. It is not only the access via a non-SAP application that is important, but also how the access takes place:

Do the users of the third-party application have the necessary SAP Named User licenses? Depending on the license conditions applicable to the scenario, it may also play a role whether data is transferred in real time or delayed, as well as some other criteria, depending on whether SAP provides a corresponding solution that could replace the external functionalities.

In which direction does the data transfer take place (uni-, bidirectional, inbound, outbound, etc.)? Is there a mass withdrawal of data (bulk)? An evaluation must be performed for each indirect usage scenario in the corporate landscape and appears to be particularly useful if one can identify scope for interpretation from possible contractual conditions that could avoid unnecessary additional licensing.

For example, in older contract constructs (interplay of relevant contract, PKL, GTC, and SUR), one often finds information that the use of information, provided it does not happen in real time, for example, and some other criteria are met, can be mapped via existing usage rights.

Contract terms in legacy contracts can thus be solution options that, for example, only require licensing of third-party application users, but not the third-party application itself.

However, this must be critically reviewed in each case and presupposes that SAP does not provide any corresponding functionalities. Thus, the interposition of middleware can be an accurate solution, but this only applies to dedicated cases and presupposes the validity of corresponding license conditions.

Here, too, it is essential to analyze the contracts in order to ensure compliance with the license terms and the necessary compliance. It should be mentioned at this point that middleware can be a technical solution as long as the functionalities of the upstream non-SAP software are not already offered by SAP.

For example, an internally developed time recording solution that does not report data to the relevant SAP system in real time and by mass deduction via message queuing middleware would not be a suitable solution, since SAP itself offers corresponding functionalities. However, the situation could be different for very industry-specific solutions that are not currently included in SAP's software program.

For the correct licensing of third-party applications, which is therefore necessary at least for most use cases, SAP included the "SAP NetWeaver Foundation for Third-Party Applications" license in the program in 2010, which can be purchased according to named-user or core metrics.

Committing to one of the metrics is only possible once, before the first purchase. This means: It is advisable to look into the rights and conditions of the old contracts and to make optimal use of existing scope for interpretation.

It can also be seen that there is a trend towards a wider range of licenses to cater for the diverse and increasingly complex scenarios of indirect use. The diagram illustrates some of these scenarios, with alternative licensing options currently being further developed by SAP.

For example, as communicated at this year's Sapphire in Orlando, SAP has addressed the most common scenarios (procure-to-pay, order-to-cash, and static read) and provides customers with license metrics with corresponding usage rights, as in the example above, to map correct licensing in a cost-effective manner.

Provided that customers are otherwise properly licensed, SAP also shows understanding of customers' timely needs by communicating concessions in the context of necessary upgrades.

Regardless of the manufacturer, it is always advisable to analyze whether indirect usage scenarios exist in the company and to evaluate them in terms of licensing law. This is the only way to ensure license compliance, which is the responsibility of the licensee.

Companion of progress

Just two decades ago, SAP systems, at that time mainly in the form of the ERP components, with their all-encompassing portfolio of business opportunities, were the ideal front end for customers to take the step into the future.

Suddenly, it was possible to design business processes more efficiently and to drastically shorten throughput times. Various workflows could also be partially or fully automated.

Thus, the introduction of ERP software was the prestigious and at the same time courageous step into a world of business processes and applications characterized by digitalization in order to keep pace with the growing international competitive structures.

It was a time of upheaval and seemingly endless technical possibilities, but not a time for anticipating and paying attention to the accompanying licensing and thus compliance risks.

In the course of time and with the development of today's technical possibilities such as virtualization, cloud applications, storage appliances meeting regulatory requirements and high-performance database solutions, the first major challenge arose for all parties involved, both licensors and users.

Licensors had to anticipate future technical possibilities when designing their license models, and licensees faced the increasingly complex variety of license models, metrics and license terms.

SAP ecosystem

In the case of SAP, the homogeneous system landscape that has grown over two to three decades has evolved away from its former importance as a general front end into a holistic ecosystem to which a large number of specialized on-premise and cloud applications are connected.

Prominent examples are CRM functionalities from Salesforce.com and Human Capital Management from Workday. Both examples generally replace or supplement SAP's own functionalities.

SAP provides the appropriate technology for the technically correct integration of these and other specialized applications. In the past, this was done in the form of the Process Integration (PI) product.

In addition to technical integration, the use of the underlying SAP ecosystem may require the acquisition of additional usage rights. A well-known example of this is the "SAP NetWeaver Foundation for Third-Party Applications" license mentioned above.

A user who, for example, accesses SAP functionalities purely via an external platform can be provided with usage rights in a license-compliant manner here by means of a corresponding platform license.

However, this is, erroneously unnoticed by many customers, not considered as sufficient licensing, but may also require the additional purchase of the "NetWeaver Foundation for Third-Party Applications" license, if the target of the application is based on the NetWeaver Platform. As a rule, even an intermediate PI system does not change this.

SAP is often accused of lacking innovative strength and its original front-end systems are degraded to a back-end system for young, innovative solution providers. However, a closer look reveals a clear picture of this change and allows it to be seen as the logical evolution of the SAP system landscape. Business requirements have changed, and flexibility has become more important in global IT structures.

Holistic transparency

With the increasing heterogeneity of the SAP ecosystems used by customers and the often customer-specific use of the integrated and interconnected products and interfaces, the creation of holistic transparency has been gaining in importance for some time.

The question as to the cause of the often inadequate transparency can often be explained in a simple manner. Whereas today a license manager is generally responsible for all software licenses and the measurement of the corresponding usage, in the case of SAP licenses this is often not the case or has only been the case for a short time.

The reason for this can be found in the frequently encountered separation between non-SAP and SAP IT organizational units. From the point of view of the customer, for whom the SAP system provides a business-critical application, this is quite understandable, but from a license management point of view it is a gray area on the map of applications to be supported.

Thus, license measurement and license purchases were understandably also initiated by these SAP organizational units in the past. However, without the establishment of appropriate role concepts and processes that trigger action in the event of employees joining or leaving the company, for example, it is almost impossible to be positioned cost-effectively.

It is also difficult for these organizational units to keep up with today's development of technical possibilities in their undoubted knowledge of SAP licenses.

Converged and hyper-converged IT infrastructures are necessary evils to ensure resiliency through the use of today's wide-area network (WAN) networks and complement the increasing level of virtualization.

However, understanding the impact of the use of these structures from a license management perspective is often beyond the scope of the relevant area of responsibility. Underlicensing is inevitable when using products that depend on the structure.

For example, legacy software license agreements based on CPU or core licensing models are often not designed for use in virtual networks.

When reviewing old Business Objects contracts, this is very easy to determine and instead of a physical server on which the software was used in the past, the physical server of the virtual environment must now be licensed, which was usually configured significantly larger in terms of processor cores, CPUs and computing power.

But that would still be the easier case to get over. Today's virtual environments, however, span at least several physical servers on which the workload is distributed in the form of a cluster. So, in terms of the need for licenses, one physical server is already several. But even this is not the worst case.

Worst Case?

If you are using current VMware virtualization technology, you are able to distribute the workload across clusters via certain functionalities (vMotion).

Via the use of NSX technology, through converged and hyper-converged infrastructures, it is even possible to cover entire data centers with a virtualization layer.

The need to acquire the corresponding usage rights resulting from licensing obligations is hardly controllable here, as this was often not included in the business case consideration of the strategic decision to introduce such structures.

But the necessity of this situation can be questioned, since it is precisely for the assessment of these scenarios that the IT asset management/license management organization is equipped with resources, know-how and competencies to be available as a trusted advisor with advice and support.

Avoiding such cases is one of the reasons for the need for an established governance structure for IT asset management.

Licensing models are becoming increasingly complex

However, this increasing degree of complexity, in conjunction with increasingly complex licensing models and licensing conditions, does not only affect proprietary products, as in the case of SAP.

Due to the described evolution of the SAP ecosystem through the integration and use of non-SAP products, this affects further areas of license management.

This poses far-reaching challenges for organizations with a low maturity level or lack of governance in license management. For example, in order to create the greatest possible transparency, it is important to recognize one's own cross-component use or to know the ways in which users, systems, bots and other actuators communicate with each other.

Today, for example, telemetry modules are increasingly being installed in the automotive and mechanical engineering industries as part of the introduction of Industry 4.0 and IoT structures. These modules report to the manufacturer, for example, with messages about pending maintenance or early warning of a foreseeable probability of failure.

Here, the integration sometimes goes so far that the corresponding support order is created in SAP and a technician is sent on his way without any further interaction being required. But the absence of human interaction does not mean that these scenarios are not subject to licensing.

The task here is to use contractual, licensing and technical knowledge to analyze how a business case can be designed as cost-effectively as possible and how implementation can be mapped in a license-compliant manner. Correct licensing is the responsibility of the customer in every case.

At the latest when using corresponding products that are installed outside of SAP but access SAP functionalities, the last reason is then recognizable, which speaks for the fact that the organization responsible for license management must absolutely be involved from the beginning of a planning.

It is necessary and important to dive into the management consoles of the external applications or to identify corresponding user groups down to folder level and analyze their access rights and permissions.

These developments have made the introduction of a governance structure, the continuous involvement of the license management organization and the constant communication of the relevant stakeholders an indispensable step towards a future in which ensuring license compliance is more challenging than ever before.

In addition to tracking all communication channels based on RFC technology between SAP and third-party systems, all non-RFC connections (e.g., HTTP, IDoc, IPSec, etc.) must be recorded and evaluated using qualitative and quantitative data collection methods (e.g., documentation, system checks, etc.).

Recommendations for functional license management

The recommendations for a functional license management organization are the same for SAP as for any other vendor, with a few exceptions.
The basic principle for every good license manager is to know commercial usage rights, to identify information about the technical type of use and the volume of use, and to reconcile these at the end. In addition, it is important to recognize developments and changes in licensing rules and metrics and to implement them in one's own environment.
In this way, information can be obtained about any existing overlicensing or underlicensing. The following is a brief overview of points that should be followed in any case to ensure the required transparency.

Recommendation: Transparency in indirect use

The indirect use of SAP systems should be considered individually within the framework of a scenario analysis, depending on the respective use case and the underlying circumstances. The following reference process has been established and proven in practice: The first step is to initiate and perform the initial data collection of all surveying-relevant productive, development or alternative usage-relevant systems. Depending on the size of the enterprise, companies have several dozen or even hundreds of different data sources. This complexity is one of the main reasons why a carefully planned and designed data collection/consolidation and subsequent analysis are indispensable.

Ideally, the central point of contact for the system-side collection of information on the RFC connections of the surveying-relevant SAP systems is a holistically integrated and centrally managed SAP Solution Manager instance.

If one does not exist, an alternative data source should be found that has a similarly centralized character. Subsequently, the collected data and information are consolidated and classified and prioritized according to their relevance as well as criticality.

The systems and the connections based on them are finally preselected for further analysis according to individual criteria.

The result then ideally represents a consistent overall view of the surveying-relevant SAP systems whose connections to third-party systems are to be classified as most critical and - taking into account various aspects of indirect use - most relevant.

Technical usage scenarios, also called use cases, represent an elementary component of the surveying and collection process of indirect usage. Depending on the size of the company, a few, but also hundreds of different indirect use scenarios can be identified.

To make this complexity a little more manageable, it is advisable to adopt a parallel approach when defining the respective usage scenarios. However, building on the underlying technical connection and depending on the initial situation, a different diversification object can also be selected.

However, a distinction is usually made between RFC and non-RFC use cases.
After the detached analysis, the next step is to consolidate the corresponding use cases into overarching scenarios. For consolidation, technical information on the assumed hardware and virtualization level is often included. This ensures further specification and facilitates the subsequent analysis and evaluation.

The result of this process step is a list of the most relevant usage scenarios from the point of view of risk minimization (in the form of a holistic logical overview).

The third step in the reference process, SAP license reconciliation, builds on a solid database. First, it is advisable to enrich the data already collected with usage data and the authorizations of the corresponding SAP users on the target applications.

This is done by means of a system-side data dump and a system-supported evaluation of this data. If necessary, this is supplemented by an analysis of access rights and authorizations in the environment of the target applications (for example, via an analysis within the Active Directory).

The first step is to identify the license-relevant information and design a data extraction and evaluation mechanism. Then, associated activity profiles are developed based on the real usage data in order to be able to take the actual database as a starting point.

It should be noted here that the real activity description should always be viewed generically. Both the usage data and the activity descriptions of the respective profiles of the users should ideally have the technical access authorizations and actually performed accesses/activities on the corresponding SAP applications.

For this purpose, it is advisable to analyze the corresponding target applications at the technical authorization level. Finally, the target state (the contractually specified license stock) is compared with the actual state. This is derived from the actual usage.

The findings from the license comparison are used in the fourth step of the reference process to be able to evaluate the previously defined use cases from a business perspective.

In addition to these considerations, risk assessments are also carried out to enable the evaluation to be viewed at a more detailed and precise level. Here, too, it is advisable to reduce complexity by dividing the business cases according to the technological circumstances, to consider them separately and then to consolidate them into overarching, more general business cases.

The overarching business cases are then subjected to a critical evaluation. This evaluation is based on previously defined and weighted criteria.

This procedure ensures that only business cases that emerge from the analysis as relevant are included in the decision-making process. In this context, relevant does not just mean relevant from the point of view of minimizing risk, but rather relevant for ensuring the comparatively most cost-effective overall licensing that can be controlled from a compliance perspective.

In the final step, technical options for anticipatory risk minimization, or ideally avoidance, of indirect use are identified. In this context, the monetary evaluation of the potential measures is carried out.

By combining the various scenarios into logical overall packages, proposals for the most cost-effective overall licensing are identified. In this context, compliance is ensured (if necessary, in consultation with SAP) through technical adjustments or through the proactive acquisition of required licenses.

Here, the focus should not only be on short-term problem elimination. Rather, sustainable transparency should be created, if necessary in cooperation with specialists. The aim of the solutions developed is to establish a set of rules for identifying and proactively evaluating indirect use in the company.

Case study: Time recording

To take a closer look at the example of time recording and understand when a
proprietary solution causes a compliance violation, three different scenarios are
used for illustration.

Employees of a company use in-house developed or third-party time recording software to record working time. Via SAP PI, the data is played into the designated SAP system.

1st scenario:

This would mean that all users who use the time recording software would be subject to licensing. The exact amount of named user licenses required would require an analysis to check whether the time recording users already have named user licenses and whether the rights they contain are sufficient. In addition, licensing of the in-house or third-party application (time recording) with SAP NetWeaver Foundation for Third-Party Applications is required.

2nd scenario:

A possible interposition of message queues that pass on data only in bulk and with a time delay via PI to the intended SAP system could represent a solution that does not necessarily classify users as license-relevant. However, this possible technical solution requires at least two prerequisites:

• Contractual requirements must be in place accordingly.
• Functions of non-SAP software are not already included in available SAP solutions.

However, this type of licensing is not clearly defined, so that in case of doubt there is at least a license obligation as in scenario 1 if SAP software offers the same functionalities. In addition, there may be a corresponding license for the message queuing used. This must be analyzed in case of doubt.

3rd scenario:

Another solution could be to interpose an employee from HR or a shared service employee who manually enters the data from the non-SAP application reports into SAP. This employee would need to be licensed and it is important to ensure that the correct license has been assigned. Typically, for an HR employee, it would be an SAP professional user license.

Insights and prospects

Challenges in license management are not an issue that is specific to SAP. Rather, as already described, SAP provides its customers with a tool to support correct licensing. Why is software asset management nevertheless perceived to be a highly complex topic that often leads to problems?

The digitization of business models works with software and in many areas software is the basis for the functioning of business processes and models.

The increasing complexity in the operation of IT infrastructures and the corresponding software applications also increases the complexity of correct licensing of the deployed and used software. Simply "counting, measuring and weighing", as was possible in the past, no longer helps.

Since virtualization and cloud computing have been increasingly used, software vendors' licensing models have become much more complex as a result of these technological developments.

Many companies are now being asked to set up hybrid models in license management that combine original license management on the one hand and the management of subscription models on the other. Hardly any license management organization can fulfill this task.

In addition, this topic does not currently have a prominent place on the agenda of most CIOs. In our consulting experience, companies with over 100,000 employees have only one person in license management who is supposed to perform license management for hundreds of software products.

It is not uncommon for this to be supported by a professional SAM tool; instead, management is carried out with the help of Excel lists. If you consider that a single software manufacturer changes around 50 license conditions every week, the result of such a constellation can only be "in-compliance".

Emerging discussions on specific topics, currently for example on the topic of "indirect use", increase the uncertainties in license management, although this topic has already been addressed by various software manufacturers for years.

Due to the recent concessions made by SAP with regard to the provision of corresponding license models for the most common scenarios, it is advisable to evaluate the individual license situation promptly in order to proactively participate in these concessions instead of no longer being able to use the offered options or not being able to use them completely in the event of a license audit.

Cloud is currently a hot topic for all software manufacturers and customers are expecting cost savings compared to their current costs for licenses and maintenance. But how is a customer supposed to make a profitability analysis if they don't even know whether they are currently licensed correctly and cost-efficiently?

A business case should be calculated on a solid basis, and a functioning software asset management contributes to this. The same also applies to the topic of cyber security.

A functioning SAM helps a company to always have an up-to-date view of the software in use at a particular version status and thus to be able to analyze version-specific security risks cleanly.

What should IT decision-makers do, what is recommended to meet the challenges described? A company dealing with SAM should implement a governance model with roles, responsibilities and processes that enable effective and efficient license management.

In large enterprises, this is not a task that can be accomplished by one or two employees; rather, the SAM organization should reflect the complexity of the enterprise as a whole.

A SAM tool should be used that supports the license managers in their tasks and allows them to control the issue. A shift to subscription models is not a solution for eliminating deficits in license management.

The commitment of top management is crucial for successful license management. For the CIO, SAM must be an important component of his overarching IT strategy. A secure basis is the basic prerequisite for calculating business cases and making sound investment decisions for new technologies.

International study results predict that in 2017 over 75 percent of all cloud transformation activities will take place without knowledge of the actual license costs before the decision is made and without effective controlling during the transformation. This makes you think!

[/av_textblock]