In the world of consulting in entitlement management and software licensing (or any other field for that matter), the term "best practice" is often used to describe the best process, method or approach for performing a particular task. It’s intended to represent the prevailing wisdom on a particular topic based upon experience and business results. It’s a term often used by both consultants and customers to describe a proven approach to solving a problem.

Best Practice is both powerful and misleading. Many best practices can be broadly applicable and should be adopted, while many are not. It’s important to realize when to use a prevailing best practice and when to not simply adopt what’s worked for someone else.

Some processes or approaches don’t need to be constantly re-evaluated as they are not important to the mission of the business. Processes like those involved in accounts receivable are not often mission -critical (and subject to audit scrutiny), so it’s most efficient to simply adopt prevailing best practices.

Over time, other best practices may evolve due to how companies manage changes in business regulations (SOX auditing, FASB compliance), technology (SaaS, Virtualization, Cloud Computing), market forces (economic conditions leading to a shift from Capital Expense or CAPEX to Operational Expense or OPEX), the competitive landscape (shift in license models by competitors), or other factors.

Having watched software licensing and entitlement management evolve for 15 years, it’s interesting to see how companies view best practices, especially when it comes to establishing powerful market positions.

Ironically, I often see companies struggle with extensive market research and analysis about what their competitors do in order to identify and adopt an existing best practice in an area where they should be looking for differentiation. We recently worked with one client who wanted to know what the prevailing best practice was for the "license metric" in their market. The license metric is the most important attribute of a software license – it’s the characteristic that drives pricing (e.g. counted user, per seat, per-minute of usage, etc). In a sense, they wanted to adopt what the market viewed as a standard way to price software, which is typically an area companies look for a competitive advantage. It really isn’t a surprise this company was not doing particularly well in the market.

On the other hand I have worked with and for companies who actually create best practices. These are the ones who are looking for specific competitive advantages or to accomplish certain strategic objectives and didn’t care too much about existing standards. I remember working with one small company who had an informal mantra of freakishly friendly - we spent extensive time with the executive leadership team developing software license models and an entitlement management process to create an extremely positive customer experience. As a result, they set a new highbar on best practices for customer experiences.

In some upcoming blogs I’ll be exploring some software licensing and entitlement management best practices. I’ll look at when it’s best to adopt prevailing best practices because it’s the most efficient approach. More importantly, I will discuss when it’s time to seek out and find competitive advantages by adopting and evolving best practices.

When working with software producers and high-tech manufacturer who are implementing software license technology, we use a top-down methodology to find the best fit for how that company will implement software licensing. The process is fairly straightforward: we work with product and business leaders to develop a written compliance philosophy, and then use the compliance philosophy to create one or more enforcement profiles which guide the implementation of software licensing. The result is a well-designed and consistent approach to software compliance and enforcement that balances the company’s desire to balance revenue recovery with a positive customer experience.

This approach can also be used for companies that aren’t using software licensing, but do want to evaluate what the enforcement experience should be for customers who are using software outside the bounds of the license agreement. The importance of this process is the conversation that results among the different business stakeholders who are participating in the process. It allows different perspectives to be discussed, evaluated, and integrated into the way software licensing will eventually be implemented (or perhaps, not implemented) in a product.

Without such a process, different product groups often make their own decisions, sometimes inconsistent with how other product groups implement licensing or approach software compliance, or, they may make decisions based upon one technologist’s view of how the product should behave, possibly ignoring the wider business perspective.

The compliance philosophy is meant to be a guiding statement about how a software publisher views software compliance and will guide the development and implementation of software licensing and associated activities. The compliance philosophy reads a little bit like an extended mission statement. It will need to consider factors (descibed in my previous blog), such as product, market, lifecycle, and geographic considerations, and describe at a high level, the approach the publisher will use to guide the implementation of technology, and it will trade-off revenue recovery efforts with customer experience. The software compliance philosophy is typically 3-4 paragraphs in length - less than a page.

After the compliance philosophy is established, we use a somewhat standardized template to develop a software enforcement profile. The enforcement profile lists about 10 -15 different parameters of non-compliance, such as: using software on the wrong machine, an incorrect user using the software, accessing an incorrect version of software, exceeding the allowed count, etc. For each of the parameters, we assign a specific enforcement action from a list of about 8 approaches. These enforcement actions collectively represent a range of experiences from "Do nothing – No Product Disruption", to "Message the User – Product Operates Normally", through other actions to the other extreme of "Disallow Product Operation". The collection of the 10 – 15 different parameters with its selected enforcement action is considered an enforcement profile.

