Software License Optimization

Microsoft Getting Behind ISO 19770-2 Software Tagging

By Alan Swahn

It’s good to see Microsoft announcing support for the ISO/IEC 19770-2 software tagging standard. Providing and leveraging these tags comes within a six step process, where both software publishers and Software Asset Management (SAM) / Software License Optimization tool providers must participate for customers to derive value. Here are the steps to tag utilization as part of the license optimization process:

 Step1: The software needs to be tagged by the software publisher. (See Flexera Software’s announcement of  end-to-end support for tagging including InstallShield 2012 support for the creation of tags and AdminStudio support for preserving tags during the repackaging process).

Step 2: The tagged software is deployed (using tools such as SCCM or Intune) to the endpoint (computer).

 Step 3: The auto-discovery / inventory tool needs to be able to collect these tags from each of the devices (desktops, laptops, servers, pads…) in the IT environment.

Today, SCCM 2012 doesn’t yet provide this tag inventory capability. It will be important for Microsoft to synchronize the future release of SCCM that is “tag-ready” and the tagging of its many software products. One without the other creates a break in the chain. Likewise, no customer value is achieved if software tags can’t be collected and processed downstream.

SAM and Software License Optimization tools pick-up where SCCM leaves off. There are several more steps in license management and optimization that lead to much higher value and return on investment. Let’s take a look at the Rest of the Story, as Paul Harvey said so many times.

Step 4: Once the software tag is collected during the inventory process (future version of SCCM or other existing inventory tools—note that FlexNet Manager Platform supports tag collection now), this evidence still needs to be recognized. The capabilities required here go beyond SCCM and a SAM or License Optimization solution is required.

Tags provide richer evidence compared to other types like Add/Remove programs, but still represent fingerprints that must be processed and matched to an application recognition library entry. This recognition process produces a list of software titles per device. Now you ‘know what you have’ in your IT environment. This is the value of tagging—easing the process of accurately identifying installed software.

Step 5: A License Optimization solution (a few SAM tools provide this too) should automatically link the reconciled software titles per device to a proper set of software stocking keeping unit (SKU) numbers, where one title may have many SKUs, depending on how it was bought. The SKU number defines exactly what was purchased and how it was purchased (e.g. under an Enterprise Agreement, Select Agreement, etc.) The linkage between the title and purchase order SKUs is the key to streamlining the license reconciliation process and reporting on what was purchased compared to what was found through inventory.

This type of ‘purchased versus inventory’ report is valuable and what many companies use to defend themselves in a software license audit. However, it doesn’t account for the license entitlements that come with the software. This means that although the report is accurate from a license compliance perspective, it’s completely non-optimized, with no product use rights taken into account. In this case, you could end up paying unnecessarily for more licenses in both an out-of-compliance (audit) situation and for a new purchase scenario.

Step 6: This step is a big one, only handled by License Optimization Solutions, and disproportionate to the first five steps. It is the key to driving down spend and forestalling unnecessary software purchases. The type of agreement under which the software was purchased, the license metric/model that the vendor uses to calculate price, the software product use rights (entitlements) under the agreement, and order of license allocation are all tied together from a license/spend optimization standpoint.

Example Agreements/Terms

Microsoft:

• Enterprise Agreement
• Select Plus
• Open Value

Adobe:

•  Cumulative Licensing Program
• Transactional Licensing Program
• Enterprise Agreement

Example License Metrics

IBM:

• Processor Value Unit
• User Value Unit
• Resource Value Unit
• Authorized User
• Concurrent User
• Floating User
• Client Device

SAP:

• Developer User
• Business Expert User
• Professional User
• Limited Professional
• Business Information User
• Employee User
• Employee Self Service
• Business Analyst User

Example Product Use Rights (License Entitlements)

• Upgrade
• Downgrade
• Second Use
• Multiple Install
• Virtual Environment Use
• Reimaging
• Backup/ Fail Over/ Disaster Recovery

Example Order of License Allocation

• Standard Licenses before Professional
• Product Licenses before Suite Licenses

The license optimization solution determines the least cost outcome considering all of these variables and conditions, which are very complex and differ from vendor to vendor, physical versus virtual and even software title to title.

It’s very common for companies that reach this step to find that they are over licensed for software from some of their key vendors. They can either forestall future purchases or negotiate with their vendor and perhaps pay maintenance for only what they really need. In an software license audit scenario, the liability calculated from a software purchased versus inventory report may be greatly reduced or eliminated, after applying product use rights and generating an Actual License Position.

Latest update on SQL Server 2012 licensing

By Vincent Brasseur

