Every where I turn there seem to be a growing series of ongoing debates about scalability. The current set of major competitors with articles in most trade magazines are the UNIX VS the NT camps. UNIX is a mature operating system that has widely proven scalability while NT is still early in its development and understanding of scalability issues. Of course with a parent like Microsoft, NT will continue to move forward. The debate is not "if", but "how long" it will take for NT to grow from a distant second into a full fledged competitor to UNIX.

This is not going to be another technical article about UNIX VS NT. Instead, I’d look at what the term "scalability" means to you. The general definition has to do with the ability of a system to grow with and properly handle the growth driving the organization. In the computer field, we generally interpret the word "system" to mean a hardware platform and operating system combination such as an Intel server and the NT operating system. But many other "systems" exhibit scalability or the lack thereof.

Software systems have many attributes of scalability and can contribute positively or negatively to hardware systems under growth and scalability pressures. For example, a daily cash receipts system might need to Sselect a historical file to find the receipts for today. This is the kind of overly simple designs I see all the time in my consulting business that turn out to scale poorly. The design is linearly expensive in terms of the history file, but unfortunately the history file may hold 500 to 1000 times the growth of the daily volume. A much more scalable approach would be to maintain a key file or index which records today’s transactions each day. Good system designers need to pay considerable attention to these kinds of simplicity VS scalability issues as they build new systems (or rebuild old ones for today’s technology).

One problem with an overly narrow definition of scalability as the hardware is that it blinds us to the realization that process scalability is usually a series function. This means that normally a complex system will by throttled by and can only grow to the extent the least scalable portion of the process can grow. This fact needs to be considered early on in the overall design process. ALL other areas of our data processing operation need to be scalable as well.

For example, you may remember the stories about the early days of the telephone system. At first they had human operators that manually ran switchboards to connect you to the correct line to call a particular destination. Long distance calls involved at least two operators, one on each local exchange, and sometimes more than two. This worked fine as long as the number of phones was very small compared to the number of people. As the phone system grew, we quickly discovered it was not a very scalable system. In fact, it was estimated at one point in the 1930’s that at the then current growth rate, the nation would shortly need to have several times the entire nations secretarial work force employed as phone operators. The phone companies were forced to develop a new systems design that did not rely on human operators to complete local calls. As time has progressed, they eliminated operators from international calls, and from half the process of telephone directory information calls. They did this by developing switches that allowed individuals to place their own phone calls - the direct dial system.

This is obviously similar to the changes going on over time in the computer industry. There were once hundreds and hundreds of key-punch operators in a dedicated data entry pool. As this became unworkable we first converted to more efficient terminal oriented data entry system, and then to a more scalable design where the data entry is distributed to the user departments. With today’s web based designs, we are now experimenting with pushing the data entry back even further into the customers hands. At least from the human standpoint, this is a highly scalable approach as the number of data entry people scale 1 to 1 with the end user data demands Some industries such as the local libraries have been able to do this even before the web with direct user access terminal networks, while others have been working with greater or lesser success in a similar effort with EDI approaches.

These kinds of changes may not always be efficient – the data entry in now being done by untrained people who make more mistakes and individually take longer to complete the process. Additionally, it may actually require more hardware and software effort and a better systems design to effect these changes. But an interesting and often overlooked thing is happening here, the most costly part of data processing and arguably the least scalable part – the human portion – is being pushed outside the boundaries of our IS department or even of our company. Web based applications are now beginning to allow users to perform many of their queries and data entry operations themselves.

Another area of concern is our ability to scale the support networks. As our products become more and more complicated, the need for understandable technical documentation and technical support for the system and the network increase exponentially. This is true at all level of the process, from the internal developers to the installers, from the end users to the support team. Delivering a web based solution works only as long as end users can figure out how to actually make it work! The system and interface designs need more than ever to be as clean and understandable as possible.

We can no longer assume we have the benefit of highly trained employees to perform the data entry – the interface must be understandable to the lay person who simply wants an answer to a question about our product or to enter an order. Often companies make the mistake of dropping historical data entry and customer support mechanisms before they have proven the new techniques are understandable and acceptable to the customer.

Today’s designs needs to be scalable not simply in terms of performance, but in terms of user understanding and levels of ability as well. Of course the web sites layout makes sense to the web designer! The real question is does it make sense to your target users? Multi-level skills testing is important. If it is a general commerce site, you need to test with the least technology capable of your users, not just the most capable! If it is designed to be a high volume site with users repeating transactions often such as a stock trading site, be sure it has an expert mode that reduces extraneous navigation issues. In short, get user feedback before committing to this kind of new imposition on your users – asking you mom if it makes sense is not as silly as it sounds.