Thoughts on Half a Century
November, 2006
by Hans Troost

In June this year I finally retired, after more than a half century of work and twenty years in Capacity Management. This milestone has given me pause for reflection about how our discipline has changed, but more importantly about the kind of people who can and should succeed in it.

The story begins on September 1, 1951 when I started working for Unilever as a junior clerk. That was quickly followed by a job as an Industrial Engineer in Motion and Time studies, calculating premiums (bonuses) for the workers in the margarine factory. Later on the bonuses were based on the achievement of various efficiency measures of product delivered (e.g., water content, weight, heat-balance of the furnace house); this was the Multi-factor System. In many ways this early assignment set the stage for my interest in capacity management: working with numbers, identifying the factors that affected performance, calculating the ability for the system to produce the desired product.

It also inspired me to begin evening courses toward a degree in Mechanical Engineering, which I received a mere (!) eight years later. Mechanical engineering requires the ability to imagine how things work together. I put my skills to work as a turner and fitter for a while and also in the Measurement and Process Control department where I designed a probe based thermometer using the Tungsten Bridge for measuring oil temperatures in the 40 meter tall oil vessels. What I liked most about this was the opportunity to discover how blue collar workers get on with each other and how a complex factory actually creates products from raw materials.

After a couple of years I transferred to the Engineering Development Department, designing packaging machines for the margarine ("the Worm of Troost") and soap industry; sludge pumps for the OMO towers; a soap dispenser for the toilet. This job required numbers skills, measurements, prototyping, and testing the design and determining the work life of the equipment. Sound familiar?

A few more years working with various types of equipment and it's now 1966. My wife Trudy saw an ad for what was then a brand new type of position-programmer/analyst. Not surprisingly, no experience was required and education would be provided. What did I have to lose? An interview and an aptitude test later and bingo--I'm now working with computers.

My first assignment at Shell was in the operations research department, where I had to design a scheduling system for the epikote factory in the Pernis Refinery to keep inventories of the various products at minimum levels. All on punch cards, written in Fortran IV and running on an IBM 7094 tape machine. You younger people will probably not be able to relate to any of the aforementioned technology. Perhaps even harder to believe was the fact that I wrote and tested the program in 6 weeks, the ROI on the system was fantastic, the user was happy, and the system ran for 5 years without a hitch on the IBM 7094.

Of course we all know there are no truly happy endings, as we found out soon enough when the system had to be converted to the next generation machine. The Fortran IV program could be held in one hand, the successor Cobol with JCL took up two 2000-card boxes. [See the oldest punched card reader for the IBM 7094 and the one for the IBM 360 series. Here's another lesson learned-if one of your colleagues has to convert something you wrote, just assume that all that swearing is not meant personally-and stay out of dark parking lots.

This project, by the way, taught us an early lesson in capacity planning. On paper the move from the 7094 at 0.13 MIPS to the IBM 360/50 (0.68) would seem like a piece of cake. Except-you guessed it-the program was memory bound. Then, to add insult to injury, one night the 7094 caught on fire. The fire brigade promptly arrived and doused the flames. To bad the 7094 had been brilliantly installed in-you guessed right again-the basement, which was now our company's unofficial swimming pool. The IBM 7094 was no more-but it solved a major conversion problem.

This incident taught us two valuable lessons-1) do not install computer equipment in low lying areas and 2) a MIP is not a MIP is not a MIP. From then we ignored any vendor's guarantees about capacity and began our own benchmarking. This effort resulted in the acquisition of the IBM 360/65 and IBM 360/75, eventually coupled via the ASP (Attached Support Processor) system, the forerunner of the JES2 system.

We also learned that, if benchmarking is not feasible, obtain contractual upgrade options (if any are available!) from the vendor at no additional cost when things turn out to be a dud.

My first formal work in performance and capacity planning came with Shell's International Computing Group in The Hague (1972). I traveled around the world acquiring performance data, benchmarking, analysing the captured information, advising the companies visited about what improvements could be obtained. I visited Shell Data Centers in Venezuela, London, Genoa, and Australia. My key tool at the time was a hardware monitor with 32 probes, the CPM II, weighing nearly a ton, which traveled with me as "luggage."