In March, Microsoft released new documents, the “SQL Server 2012 Licensing Quick Reference Guide” and the “SQL Server 2012 Licensing Datasheet and FAQ”. Both are available online from this Microsoft SQL Server licensing page. The most noticeable change from the previous edition is the introduction of a core factor table similar to the Oracle Processor Core factor and the IBM Processor Value Unit tables. The new Microsoft table is very simple and considers several case scenarios:

• All cores of a physical processor (socket) must be licensed with a minimum of 4 cores. This explains why the factor is 4 for single core and 2 for dual core processors.
• Some AMD processors have a core factor of .75 as they are deemed less powerful than Intel processors with an equal number of cores.

The March 2012 table is published online and is subject to change overtime. These changes will likely be driven by the release of new processor models. This is another piece of the licensing agreement that is now published online, like the product use rights document that is updated on a quarterly basis. The calculation of a license position must consider these rules, so monitoring any change is required to accurately measure compliance.

Using the Microsoft core table for physical machines is very simple. The number of cores for all processors is counted, then the core factor is applied and the result is the number of licenses that need to be purchased. For instance, if a server is equipped with 2 Intel Xeon 6 core processors, then 12 core licenses are needed as the core factor is “1” for Intel processors with 6 cores. When it comes to purchasing, core licenses are only sold by packs of two, so only 6 “packs of 2 cores” are needed. With AMD processors, the calculation may not provide an even number. For instance, an AMD FX-6100 6 core processor will require 5 core licenses (6 *.75= 4.5 rounded to 5) and the purchase of 3 “packs of 2 cores”. The extra unused core can be reallocated to another machine. Note that hyper threading is never considered for physical machines.

On virtual machines, the core table is never used. What is counted is the number of virtual cores (v-cores) supporting each virtual operating system environment (OSE), with a minimum of 4 v-cores per environment. The definition of a v-core is done at the hardware thread level: if multiple hardware threads are supporting a single virtual core, then additional licenses are needed for each thread. With the Standard Edition, each VM needs to be licensed individually. With the Enterprise Edition, there is also the possibility to license all the cores on a physical server and then run an unlimited number of SQL Server instances in physical and virtual machines, up to the number of core licenses assigned to the server. With Software Assurance, and only for the duration of it, this last limit is lifted and the number of v-cores where SQL Server is running may exceed the total number of physical cores.

Details are provided on how to migrate licenses from the processor to the core model under Software Assurance. No change is required until the end of your current agreements but the possibility exists to use the SQL Server 2012 core license model for specific deployments with new or existing licenses. At the end of their current enrolment, customers must perform and record an inventory of their servers. Their current processor licenses will be translated to core licenses according to their findings. Microsoft also guarantees a minimum number of core licenses per processor depending on edition: 8 per SQL Server Datacenter edition processor licenses and 4 for any other edition. There are two additional restrictions:

• To exchange a SQL Server processor license for core licenses, SA coverage must be renewed based on the number of core licenses required to license all of the physical cores in the processor.
• To be eligible for more than the minimum exchange, the total number of processor licenses assigned to a given server cannot exceed the total number of physical processors in the server.

The primary impact of these changes is on SQL Server licensing costs. There is no benefit in licensing old servers with less than 4 cores per processor considering that 4 cores at a minimum must be licensed for each processor. Configurations where processors have 4 cores will not be impacted by the change. Licensing SQL Server on high end processors may be significantly more expensive.

If we compare the price of SQL Server 2008 R2 Enterprise edition ($27,495 per processor) and SQL Server 2012 R2 Enterprise Edition ($6,874 per core), and apply the .75 core factor to AMD processors over 4 cores, the figures go as follows for a single processor:

As you can see, the use of newer processors with a large number of cores substantially increases the SQL Server core-based license cost.

***

To learn more about optimized license management for the datacenter, please download our whitepaper.

Software Asset Management in R&D Organizations

By Natalie Overstreet Lias

Software asset management (SAM) projects typically originate in traditional corporate IT organizations, whether at a global or large subsidiary level.  This makes sense, because the software publishers with highest visibility across the organization are the ones who fit squarely into the operations of central IT.  Almost everyone in the organization, including executive management, is familiar with and uses the products of Microsoft, Adobe and other major desktop software vendors.  Central IT also has ownership of IT infrastructure, so they know the importance of server-based software vendors such as IBM, Oracle and SAP.  Most critically, all these vendors, whether for general-purpose desktop software or corporate IT infrastructure software, typically impact the general corporate IT budget itself.  This means that a lack of license optimization affects the CIO’s budget.  Because of this, SAM projects usually begin by focusing on large traditional IT vendors. 

