Entitlement and Compliance Management

The Ten Step Process: Converting Your High-Tech Company into a Thriving Software Company

By: Cris Wendt

Last week we described what we see in many of the high-tech manufacturing markets – companies wanting to transform from a pure-play hardware company to a successful software company – and some of the associated problems—software licensing, packaging, and delivery, entitlement management, license enforcement, etc.

Over the next few weeks, we'll describe how high-tech manufacturers can think like a software company by adjusting their business and licensing models, deployment methods, and operational and business processes to be more like a software company.

We've laid it as a 10 Step Process:

1. Understanding the Opportunity that Becoming a Software Company Can Offer
2. Use Software Licensing Methods to Enable Product Agility in the Marketplace  
3. Balance Revenue Recovery & Customer Satisfaction With Your Compliance Strategy  
4. Designing a Model to Deliver Digital Goods  
5. Begin the Process Journey – Designing for Entitlements & Fulfillments  
6. The Importance of the License Lifecycle  
7. Designing the "Prospect to Support" Business Processes  
8. Empower Customers with Self-Service Capabilities  
9. The Supply Chain Design Secret All Hardware Companies Need to Know  
10. Compensation Models to Unleash the Power

Next Time – Step 1. Time to tune in, turn on, and buckle-up! Let the journey begin.

Expanding Software Compliance Programs through Automation

by: Steve Schmidt

A number of recent discussion with ISVs have centered around expanding their software compliance programs.  This has been triggered in part by industry examples such as those provided by SAP and Oracle.  SAP has a policy of reviewing compliance frequently, and has provided basic tools to gather the required information.  In recent news, Oracle has a verification program underway, where third party solutions have been confirmed to provide high quality data that can be used during a compliance review cycle.

Automation is a key requirement to expand a software compliance program.  Neither the ISV nor their Enterprise customers will tolerate too much manual activity.  From the Enterprise perspective, data regarding what is installed and used needs to be collected rapidly and accurately, from across the entire enterprise.  If there is too much work, ISVs cannot reasonably expect high participation in the program.  Instead they will hear “I want to be in compliance, but need your help to get there; what tools can be used to do that?”  If pushed too far, user satisfaction also declines and starts to affect all parts of the customer-vendor relationship.  From the ISV perspective, mechanisms to get the usage data back to them are needed, as are mechanisms to perform the comparison of usage data to a full list of software entitlements per customer.   Hiring tens or hundreds of additional employees to go onsite to gather data, or to compare lists, is not an option. 

Three key considerations in determining an approach to automation are:

• The level of pre-instrumentation required in the application - In other words, does the application need to be built in such a way that it can be identified and tracked?  This depends on what type of information is needed to find the application and determine “usage” per the software license agreement.  For most applications, solutions can be built to identify where existing versions are deployed and once that is done, any components required for advanced usage tracking can be installed in a targeted manner.  This process can be improved, though, for future generations of the product by shipping those versions with a self-identifying and usage tracking capability.  Thinking through that design now will improve software compliance program expansion options dramatically in the future.

• Data access - Who will have access to the information and how it will be shared?  In many cases, the Enterprise users of the data will want to confirm that the solution is sending only the data required.  A demonstration of the type of data may be sufficient.  In other cases, the ability to review the filtered and pre-packaged results before they are shared with the ISV will be a requirement.

• Entitlement aggregation process – What will be the ultimate source of truth regarding the customer entitlements?   Many ISVs sell and deliver their products through multiple channels, including direct, distributors, resellers, and retail.  Ideally, there would be a common view per customer across all these software entitlement sources, which is maintained automatically so that it is accurate at all times.  Integrating that data source directly with the data regarding entitlement consumption (what is downloaded, what is installed, what is used, etc.) will further streamline the process.

Where do you see automation successfully driving software compliance program expansion?  What other factors are key to the automation process?

 

The Secrets to Moving from High-Tech Supply Chain to Software Licensing Expertise

By: Cris Wendt

The race is on for equipment manufacturers in IP telephony, storage, electronic gambling/gaming, manufacturing control, security, and medical devices to become more like a software company, if not an outright software company. Due to a variety of factors including increased market competition, commoditization of the underlying hardware platform, end-customer appetites for virtual appliances and increased investments in software to establish differentiation, many equipment manufacturers are becoming software companies. In fact, most of these companies now invest more of their R&D budget in software, and not in the underlying hardware. In most cases, the actual hardware component is usually purchased from another supplier.

