CHAPTER 10: SWID AND SWEID TAG MANAGEMENT FOR CONSUMERS

The software life cycle

Figure 54: Software/Saas product life cycle

Figure 54 is a reminder of our life cycle. The third step in the cycle involves both the publisher/creator as well as the consumer. The publisher delivers both SWID and SWEID tags; the consumer receives them.

The SWEID tag

The SWEID tag may be recorded directly into some form of entitlement database, an example of which is shown in Figure 55.

Figure 55: VeriTag Enterprise architecture

The task requires that:

• the publisher issues SWEID tags as per the standard and delivers them in a manner in which the consumer may accept them
• the consumer has the process and supporting infrastructure to process SWEID delivery.

The SWID tag

SWID tags of the build variety may arrive as part of a publisher distribution and if so, as part of the ‘Install Software &/or Service Client’ step in Figure 54, will be deployed automatically on each computing device that the software is installed upon using the standard installer as supplied by that same publisher.

Subsequent software deployment and usage management information may be derived by using SAM tools that are compliant with the ISO/IEC 19770-2:2009 standard to harvest and report on this information.

Altiris, a Symantec business unit, will be releasing this functionality with their management tools in the near future.

Another option is to either modify the installation tools to record the deployment information in a configuration management database (CMDB) that supports the SWID data format, or even to go to the next level and execute the installation inside standard processes using tools, examples of which are currently available and widely used, to populate a CMDB automatically.

Following this process allows each deployment to be installed with a uniquely identifiable SWID tag(s) and include deployment information, using the ISO/IEC 19770-2:2009 elements described earlier on, allowing for very precise management information being available further on in the life cycle.

Usage, upgrades and renewals

Without implementation of SWEID tags, there is currently not much leverage to be gained in managing renewals unless a publisher of SaaS clients adopts the usage paradigm mentioned in the previous chapter, thus allowing client-side usage management. It remains to be seen how this notion is adopted going forward.

Similarly the usage reporting of licensed software, with the exception of that currently planned by Symantec, is restricted to whether a software product is deployed and/or possibly running.

Upgrade and patching information may be tracked in the same fashion as initial installs.

The reconciliation point

I have already discussed the ‘two hands clapping’ metaphor earlier. Until the SWEID is accepted by ISO and fully adopted by publishers and service providers, the case is very much ‘one hand clapping’. If you are a student of Zen, this should be a familiar koan and thus can only be related to your own context.

If, however, you have or can acquire a record of your entitlement purchases, the task of reconciliation can be made easier with the use of SWID tag information, describing deployments and usage at their most primitive level.

Currently, even SWID tags are not being issued as a matter of process by publishers. Notable exceptions to this are Symantec and Adobe.

SKU element considerations within the SWID tag

In its simplest form, the process of reconciliation is required for each licence feature, eventually to be manifested by a SWEID tag, and an associated SWID tag.

Any given licensable function may be sold in many ways. For example, using the example shown earlier, licensable function SEF1.0-FW-25 may be sold as shown in Table 15.

Table 15: SEF base SKU

If the SKU element in the SWID tag is not correctly formatted in the distribution for each of these SKU types, reconciliation becomes more difficult, since reconciling with the correct entitlement becomes less precise.

In order to achieve this, it is important that the SWID tag generator is integrated appropriately with the publisher infrastructure (as described earlier) in order to facilitate this process. VeriTag Publisher is designed to interface in this fashion from the outset.

Frankly, it is not clear that there is a clear business argument in my own mind that can justify a publisher attempting to uniquely identify SWID tags other than to attempt to increase customer satisfaction. However, as an idealist, I live in hope.

More likely is the scenario presented earlier of identifying each SWID tag from the installation process, which of course may or may not relate to the entitlement SKU associated with the deployment.

Overcoming the inertia of ISO/IEC 19770 adoption by software publishers

Oh, the pain that is involved for both those proposing and those adopting any new standard! Of course, how can a standard be truly considered a standard unless it is commonly used (or used at all!). If this particular paradigm did not seem to solve so many problems in my opinion, I would be condemning it to the endless abyss of thoughts and ideas where many a creative notion has come to rest.

