CHAPTER 1: SOFTWARE ASSET MANAGEMENT: BOTH SIDES OF THE EQUATION

Overview

A software publisher rarely allows the software itself to be sold. The publisher sells rights, or entitlements, to use via the sale of licences. The risk to both the customer and the publisher is that software deployment and usage is very difficult to measure. Even the term usage is very difficult to define and must be described very specifically as part of the ‘right to use’ or licence.

Such confusion can give rise to two dominant questions for the IT manager:

1. Am I using more or less than I am entitled to?
2. Am I optimising usage across all my titles such that I am getting business value for my expenditure?

The single rule that governs whether a customer is in compliance with respect to their software asset is that for every deployment there must be an entitlement that allows the deployment.

A simple view of this situation is shown in Figure 1. On one hand, on the left, is the entitlement for use as defined in the licence or software right-to-use agreement. On the other hand, on the right, is the representation of how the software is actually used, that is to say the deployment and usage of features provided as defined in the agreement. This balance is described as reconciliation and ideally should always be in complete balance. When a measurement is made, if the reconciliation matches, i.e. there is a zero reconciliation gap, then the two hands clap. I like to picture this as applause, which of course becomes louder as a greater number of agreements are sold and greater amounts of software are used.

Figure 1: Reconciliation gap

Reconciliation gaps are a problem for both the end-user and the publisher and provide a barrier to a sound relationship between the two sides.

Even if there is a zero compliance gap, this does not necessarily mean the user is deriving value from software expenditure. This is where the concept of use becomes hazy. Just because a software title is installed, it does not necessarily mean it is being used. Further, if a single title is installed in two places, but only used by one user at a time, the user may have purchased twice the true entitlement needed because the publisher licenses only by seat, not by concurrent users.

I could write several chapters here on licensing models, but this book is not designed to address that topic. However, what I do want to discuss here is the ability to measure these different models, using standards-based technology. Both the vendor/publisher and the consumer should be able to engage in software commerce with a clear understanding of expectations and deliverables on both sides, and both should be able to optimise their business for profits in their respective fields without confusion or the practice of black magic.

Compliance: the delicate balance that rules software commerce

Depending upon the ‘go to market’ scenario through which an entitlement was delivered/granted, at one extreme there may be a unique entitlement(s) for each deployment. At the other extreme, there may be a blanket agreement that allows unlimited deployment. Of course there exists every case in between. There is also the consideration that for most large enterprise customers, deployments of different products may have been granted as a result of multiple agreements, which in turn have probably been made at different times, perhaps even with different channel suppliers for the same product. To complicate matters further, there may be multiple agreements in place concurrently. Thus entitlement management and the understanding of entitlement is a very complex process that can change depending upon the point in time at which the entitlement measurement is taken.

When corresponding deployments are measured in order to match against entitlements, the licence model or business rules for product usage for any given product frequently change from release to release. Therefore, it is important to attempt to identify each deployment uniquely as well as understand the version and release date for each product deployment.

In this situation, the deployment report could look identical for the two different versions of the product since the functional model is the same for each. However, the entitlement purchases may be different for each and therefore have an impact on the compliance assessment.

To further complicate matters, the entitlement for any single deployment may not be valid for another deployment of an identical release as the business rules governing the entitlement for any deployment may be unique.

Figure 2 illustrates the four-layer approach to compliance. As can be seen, in the compliance scenario, simply understanding the deployment and the individual licences acquired is not sufficient to understand whether compliance is in place or not. It is necessary to understand the model for each individual deployment, and the contract terms under which the licence was acquired.

Such confusion can easily present a problem in the relationship between the customer and the vendor. Therefore, once an acquirer (end-user) has received both software and licence, it is desirable for both the supplier and the user that the usage of the software matches the entitlement or licence to use.

Figure 2: Four-layer approach to compliance

This paradigm is fundamental to the concept of compliance.

The single rule that governs whether a customer is in compliance with respect to their software asset is that for every deployment there must be an entitlement that allows the specific deployment, including the usage of that deployment.

Compliance is a common goal for both supplier and consumer, but for different reasons. The consumer, or end-user, wishes to ensure that they do not purchase more rights to use than needed, and the supplier wishes to ensure that the end-user does not use the supplied software beyond the bounds of the right to use. This situation should remain in place for the entire life cycle of the software usage and its rights to use, both of which may change over the life cycle.