We typically start by creating about 5 or 6 enforcement profiles for larger companies, based around where we think there may be some commonality for enforcement behavior. For example, we may create one profile for "mission critical" products, one for "commodity products sold into Asia/Eastern Europe", another for "Software sold in large enterprise deals", etc. As we go through the process to develop and compare the different profiles, we usually consolidate the profiles down to one or two. Typically, companies will trade off the simplicity of fewer, more powerful enforcement profiles over the complexity of too many.

After the enforcement profiles are created and socialized, the remaining steps are to implement the software enforcement profiles in standard ways (typically, creating standard implementation libraries), integrating changes to the enforcement profiles into an existing change management process to ensure that consistency is maintained over time. That is how you maintain a good design while implementing software licensing and auditing.

Does your company have a common compliance philosophy? How do you approach this issue?

By: Cris Wendt

Sometimes the topics of software license compliance and enforcement seem twisted, very much like one of those M.C Escher drawings popular in the 70’s and 80’s that show complex physical objects connected in impossible ways though the optical illusions created by his drawings.

To this end, I thought a few blogs on the subjects of enforcement and compliance would be useful and interesting topics.

Let’s start with some basic definitions: software license compliance is a broad term to describe the behavior - whether or not software is being used within the bounds of a software license as established by the license agreement or the software entitlement the customer purchased. Software license enforcement is the mechanism or the mechanisms that are used to manage software license compliance. An enforcement mechanism will usually result in some experience to the user of the software to let them know if they are using the software outside the bounds of the software license agreement.

An enforcement technology and associated implementation method are designed to balance the needs of the software producer and the software consumer. In general, the software producer uses enforcement to grow revenue in one of two fundamental ways:

1. By making software easier to use so customers use and buy more than anticipated (making this a lower cost way to generating increased sales);

2. Or, by eliminating revenue leakage caused by software piracy and usage of software outside the bounds of the license agreement.

The software consumer doesn’t want unnecessary barriers to adoption of the software, in most cases, but they also don’t want to be out-of-compliance for any extended period of time, because that increases potential liability and risk.

Software license enforcement can be designed to create a continuum of possible outcomes for software that is used outside the bounds of the software license agreement. This continuum can vary from a "do nothing" approach on one extreme of the continuum, all the way to preventing the software from operating at the other end of the continuum. Within this range are a number of possible results such as messaging, enabling overdraft, warning customers that they’re approaching a limit, reduction in quality-of-service, and queuing requests. In fact, the outcome can vary by the specific type of software license compliance condition. For example, you may elect to prevent your software from starting if the customer does not have a valid license, but you may only want to give the customer a message if they are using the wrong version of software.

The software license enforcement methods that software producers employ don’t have to be a one-size-fits-all approach. The enforcement method can be tuned by a handful of key factors:

By: Cris Wendt

By: John Frame

This past summer, in my conversations with customers, analysts and prospects, a recurring theme was that for all the differences between SaaS and Software + Services models, the number of things that remain the same is remarkable.　Software as a Service, or SaaS, is the latest software delivery model.　 As such, SaaS can be a new way for you to have a relationship with your end-users.  It can address long upgrade cycle times and provide an advantageous cost model.

All indications show that SaaS is likely to follow the same adoption curve as any other new technology -- high growth in the initial phase, but slower growth over time, which makes sense. In fact, many of you are already thinking about and planning for this technology change and are putting in place efforts in two areas.  First, you’re making changes to your product plans, packaging and pricing to enable penetration into adjacent or alternative markets.  Second, you are making changes to ensure that you are fairly compensated for the value that your end-users are getting from the service.

Today access to your services is universally by means of a name and password, or authentication.  Most SaaS / Software + Service providers recognize the problems with authentication and are using session monitoring to try to detect over use or malicious use of the software.  Details on the user sessions are compiled. Reports are generated and based on suspected patterns of abuse; offenders are flagged and targeted for further conversations.  Session monitoring does give software vendors a level of understanding of who is using what. However, it tends to highlight the clear or extreme cases, and does not pick up on cases where the patterns may not be as clear, or if the misuse is more sophisticated. Please remember, unlike traditional software, vendors/manufacturers have a real cost associated with every user of the service regardless of whether the customer paid or not.  Understanding who is using the service and getting fairly compensated by them is a great way to expand profitably.

