In last months column, I hinted at the need to consider what happens when things don't work quite like you had planned them. In my view, this is one of the biggest unaddressed issues in data processing today. Virtually all the applications I have had the opportunity to review assume everything always works perfectly. Oh – there are the (all to rare) operations managers who actually do more than worry about disaster recovery. Who have actually taken some steps to have off site backups, written an operational recovery plan, and have lined up equipment suppliers. Even rarer today are the ones who have run a mock disaster to test the plans. What those who have tried have found is that nothing works as documented. No plan stays intact for long. Even in the confusion of a mock event, the reality is much worse than the plan assumes.

"Well" you say, "so what?" "That stuff is for the big main-frame guys – I only run 50 (100, 250?) terminals. I don't have the same problems they do."

"Well" says I, "you are only partly correct. And both size shops may be missing the real point". Yes, today most of you are on smaller boxes and your exposure to physical disasters may be quite a bit less than someone who needs to replace a 2000 terminal system. But besides the fact that everyone still needs to be responsible and do their homework in this area, both large and small shops need to realize the world is quite different today than in the sixties and seventies. That was the point buried at the end of the last column I now want to reemphasize. Computer systems have stopped being adjuncts to the business, in most cases today they are the business. Disaster recovery programs are more important than ever, but designing in disaster prevention may mean corporate life or death. Twenty years ago we worried about getting back on line in a couple of weeks and how to get replacement hardware. For many companies today, a couple of days without computer support may destroy a whole years profits, or even mean the end of your company.

The difference today is the central role computers play in the life of the business. Twenty years ago, the business ran on a series of transaction oriented independent batch systems that often ran on separate hardware systems. For the last two decades, the push has been for ever tighter application systems integration on ever faster, larger hardware. The dramatic increase in hardware technology and fault tolerant or fault resilient operating systems has barely kept up with the runaway corporate reliance on computers.

While the world is rapidly moving towards distributed applications on independent hardware systems, its not entirely correct to say we have come full circle. The distributed, independent systems of the future will have to do much more than the previous systems. They will have to provide the fault resilience and performance that both large and small customers have grown to depend on. The hardware can be relied on to help provide the performance, and the OS's should provide a degree of communications error recovery, but the applications design will have to supply much of the application fault tolerance.

As systems designers, we will have to begin thinking about new ways to design systems. Designs with more emphasis on reliability issues which are largely ignored in current systems. Designs that will probably violate some of the accepted data normalization rules and actively store data in multiple locations to provide redundancy. And designs for robust transaction based applications that can withstand major sub-systems being off-line or out of sync with each other. Virtually all existing application systems were designed without regard to any of these issues, and not many of today's system designers have a clue how to go about this process. Most designers (especially in the MultiValue community) are working with on-line systems that are not at all transaction oriented. In fact, many current applications people have never considered the impact of a transaction based design.
MIS management is going to have to understand that the organization is likely very weak in these new issues. You will need to allocate budget and stress a commitment to actively develop expertise before jumping in with both feet. Education is critically important. Send your staff to classes that address these issues. During your internal group design discussions, be sure you include questions regarding the effects of total volume and error recovery issues. Questions such as the impact and recovery from the loss of part of a network or different portions of a database being 'out of sync' in time with each other. You must begin to think about and design systems that are less monolithic and more resilient to various errors.

Client Server certainly may be the wave of the future, but companies that move to this new technology before understanding the application changes required will end up in trouble. If they fail to build in the necessary software flexibility, they will find their monolithic system shattering. Those who stay where they are will find tomorrow's offerings from Pick (and Pick-like) vendors will continue to improve error recovery and OS fault tolerance. On the other hand, antiquated application designs can only be stretched so far before they fall apart or get passed by more nimble competitors. Jack be Nimble is the watch word of the Nineties. Being nimble starts with a MIS management attitude. It takes some time, but costs less than you think. Running uphill before you are sure your organization is nimble leads to falling down and breaking your crown. Consider which Jack ended up ahead.