True value: the software consumer’s continual quest

I doubt that anyone reading here would bother to rent a car, take it home and then just let it sit in the driveway (unless trying to impress the neighbours with the fact that they have such an exotic machine at their disposal of course!). Value is using our resources in the optimum fashion.

For instance, if I have one car and it can be used 24/7 by multiple people who never need simultaneous access and the terms of car usage allow for such an arrangement, then perhaps I am close to optimising value. However, if one driver wishes to transport eight people at a time, another only needs to transport two, and yet another wishes to carry bales of hay, then there may be further issues of size (meter) and functionality with the single vehicle.

If the vehicle is rented, there may also be further complications added by the entitlement. Perhaps there are restrictions on the load, on the mileage travelled per day or on the hours used.

Software is no different when regarded as a resource. Often, however, it cannot be functionally identified in deployment, usage or entitlement. Not only does the licensing model not support varied types of usage, the measurement of such usage is not possible.

Software as a service

Software as a service (SaaS) is a technology that is emerging as a replacement for licensed software in some places and will no doubt continue to grow and prove more useful as time goes on. We are continually bombarded by concepts of the Cloud by the media these days. The notion that this is new or the next big thing is quite valid; from a practical and architectural point of view, the so-called Cloud has existed for many years.

The current version is an evolution of a concept that did not catch on at the end of the twentieth century: application service providers (ASPs). ASPs were supposed to provide out-of-the-box functionality with minimal requirements for on-site software and software management. Unfortunately, the implementations were based upon traditional software architectures and proved to be as expensive to maintain, if not more so, than in-house applications and the ASP concept failed miserably.

As soon as applications started to be implemented using Internet technologies and architecture, the ability to build multi-tenant applications (such as Salesforce.com) was made easier and there is now an exploding set of offerings in a variety of business applications.

Despite the more managed nature of SaaS, there are still aspects of overall management that have issues that are yet to be solved in a standard cross-platform manner. Some of these issues may be overcome by the appropriate application of ISO/IEC 19770 ID tags in order to ease the pain.

The issues of entitlement management remain very much the same. It is critical to understand and manage entitlements, whether they be for licensed software usage or SaaS usage. Understanding usage against these entitlements is, of course, slightly different for each one. While the measurement of software usage is challenging, as outlined above for licensed software, similar issues are there for SaaS also:

• The entitlement model for the service offered may not be appropriate in order to understand true value.
• Any usage information can only be derived from the service vendor, which may not match the usage perception of the consumer.
• A method to match vendor-generated usage information with a standard form of entitlement information supplied by multiple services does not exist.
• For many years to come, Cloud-based services will need to interoperate with licensed software in a user environment, thus a common usage measurement system with a single source of truth is required.
• There is a need in the service’s life cycle management for an understanding of the current state and history of service usage from a feature, meter and version point of view. This information may be required in a consolidated fashion across multiple providers and licensed software applications, so simply using provider information is not adequate.
• Internal Cloud services need to be maintained by a user/consumer with just the same rigour as licensed software.

The software product life cycle

My view of a life cycle was so simple when I only had to consider that of the lowly amoeba! Today, we are bombarded with the concept of life cycles. Everything in my life has a life cycle, according to the guy down at the DIY store. Of course, that guy oversimplifies the issue. If it’s broken, the useful life cycle is over and I need to replace it with a new, improved, shinier model. Whatever happened to the tool repair truck that went round sharpening tools and repairing broken ones? But that is a story for another day.

Software is no simpler of course; there are several intersecting life cycles, some depending upon your point of view, provider or consumer perhaps, some depending upon your role.

ISO/IEC 19770-2 SWID tag management and the proposed ISO/IEC 1977-3 SWEID tags allow, to some extent, quantitative measurement of software deployment, software usage and software entitlement. Figure 3 illustrates a software product life cycle and where these tags may be used by both the software publisher and the software consumer for management purposes.

The concept of a software product life cycle is the foundation for all arguments and ideas I present in this book!

Figure 3: Software/SaaS product life cycle