This wide-scale trend is underscored by comments we hear from these companies, such as…

• "We are moving to software as a business, and no longer giving it away."
• "Our CFO wants recurring revenue streams, just like a software company."
• "We need to establish a software business model."
• "The hardware is just a vessel to sell our software."

What these companies are finding is that the operational excellence that they have created in their hardware supply chain seems to elude them as they move to a more software-centric business model.

For equipment manufacturers, the automated systems and processes that were developed to produce a physical device, don't work as well for software, and as a result, many processes have become manual, and, ERP and CRM systems are being endlessly taxed and stretched. Customer records become inaccurate, and visibility into the "installed base" becomes difficult at best. Even the sales culture and compensation models are challenged. Traditionally, the sales forces of these companies were used to selling the physical devices, and giving away the software "as a kicker", today that is no longer the case.

Software operational excellence seems elusive to these equipment manufacturers, yet ironically, there is a supply chain discipline required even in the software world. It's just that the paradigms for an equipment manufacturer are slightly, yet profoundly different than those required in a software world. When working with equipment manufacturers, the companies seem to have many of the concepts and ideas, but they seem to be wrapped into a giant ball of assumptions that are often incorrect, and undermine how a software business is approached. These assumptions become institutionalized in an inefficient manner, and then often get "fixed" in incorrect ways, leading to more confusion and problems.

Next Week is Step 1 – How to Think Like a Software Company.

In the following weeks, we'll explore various ideas, business and software licensing models, and processes to enable the transformation to a world-class software company!

 

Ownership of the Software License – What Does it Mean for Software Pricing?

by: Cris Wendt

Recently, as you may have read, the 9th US Circuit Court of Appeals ruled that software publishers can forbid the transfer and sale of software licenses as part of the terms of their software license agreement.  For most software publishers, this is not really a new revelation, but it does underscore how to think about your software when you bring it to market.

 
The sale of a software commercial software license (generally) does not convey ownership, but simply a “right to use” the software.   This means the person who buys the software license is only using the software in a compliant fashion when they use the software based upon the terms of the license agreement.   The end-user cannot simply use software any way they want.

What this also means, is how you should think about software when you price its value.  We often like to stress with clients that produce software that when creating license and pricing models, it’s best to think of the software license as a service that provides value in the context of usage.  In that context, the more of the service that the end-customer uses, the more value they obtain, and therefore, the more the software publisher can charge for their offering.    This allows the software publisher to really understand value to the end-user of the software provider, and perhaps think outside of the simple box of feature and function and into additional dimensions of license rights.   This can also lead to some segmentation of markets for products, and therefore, additional price points.  More importantly, it allows the software producer to really match the value of the software to its expected use.

Some ways this may affect your pricing includes:
• Resale or re-distribution.  While the software producer can limit the resale of software, they can in fact allow re-sale, but perhaps at an optional price. Some software publishers allow the movement of software license rights from a particular user to another use within a company for some set number of times to accommodate the need to share the value of the software among users.  Beyond a set limit of transfers, the software publisher can charge additional fees.

• Wider use of concurrent licenses.  In many markets, software products can be used by any user, as long as only a set number of users can use the software at any one time.  The concurrent license usage can be priced based upon the scope of usage.  For example, you can charge an additional amount of the users who access the software are geographically dispersed, as more value can be obtained if the software usage follows the sun. 

• Limited Time Usage.  Some of your customers may use the software for limited periods of time during the day, or, over the course of the year.  When taken to an extreme, this becomes a form of pay-per-use license and pricing model.

• Project-based Usage.  Some customers plan to use software only for certain projects that exist for certain time periods, and want to allocate the usage of software to a specific project, using what is often called OPEX (operational expense) budget.  This may lead to offering your software license as a time-based license for the period of the project.

• Payment Terms.  Some enterprise customers who use software may have the need to manage cash flow, and may be willing to buy a software license if they can spread the payment terms of a period of usage.

In many cases, the enforcement of software usage as described above requires technology such as a license service or license manager, but these technologies are mature and well understood and can easily be applied to the creation of new license models. 

This approach to understanding usage will become a vital approach as software usage becomes more “cloudy” with the emergence of cloud computing, virtualization, and SaaS delivery mechanisms.

 

SoftSummit Shaping up to be a Great Software Licensing and Pricing Event

