Entitlement and Compliance Management

Best Practices for Software Licensing in the World of Machine Virtualization

By: David Znidarsic

You may be trying to apply your existing software licensing and support models to the world of machine virtualization. Sometimes this is possible; sometimes those existing models are at odds with this new world. Here are some best practices for deploying a licensed application in a virtual machine environment which allows the greatest flexibility to your customers without creating vulnerability for your revenue stream:

Best Practice #1 – A licensed application that supports a given physical machine should also support all popular virtual versions of that machine

Best Practice #2 – Capabilities of the licensed application should be controlled by a concurrent license which is managed by a license server

Best Practice #3 – Choose between the following two ways to deploy the license server:

a.)  Allow the license server to run only on a physical machine and load concurrent licenses into that license server from trusted storage

b.)  Allow the license server to run only on a virtual machine that the ISV packages as a virtual appliance and load concurrent license certificates bound to the UUID of the virtual application into that license server

Justification for Best Practice #1: it is futile for you to license your software in a way that reduces or eliminates the benefits your customers receive from running your software on virtual machines.

Justification for Best Practice #2: licensing an application based on properties of the machine running that application no longer makes sense…multi-core and then virtualization destroyed CPU-based licensing, and node-locked licensing can't tolerate the volatility of virtual machines. You must use a "virtual license" (a.k.a. concurrent license) on a virtual machine.

Justification for Best Practice #3a: providing flexibility on where your customers can run your application may be enough. By forcing your customers to run the license server on a physical machine, you limit your vulnerability to the malicious use of virtual machines to duplicate license server deployments. By using trusted storage, you further limit malicious duplication of the configuration of the physical machine running the license server.

Justification for Best Practice #3b: first, you only have to provide one build of the license server for the one platform of your choice and are able to pre-install and pre-configure it; second, binding to the UUID of the virtual appliance allows your customers to move that virtual appliance without re-hosting its licenses; third, packaging your license server as a virtual appliance gives you the opportunity to encrypt that entire virtual machine/appliance to limit tampering.

What software licensing best practices have you implemented for virtual machines?

Beware: “All-You-Can-Eat” Software Licensing Can Give You Indigestion!

By: Jim Geisman, Software Pricing Partners

Whether you call them "enterprise-wide", "site license", "all-you-can-eat", or "strategic", all involve unlimited software license use in one way or another. If you are involved in these unlimited software license deals, no matter what they are called, you may be leaving a lot of money on the table unnecessarily and as a result, suffer from chronic indigestion.

Of course, it is always better to do the deal, and get the cash, than to leave money on the table. But if you are going to do the deal, either get paid the amount YOU think is fair or make sure you get something in return. An unlimited software license doesn't have to mean an unlimited everything-else deal.

When a prospect asks for an unlimited software license deal, price isn't the only response. Recognize there are many dimensions to a deal so look for ways to pull out value and costs to make sure the money you receive is in line with the value your software delivers.

Prospects wanting unlimited software license use shouldn't be given a perpetual license. Unlimited perpetual license deals limit a vendor's upside to add-ons. Instead of a perpetual license, consider using a limited-term license, a.k.a. subscription license. If you are going to get "hosed" make sure you know how long that situation will continue. Even all-you-can-eat buffet restaurants aren't open 7/24, 365 days a year.

Don't rely on maintenance and support fees (M&S) associated with the unlimited perpetual license either. Make sure M&S is priced correctly based on the level of support and the maintenance hassles you might encounter. The typical "X-percent-of-license-fee" may not even cover your costs.

If you get squeezed in M&S, consider reconfiguring your traditional maintenance and support offering. Can you offer second level support? What about per-incident pricing with a guaranteed minimum? As for upgrades and product updates, forget about them – updates maybe – but upgrades are out.

Another way to deal with all-you-can-eat unlimited software licenses is to extend the range of volume discounts.

Suppose a multinational company wants to use your products in multiple subsidiaries and multiple locations within each subsidiary. To make sure you are being paid fairly, develop a discount structure that will encourage customers to pay fairly.