Figure 3 centres greatly around VeriTag products, but there will be other products appearing over time that can support similar functionality. The life cycle and appropriate points of contact for ISO/IEC 19770 ID tags remain relevant for all supporting tools and products.

Product offering

During this step, usually carried out by product management, software product offerings (licences for use/entitlements) are defined. This involves defining the product components; that is to say the basic configuration, optional or add-on features, meters, suites, etc. At this time, a tool such as VeriTag Publisher (VTP) may be used to define the configuration and the set of ISO/IEC tags associated with each of these components and entitlements. Once this has been completed, a tool such as VTP, with database functionality, contains the tag prototype information required in order to generate SWID (19770-2) and SWEID (19770-3) tags on demand, either manually or automatically via a web service application programming interface (API) if available.

It may be possible, with an appropriate tag architecture, to create a one-to-one or many-to-one correlation between SWEID tag prototypes and SWID tag prototypes at this point. Doing so will allow the two types of possibly unique tags that are generated later in the life cycle to be associated with each other. This topic is covered in more detail in a later section illustrating the design of tags. If it is possible to create this association, the information generated as a result can be invaluable when deployments and usage are reconciled with entitlements during the product usage cycle.

Create software package and configure the fulfilment infrastructure

As the distribution is built ready to ship to customers, placeholders are created by a SWID creation tool such as VTP. These placeholders will contain the SWID tags that are ultimately generated for inclusion in a distribution that is shipped, either via electronic distribution (ESD) or physical media.

The SWEID tag prototype may also be associated with a unique licence price item at this point. Doing so will allow the generation of a uniquely identifiable SWEID tag when an entitlement is granted as the result of a transaction entitling a user to be licensed to use a software component. If the software component is tagged with a SWID generated by a SWID prototype that has been associated with the SWEID prototype that generated the SWEID tag for the entitlement, these unique tags may in turn be associated throughout their complete life cycle for management purposes.

Fulfil software and entitlement

At this point in the life cycle, it is possible to inject the SWID tags into the shipped distribution. Using a VeriTag patented process built into VTP, the publisher/OEM has the option to create a uniquely identifiable SWID tag for each shipment, allowing the distribution to be referenced back to a specific business transaction if required.

Alternatively, the publisher may merely create a static build SWID tag that is shipped with all distributions, still enabling the end-user to identify precisely the version of product distribution that was used to install the product which is eventually used within the customer infrastructure.

A publisher/OEM also has the option, using a tool such as VTP, to create and fulfil a SWEID tag that can be used by consumers as a source of truth for their entitlement. This tag may be read and understood by an enterprise software management tool such as VeriTag Enterprise (VTE) for consumer management.

A useful piece of functionality supplied within the currently proposed ISO/IEC 19770-3 draft contains mechanisms that allow a consumer organisation to take a single ‘root’ entitlement and allocate the entitlement across one or more subsidiary organisations, creating partial entitlements from the original root entitlement.

Install software

Installer scripts and programs that have been integrated with a tool such as VeriTag Writer Suite have the ability to customise the SWID tags for each software installation with a variety of information specific to the installation process. The information, which might include time and date, authorisation information, etc., is in addition to that data supplied in the SWID tag included in the software distribution by the publisher/OEM.

If the end-user environment contains a SWID tag-enabled tool such as VTE, the record of deployment can be updated in the enterprise embedded-software management database for use by the end-user in software management and, ultimately, reconciliation exercises. If the SWID tag has not already been uniquely identified by the software publisher and is a static build SWID tag, a tool such as VTE can serialise each deployed tag uniquely. Additionally, if the publisher has supplied a SWEID tag for the entitlement, the SWEID tag’s unique identifier may also be associated with the deployment, allowing ongoing ‘true-up’ information to be available on a continuous basis, not just at reconciliation time.

When a deployment of software is removed, removal scripts that have been integrated with a tool such as VeriTag Writer Suite can record the removal of the software with the same amount of detail as that recorded during installation. The information is stored and transmitted to the enterprise embedded-software management database, if present, in the end-user environment.

Use software

There is an element within the SWID tag that defines the characteristic of product usage. This element contains information that will allow a SAM tool that is SWID tag enabled to execute algorithms that can measure some level of activity or usage.