Licensing services offer some key benefits:　

By including licensing in your service, all of these benefits are available to you.  You can control all of these different options from the back office and modify the approach based on different users, services, geographies and channels as needed.

I’m going to go out on a limb and say that it’s highly likely you are reading this blog post because you use or offer a service that combines Authentication and Licensing.　

I’ve got a $25 Starbucks card for the first person who can, as a comment to this blog post, name the service with the following characteristics that combine Authentication and Licensing:

What is this service called? (Please provide your answer in the comment box)

By: Cris Wendt

For software producers, entitlement management lies at the heart of the business—just as the supply chain is the heart of the business for traditional manufacturers.

In the software business, entitlement management describes the rights that you acquire when you purchase a software license as well as the ongoing management of those rights.

To describe software entitlement management by analogy, we can look at the purchase of an airline ticket.  When you purchase the ticket, you are entitled to travel from, say, San Francisco to New York in seat 15A on November 11 at 8:50 a.m.  You are also entitled to receive frequent flier miles equivalent to the total miles flown for the trip if you’ve enrolled in the airline loyalty program.  To poke a little fun at the airline industry, we can also say that you are entitled to flight delays, poor food, unfriendly flight attendants, and a hard seat.  When you actually fly, then we say that you’ve fulfilled those rights.  But, if you change your mind, you may be able to change the flight date and destination, given the particular entitlement rights associated with the airline ticket purchase.

The reason that entitlement management is such an important concept for the software business can be illustrated by some real life incidents that I experienced.  Several years ago I purchased some anti-virus software for my home computer.  Based upon what I purchased, I was entitled to use the software anti-virus engine and access virus signature updates for a year. 

Near the time that my subscription was about to expire, I purchased another computer.   When I went to update my subscription, I made a request to purchase the anti-virus software subscription for 2 computers for a year. In a sense I was renewing the annual subscription for my existing entitlement and purchasing another entitlement.  After conducting the online purchase, I ended up with a total of 2 years of anti-virus subscriptions that worked on both of my computers.  This resulted in what we call “over-entitlement” – a situation where I was trying to do the right thing, but I received more than I was entitled to receive.

Near the expiration of that term, I found out that my internet ISP fees entitled me to use the same anti-virus software as part of my standard monthly fees.  As a result, I decided to access the software entitlement that was provided by my ISP and to not renew my existing entitlements.   So, I enrolled in the ISP’s program.  Meanwhile, the previous entitlement that I purchased had expired.  No problem, I thought.  However, the expiration of my old entitlement also made the entitlement that I was supposed to receive as part of my ISP service to disappear as well.  

So, ultimately what happened is that the anti-virus software company lost some revenue at the first subscription renewal. They had increased support costs to rectify the situation, and they had an unhappy customer, who may switch anti-virus providers at the next opportunity.  In addition, by not knowing who their customer is, they are losing great up-sell opportunities

Furthermore, the lack of accurate entitlement tracking can lead to problems for customers of the software producer.  If the customer is responsible for ensuring compliant usage of software, to what benchmark are they supposed to measure compliance if the software producers themselves cannot keep track of what customers are entitled to use?    Without knowing what entitlements are in effect, how do software users manage compliance?

As it turns out, this entitlement management scenario is not that unique.  We find that software companies often have much more intricate and complex entitlement management situations that occur reasonably often.   Fortunately, the airline industries can teach us a lot.  

Next Time: ERP’s Dirty Little Secret – Entitlement Management.

For software publishers, the uncertainty over change and disruption caused by virtualization appears greater than the possibility of gaining a market advantage or seeding new opportunities.  However, the study found that 13% of software producers believe there may be opportunities with virtualization, so there are positive signs that virtualization is being embraced.

The major stumbling block is the impact of virtualization to what is known as the "license metric," that part of the license model that is a measure of usage and to which pricing is applied.   A license metric is identified by such terms as: named user, concurrent user, or number of cores.   Clearly, any change to how software is licensed and priced is not something taken lightly, especially if the license metric is based upon a characteristic of the hardware.   But a failure to do anything can result in lost revenue or risk to customers who are trying to do the right thing, but aren't given any guidance or support by their software vendor and face the financial risk that non-compliance can bring.