The visit to Shell's Australia location prompted me to move to this fantastic and beautiful country in 1977. I started with Shell Australia first as a systems programmer and later in 1985 with the then-rare title of "Capacity Planning and Performance Manager," which I held until I retired in 1992. These were exciting days in a brand-new field and I can say our efforts saved the firm millions of dollars in computer expenses.

One of the critical achievements at this time was the founding of CMG Australia, along with Brian Jennings, Peter Greening and Stan Laugher, these fellows founded the Aussie group in 1983. In addition I became a member of the International CMG (USA) for twenty years. I served as vice president and program chair for the Australian CMG, and was active in getting many of the noted US speakers (e.g., Connie Smith, Jeff Buzen, Leilani Allen, Steve Sampson) down under. We were rewarded in our efforts to establish the profession by seeing advertisements for "Capacity Planner urgently required" appearing in the newspapers.

The urgency came from the fact that this era saw the first great wave of business automation, and large companies like ours were constantly challenged to keep up with the demand. And the financial decisions became a whole lot bigger as well. Capacity planners were now responsible for multi-million dollar decisions, and that naturally brings a lot of attention.

My most memorable benchmarking study happened in 1986 and became an international cause celebre. We recommended purchasing the first IBM-compatible mainframe running MVS/XA from National Advanced Systems (later Hitachi Data Systems - HDS) at a substantial cost savings, after lots of back-and-forth with Papa Shell in The Hague. Acceptance testing was extensive and included having three of the staff of NAS who had built the microcode on site. We only had one major hiccup and ended up ranking the machine at 26 MIPS for our workload mix.

We quickly became a showplace site and I had numerous opportunities to visit the Hitachi factories in Odawara and Kanagawa and meet the engineers who were really on the leading edge. To this day the inventor of the XL-60, Michihiro Hirai, who speaks 16 languages, sends me a Season's Greetings message partly in Dutch.

But dark forces were gathering and both IBM and Amdahl went to court in San Francisco, challenging the data we had presented to CMG Australia. Fortunately common sense prevailed and the witness called in by IBM and Amdahl attested the findings in the CMG report to be correct. Who says capacity planning isn't filled with thrills and chills?

After leaving Shell in 1992, I worked as a contractor for Telstra's (Telecommunication) Corporate Marketing organization, followed by a 13-year stint with Philip Morris Information Services. By then capacity planning had moved beyond the mainframe and I spent most of my time on the Wintel and AIX (IBM's UNIX) platform.

So what have I learned? First, a CM professional should have a desire and ability to work with numbers. Ultimately, what we do has to be based on sound measurement and calculations. Second, working with a wide variety of machines helps you place those measurements in context. Third, I'm convinced that IT professioinals should seek varied employment, either with different companies or even with one employer. With all respect to the dot.coms, a large, established company provides a variety of experiences that is hard to match.

I do have my concerns for the CM field as a whole, however. Nowadays, although computing has become more complex, service has not always improved after adding more server and network capacity. Hardware and software spending has become hidden, and therefore savings and the motivation for "capacity planning function" has become less of an issue. This is false economy, but it seems to be the trend.

Another factor is one that has been with us from the beginning-the need for adequate tools. Buying software for performance and capacity planning has become prohibitive for many companies. As a result, systems programmers turn to open source software or freeware instead of professional developed (AND SUPPORTED) packages. The time and cost to build these band-aid systems with their nonexistent documentation is also largely hidden-and the risks of relying upon them is disproportionately high. I know this from experience since my last suggested assignment was to support one of those homegrown performance applications.

So what do I have to look forward to in retirement? I'll probably keep a hand in by doing some odd jobs for CMG Australia. I'll still keep traveling and will do some volunteer work at a small travel bureau. Then there is lawn bowls and bridge. Most of all I'll get to spend more time with that same beautiful girl I met and married at Unilever over 50 years ago.

Fondest regards,
Hans Troost