This focus on central IT scope and budget can obscure a critical area of the business that affects both software spend and software risk:  R&D and engineering organizations.  R&D organizations often have separate sourcing, purchasing, and IT processes from the main enterprise, so software asset management projects originating in central IT frequently lack visibility into software deployments and software purchases in R&D.  In addition, R&D environments often include systems that may be critical to R&D activities but fall outside the scope of central IT.  Central IT may only support Windows systems, for example, but R&D might require large Linux systems to support heavy-duty simulation work.  Finally, there can often be political tension between R&D organizations and central IT.  The potential rift between enterprise IT goals and R&D requirements can result in a siege mentality among R&D management and R&D IT staff. This can lead, in turn, to a lack of cooperation with central IT initiatives including centralized software asset management programs. 

Because R&D is often a relatively small part of an enterprise, SAM projects sometimes assume that the technical and political obstacles to including R&D environments in software asset management activities justify leaving R&D out of scope.  However, software spend in R&D is typically out of proportion to headcount, because engineering software is very expensive compared to standard desktop applications.  In fact, annual software license and maintenance spend on engineering applications can actually exceed the overall spend for software licenses and maintenance on the enterprise’s standard Windows desktop, even when R&D users are a small minority of overall users! 

In addition, R&D environments are filled with engineers.  I began my career as an R&D engineer and continue to support engineering IT teams and license management activities, and I can confidently say that engineers, as a class, possess two traits that should concern anyone interested in enterprise software license compliance.  First, engineers have the technical capabilities to acquire, install, configure, and run software in their environment.  This includes software authorized by the enterprise or by R&D management, as well as software introduced into the environment solely by the individual engineer.  Engineers also have the ability to reconfigure the software to point to a different license server than the one authorized by R&D IT, as well as remotely access systems in other geographies that may have licenses available. 

This might be manageable except for the second trait:  ignorance of the implications of software licensing on their software installation and configuration decisions.  Individual engineers are generally insulated from software contracts and purchasing processes.  As a result, they are frequently not sensitized to the financial implications or compliance and audit risks of software they have acquired and installed (through various means, some legitimate and some not).  Even in cases where an organization has an agreement with a software publisher, engineers often think in terms of site-wide licensing and may not consider that their individual actions can affect overall budget. 

The unique characteristics and risks of R&D organizations warrant their inclusion in enterprise-wide SAM projects.  While there are obstacles to such inclusion, the gains to the overall enterprise in terms of financial savings and license compliance risk mitigation mean that the effort will be worth it. 

***

To learn more about concurrent license management for engineering applications, please view our on-demand webinar: Pure Gold-- Leveraging Software Usage Data to Reduce License Costs and Risk

Promoting your Software Asset Management Programme- Part 2

By Rory Canavan

Following on from the original Promoting your Software Asset Management Programme post, I thought it would be useful to expand on the thinking behind the bullet points proposed in a software asset management (SAM) communications plan.

To recap, they are listed below:

1. Identification of stakeholders
2. The agreed triggers/waypoints which instigate communications to the stakeholders
3. Demonstration of how those triggers/waypoints support the business
4. A communications schedule
5. The agreed to method of delivery for all communications
6. Any privacy/security caveats applicable to communications
7. The content of communications to the stakeholders
8. Periodic review of personnel data contained within the communications plan

Identification of stakeholders:  There are a couple of key issues here. First, there is often resistance, at least initially, to a centralized software asset management and license optimization programme, at the business unit level of large organizations. Business unit CIOs may fear a loss of control, for instance. It will be important to not only identify these key stakeholders but to also communicate programme “wins” that positively impact the BU as well as the organization as a whole.  Second, it’s critical to have an executive sponsor for the programme, who will champion the effort and communicate the need for cooperation from all the parties involved.

The agreed triggers/waypoints which instigate communications to the stakeholders:  Weekly updates of how a SAM Programme may be going could offer visibility to stakeholders as to how soon or far away hoped-for license consumption or metering reports might be, but equally they could be dismissed as fodder for someone’s junk basket.  Flip the situation on its head and ask yourself: When would I want to hear about events pertaining to the SAM Programme?  You may even want to consider how you would answer this question depending on which role you occupy within the company.

Demonstration of how those triggers/waypoints support the business:  It never hurts to remind stakeholders why they are hearing from you, or how progress/pitfalls might influence what they can expect from a SAM Programme.

