Your computer is running slowly. Guess you have to buy a faster processor, right?

Not necessarily.

You want strong encryption. Guess you have to increase the encryption keylength, right?

Not necessarily.

Long ago in Internet time – which is to say, a more than quarter of a century ago, from 1980 through 1983 – I was an HP3000 MPE-operating-systems-internals specialist and IMAGE/3000 database-performance specialist for Hewlett-Packard (Canada) Ltd, working out of the Kirkland, Québec, office. One of the lessons we learned and had to teach our customers as performance specialists is that there are five components that can account for computer system performance:

• Access to and speed of the CPU;
• Access to and speed of main memory (RAM);
• Access to and speed of secondary memory (magnetic disk);
• Network bandwidth;
• Application design.

Whichever of these factors is slowest defines the current performance bottleneck and limits the overall system throughput. Improve the factor causing that bottleneck and you will improve performance – until it hits the next bottleneck.

For example, after I went solo in my own JINBU (Mandarin Chinese for “Progress”) Corp. consulting firm (1986-1998, RIP), I handled a major Canadian government HP3000 system in August 1989 that was up for replacement at a projected cost of C$2 million. The administrators called me to help because their batch processing had crept over the morning shift start time of 7 a.m. and the unionized employees had to be paid for waiting around until 7:30 and then paid 1.5x for working the extra half-hour at the end of their shift – an expensive half-hour indeed. They wanted to survive until the January 2000 delivery date.

That report had my favorite executive summary of my entire consulting career so far. It was a single page that said “EXECUTIVE SUMMARY” and then had the question “Does <government agency> need to replace its HP3000 computer?” After 20 blank lines I wrote the single word, centered on the page, “No.” <g>

The next page was labeled “SLIGHTLY LESS EXECUTIVE SUMMARY” and explained that the reasons the batch processing was slow had nothing to do with the speed of the CPU, which was the only improvement available from a CPU upgrade. The problem was that the product databases (1) hadn’t be repacked on the main indexes in use and (2) were missing a couple of obviously useful indexes that would convert serial searches of huge datasets into random-access searches.

M. E. Kabay, PhD, CISSP-ISSMP, is Program Director of the Master of Science in Information Assurance program at Norwich University.