Last month, after talking about the positive aspects of a Pick Systems survey, I asked you to spend a moment to consider what you wanted to see added to the Pick system to make it more productive, more usable and perhaps even more competitive. After more than twenty two years in the MultiValue community, I have some significant personal biases. I feel strongly that the Pick System is still competitive and can be even more so with your help and involvement. On the other hand, if the three responses I've received to date are indicative of the current level of concern in the VAR and user communities, Pick is in big trouble.

As I said last month, its you people on the other side of this page who hold the key to the future of Pick – not the manufacturers or the software techies. You, the VARs who wage the real-world fights and know how Pick currently stacks up against its competition – share that knowledge with us for the betterment of Pick. And you guys, the end users and consumers of this technology who make the market work, we need your input too. If you are happy with things the way they are, that's OK too. But say so, and say it loudly or I'll end up with the impression that there aren't any VARs or end users left.

I see this lack of involvement in other areas as well. I work with quite a number of Pick sites as a consultant and it is surprising how few of them have any real involvement in their own data processing systems. I know that's a strange thing to say, but please hear me out. Most of you have gone through the process of purchasing a car, and then having to maintain it afterwards. Lets take a brief look at a few of the surface issues in this simple process.

The process starts with some serious thought regarding the design decisions of car purchasing. Do I want my car to make a statement or just supply economical transportation? Will I be taking long trips in it or just driving to and from work? Will it have to serve double duty as a truck for my remodeling and yard needs? What about safety issues – do I want anti-lock breaks and air bags? For most of us the list goes on and on. Some of the questions are part of our frame of reference and never really asked, but they are there if we think about it.

After we purchase our car, we have to face other issues with its upkeep. We all know a car needs certain chores performed periodically to keep it running safely and to help it last for its design life. Some of these like insurance vary little with its use while others such as frequency of oil changes, and the thoroughness of other inspections do depend on use. Most of us would pay much more attention to our car if we regularly drove it through Death Valley than if we just drove three miles to the office every day.
This car scenario is certainly a easily understood analogy for many life cycles, including computer related ones. Unfortunately, I see many companies who fail to take even rudimentary maintenance steps with their huge investment in computer technologies. Many purchase decisions are made on mostly emotional grounds. We sometimes pay more attention to look and feel issues than to the utilitarian useabilities of software. Are you requiring GUIs to satisfy some VP or is it really needed to efficiently enter orders? VIPs can afford to have luxury cars and GUIs, whereas most order entry people drive more efficient cars and need to have more efficient computer interfaces. Both are valid 'needs' in their own environment.

All too few of us have ever really performed a textbook system design analysis. Hardware is purchased and software built without exploring the impacts of the business volumes. Then we act surprised when there are not enough hours in the day to run the required jobs in the system. What's to be surprised about? If you need to read X million records to finish a job and you know it takes Y milliseconds per record, its grammar school math to take X*Y and know how long the job should run. Yet I have rarely (not this decade) seen systems analysts do the math! I can drive five minutes to the grocery store, but I would not ordinarily drive from my home in California to New York. Why not? Because while it is one way to get to New York, common sense says its not ordinarily the 'best way'. Where did common sense disappear to in the computer world?

Nobody would expect a car to continue to run efficiently year after year without some periodic maintenance. If you didn't change the oil and tune the engine you would expect things to get gummed up and the car to run less efficiently. Why do people seem to expect computer systems to be different? Oh, we know we need to make minor adjustments like changing withholding rate when the tax laws change, but very few shops perform the periodic maintenance on the computer software that they wouldn't think of skipping on their automobiles. When files are allowed to grow to several frames per group, the computer engine gets gummed up. When the business volumes have changed by an order of magnitude, you probably need the equivalent of a major tune-up to rethink the application designs.

This is 'common sense' but it is uncommon to see it applied in the computer world today. Instead I see people stroll on down to the showroom and begin looking at new models of hardware and software. This may sometimes be the correct choice, but it is foolish to assume this should always be the first choice. After reflecting for a while I believe I have come up with a reason for these problems. In the Old Days, the computer hardware was so expensive that the industry invested a lot of time and energy in training people to 'analyze' the business systems and come up with the most efficient solutions for the computer. Note that this training was usually provided by the big hardware manufactures, not by universities or independent trainers. When the hardware prices started to fall, two things happened. First, the margin pressures on the manufactures caused practically all of them to drop this kind of educational support. Secondly, the current MIS managers (who were probably not senior analysts in those days) have seen the dramatic change in the cost ratio of people/machines. They have erroneously concluded education and system performance understanding are no longer critical skills to be cultivated in their shops. This slack has generally not been taken up by schools which still lean on the scientific and theoretical end of programming rather than the practical business end.

Today, the major database companies such as Oracle generate a very substantial portion (some say approaching half!) of their revenue from implementation and consulting work. This is another way of saying they are working hard to fill the gap by educating users on the best ways to design business systems using their data bases. This serious void in application design education in the MultiValue community is one more reason the strengths of Pick are less visible and less acceptable in mainstream boardrooms than it deserves. Add this to my personal list of the things we need to fix in order for the Pick database to stay successful and competitive.