In this second part of our SAM Foundation series we look at Compliance Reporting and the importance of understanding your deployment position.
In part one of this series we covered the importance of a full data collection across your data sources and contract and licensing information, now we look at how to bring that together into a compliance position.
The first realisation is - wow! - that's a lot of data we have out there! So just as we needed tooling to perform the data gathering exercise we are going to need analytics to decipher not only what's important but how to interpret it all, for which there are two aspects:
Now what exactly do we mean by 'Scale Reporting'? Basically this means a reporting facility that enables you to stipulate variable parameters from product to vendor to company, with the output organised by device in a concise and easily readable form - for example ComplianceWare's powerful python & pandas based analytics engine that slices and organises the data into output as a familiar Excel workbook.
A snapshot of the output as below:
The analytics should also consider base licensing metrics such as server core and PVU minimums, apply relevant bundling rules to avoid double counting, and recognise non-chargeable installations such as clients and free-edition software.
So we now have our first view of what's deployed where - and that's a good start, but it doesn't mean the jobs done. You'll want to perform some spot / sanity checks across the report, and that's where the 'Direct Examination and Querying' comes in. Here, your tool should allow you to easily interrogate your data collection (which can span many millions of rows) for further review and confirmation, and that's accomplished via smart features that enable you to slice, limit and target the fields and items of interest. Again, with ComplianceWare as an example you can easily navigate through the data by vendor, product, data source, and perform smart searches with inclusion and exclusion parameters to dynamically find exactly what you are after.
ok ... we're happy with our deployment report - now what?
Now it gets interesting - does what's reported as deployed match what we're actually entitled to? While some products can be automatically tallied (eg. products with simple install or device metrics) others will require more effort such as resource based metrics like cores or logical licenses such as users, and those in more complex environments such as virtual environments where physical v virtual considerations must be taken into account.
Here there are no short-cuts - it will require a knowledgeable individual (preferably with prior experience in the environment) to work through each product in a methodical and calculated manner to (a) derive the optimal licensing construct and then (b) reconcile against the recorded (and evidenced) level of licensing. As this progresses it is imperative to capture your findings and ensure they are lodged as an artefact for audit readiness and as a baseline for future reporting cycles (again with ComplianceWare this can be stored as 'Verification' material alongside the updating of actual usage figures).
And just how often should the whole exercise be performed? We'd recommend that you cover your major vendors at least annually, and institute a program of work that targets a select number of products or vendors quarterly. The good news is that once you've completed one cycle others become easier as you'll have a baseline to compare or commence from.
So to summarise:
Extending Software Compliance's services to a global organisation meant expanding ComplianceWare to support multi-entity hierarchies, timezones, and currencies.
In an exciting development for Software Compliance we are very pleased to announce the expansion of our services to a major global operation, delivering SAM support built on our flagship ComplianceWare platform across 3 regions, and 18 different countries and companies.
While single entity customers will not notice any (well little) difference in the presentation and operation of the system there have indeed been a number of changes 'under the hood' with some of those features of benefit to all clients such as:
It has been a period of vast growth and development for Software Compliance, and we are very appreciative and fortunate to work with the many insightful people on this continuing journey.
And if you're thinking that Managed SAM Services built on the most cost effective tool in the market could help your organisation, please just get in touch with us to talk about what we could do!
All might not be as it seems - check this list of ILMT gotcha's
Here are out top five tips for trimming your PVU sub-capacity report counts:
1. Incomplete Vitualisation - the 'TVM' predicament
If your ILMT configuration is not fully or properly implemented you're likely to find incomplete virtualisation heirarchies in your VM Manager connections, which result in every affected VM being treated as a stand-alone physical machine at the highest PVU rating of 120 PVUs per core). This can quickly add up where you might otherwise be entitled to the likes of 70 PVUs per core.
2. Missing Software Classifications
Central to the accuracy of ILMT reporting is the much dreaded 'Software Classification' process. If you choose to ignore this painstaking requirement you can be sure you'll pay the price either in real terms or in time-draining dispute at your next audit. Essentially, every exempt PVU count in your environment needs to be catagorised as such, meaning instances that are to be excluded from PVU counts (which depending on the License Terms are likely Developer, DR, or Test installs) need to be individually identified as such via this (ongoing) activity.
3. Unrecognised Bundling
As a follow-on to the Software Classification issue above, you'll then likely notice that where you have installed Supporting Programs on a different server - where entitled to do so under the License Terms - the program will magically form part of the PVU count, ie. bundling is not recognised across servers. So once again you'll need to identify these instances and exclude them from the relevant count, making sure you add comments to qualify the classification.
4. Reallocation High-Water Marks
So you dutifully maintain your vCPU's to your level of entitlement, which, as you're permitted to do, includes the occasional reallocation across servers to match processing and performance needs. Given you've balanced the core counts out all is good - right? Well ... no, ILMT will track the high-water mark for each server in the 90-day reporting period, so for example a taking a core from a 4 vCPU server to assign to a 3 vCPU server will see both reporting as 4 vCPU servers for that period.
To be in a position to challenge this make sure you have or take - and keep - separate records that evidence the reassignment of cores to negate any double counting.
5. Ghost Decommissioning
Similar to the above, you might think that decommissioning one server to deploy another would be quite within your rights as long as you (as always) don't exceed your level of entitlements. Well ... no, the decommissioned server will also report within the same 90-day period as the new server - potentially a bigger problem than the issue with high-water marks. So again you'll need to either classify the server accordingly, or ensure you have the right artefacts to contest any double recognition, or both.
... a lot of overhead right?
And that's where a secondary source of truth can prove essential ...
Announcing ComplianceWare 3.0 with the addition of Hardware Discovery and Inventory
As a logical extension to the extensive Software and Licensing functionality of ComplianceWare we've now added the capability to track Hardware as well. Using the familiar script extract and load process across hardware devices you can now inventory your IT assets by site, view associated attributes, and generate reports based on specific templates.
For companies with sub-entities there is also the ability to create a hierarchy of related sites to provide a holistic view across all assets - a valuable insight into what refreshes might be necessary and coordinated across all sites enabling:
Future planned enhancements include the ability to interrogate failure rates to assist in determining which products and models are performing better than others, enabling procurement of least costly and more reliable IT assets.