Start with a volume discount schedule that maxes out at a reasonable (large) number of users. Offer a site license price that is beyond the maximum number of users. In addition to the site license price, offer multiple-site license prices that are also suitably discounted. Then provide an enterprise-wide license price that is beyond the multiple-site license discount schedule and is an amount you would accept.

Even if the customer is unwilling to pay what you ask, you have provided a framework for establishing a price you think is fair while offering the customer less costly options.

But frankly, we've found no one is really empowered to do an enterprise-wide deal especially in a huge multinational company. Sometimes the enterprise-wide deal is a way to avoid license administration. If that is the case, either make the administrative tasks easy or do the work for the customer if you can. In general, though, a request for an unlimited deal is really just part of the negotiating dance and the more you have heard the music the better you can dance.

Regardless of how you configure the unlimited deal, make sure you are gathering information about software license usage even if the customer is paying a flat fee. It is essential to gather usage data so you know what an unlimited deal really means and what it is costing you so you use this experience to price other deals appropriately and, possibly, avoid unlimited deals altogether.

We've described a few ways to deal with "all-you-can-eat" software licensing deals. How do you respond to your customers or prospects who want them?

Jim Geisman is a guest blogger on Flexera Software's Entitlement and Compliance Management blog. Jim is the founder and principal of Software Pricing Partners, Inc. He provides senior management counsel, marketing and sales consulting services and workshops. Learn more about upcoming workshops (including the one after SoftSummit 2010).

Reaching New Markets with a Metered Software Licensing Business Model

By: David Znidarsic

What do you do when the high-end market for your high-end software product or high-tech intelligent device starts stagnating? Throwing more capabilities into your existing product to lure existing customers to upgrade might not do the trick. You might have to appeal to prospects in lower-end markets, some of which may be your former high-end prospects.

Should you Discount?
Luxury brand owners have known for years that you can't just reduce the price of your high-end product to reach lower-end prospects. Your high-end customers will get wind of that and demand the same discount, or worse, shun your brand because your reduced priced also reduces your product's perceived value.

Should you Retool?
If you can't change the price of your product to reach lower-end markets, then you have to change your product, but how? Lower-end markets may indeed have unique needs that cannot be satisfied by your existing product or even by a derivative of your existing product. If this is the case, then you have a much harder decision regarding the direction of your business. However, often your lower-end prospects today aspire to be your high-end customers tomorrow. They currently need all the capabilities in your high-end product, but can't yet afford it. So even as they acknowledge that your current product is out of reach for them, they would like to see a straightforward path that gets them from where they are today to where they aspire.

Should you Offer to Lease?
Leasing of luxury items has long been a way to reach lower-end markets without discounting or retooling. Here are two metering options to consider when considering leasing: by time and by usage.

• Meter by Time – Some of your lower-end prospects may value the ability to use as much of your product as they need within the lease period. The pricing of the meter by time will be based on the assumption that the customer will be heavily using your product through the lease period. When the lease period ends, your software will be controlled with an expiring electronic license that is enforced by the software itself.
• Meter by Usage – Some lower-end prospects won't be using your product continuously, so will want to extend the lease period. However, an extended lease period may be too expensive for them. These prospects will want to pay for only the amount of your product they actually use regardless of how long they possess your product. The payment for this type of model can range from pre-paying for a specific amount of usage, to post-paying for the amount of actual usage, to putting down a deposit toward the eventual post-use payment.

Defining Usage
A key component to metering by usage is the ability to define usage in a way that is satisfying to you and your prospects. After all, prospects that need such fine-grained pricing will scrutinize the metric to which their price is tied.

Your pricing metric can be based on transactions processed by your application or time spent using your application. If your product offers very discreet units of value to your customers, say, number of tests performed or number of gigabytes processed, then those would be ideal metrics to base price upon. However, if your product doesn't offer such discreet metrics, metering based on time spent in your application is the best option.

Here are some other considerations as you try to define time spent using your application:

• Is application idle time counted as usage?
• Is the time the customer is navigating menu items counted as usage?
• Is one second of usage rounded up to one hour of usage?
• Is thirty minutes and one second of usage rounded up to one hour of usage?
• Is only sixty continuous minutes of usage considered one hour of usage?
• If, say, twenty minutes of usage is immediately followed by, say fifteen minutes of usage, but both within the same hour, is that two (rounded up) hours of usage, or added together (then rounded up) to be one hour of usage?

Regardless of whether you choose transactions or time spent in your application, you will have to have a pricing policy in the event a bug in your software renders useless the transactions or time spent. Do you offer full credit? Partial credit? Refund? Neither?

Get Help
Once you have established the lease model you want to offer your lower-end prospects, you may need help managing this entire process in an automated fashion. Application usage management technology can help you process, monitor, and enforce whatever lease model you offer to your prospects.

                                                                                                                                        

Entitlement and Usage Management Headaches Part II: Too many product models & configurations…strategies for reducing SKUs

By: David Znidarsic

Previously we discussed how to some, "SKU reduction" means simplifying a complex product portfolio. This time we will discuss how others view "SKU reduction" as a means to efficiently producing a complex product portfolio.

Efficiently Producing a Complex Product Portfolio
You might be spending too much money and time producing the multiple products that comprise your complex portfolio. In this situation, you are convinced that you must continue to offer the complex combination of products and options you currently sell. In fact, you might even be planning to provide more product combinations and more options. Here, you are not trying to reduce the complexity of your portfolio, but trying to produce your complex portfolio more efficiently.

Often a company doesn't plan to create a complex product portfolio. Instead, it happens over time when markets demand products derived from an already successful product. Those derivatives could be a result of capabilities added to or removed from that product; then there are derivatives of those derivatives, etc. After a few years or few product releases, you've met the immediate customer demand, but you can't sustain the cost of providing all of these options.

In this example, at the core of all these derivatives is a base product. The best way to efficiently continue to provide all derivatives is to engineer one master product, to which and from which capabilities can be added and removed. If those capabilities are implemented in software (or firmware), then use an electronic software license management system to control which customer gets to use which capability. Even if licensed capabilities and capacities are implemented in hardware, electronic license management systems may still be able to help. If the hardware's configuration can be controlled by firmware or software, then that controlling firmware/software can interrogate an electronic license and instruct the hardware how to configure itself.

Implementing an electronic license management system to efficiently produce and maintain a complex product portfolio is a best practice followed by thousands of hardware and software providers. The flexibility of such a system allows you to introduce additional capabilities to existing customers, as well as reduce capabilities in order to reach low end markets without eroding your high-end price points.

How have you tackled "SKU reduction" and "SKU complexities"? What are your best practices?

Entitlement and Usage Management Headaches—Part I: Too many product models & configurations…strategies for reducing SKUs

By: David Znidarsic

The term "SKU reduction" is thrown around a lot these days, but it means different things to different stakeholders. To some, "SKU reduction" means simplifying a complex product portfolio. To others, "SKU reduction" means efficiently producing a complex portfolio.

Simplifying a Complex Product Portfolio

If your prospective customers are confused by the complexity of your product portfolio to the point where they don't buy (or buy less) because of its complexity, then you need to simplify that portfolio. You can do this by either dropping products or by bundling products and options together.

However, be aware that while a complex product portfolio might be a problem for your high-end prospects, the fact that your low-end customers were able to buy only the products and options they needed may be the only reason you have low-end customers. Complexity can be perceived as either choice or chaos.

However you get to the conclusion that your product portfolio is too complex, simplifying your portfolio cannot be done over night. Of course, you may have entered into contracts which commit you to provide certain product combinations into the future. But, more fundamentally, you may not even know who is using what product or product option and how they are using them.

Making the decision about what products and options stay, go, or become consolidated starts with knowing who is entitled to what products and options. It then proceeds to who has fulfilled, deployed, and configured those products and options. While it may be a challenge to even get that far, you can go further. Instrumenting your products with usage management technology can allow you to harvest information about the environment in which your product was deployed as well as when and how often it has been used. Usage management technology can even provide this information back to you through your multi-tiered product distribution channel. Visibility into any or all of the transactions mentioned above will give you the information necessary to decide how to reduce the complexity of your portfolio.