Unfortunately, there are no magic pills to address virtualization, but if you do decide to take the Red Pill, there are some basic steps you can take, as described by Jim Geisman (of Software Pricing Partners) in a recent webinar we presented on the topic:

· Embrace Virtualization.  Virtualization is here to stay, acknowledge it, it’s a part of today's computing fabric.

· Get ready to Virtualize.  Review your pricing metrics and update your entitlement and support models.

· Commit to a Position:  At a minimum, establish a platform neutral position where your customers are not at a disadvantage for using your products in a virtual environment.  However, seek ways to find competitive advantages:  Offering your products as "virtual appliances" or using virtualization as an entry to cloud computing are possible starting places.

· Establish a Compliance and Enforcement Philosophy: Determine your position with balancing customer experience with the need to manage revenue.  Do you have trusted customers who simply want to be compliant in a virtual world; or do you have problems with intentional software theft or piracy?  Once you’ve characterized and segmented your market, you can then apply the correct level of technical enforcement.

· Partner for Success:  Companies like Acresso can help you map out a roadmap and provide you with the technology that you may require to rapidly meet your market requirements.

With Morpheous at your doorstep, remember that there are not magic pills, but the Red Pill will lead you to the truth.

Are you debating which Virtualization pill to consume?  Let us know!

In the meantime:

By: Cris Wendt

Ironically, one of the members of our Global Consulting Services organization at Acresso had to learn the true costs of a build-it-yourself approach the hard way.

"Michael", one of our top system architects and implementation consultants had a legacy sprinkler system in his yard. Michael recently bought a house in the central valley of California with a lawn and garden sprinkler system that had been installed by the previous tenant. Of course, the previous owner is now long gone and he didn’t leave much documentation behind. The demands of the sprinkler system had increased, as Michael had new requirements to extend the system to include watering an extended portion of lawn and drip into a garden area. He was done with using the hose and manual sprinkler to get the job done. To update his automated sprinkler system, he needed to add another circuit to his legacy system and add some new types of sprinkler heads. This required some new plumbing, and ideally, a new control unit and a re-design of the sprinkler control units.

Michael could have hired the job out to a local plumber who could install new equipment, added newer control units, and re-design the new circuit in less than a day. But, being an engineer, Michael said to himself, "Hey, I can do this myself, and, I can save a few bucks in the process. We don’t need to re-design the pipes, nor add a new control unit". Michael, did in fact do the job on a warm August weekend, and returned to work on Monday with a nice tan.

A week later, we were working with a customer who was going through a similar experience with their entitlement management requirements. They had a legacy ERP system and needed enhanced functionality to accommodate the growing needs of their software business. Their needs seemed simple. They needed fewer manual steps and a more automated entitlement and customer license fulfillment process. In the room were the 2 lone marketing managers and their business requirements, surround by a lot of business process people and IT architects. The company had spent months evaluating different systems, and decided to build-out and extend their legacy system to accommodate some new requirements to automate more processes. The ROI analysis they did showed that it would be less expensive to build it themselves. They also spent months in mockups, trying to design for every possible business process scenarios; all while making different architectural design assumptions. In the meantime, a competitor had updated their offering and had created competitive havoc in the field.

While we were helping the client to think through all of the activities associated with the entitlement lifecycle of software, Michael received an email on his Blackberry from his wife who was at home. In the email was the single word, "Yikes", along with an attached picture of a very flooded side yard. The legacy sprinkler system that Michael had built upon had malfunctioned due to a brief power spike, and all of the sprinkler control units were activated simultaneously. This led to (pardon the pun) an over-entitlement of water in his yard. To make matters worse, his large dogs were in the area and decided to have some fun and wrestle in the mud. This activity caused them to break a long, exposed pipe, leading to an unrestrained flow of water into the side yard. The result was an undermined concrete walkway and potential damage to the concrete foundation of the house. Michael’s initial cost-savings were over-run by the unexpected costs of the real "lifecycle" of the sprinkler system. It seems the build vs. buy analysis was incomplete and inaccurate.

As Michael returned to the customer meetings, the discussions were still continuing and the final design is more than nine months away. Hopefully, the decision to build won’t result in a flooded foundation.

Is your company debating "build vs. buy" for a licensing and entitlement system? Let us know!