Avoiding Mistakes in the Development Process

The concept of distributed databases is a most attractive one to the modern corporation. Coupled with the flashy, icon-driven front ends that are becoming more and more available in the marketplace, this concept is almost too attractive to resist. What could possibly be wrong with downsizing applications from mainframes to minicomputers and even desktop PCs? What could possibly be the problem with allowing data to be owned where it originates? What could be the drawbacks of allowing end users to step up from dull, dumb terminals to the modern-looking interfaces as typified by the Microsoft Windows environment.

The answer is, there's nothing intrinsically wrong with the concept. True, the technology is still in its infancy and there are bugs that need to be worked out. Modern-day PCs capable of running Windows are as powerful as the minicomputers of several years ago. Desktop PCs can now have more than 128 megabytes of memory and can have many gigabytes of hard disk storage. Modern network operating systems are approaching the flexibility and performance of mainframe and minicomputer operating systems such as UNIX. Even more powerful desktop machines are on the way. Even better operating systems and application software packages are being released on an almost daily basis. Costs seem to be going down, making downsizing look better and better every day.

So where's the drawback? Is there a drawback? Are we really living in computer heaven? Can you really get something for next to nothing? An example taken from the real world may shed some light on some of the things that can go wrong.

The OSCAR Syndrome

Several years ago a medium-sized corporation had a legacy software package that had been running for years on a mainframe. The application was a database that managed several gigabytes of data. This was the main application for the firm, mission critical in the truest sense of the word. The firm could not live without it.

The problem with the old legacy system was that the ongoing costs, which included rental of time on another firm's mainframe, came to about $500,000 a year. The director of Information Services saw that downsizing the application to a network of UNIX machines could save the company millions. Without the approval or knowledge of the CEO, he began a secret project to begin to port the legacy application to UNIX. He hired a programmer out of his regular budget and put that programmer to work with an Oracle database. This went on for several months until the programmer completed a demo application.

The director of Information Services then presented the demo to the officers of the company. The demo was a smash hit. The old green-screen CRTs of the legacy system were replaced with color PCs with pop-up windows. Whenever a data item crossed a threshold of criticality, the data was shown in blinking red. Users who saw the demo were thrilled with it. Management saw visions of cost savings. The PR people saw a showcase application that would certainly impress new customers. This company was going to become a technology leader! After much wrangling and ego bashing, the new program was called OSCAR and funds were allocated.

Now the project began to pick up steam. Five outside consultants were hired to develop the entire system. The team was given carte blanche. They were given their own offices, away from the rest of the developers so that they could concentrate on OSCAR alone. They began an exhaustive series of Joint Application Development (JAD) meetings with users, soliciting their input and trying to design a user interface that the users would love. Everything was done to empower the end users, knowing that their approval and participation in the project would ensure its success.

Eventually, plans were made for the actual implementation of OSCAR, Phase I. Remote locations were wired for the UNIX terminals. PCs were bought to serve as terminals. Several mid-range UNIX machines were purchased. Beta testing went off without a hitch. Life was wonderful. A few weeks before the scheduled implementation there was only one little hitch.

Phase I was not going to totally replace the legacy system. It was going to offload a few of the processing modules and remove some of the load from the mainframe. The mainframe database was to feed data to the UNIX machines, the UNIX boxes would do some processing, and eventually give the data back to the mainframe. Finally, someone asked the critical question. How were they going to keep the databases in sync? What happened if data on the mainframe was changed while the UNIX box was working on the same data? Nobody had given serious thought to the problems of data concurrency.

The interface was wonderful. Users were excited. But OSCAR would never work. The department was eventually outsourced after blowing $6 or $7 million.

What's the lesson learned from OSCAR? Everyone involved fell into a trap that is very easy to fall into. Data concurrency was only the executioner's blade. If it had not been concurrency, it would have been something else. The project was doomed to failure from the start.

The emphasis was on the front end. The interface. The GUI. This was the sexy part of the project. It was flashy, attractive, a wonderful tool for selling the project to the users. It was also the last thing that should have been done. The prototype turned into the project. As an afterthought, the team turned to the underlying architecture. By then, they had committed themselves too deeply. The architecture would never work.

Readers may say this was an incredibly stupid mistake. It was. They may say that nobody is that stupid anymore. They're wrong.

In their rush to please their internal customers, data processing shops are giving users unprecedented input into the projects being written for them. Users see a flashy demo running on a minimal database and think that this is the real application. They think that the job is finished when it has not even started.

There are several lessons to be learned from the OSCAR experience. First, a prototype should never take more than a few weeks to develop. If you need to muster the political and executive support, go ahead and build a flashy interface with circles and arrows and a paragraph on the back of each one. Don't spend a lot of time worrying about which tools to use. Don't spend endless months benchmarking different products, at least not yet. Once you've gotten approval for the project, go right to work on the underlying architecture. Move data around. Update it. Insert it. Get the data flows and the data accessibility right. Once you are sure you can move the data into the right places, concentrate on the flashy screens. Choose your tools. Bring the users in and let them become your partners in building the interface. Just don't do it until the underlying structure is tested and proven.

GUIs and flashy screens are downright seductive. The excitement of seeing your applications almost magically change from a green and white terminal to a brilliant color monitor is almost too much for anyone to resist. Sure, get excited about the interface. Just don't confuse it with the real application.