The SPLA Program is quite different from a traditional Perpetual or Subscription agreement, mainly because there are no acquired or fixed number of entitlements, setting limitations on usage.
Therefore, it is not the history of acquired license entitlements in relation to the number of installations, but the current need for licenses in a complex and ever-changing environment that is important.
A traditional SAM tool is built to keep track of the balance between acquired entitlements and usage, typically for the contractual period and beyond.
SPLA compliance is about ordering licenses based on the actual license need per reporting month.
An inventory tool will give you the actual numbers on installation/access which is the foundation for calculating your licensing needs, but it does not assist you in keeping track of the rules and requirements from the SPLA agreement(s) or SPUR documents, especially the use rights which may change through your SPLA agreement period – or across several agreements, if you have more than one.
At the end of the day what you need for running an SPLA business is support for the full process, including compliance documentation for Inventory, License calculations and what you have ordered to give the full overview.
SPLA Manager is tailor-made for the sole purpose of doing this – and nothing else.
For more information, request a free demo.
Every once in a while Microsoft changes their way to license their software or the cost of using this. How do you keep up with SPLA Licensing when the changes occur. Or more important WHY should you stay updated?
The answer may fall in one or all of 3 categories:
In many cases, there is more than one option for licensing, based on editions and sometimes also product bundles.
An example could SQL 2017 in a virtualized environment, where, in the majority of cases, it will make the most sense to assign Enterprise core processor licenses based on the hardware configuration.
But how (often) do you determine if it is more cost effective to assign Standard licenses to the virtualized instances? And are you taking into consideration if any of the instances are covered by License Mobility – and the impact this has on your licensing options?
Two different versions of a software can have a very different cost, depending on the environment it is deployed in.
This is especially relevant if you start to deploy a new version in a clustered environment as the entire license calculation is based on the highest version.
An example could be Windows Server 2012 vs. 2016, where the transition from CPU to Core may have a significant impact on the requirement for licenses. Failure to adjusting to these requirements may pose a compliance risk.
When you design and size your next deployment the licensing metrics and attributes may have a significant impact on the TCO.
A simple example: One SQL server (2016) with 1CPU and 2 Cores is having the same price tag for SQL as a server with 1 CPU and 4 Cores. Reason: The Entitlement is 2 Cores per license, but with a minimum of 4 Cores per CPU = 4 Cores needs to be covered as the minimum.
History tells us the license rules and metrics are not static and there is no guarantee the software manufacturers, in general, will work on a standard for license metrics, so the need for staying updated is ever present.
Of course, a tool that keeps track of the entitlements and uses rights can be of significant value, if you do not have the time or natural interest to stay updated. This is one of the key value propositions of SPLA Manager.
If you want to learn more contact support@splamanager.com
SPLA Reporting Made Accurate & Automated