We're about a month away (October 11-13) from our annual SoftSummit software licensing and software pricing conference in San Jose, CA.  We are very pleased with the way the agenda has come together and are expecting a great crowd of industry experts from some of the world's leading software producers and high-tech manufacturers.

We're very pleased to have Tom Reilly, President and CEO of ArcSight (it was just announced that HP is acquiring ArcSight), as our keynote this year to share his perspectives on the role of software licensing and entitlement management in his rapidly growing security and compliance management solution company. 

This year's event will also feature speakers from Microsoft, Oracle, Symantec, Synopsys, Siemens, EMC, Alcatel-Lucent, CPU Technologies, CA, Big Band, Invensys, Software Pricing Group, IDC and many Flexera Software led sessions.

Topics will range from discussions on the impact of SaaS/cloud/virtualization to usage-based software licensing models, the convergence of hardware and software business models, software tagging and continuous software licensing compliance.  There is a dedicated business track and technical tracks on software licensing and entitlement management.  In parallel, we are hosting a user group meeting for our FlexNet Producer Suite On-Demand products.  Amy Konary of IDC will also share the results of the just completed software pricing and licensing survey as well as her predictions for 2011.

You can review the entire agenda for the event here.

SoftSummit promises to be a thought provoking event with lots of opportunities to network with some of the industry's best and brightest.  You can register for SoftSummit 2010 here.

Convergence of Software and High-Tech Licensing Models

By: David Znidarsic

Many of today's high-tech devices look more and more like general-purpose computing platforms. As such, the digital goods (software and data) on these new platforms can, and should, be managed in the same way that digital goods are managed on other general-purpose platforms. They should be entitled, fulfilled, installed, licensed, returned, transferred, and updated all using the same usage management technologies that have been used by the software industry for over twenty years.

Many early-stage high-tech devices had all of their logic burned into their circuitry, then the circuitry became programmable, then a device-specific firmware layer was added, then the firmware because upgradeable, then the firmware became software, then the circuitry commoditized into a general-purpose computing platform. Firmware upgrades are almost always free and the conversion from firmware to software often inherits that same pricing policy for software.

With the standardization of their high-tech devices, manufacturers can more efficiently develop enhancements for their devices in software and even open those devices to software development by partners or by customers.

Regardless, of whether these high-tech devices become embedded Linux boxes, embedded PCs, or new platforms, the fact that software developed for them has become their differentiator makes that software a valuable asset that must not be given away for free.

If not free, how do you monetize that asset? If your device is complex enough to host a significant software layer, it is likely complex enough to offer multiple capabilities, each representing a tangible value to your customer. From your perspective, you want your customers to pay for the new capabilities you add in software. From your customers' perspective, they don't want to pay for capabilities that they don't use.

Using entitlement and fulfillment management systems optimized for digital goods helps you, your distribution partners, and your customers know who owns and who has received which of your products and capabilities.

Using electronic license management technology to grant access to only those capabilities that have been paid for by a particular customer is the best practice for monetizing your investment in your device's software by controlling its usage, its returns, its transfers and its updates.

You can also achieve enormous manufacturing efficiencies by standardizing your device's platform and by adding value in software. However, that same method of manufacturing efficiency can be your key to revenue growth through new licensing and pricing models.

How have you seen software and high-tech licensing models converge?

Making the Subscription Software Licensing Model Work for You

By: Cris Wendt

Subscription license models are still a hot topic in the software industry, especially with their more widespread use with SaaS software.  The subscription license model typically involves providing the combination of a software license (or “right to use” the software) along and all software updates during a period of time, typically on an annual basis.  The benefit to the software publisher is the promise of a strong annuity-based revenue stream.  This is because the revenue for a subscription license model is recognized on a company’s income statement over the period of the term.  In the traditional perpetual license model, the revenue is typically recognized at the time of booking, leading to the proverbial revenue “hockey stick” at the end of the quarter when most deals are booked. Most CFOs see the subscription software license model as a good way to manage revenue streams in a more predictable way, and, create an overall higher revenue stream over the course of time when the subscription license is renewed. Typically, the cross-over point is in 4-5 years, at which time the subscription license model provides more total revenue.