What may appear to be a major roadblock to the consumer – the adoption of the tagging standards by publishers and service providers – may not be an insurmountable hurdle.

There is the concept of SWID tag retrofitting, elements for which exist within the ISO/IEC 19770-2:2009 definition. That is to say, it is possible to add SWID tags to existing software deployments, as well as maintain the infrastructure by adding SWID tags to upgrades, changes and new software as they enter the infrastructure.

Of course, an immediate question would be… Why?

After some considerable research and calculation, I have derived the following.

SWID tag retrofitting, saving on reconciliation expense

I used some figures for the true-up exercise that seem to be typical of use as a measuring stick by most. If you are someone who has to manage this exercise on a day-to-day basis, you will already have a good idea, and actually I would like feedback on your experience if possible.

I used the following sample configuration:

• 50 servers
• 1,500 workstations.

Estimated cost of a manual biannual true-up

Time taken

• Full software true-up of 1,550-machine organisation – 100+ working days (~US$100K).

True-up costs

• True-up of 500 workstations – $150.00/machine per event
• True-up for Adobe of 250 instances – ~$75.00/machine per event
• True-up for Oracle of 30 instances – ~$450/machine per event
• True-up for IBM of 50 server instances – ~$350/machine per event.

Figure 56: Manual biannual true-up

Estimated cost of a SWID tagging-assisted annual true-up

The calculation below assumes a cost of ~$10 per SWID tag deployed as an overhead on SWID tagging.

Time taken

• Full software true-up of 1,550-machine organisation – 15–20 working days.

Cost – six-year total ~$2.4M

Annual tag-assisted true-up of $25K, which assumes every product upgrades annually and thus requires each and every tag updated and redeployed:

• Tags for 1,500 workstations – $30.00/machine/install or upgrade
• Tags for Adobe 250 machines – ~$30.00/machine/install or upgrade
• Tags for Oracle of 30 instances – ~$80/machine/install or upgrade
• Tags for IBM of 50 server instances – ~$100/machine/install or upgrade.

Figure 57: Software management with SWID tagging true-up

Challenges to the process

The first annual event requires a full manual true-up in order to establish the install data upon which to build. Thus there is a considerable overhead in this first year, which is illustrated in Figure 58.

Working on the premise that the publisher has not designed or produced SWID tags (unless your only suppliers are Symantec or Adobe!) for the software components found, this task must be performed. The process is described in the previous chapter.

There are now services becoming available from consulting and SAM practitioners that will perform this service as part of a true-up exercise.

Figure 58: Cost comparison over six years

The resulting SWID tags are verified and registered with TagVault.org as a step in the process and as a result the number of TagVault-compliant SWID tags is constantly increasing. The SWID tags that already exist may reflect deployments found in multiple consumer infrastructures. By default, TagVault.org allows these SWID tags to be used by members of the organisation.

Advantages to the process

For each year after the initial true-up year, it is assumed that every product receives at least one patch or upgrade per year, thus a complete set of SWID tags is required each year at a further $10.00/tag. Additional manual effort is required for the true-up in assembling reports, etc.

Figure 59: Potential savings year over year for 10 years

I am predicting a reduction in cost, a higher frequency of true-ups occurring, plus, if the CMDB is available, up-to-date deployment management reporting will be available any time.

As can be seen in Figure 59, the longer-term potential savings can be considerable, even if the figures shown are considered optimistic. The economic advantages are clear, even if my estimates on true-up vary by 50%.

Conclusion

I hope I have shown that economic advantages for the enterprise software consumer exist from even the current state of the ISO/IEC 19770-2:2009 standard as well as the upcoming ISO/IEC 19770-3 standard in that IT resources may be better utilised, enabling more productivity and reducing waste of revenue on needless entitlements and supporting infrastructure costs.

These advantages will only increase over time as the standard becomes exactly that, a standard used by most.