Guest Commentary

BUSINESS APPLICATIONS ANALYSIS—THE MISSING STEP

Editor's Note: This article, originally printed in the July/August, 1980 COMPUTE!, is reprinted because of its usefulness.

Hal Wadleigh

Business applications analysis seems to be the most neglected element of the microcomputer industry today. The shame of it is that the principles of business analysis affect almost every phase of the use of microcomputers in the business environment—from the initial choice of equipment to evaluating programs in use. The root of the problem appears to lie in the history of microcomputer software.

A short time ago, there was little or no business software available for the smaller microcomputer systems. The software market was flooded with games, but programs that do anything useful for businesses were few and far between. When business programs could be found, they were unfortunately lacking in the qualities that make "good" software distinct from "bad" software. Now that the systems have been out for a while, the quantity of business packages available is greatly improved. The bad news is that the quality of this software (with a few notable exceptions) is as poor as ever.

Both of these situations—the plethora of games and the low quality of business software—seem to be related to the way in which most microcomputer programs are developed. The programmer gets an idea and sits down to start coding. This approach is ideal for games because any interesting oddities that occur during this rather non-objective procedure can be incorporated into the game to make it more interesting. This is also the worst procedure possible for business programming.

The nature of games is that they don't have to do anything in particular (except hold the player's interest) and the job itself can be redefined to accommodate any discoveries made during the programming process. In this case, the program is more important than the job it is supposed to do!

Business programs, however, are the exact opposite—the job is everything and elegant programming is almost meaningless. A good business program is one that does the job well. A bad business program is one that does the job poorly. The elegance and sophistication of the program does not matter. Successful games are usually programs that continually surprise and amaze the user. Business programs had better NOT surprise and amaze the user.

The principles of business applications analysis are really quite simple. It does not take a great deal of intelligence or education—just a little control. It is a five step process:

STEP #1: Define The Job

It is not too unusual to hear a small businessman say something like "I bought one of those little computers last year. What do you think I ought to do with it." It's a rather amazing statement when you think about it. The man has a tool and would like to know what kind of job to do with it. The proper procedure is to buy the tool that best fits the job that needs to be done—it doesn't matter if we're talking about hammers or computers.

Any computer is a tool for processing information. Defining the job for a computer is usually a simple matter of completing the sentence "I want to get..." with a detailed description of what will be the output of the system.

This step is often called the OUTPUT SPECIFICATION phase.

STEP #2: Define The Information Necessary To Do The Job

No computer will create new information. A computer will, however, change the form of information that is available to it into a more useful form. For example, a file available to the computer might have a lot of records on items in a business' inventory. Each one of these items has the information on what the value of the items are individually and a count of how many of these items are in stock. The computer can, whenever necessary, take these individual items of information and produce that information in the form of a statement that, "Current inventory is worth $9875.42" on a display. This is not really a matter of producing new information—since the information is already contained in the individual inventory items. The computer has simply changed the form of that information into something more desirable.

Since we have already defined the job we want the computer to do, we now have to define the information that the computer will need to do that job. This often involves a bit of research. The person who does this part of the analysis has to know how to do the job itself. It also usually involves finding out the exact form the information is in when it becomes available to the people who will be operating the computer.

This step is often called the INPUT SPECIFICATION phase.

STEP #3: Define The Information To Be Stored

Some of the information necessary to do the job will be needed over and over again. It is silly and wasteful to require operators to enter this information every time it is needed. Sometimes the job itself is simple data retrieval—looking at stored information. This is the step where the information that should be stored is defined. In this step, you decide the number of data files, the form of each data record in the file, and even the size of the file.

This step is often called the FILE SPECIFICATION phase.

STEP #4: Determine The Physical Flow Of The Information

Business applications are a matter of getting the right information to the right place at the right time. If the computer is going to be printing reports in the accounting office and the information is needed at the loading dock, then the system specifications have to include a means of getting that printed report to the loading dock. This step will be almost meaningless in some applications—but it will be the most critical step in others. In either case, it cannot be ignored—even if it seems to be unimportant at first glance.

This step is often called the WORKFLOW SPECIFICATION phase.

STEP #5: Define The Time Contraints Of The Operation

Since we are dealing with a system that has to get the right information to the right place at the right time, we need to make some rather exact definitions of the tolerable delays for each step of the job. It would be silly to define a system that has to sort large files in many different ways without allowing enough time for these sorting operations. It would also be silly to try to function without such sorting operations if they are critical to the operation itself. This final step is often called the RESPONSE TIME SPECIFICATION PHASE.

This constraints defined in this stage may show that the previous steps have resulted in a system design that simply cannot work fast enough to do the job. This could necessitate doing one or more of the earlier steps over until all five steps conclude with a acceptable applications design.

The Final Result—System Specifications

Now that you have completed these five steps, you have some idea of what you are looking for. You still haven't chosen any equipment and you haven't even designed any programs—but you DO have a complete definition of the exact job to be done—and that is the most critical point:

YOU CANNOT BUY AND PROGRAM A COMPUTER TO DO A JOB UNLESS YOU KNOW EXACTLY WHAT THE JOB IS!!!!

Unless you have gone through this process, you don't really know what the job is and you can't really make any informed decisions about equipment or programming. The end results are all too often either comical or tragic.

The general impression of many computer professionals is that micro systems are toys and that micro software is limited to games and junk. There is an uncomfortable amount of truth to that view—due to the haphazard way in which micros have been used. If people in the microcomputer industry begin using their tools properly, that attitude will change. It will soon become obvious that mainframe systems are needlessly expensive behemoths and that mainframe software is archaic and oversensitive to small errors.

The real microcomputer revolution will begin when microcomputers are used properly—and defining the job to be done is always the first step to proper use.