A communications schedule and template:  This could be established as a grid in the first instance; with the following columns:  Name; Job Title; Stakeholder position; Waypoints of primary interest; Why they are interested in that Waypoint; Frequency of Communications.  Other columns might well be added as the project progresses.

The agreed-to method of delivery for all communications:  Often, email will suffice as the easiest means of communicating with stakeholders – however, certain programmes may have to deal with remote locations, home workers, contractors or perhaps staff whose access to email is limited.  This could easily be another column on the Communications Schedule, mentioned above.

Any privacy/security caveats applicable to communications:  I would suggest that most software asset management programmes are, as a minimum, treated as “Commercial-in-Confidence”, and as such recipients are made fully aware of the consequences of passing potentially valuable information beyond any circle of trust established by the Programme.  Indeed, some programmes may insist on a classification of data based on national/military requirements.

The content of communications to stakeholders: Again I refer to the question we asked ourselves earlier: What information is likely to be of interest to a stakeholder?  A business unit manager may want entirely different information, as compared to an IT procurement manager.

Periodic review of personnel data contained within the communications plan: Since your SAM and license optimization programme is (or should be) an ongoing effort, it would be prudent to consider refreshing the Communications Schedule to ensure that employees/others have not changed roles or left the company entirely.  Indeed, if we return to our Military/national security example, this will be a mandatory requirement to ensure confidentiality of information is maintained.

Obviously, an enterprise-wide broadcast email to all employees about the day-to-day dealings of a SAM Programme is not the way forward. However, accurate and concise communications with relevant stakeholders is vital to ensure traction and continued momentum for the programme in the medium to long-term.

***

To learn more about Software Asset Management best practices, please download our whitepaper:  NCC Guideline to IT Management: Software Asset and License Management Best Practices.

Promoting Your Software Asset Management Programme

By Rory Canavan

Having recently commented on an IT thread on the ITAM Review  concerning the definition of Software Asset Management (SAM), I got to thinking about the SAM programmes I have been engaged in previously.  Software asset management clearly offers benefits to the organization in the areas of:

• Request Management
• Inventory Management
• Asset Management
• Business Continuity Management
• Service Desk/Incident Management
• Change Management
• Vendor Relationship Management
• License & Contract Management
• Spend Management
• Disaster Recovery
• Data Protection & Information Security Management
• IT Operations
• IT Strategy

However, when it comes to promoting the software asset management and license optimization cause, or seeking buy-in from non-IT individuals, waxing lyrical about the visibility of devices or being primed and ready to face a vendor account manager with up to date inventory and license entitlement data, are hardly likely to win the day. Other areas of the business that see IT merely as a utility with a keyboard attached, require a different approach.

And considering that IT is predominantly focussed on the quality and quantity of information flow through a company, as communication professionals we often let ourselves down when it comes to delivering the correct message!

So perhaps a revision of strategy might be required – if we are to embark on a SAM and license optimization programme and we wish to make sure that it is not shelved prior to becoming business as usual, then perhaps we should adopt a bit of self-promotion, or as a minimum at least, have a SAM Programme communications plan.

For the foundation of such a plan, we could do worse than consider the follow points:

1. Identification of Stakeholders – who will be influenced by this software asset management programme?
2. The agreed triggers/waypoints which instigate communications to the stakeholders – What milestones should be reported upon to Stakeholders?
3. Demonstration of how those triggers/waypoints support the business – Re-emphasis of why the SAM programme exists
4. A Communications Schedule – An agreed-to schedule to ensure that timely and accurate communications do not swamp those highlighted in point 1.
5. The agreed-to method of delivery for all communications – Email might be an obvious choice, but some people may be harder to reach than others, and so replies could be delayed (if required)
6. Any privacy/security caveats applicable to communications – MoD/DoD/Medical projects may well have caveats that influence the choice for item 5; or even 1 (some individuals may be excluded access to sensitive data based on role, geographic location, etc.)
7. The content of communications to the stakeholders - What information would be of interest to the stakeholders?
8. Periodic review of personnel data contained within the communications plan – People come and go, both internally and externally – who are their replacements? Are they no longer privy to classified information if they have moved to a different post within a company?

These 8 points should be considered in light of project status and business as usual, and will be expanded upon in a forthcoming blog. But for now, I would like to draw your attention to point #3 – please note: it does not say ‘Demonstration of how those triggers/waypoints support the SAM programme or the IT Department.’  Your SAM programme has the potential to reach as far as your IT systems do, and so we have to engage the business in terminology that it understands.

***

To learn more about Software Asset Management best practices, please download our whitepaper:  NCC Guideline to IT Management: Software Asset and License Management Best Practices.

