CHAPTER 2: CURRENT APPROACHES IN BOTH PROCESS AND TECHNOLOGY
The people
I am reluctant to dwell in detail on the topic of software management, especially the asset management aspect, for risk of sounding more like a critic and detractor than a promoter of technology. The truth is, the art of software management thus far has very much been exactly that; ‘art’.
As with all art, the success of many of the tools has very much relied upon the artists handling them and there are some very fine practitioners in the field today. Again, at the risk of alienating people for whom I have a great deal of respect, I am not going to mention names specifically.
Other than my SE friend, Steve, that is, whom I mentioned earlier. Yes, some of the finest practitioners of the art are the loyal SEs who are out in the field helping customers. I should mention that most if not all, including Steve, of the SEs I have known have been loyal to both customers and employers, since they realise that the long-term relationships that they have built with their customers on behalf of their company are fragile and worth sustaining for the benefit of both sides.
No, I have never been an SE, plus I know several third-party audit specialists who might disagree with me, but several years of working with these SEs have revealed no exceptions that would change my point of view.
The process
The basic principle is exactly as I have mentioned earlier: the enforcement of the balance of consumption with entitlement. There are two extremes in achieving this enforcement.
Hard enforcement
This is really the practice of restraining the use of software and services with some technology that cuts off usage beyond a certain pre-agreed threshold that is defined by the maximum entitlement. Depending upon the licensing model, such enforcement can either be very simple or extremely complex. At the extreme, hard enforcement can constrain usage to the location, the time and perhaps even the user, to rules as defined in a licence agreement.
The trick often is for the software or service to be aware of the context that it is running within in order to provide enforcement. If the constraint is the number of CPUs then the software enforcement mechanisms must have a way of measuring this metric (I have not made any judgement here as to whether this is a sensible meter of course!).
Why do we need hard enforcement? The basic premise is, of course, that potential users of such products have no desire to conform to the licence agreement and their behaviour cannot be policed in any other way. In general, from my experience, most enterprise software users do not fall into this category.
However, there are a couple of environments where this might be a valid judgement:
- The anonymous user – perhaps a small business user buys software off the shelf as a boxed product in a store. This user perhaps has no desire for any relationship with the software supplier and regards the product as a commodity for exploitation.
- Users in certain geographies – there are regions in the world where: a) intellectual property (IP) is not valued or held in high economic regard, and b) the governing bodies have few rules to protect IP and probably have no enforcement of any rules that might exist.
The climate is changing though. As more regions that originally were purely at the consumption end of IP commerce now become inventors in their own right, there is an increasing awareness that their own IP must be protected and attitudes are changing.
Many enterprise software vendors are moving away from this form of enforcement.
A story comes to mind where this move was greeted with enthusiasm by a Swiss Bank that was upgrading its servers late on one Saturday night. Since this was a quiet time in the global weekly business cycle, the IT department elected to upgrade to new hardware in a quick overnight, well-planned upgrade session. The bank’s IT team even practised the upgrade using a test machine during normal working hours to ensure that the window, four hours, was sufficient to shut down, perform an upgrade and restart the system. It seemed that everything could be achieved easily in three hours, maybe even faster, since the test system was not as powerful as the new system being installed. With such preparation, all went well, right?
Wrong! When the new system came up, the US-developed application realised that it was now running on a more powerful platform and that the licence key was not valid for a platform of this level of performance. Three hours out of four gone, no time to restore the original hardware… panic at 3 am in Zurich!
Luckily (or not, depending upon who you were), the software vendor had an SE on site from the Germany office. He surely had keys available to him, either in Germany or in the US? Unfortunately, this was not the case. The US software vendor had recently been acquired and thus their systems and support were in the middle of the integration transition. This is where the ‘people magic’ kicked in. The SE was able to call a head-office licensing expert in California, with whom he had a personal relationship, on his cell phone. The expert was at a baseball game in San Francisco (6 pm Pacific Time), but fortunately had a laptop in his car in the parking lot. He ran out to his car and generated a new key across the Web. He then e-mailed it off to Zurich and went back into the ball park to watch the rest of the game. By 3.15 am Zurich time, the application was starting itself up happily on the new key. All the necessary licensing paperwork between the bank and the publisher was taken care of after the fact.
Believe it or not, there are flip sides to this story. A new agreement was being made for a public utility in the southern US. A new set of products to replace older, hard-enforced products was being offered. Suddenly, on realising that hard enforcement was no longer in place on the newer product set, the chief information officer (CIO) of the utility baulked at the deal. The premise for his reluctance? He was concerned that he could no longer control indiscriminate deployment of the product set by his IT managers.
Should this CIO rely upon hard enforcement of the product to police his own management team? Should the CIO and his team not have adequate management processes in place to prevent this from occurring?
In the absence of adequate, hopefully cross-vendor, software management tools, maybe this was the CIO’s only affordable option.
The bottom-line message here is: other than providing more information and allowing proactive software, and thus key, management, ISO/IEC 19770 standards provide nothing in the way of improved hard enforcement functionality.
Soft enforcement
So called because there may not be any immediate impact for exceeding a licence agreement or entitlement limits, the impact remains, however deferred, because the balance between entitlement and usage must remain in place at all times.
Soft enforcement is very hard to manage without a good set of tools for managing usage as well as an equally efficient set of tools for managing licences and entitlements. Theoretically, the management processes are easier to execute, though no less rigorous than processes for managing hard-enforced tools. Since there is no requirement for key management, reporting and tracking are the order of the day.
Increased use of the Cloud introduces shifts in paradigm also. The traditional licensing models are shifting towards the concept of user provisioning. This is not all bad, since licensing can also be shifted perhaps towards the utility model. This requires similar processes, techniques and technology across both services and licensing, something that the ISO/IEC 19770 standards can leverage.
Let me explain what I mean by utility model. Those of you using water in the City of Surrey in British Columbia, Canada, may not need an explanation. For many years, houses have not had metered water usage in this location. Having spent some considerable time in BC, I can understand in some ways why this was the case at the outset. There is so much water falling out of the sky in BC throughout the year that the thought of actually having to measure consumption once the water service was available to households was not a consideration.
I moved to California, Marin County, in 1981 and soon realised that water was a precious commodity in this region. In Santa Cruz, where I live now, there are frequent water usage restrictions during the summer (which starts on 4 January and ends on 23 December, in order to allow for a white Christmas!). This may seem like a slight exaggeration, but there are times when January has had no rain and temperatures in the 80s Fahrenheit. Which means the snow pack, which we rely on in California (a great deal of which can be classified as desert) for our water given the lack of natural lakes full of fresh water, does not always carry enough to satisfy our state’s thirst.
Some believe that fresh water will be the strategic commodity of the future, rather than oil, and Canada will be one of the main sources for the world. Hence, the City of Surrey is now mandating meters in each household and will be measuring, and billing for, water on a usage, or utility, basis going forward.
As the City of Surrey puts it, ‘Metering water in a household helps determine how much a family uses, and might even change some habits. Metering is also an opportunity to save money on the utility bill.’
Many, although not all, consumers of software would like to purchase their software in the same fashion.
There is a design house in Silicon Valley that uses computer-aided design (CAD) software (who doesn’t these days?) and their cycle of usage over the year varies. At one point in the year they have 500 concurrent workstations actively running the CAD applications. At other times, when the products are through the design cycle and into manufacture, they are using many fewer workstations. However, in order to support this habit, since the CAD software publisher only offers perpetual licences sold by the seat, the design house has to purchase and maintain 500 licences for year-round use. Of course, they would much rather just pay for use on a utility basis – the utility model – and who knows, they might even change some work habits!