Don't cut corners on e-gov hardware
FCW's Dot-Gov Thursday column gives pointers in buying hardware to support speedy Web-based services
Hardware is not the area to cut corners on as we move forward into a more transaction-based government.
Shortcomings in your hardware infrastructure will cost you enormously later in higher maintenance costs and reduced productivity, and it will create feelings of ill will among your customers because of slow response times.
From the beginning, you must consider how to design a responsive system that can accommodate dramatic growth and voluminous interactions with the public.
In order to design geographically dispersed systems involving multiple platforms (client, server and mainframe) some understanding of hardware principles is necessary to help you avoid making obvious mistakes in systems architectures and, in the long run, minimize the overall costs of the system you are installing.
You can and should take an overview course in system design, but hardware courses often have difficulty incorporating the big-picture issues provided below. These lessons were learned through the school of hard knocks. They should help get you into the right zone of what you need to know to make purchases for supporting large and geographically dispersed information systems.
Despite all the rhetoric about whose product is better, the one concept that should determine how you design your system is speed.
For example, the clock frequency of a microprocessor is a good indication of the speed of that device. The read/write speed of a disk provides an easy and direct measure. A device such as a microprocessor running in nanosecond time can easily support many devices, such as a hard drives, which run in millisecond or micro-second time. A single computer running at about 500 MHz can easily support many modems running at telephone speeds of 56K.
The rules of thumb below are a way of thinking about system design architecture. Click on the links for more detail.
1. Design in parallelism at all levels when building systems. Avoid linear designs.
2. To contain costs, buy hardware over software and invest in both hardware and software over more people.
3. Identifyand then design around the information choke points, using basic approximations for speed.
4. Incorporate significant extra capacity throughout your design, recognizing that systems degrade exponentially and that the Internet is driving a boom in information processing requirements.
Webmasters often are immersed in content and application software issues. These hardware principles will help you design the hardware component of your system. All of these principles are used when building a basic support infrastructure for a single building or when scaling up to support much larger, geographically disbursed IT systems. With these principles in mind, you can more confidently look at the hardware designs and ask the right kinds of questions.
Kellett is founder of the federal Web Business Council, co-chairman of the federal WebMasters Forum and director of GSA's Emerging IT Policies Division.
NEXT STORY: USDA plans consolidation