Choosing the Architecture
There was no doubt that we needed a bullet-proof architecture for the new product line. I decided this was our chance to start fresh and design a product from the ground up that would be equal to my vision of the all-encompassing manufacturing software system.
We chose the Oracle database for the back-end in part because it was by far the most robust and scalable system on the market at the time. I believe this to still be true today. Another reason for our decision was that a large current customer that used our DOS-based RealTime Machine Monitoring was pushing us toward Oracle. Their large IT department presented us with their research which we were more than happy to accept.
For the front-end we selected the Delphi RAD IDE Windows development system which at the time had the best native connectivity to the Oracle database and the fastest performance on the Windows platform. Delphi also allowed development of multi-threaded Windows NT applications which was critical for developing our real-time products such as our RTServer RealTime Machine Monitoring system.
I later found out that many of our competitors selected integrated development systems such as Progress or Power Builder. While both of these client server development systems offered a quick way to build enterprise software they did not offer the scalability and performance of Delphi with the Oracle database. The architecture choices we made were hard on our programmers which were headed up by Arik Averbuch. Arik had been with us for a number of years and was our top Clipper programmer specializing in object-oriented development. The choice of Delphi and Oracle necessitated a double learning curve for the coders. Dephi’s base language is Pascal and Oracle stored procedure development is PL/SQL. Both of these languages are different than DOS-based Clipper and from each other. Not only did our programmers need to learn a new language, they needed to learn two new languages and they needed to do it quickly.
Our goal was to start out with a normalized data structure and utilize Oracle stored procedures, packages and triggers to provide the required referential integrity. All transactions and business rule processing would be done on the Oracle server. I knew that front-end operating systems come and go but the data will always live somewhere and that somewhere should be a single place (one version of the truth). Putting all the data processing on the back-end had many advantages. It didn't matter which client UI (user interface) was/is used as there was/is no data processing taking place on the client. Windows-based programs, web applications or even mobile applications all call the same stored procedures which means the answer will be the same across any type of UI. By putting all of our eggs in the Oracle basket we took the gamble that the Oracle RDBS would continue to be the dominant system in the future. This was a time before Microsoft SQL made a debut so the choice was easy to make. We also gave up the ability to be database independent via a three-tier architecture. This architecture is where the middleware processes business rules, and as long as the database system would support the SQL 92 standard, it could be used. I thought the three-tier methods could lead to poor performance and increased hardware costs to our customers as well as a possible headache for our support department.
In the end, Arik and I agreed that going with the Delphi/Oracle architecture would give us the most performance and the longest product lifecycle. Now all we had to do was to define hundreds of tables and views, then write, test and document millions of lines of Delphi and PL/SQL code. During that process we would always take the long term view when making development decisions. The easy way is very seldom the best way. We always asked “What would be best?”. All we had to do was answer that question and the decision was made.