Software products that have been integrated with VeriTag Writer Suite runtime libraries can record not only activation and usage data for collection by VTE at any time, but may also optionally use patented technology integrated within VeriTag Writer Suite that can measure incremental usage on a feature-by-feature and/or meter-by-meter basis.

In addition, in the end-user environment, if VTE is installed, a record of software and SaaS usage is maintained regularly within in the VTE software management database for use by the end-user for SAM purposes.

Upgrade or patch software

In much the same fashion as during initial deployment of a product, patching/installer scripts and programs that have been integrated with a tool such as VeriTag Writer Suite have the ability to tag each software installation with a variety of upgrade information specific to the upgrade or patching process, as well as that data supplied in the SWID tag included in the software distribution by the publisher/OEM. Once again, as with the initial installation, each tag may be uniquely identified for management purposes with both the upgrade/patch event as well as the entitlement (tag) that qualifies the upgrade/patch event.

During this step, software that was not previously tagged with information may have its deployments upgraded with newly designed SWID tags and have the information recorded in the VTE (or functionally similar) database, if in use in the end-user environment.

Such a practice allows end-users to revise legacy software products that were released prior to the existence of the ISO/IEC 19770-2:2009 standard such that they may be managed by tag-enabled software life cycle management tools such as VTE in a similar fashion to those newer products being released with this functionality.

Renew software and/or service

Acquiring a renewal via a business transaction of some kind may result in the issuance of a new SWEID tag, which can be associated with previous renewals and even perhaps other entitlements such as licence entitlements. A service can consist possibly of SaaS, maintenance, content for some application (signatures for security issues, mapping updates, document updates, etc.) or possibly combinations thereof.

Reconciliation point

This is the point at which the ‘hands clapping’ might be achieved. Currently, as only the ISO/IEC 19770-2:2009 SWID tag standard is officially defined by ISO, the reconciliation is very ‘right-hand centric’ since only deployment information has been enabled by the standard. However, the ISO/IEC 19770-3 entitlement tagging standard defining the SWEID tag is very close behind (the first draft having been completed), which when adopted will enable raw entitlement information management.

At any point in time, as defined by the end-user, a tool such as VTE may report on all tagged and recorded software within the end-user environment. This information may extend to uniquely identified installation events, removal events, product usage and redeployment. By the end of 2011, the tools will be available for both publishers and enterprises to track entitlements using the ‘-3’ standard in anticipation of the official adoption of the proposed standard by ISO.

However, as shown earlier, the exercise of reconciliation, while hopefully being somewhat simplified by the availability of raw information available via the use of SWID and SWEID tags, will still be complex and require judgement calls based on business rules.

Associated life cycles

As I have tried to explain above, the view of software is not simple when considering the product life cycle. To add complexity to the earlier illustration, there are several intersecting life cycles, some depending upon your point of view, provider or consumer perhaps, some depending upon your role. Here are some examples:

• Software product manager – who is concerned only with the annual revenue generated by the licences sold, and therefore the evolution of the product, how the licences are offered and the release schedule, in order to maximise the market.
• Software support and services manager – who is concerned with how much can be made annually from support revenue, how to offer support with as little cost as possible in a continual stream of ever-changing licensing models that defy understanding or continuity.
• Brand protection manager – who is concerned that all the copies of software in use are:
  • not pirate versions
  • used in compliance with the terms of the licences sold.
• Chief finance officer (CFO) of the enterprise – who has purchased the rights to use the software.
• IT manager – who is deploying the software on behalf of the purchasing enterprise.

For software management to be successful, all of these consumers of software management information must be satisfied.

The product management life cycle

A product manager typically thinks of the product life cycle as outlined in Figure 3. The time line between conception and first release to general access can be months or even years, depending very much upon the characteristics of the market that the product is being sold into. For instance, a security product usually must have a very fast cycle rate, since it is a weapon in the cyberwars and is built to respond rapidly to threats, either anticipated or existing.

A banking application (yawn), once released, may change very slowly. The world’s bankers usually have a very conservative attitude towards change (as we have all seen, despite recent economic circumstances) and if an application isn’t broken, they want no improvements unless the changes provide a very measurable financial benefit.

