by Marjorie M.K. Hlava
First published in Information Today, Vol. 1, Issue 4 (April 1984).
People are talking endlessly these days about the selection of hardware and software for your business, your library, your home, your children, your education, your games, your home security system, etc. The articles on the topic are numerous, and here’s yet another one. This article will deal specifically with the selection of hardware and software for bibliographic files and give a checklist of salient things to consider — not an exhaustive list, by any means.
Questions about computer software and hardware can arise at any stage in the process of planning the creation of a database right on through to the final execution and implementation of the file for users. Then,of course, there are questions about improving the software for the user so that you remain state-of-the-art if you indeed arrived there to begin with.
It’s handy, when you go to a computer store or when you are talking with a salesperson in your office, to have a list of questions that you need answered before making a final selection. I recommend that, if possible, you choose the software before you choose the hardware since software today is actually a more limited choice than hardware.
Questions about whether to get a mini, micro, or mainframe all seem to have merged together into system questions. At the moment, the lines between a micro and a mainframe are becoming extremely fuzzy to me, and I think as you dig into sales data and ask questions, you’ll find that they are fuzzy to you also. Rather than talk about a micro as opposed to mainframe, I would rather talk about a “big system” or a “little system” and have the differentiation be based only on the number of kilobytes (or K) in the main memory and how much storage there is in kilobytes (K) or megabytes (M). The main jargon of computers is sometimes frustrating to understand but I think you will find that there are only a few words that people use a great deal. Once you get past those by reading through a handy little dictionary that you can find on the bookshelf in most computer stores, you’ll be in business and can sling the jargon with the best of them. The following list serves only as a checklist and is not ranked in order of importance of selection. The important features will vary from person to person, organization to organization, and so no attempt has been made here to rank the questions that should be asked — only to point them out in order to serve as a guide to you.
What to ask
1. How easy will it be for the end user to operate the system effectively?
Remember to consider the end user — the “dumb cluck” who has to try to get the data out of the machine; not the programmer, who is the person who put it into the machine. We have found that people who are very close to the system often begin to think it is very simple, although it is not. They think that because they use it regularly and have all of the shortcuts memorized, everyone does. You’ll also notice that I don’t say user-friendly, but only how easy is it to operate the system effectively. User-friendly systems become frustrating to users quickly when they want to be able to bypass menus and get to the meat of the matter in a limited amount of time.
2. Do you want your system to be multi-functional?
Consider whether you will be doing more than one thing at a time or using the system for a single activity. Think about whether partitioning(dividing up of the system) or having more than one terminal is important to you.
3. How easy will it be to access the system?
Is it a system, for example, on an inhouse mainframe computer that you will only be able to use from 2 AM- 4 AM because of the priority that you are assigned? Or, is it a timesharing system where the only good reaction times are in the middle of the night or early in the morning?
4. How often is the system available?
Will you have to wait to get on or will you be able to use the system on demand?
5. What is the growth potential?
This consideration, of course, will be dependent on whether you will be able to continually add material to your file or you will have to purge data when it gets to a certain size.
6. What are the long-range time considerations?
How long will you want to have the data in the file stored? Overnight, or six years?
7. How secure is the system from loss of information?
Is it possible that it will erase all of your information if the system goes down, or will it be held if all of the electricity in your area goes out of order? How secure will it be from unauthorized use? Is it simple for another group to tap into the system at any time?
8. How much is it going to cost?
Expenses not only include the cost of the hardware and software but the staff time involved in getting them up and the time spent maintaining the file and training your staff once it is up and running.
9. How reliable is the system?
Do you know its past history? Can you talk to people who are using it? Get the gossip. Don’t mess around with any system unless you can get some story about it from a current user.
10. Will there be a backup copy of the database somewhere around? Where will the backup file be stored?
If it is going to be stored in the computer room, a fire could destroy all of your work. Make sure that it is possible to have an off-site copy of your data as well.
11. Who is going to maintain the software and the hardware?
Is the vendor going to do it? If so, what recourse do you have if they don’t respond in a timely fashion? Will they fix it in two hours? Two weeks? Two months?
12. How much installation support and training is provided?
Is the training information well documented? If people miss a class, can they catch up? If you take a random page from the documentation manual, will you be able to read it? Some of the documentation of this type is absolutely unreadable even by an experienced programmer if they aren’t already familiar with the program itself.
13. If it’s a timesharing system, how many users are there?
How long has the system been in existence? What do other users say about their experiences with the system?
14. If it’s an inhouse system, how many working installations are there?
How many will you need? Do you need an extra copy? Are there two installations of four hundred? Can you call and talk with somebody?
15. What kind of output medium does the system have?
If the search information is delivered on diskette, how are you going to have this information printed? Is it delivered on tape? Can you access it only by telephone? Can you only get into it with a hardwired terminal? Can you call it up from home at night, or do you have to be in the office to search the system?
16. Can you have a demonstration? If you can’t have a demonstration, can you get a demonstration diskette? Can you buy a users manual and read it?
If these things aren’t offered, DON’T BUY THE SOFTWARE!
17. Can you see a test file using your data?
How fast is the response time of the test file? If there are only thirty records in the test file, what happens when you get 12 thousand records in the file? Is the response time still that fast? Will the person supplying the hardware and/or software guarantee that kind of response time?
18. Training can’t be overemphasized when you are shopping for software and hardware.
Training the end user is crucial yet it is seldom done. It is often overlooked or done poorly. Too often, computer people train other computer people while the person who will eventually work the system and retrieve the information is ignored. Training should include lessons on how to use the system’s software and hardware, but it should also include lessons on how to develop a search strategy for the system and some training in a reference interview for dealing with the system. If people know how the information is stored, it is much easier for them to retrieve it.
19. Can you search for any piece of information contained in your database?
Some software allows searches based on a particular field, or only the first so many characters of the field. If there are limitations such as these, you need to pay particular attention to the format of your database–or choose another piece of software.
20. How fast is the system? Does a search take half an hour or three seconds?
Count to three seconds and see how long that really seems. Watch the response time on one of the online vendors and see if you can stand a 15-minute turnaround time on a search of 10 thousand records.
21. Write tight specifications for your system.
Get examples from other people who have written specifications on computer systems. Some people even copyright their specifications, but they are certainly worth the money you might have to pay to get them written and written straight. Sloppy specifications ask for a sloppy database.
Not in the books
Well, that ad hoc list is probably not the kind you will find in computer books.
I encourage you to shop around for a system that is already in existence. Even if you and your staff have to build a system inhouse, it is convenient to be able to model it on an already existing system. Try sending your staff to a training workshop dealing with some inhouse package or time-sharing package. Send your programming staff to a Dialog or BRS or SDC workshop to give them an idea of what other kinds of systems are available. Have them take a tour of the local library that has an online circulation package. If the staff starts from scratch, at least have them write the user manual first. That will keep the process clear and consistent.
All of this should give you a good indication of some of the considerations you have to entertain when designing a file to meet your specific needs. There are obviously a great many variables throughout the entire database construction process. If you can, design your file first; pick the software;then find some hardware. That is an ideal kind of situation, however. Most people can’t actually go that direction and be successful.
Best of luck on your experience.