Next time: Part II—Efficiently Producing a Complex Product Portfolio

Software Entitlement Management & the Compliance Burden of Proof

By: Cris Wendt

If you buy software licenses, you will probably be presumed guilty until proven innocent for ensuring that you are using software in compliance with your software license agreement. The burden of proof of evidence is place upon the user of software. If an audit occurs, you somehow must match the deployment and usage of software to some combination of documents to show entitlement rights.

However, if the burden of proof were placed on the shoulders of the software vendors, then the story may be different. This is especially true in the world of B2B enterprise software.

As a colleague of mine once said, "compliance is like the sound of hands clapping – one hand is usage reporting and software asset management from the customer, while the other hand involved in the clapping represents the software vendor's entitlement management systems." In most cases, the hand representing the software vendor's entitlement management system would be missing, or at least missing a few fingers.

Many software vendors will readily admit that their records of what software licenses customers are entitled to use are so bad, that they often call their customers to find out what the customer should own. In fact, I think that every software vendor over $1M in annual revenue has dirty data in their entitlement management systems.

How can this be? There are several problem areas that seem to contribute to an ever-worsening situation. Below are some of those problem areas:

• Non-standard agreements with little auditability: Many software vendors derive the lion's share of their revenue from large ELAs (Enterprise License Agreements )– deals designed to meet the specific needs of their customer, but they are often non-standard in nature and include many terms that cannot be tracked without spreadsheets, and knowledge inside of people's heads. One example is the "remix" – an approach to allowing customers to remix their licenses annually, based upon a formula that involves the list price of the software, and, the percentage of the total software purchased.
• Fuzzy license models: Some software vendors sell concurrent licenses, but aren't clear on the distribution of those concurrent users – are the users all local to one building, or, can they be dispersed geographically? The issue arises when licenses are being used on a worldwide-basis (24 hour usage), but the pricing intent was for the licenses to be used locally.
• Product packaging changes: Over time, software entitlements change because the underlying software product packaging changes. As the result of M&A, market re-branding, or end-of-life processes, customers may be "migrated" from one set of products to another, using a method that is customer friendly, but difficult to track or audit in an entitlement management system.

• Using ERP systems as entitlement management to track license rights: ERP systems were designed to track the manufacture and delivery of physical goods. Upon delivery, the product is shipped, and the role of the ERP typically ends. With software, the trouble usually starts after the software is delivered, as exact mix and version of software, including who exactly is entitled to use the software evolves over time due to upgrades, updates, moves, M&A, and product repackaging. Over time, software vendors often lose track of which customer is entitled to own a product. A true entitlement management system is needed, and must be properly integrated with an ERP system to effectively manage software entitlements.

Next week – How to approach improved entitlement management…

Vendors and Enterprises Moving Closer Together on Software Licensing

By: Randy Littleson

In this interview, Amy Konary of IDC talks about how vendors and enterprises are moving closer together on their viewpoints related to software licensing.  She discusses where a true "partnership" relationship is emerging and where it is not.  She details the areas of breakdown and avenues to move vendor/customer relationships to a new level.

 

Cost Savings or Revenue Increases – Where to Start When Leveraging Embedded Software?

By: Steve Schmidt

I recently had a chance to sit down with Jane Barrett, VP of Research with Gartner's AMR Supply Chain Research group and we had a chance to discuss device lifecycle management, the benefits of embracing embedded software and how high-tech manufacturers prioritize these initiatives.  It was interesting to hear Jane's perspective on using software to control the configuration and capacity of a device or system, the benefits and value of postponing the final configuration decision to realize significant cost savings in the value chain, and the great value in using the configuration control to create new types of products that can reach new markets with new business models and price points.  The question becomes… where should a company typically start—strategies for cost savings or increase revenue?