Even then, the risk of changes causing some instability sometimes prevents even the smallest evolution from being applied to an existing deployment. I have seen circumstances where existing releases have been in place for several years, and even then only the need for an upgrade due to unsupported or worn-out hardware has forced the installation of new versions of software.

So what is the product manager looking for in information provided by software management? This is marketing information. You might think such information can be gathered from sales information, but how licences are sold does not necessarily match how products are used. Here is the concept of needing two-handed clapping again. Product managers need to understand usage trends in order to blend those trends with anticipated future requirements. Past usage trends may help as predictors of the future, although I once worked with a sales vice-president who claimed that product managers who were passionate about past usage trends were like automobile drivers navigating a journey by looking in the rear-view mirror!

The critical points for software management information in this life cycle come at the stage where the pricing and licensing decisions and designs are made. If the licence offerings are such that the business value to the consumer of the software for each offering can be measured, then sooner or later the consumer will select an alternative. Therefore, if the usage of the software in real-world terms cannot be reconciled with the cost of the licence and maintenance of the software or service, the consumer is at a disadvantage. If this information is not available from publisher A, but is available from publisher B, then even if A’s product shows some functional advantage over B’s product, a consumer (especially our banker!) will likely choose B.

Let me give you an illustration of what I mean here. Consider the software publisher who sells the product based on a meter that is derived from the size of the CPU (model, cores, clock speed or some other measure). Unless there is a clear measurement of ‘real work’ throughput in the application of the software, how can the consumer possibly understand the business benefit of purchasing licences this way?

Let’s look at my friend, Hans, who ran a small private railway in Switzerland. His railway transported people up 10 km of track to a mountain resort. Each time, his train travelled at a certain speed owing to track conditions, and he could only put a finite number of carriages on his train because the platform length of each station limited the number of carriages that could be loaded and unloaded simultaneously. Now, while it is very clear that had he been able to purchase a locomotive of twice the power, theoretically his train would run faster or could carry more passengers at the same speed, but real-world constraints prevented that. Thus charging passengers more for travelling on a train powered by a more powerful locomotive was not an option.

In a similar fashion, our software consumer must have a way of measuring the value in a simple fashion; that is to say, the value of the software in business terms, i.e. the effective use as well as throughput of the application over an appropriate period of time.

This ability is part of the role that should be played by software management, and it is the responsibility of the product manager to ensure that these measurements are possible from any deployment of the software. The licensed offering must be measurable in terms of functionality and meter.

This factor becomes even more important in the virtual machine (VM) world, where the separation of software from the hardware platform is becoming more distant as VMs evolve.

The software support life cycle

I have another friend, let’s call him Steve, who is a sales engineer (SE) for a very large software publisher. He is located in Detroit and covers a large area helping to support and comfort several significant enterprise software users in the region. Steve is the kind of fellow who stands up in the middle of the global quarterly earnings report and asks the CEO, ‘If we are doing so well, how come we can’t afford to develop better, or even any, tools for our customers to manage the software we sell them?’

Steve is on the front line daily with his customers, dealing with ‘out of band’ problems as well as the normal events in the software life cycle such as a ‘true-up’.

Steve’s life cycle starts with a new product release and rotates through renewal cycles.

Tag life cycles

The SWID and SWEID tags have their own life cycles. Depending upon how the tags are used (more on this topic late), these cycles start and stop at different parts of the software product life cycle, but intersect at well-defined points.

Critical measurements required for software asset management

Ultimately, functionality exploiting the ISO/IEC 19770-3 SWEID standards currently under development will be included in the software management process. The standard approval is scheduled for late in 2011 or early in 2012.

When corresponding deployments are measured in order to match against entitlements for any given product, licence model or business rules for product usage, there are frequent changes from release to release. Therefore, it is important to understand the version and release date for each product deployment, since an entitlement for one release may not be valid for another as the business rules governing the deployment may be different. There are also cases where a single product may be licensed in multiple ways. An example of this situation could be that a single product might be offered in, say, France and Belgium; both are French language versions, but are either priced very differently or metered very differently.

In this situation, a deployment report could look identical for the two different versions of the product, since the functional model is the same for each. However, the entitlement purchases may be different for each and therefore this has an impact on the compliance assessment.