In this article, I would like to quickly discuss and bring to attention the primary compliance issues that usually pertain to the management of engineering applications. By engineering applications I mean primarily the PLM, CAD, CAE tools used by companies worldwide that still primarily utilize the network concurrent licensing model.
As with the network concurrent licensing model in the majority of the cases, there is a technical limitation that prevents the use of more licenses than actually bought, the vendors do focus on different ways to create obligations and measure compliance.
For the standard core applications usually covered by SAM Managers around the world, the high-level focus is pretty straightforward:
Compliance – ensuring the deployment is within the range of entitlement
Cost Optimization – ensuring the entitlement is effective vs the deployment
For engineering applications, it’s a little bit different.
So let’s discuss the first point and that is “The Obligations”
The definition here is again pretty straightforward, obligations are created by the contracts signed between the software vendor and the customer and mostly come in a defined usage scope for the licenses.
For engineering applications these usage scopes can take many different forms, some are more prevalent than others.
The most widely used usage scope is the geographical one. This clearly defines the geographical location where the usage of the license is permitted. The locations can range from as small as a single location/site through In-Country licenses permitted to be used within a single country (i.e United States), through Region-wide licenses permitted to be used within a region of the Earth (i.e. AMERICAS) through Multi-Region licenses permitted to be used simultaneously through several regions of the globe (i.e. AMERICAS + APAC) to fully-fledged Global* licenses where the limitation does not exist.
*Global licenses are the most expensive, but can also become very effective – I’ll cover this topic in another article.
Another commonly defined usage scope may be concerning the internal employee vs a contractor. Some vendors do allow the use of the licenses only for the internal employees of the customer, others may allow the use for external contractors as well.
Licenses may also be viewed differently for compliance depending on whether they are used to produce value or just used to support the application in question. A CAD engineer designing a CAD part is producing real value compared to an IT technician just starting the CAD application to support it.
There are several other important usage scope definitions that can stem from the contracts, such as ensuring a certain % of ownership in a Joint Venture or following the rules of a Transition Service Agreement, it’s important to always ensure that the contract is properly analyzed and all the obligations properly discovered.
If you are an experienced SAM manager, you may be thinking that what I have written above is automatic, but I can speak from experience that it can be easily overlooked.
Not too long ago (and still in many places) the importance of managing Software Assets was not too prevalent and still to this day the SAM can take a backseat to the company’s spends that are “more important”. In the same manner, the engineering software portfolio is even more easily overlooked, especially when compared to the big software spenders such as Microsoft or IBM or Oracle.
Now that we covered the obligations, let’s talk a bit about compliance and how to achieve it.
It is critical to ensure that once you identify all the contractual obligations stemming from the contracts, you ensure that all the usage scopes of the licenses are correctly implemented on a technical level and proper measures are taken against any breaches.
There are three primary steps of securing the environment and preventing compliance breaches.
1. Proper license servers infrastructure – splitting the licenses into different license servers whenever possible, specifically for installations where there is no overlap in the license usage scopes for a single license file.
2. Proper authorization rules – most industry standard license managers do allow the implementation of authorization rules that enable the “Allowing & Denying” of users based on certain parameters such as “userID, group, hostname, IP Address”
3. Periodical self-audits – Analyzing the license usage periodically and comparing the usage data to the contractual obligations.
So what is the bottom line here? Software audits are as actual as ever and it’s always better to be prepared in advance than having to scrap around once the audit is already at your doorstep.
Proper management of software is crucial to success and engineering applications should not be overlooked.