![]()
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:
- Am I using more or less than I am entitled to?
- 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 ...