As we learned with Jane, the answer may be found in the maturity of the organization's value chain processes.  Gartner highlights a model that includes these levels:  1) React, 2) Anticipate, 3) Collaborate, and 4) Orchestrate.  Most organization are in the first level, with very few reaching the third and fourth levels today.  Within this model, organizations typically start with a focus on cost reduction, then increasing customer satisfaction, and then increasing revenue.  A key reason for this approach is the type of questions asked and the type of measurements used in each stage – e.g., What is the overhead to manage the system and respond to customer needs, then what would customers expect from us and how can we delight them, and then how can we leverage the system to grow the business?  Another reason is that the cost reduction steps often offer the easiest ROI calculation, even if it is not always the largest ROI.  A third reason is that the owner of the project is often in a cost center (e.g., Operations, IT), rather than a profit center (e.g., Sales, Business Unit).

Prioritizing the benefits from an investment is helpful in setting expectations properly and maintaining focus through each phase.  The maturity model can be leveraged to justify the priorities.  At the same time, it is useful to look at the full set of opportunities before beginning.  Highlighting that embedded software can be leveraged to reduce cost (create a single device and use embedded software licensing to electronically turn on and off device capability and capacity) AND increase revenue (use embedded software licensing to reach new markets by creatively packaging and pricing intelligent devices) builds a more compelling argument.  It builds momentum with more stakeholders.  It paints a broader vision and ensures choices made early on will enable additional benefits. 

Where and how do you believe device lifecycle management will be leveraged first?

Software Licensing, Monetization and the “Build vs. Buy” Decision

By: Jim Geisman, Software Pricing Partners

Don't wait too long to make decisions about software licensing and monetization like one of the entrepreneurs at a meeting I recently attended. This entrepreneur was about to launch an innovative mobile application and was asked "How are you going to monitor and monetize your offering?" He had this deer-in-the-headlights look and said "We don't know but we're going to build our own system."

I suppose there are some things that you can leave until the last minute but it's not smart to do this when it comes to making money. You can make more money if you monitor application usage but some things need to be done in advance:

• Choosing which metric to use for your product and which functionality will go into the various packages of an offering
• Building "hooks" into an application to monitor and ultimately monetize certain features or user attributes using these metrics
• Knowing the usage information needed so the right price levels, discounts, and products are included in a billing or credit card transaction

If you do these things in advance, the system(s) that monitors and monetizes and application activity can be used more effectively in generating revenues that arise from the metric and packaging parts of your pricing model. This system is also critical to fulfilling – literally and digitally – the value that is promised by your application.

Because this system is so critical to your financial success, think twice before spending "core" development dollars on this "non-core" activity, applications monitoring and monetization. In general, in-house developed non-core applications don't work out well because companies tend to overestimate the benefit they get and underestimate the time and ongoing effort such a development requires.

In this case, find an organization whose core activity is applications monitoring because a poor "build versus buy" decision can hamper your monetization strategy and revenues.

There are two reasons for doing this: focus and expertise. Companies that focus on monitoring and monetizing applications will always do this more effectively than companies that focus on doing something else – like delivering applications that meet customer needs. A focus on one area (applications monitoring and monetization, in this case) means acquiring the expertise to build products that anticipate the needs of a broad customer base – something an application developer cannot do because they can't anticipate how their needs may change over time.

The net of all this is use others' expertise to leverage your investment in product development and support. Maintain your focus on monetizing the value you deliver to your customers, if you want to maximize your revenues.

Jim Geisman is a guest blogger on Flexera Software's Entitlement and Compliance Management blog. Jim is the founder and principal of Software Pricing Partners, Inc. where he provides senior management counsel and marketing and sales consulting services. He has led consulting engagements for a broad range of clients addressing fundamental issues affecting business success.

The Value in Sharing Software Licensing Data Between Vendors and Customers

By: Randy Littleson

Jim Geisman, Principal & Founder, Software Pricing Partners, discusses the relationship between software vendors and their customers.  He discusses why each party is afraid to share data with the other and discusses the value of doing so in terms of improving vendor/customer relations.