Certainly, the apparent downside can be the initial revenue drop to the P&L if the company sells a subscription license instead of a perpetual license.  For a perpetual license (say $100) and maintenance (say $20) that is sold at the end of the quarter, $100 is recognized immediately, the maintenance revenue deferred over the course of the agreement.  When a subscription license is sold at the end of the quarter,  $0 at that time if an annual subscription license is sold.   The $35 - $40 for the subscription license fee (a typical number if the perpetual license was priced at $100) is then recognized over the next year.  Hopefully, the customer continues to renew the license, and over time, a stronger revenue stream is build.   However if the sales rep is compensated on bookings or even revenue, then there is little incentive to sell the subscription license.  In addition, the CFO doesn’t want to take the revenue “hit” as the revenue stream is converted to the more predictable subscription revenue stream.
If the only option is to sell a single subscription license instead of a single perpetual license, then the benefit is marginal, and, the sales rep may not be incited to sell the subscription. This can lead to low adoption.

However, the secret is to increase deal size with the subscription license, so that the initial bookings remains the same, even though the revenue recognition occurs over a time period. This creates the proper incentive for sales, and, helps to increase your market penetration.

The way to do this to find situations where the demand for your software licenses is higher than the customer can afford in a single purchase. This allows the customer to acquire more software license rights in a single purchase, and satisfy the needs of more users. This tends to work quite well in many desktop application markets where teams of employees need to work on tasks, and when the tasks may change over time, requiring the purchase of new software.  In these cases, you can equip more users with your software.  This can also work well in some enterprise software markets, where you want to achieve rapid penetration across an entire organization, and the subscription license model makes this adoption easier.  In these cases, the customer may buy more software over time for more users, because it’s more affordable for their budget.

In addition, software licenses may work well where customers generally prefer to purchase the perpetual license, but have an occasional need for periods of high workloads, and the subscription license can meet this need.  

So, if your choice is only perpetual vs. subscription, the option may be to remain with the perpetual license, as your business is probably built for selling that way.  But, the subscription license model works best when it helps you to capture more business and opportunity.
How have you made subscription software licensing models work for you?

Turning High-Tech Device into Virtual Appliances

By: Steve Schmidt

A new customer, who happens to build network devices, recently summarized a number of reasons for deciding to add a virtual appliance to their product lineup. Looking internally, they found the reasons to make the transition centered around reduced costs and additional flexibility in meeting market demand. They had also surveyed their customers and found that many already supported virtualized environments in their data centers, and were ready to support other virtual machines. Customer demand for virtual appliances, as well as the manufacturer's need to reduce costs and increase operations flexibility helped drive this manufacturer to offer a virtual appliance.

Reduced Costs – Supply Chain Simplification, Hardware and Support Expenses
When the offering is physical manufacturers create inventory specifically for each customer, creating many variations, with this comes added carrying and shipping costs. Their supply chain and entire device lifecycle management process is more complex. When the offering is virtual, though, they can manufacture more generically and allow for delayed configuration. They do not have a physical inventory and do not experience high shipping costs.

In addition, the customer can experience lower implementation and support costs, as noted in a recent blog post on this topic.

Flexibility – New Business Opportunities, Disaster Recovery, and Leveraging the Cloud
Evaluation periods become much more practical when the offering a virtual appliance, rather than a physical device. The incremental cost to create and deliver the evaluation is very low, delivery is rapid, and the limitations in its behavior (e.g., reduced time period, feature set, capacity, etc.) can be controlled via the embedded software that ships with the virtual appliance. There is no need to return any parts. The result is that more prospects are willing and able to try out the product, and sales cycles advance more rapidly.

The delivery of a virtual appliance can also be used to differentiate the offering and add more value to it. For example, a Disaster Recovery electronic license could be delivered with the physical system. In the extreme case that the physical device was destroyed or could no longer be operated, the electronic license for the virtual appliance could be rapidly implemented as the backup. Offering a virtual appliance also makes it more practical for the customers to consume the capability via Cloud computing resources, whether public or private clouds, matching the computing model of their choice. This concept can be extended to other special cases, such as "burst of use" or unique "test and development scenarios". The result is a product line extension for the manufacturer, and new high-value ways to use the product for the customer.

Share your thoughts on virtual appliances. Are you moving to virtual appliances, and what benefits have you experienced?

 

 

 

Desire for Business Intelligence on Software Licensing

By: Randy Littleson

 

Amy Konary of IDC talks about "information as power" when it comes to software licensing use.  Understanding how software is used is a critical insight to both enterprises and software vendors alike.  Amy discusses what companies can do with this information to better their software license 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?