Investment Planning Primer for Concurrently Licensed Software

By Donna Yobs

Optimizing the spend for concurrently licensed software applications is quite different from software that is licensed on an installed or device basis, like Microsoft, Adobe, and Symantec applications. Typically, for concurrently licensed applications—Cadence, Mentor, Synopsys, etc.—you are planning for the best application mix to maximize the use of the software by your end-users while minimizing software costs, or preparing for vendor negotiations. In either event, it is important to understand your users’ application usage history, governing contract terms, different regions’ requirements, seasonal or project phase differences, organization growth, and what your company is considering to purchase in the near future.

History:

Understanding your past trends such as what is your most valuable software, how is it used, and what are the usage patterns allows you to predict your future usage and license requirements. Do you have enough user history to have a trend? If you are working with a new department you may lack visibility into that group of users, yet you may be able to draw upon the usage history of another similar group.

Contracts:

A good first step is to review your contracts to find opportunities for license optimization. Applying the contract terms, conditions and pricing information will help you best understand a given application’s place in your planning hierarchy.  A key technique with concurrently licensed software is finding opportunities to share licenses across a diverse group of users, especially where groups have different usage patterns (differing peak hours or product design phases). Other questions you should address when looking at the contracts include the following:

• Governing contract terms:

Are the terms understood by the license manager, so that software usage controls can be tracked and enforced without having to train the users?  Do the end users have a basic understanding of the rules so they don't violate any license restrictions—such as usage by employee type or applications purchased for specific project use only?

• Regional requirements:

What do the contracts allow?  Are the license servers restricted to certain geographies?  Do the end users have a basic understanding of the rules so they don't unintentionally break  them (e.g. point to license servers outside of their geography)?

 

Project Plans:

Because history tells only part of the story, it is important for the team to create project plans that will either accelerate current trends or reverse them.  Each project will have differences in the amount of time spent on particular features and applications used throughout the design cycle.  By understanding this variability across overlapping projects, you can determine the best path forward for your remix strategy. Be sure to take into account the following:    

• Seasonal or project phase differences:

When projecting usage that has a quarterly cycle, be sure to include the full quarter in your analysis or your planning could miss a key stage.  For annual use, include a 13 month calendar for completeness in projecting unusual spikes.

• Organizational changes:

Have you taken into account new users as a result of mergers and acquisitions, removing users due to divestitures, and general organizational changes associated with reorganizations?

• Planning for known software purchases this year:

Do your plans require different vendors or just different applications? Be aware of shifts in development phases and technologies that may change who your top vendors are from year to year.  Understand the shifts in your market that change how software is used. As an example, a chip company that had a long consistent growth in one type of component may see a major spike when adding a mobile or sensor design group to the engineering application user pool.

The following basic steps are necessary to compare your enterprise’s licensing contract terms to actual product usage, to meet current needs and determine future demand.

1. Track inventory and application usage data

2. Generate reports for relevant contract categories:
   1. Vendors
   2. Geographies
   3. Projects
3. Determine Metrics:
   1. Desktop Applications tend to be tracked by installations and packages accessed.
   2. Concurrent Applications are tracked by simultaneous use.  They tend to be licensed by feature & purchased by product or product bundle.
4. Understand contract terms and conditions:
   1. Usage restrictions and costing information
5. Consider organizational groupings:
   1. Track usage and other key metrics by business departments, cost centers, projects or geographies
   2. Facilitate: Chargeback, Showback, Project Billing
6. Review trends and feed into operational and budget planning 
7. Prepare both compliance and business reports
   1. Compliance is about reconciling  entitlements and usage
   2. Business Reporting is about reporting by relevant business units and metrics.  Reports will reflect business needs for project billing, chargeback, ROI and department priorities.
   3. Compare contract specifics to determine if you are compliant per license count, per geography, platforms, user types, etc.
   4. Determine if you are under/over licensed
8. If relevant to your set of applications and licenses, review remix options
   1. Many vendors allow customers to optimize licensing by requesting a different mix of products quarterly or yearly
   2. Did your user types change?
   3. Did your mix of development phases (and hence applications needs) shift?

With efficient investment planning you can optimize your mix of concurrently licensed software to provide the best availability and maximize its value. This is accomplished by reviewing current usage and trending patterns, then applying them to projected business plans (new projects being added, existing projects ending, emerging markets and new technology trends).   This will result in optimal software use at the lowest cost.

***

To learn more about tracking software usage to reduce licensing costs and improve end-user productivity for concurrently licensed applications, view our on-demand webinar: Pure Gold--Leverage Usage Data to Reduce License Costs and Risk.