In late 1996, our company embarked on a project that would bring our customers closer to us by allowing them around-the-clock access to information in our database system. We wanted to give our customers the ability to submit information to us directly over the Web, which would allow us to streamline our credit processing, provide faster turnaround time, and reduce our operating expenses at the same time.
We decided to investigate technologies that would enable us to replace our antiquated third-generation language (3GL) Open Basic Leasing System with newer fourth-generation language (4GL) relational-database technology. After considering several products, we decided to develop the new system on an Oracle database, using the latest development tools from Oracle, including Designer/2000 and Developer/2000 Forms 4.5.
We decided to structure our five-person development team in a somewhat radical way: The leader of the team would be a businessperson with some degree of technical ability, and other team members would be people from our information-systems department who were familiar with our business and skilled in the Open Basic system. The idea was to send this group to Oracle Corporation for training and then sequester them and have them develop the new system while a separate team continued to support the existing system. I was selected as the team leader (I was formally vice president of Operations), and we were put to the task of development.
After we were trained in data modeling, PL/SQL, Designer/2000, and Developer/2000 Forms, we brought in two mentors from the Group-R (www.group-r.com) and Adaptive Consulting Partners (www.adaptivepartners.com) independent consulting firms to help us learn the "real world" applications of the technology.
We had originally decided to build our system by utilizing the latest CASE technology. We planned to use Designer/2000 to model and construct the database and Developer/2000 Forms to build the interfaces. We intended to generate between 80 and 90 percent of the system code by utilizing Designer/2000.
To get us up to speed, we started with a pilot project: the construction of a relatively simple data warehouse. The pilot project took three weeks. We developed the database with Designer/2000 and attached a BusinessObjects front end to the data warehouse. During this project, we achieved our goal of 90 percent generation with Designer/2000.
After this success, with the knowledge transfer well under way, we were set to begin development of our Lease Administration System, using the Oracle tools for development and a centralized UNIX-based production environment with the requisite "fat clients" for the users. Each fat client was to have a runtime version of Developer/ 2000 Forms 4.5, SQL*Net, 32 megabytes of RAM, and a 1-gigabyte hard drive.
During this same time, however, Oracle introduced Designer/2000 Release 1.3 with the Web Generators. After reviewing the features of the new release, we revisited our plan of a centralized UNIX-based, Oracle Forms-intensive, fat-client approach to our production environment as compared to a thin-client system.
A thin-client approach was compelling, because the hardware requirements were so flexible and our application would run on virtually any machine--including palmtop computers--with a browser and access to the Web. In addition, if we went with Microsoft Windows NT instead of UNIX, we could administer our production servers remotely in a distributed environment. And by having the software resident on our servers instead of on each client machine, any updates or modifications to the application would be implemented immediately to all users without any work on the client side.
Because our organization has several offices in the United States and Canada and one in Europe, we had wanted to move to a simpler, distributed architecture that would be easier to administer. The Web technology inherent in Designer/2000 Release 1.3 would enable us to move to a distributed system if we could still do between 80 and 90 percent of the code and screen generation. We'd heard that companies using Designer/2000 usually achieved between 60 and 70 percent generation, but we were striving for a higher number, because we were all new to the technology. We stuck to the screens as they were generated whenever possible and used Java and PL/SQL to tweak reports and menus, and to add some graphic elements for look-and-feel.
To our knowledge, no one had yet utilized the new version of Designer/2000 with the Web Generators and Web-server technology this way. Our project was an enterprisewide global, distributed system for more than 700 users. In addition, changing the production system from traditional Oracle Forms-based applications to a Web-based, thin-client application was a radical departure from our original plan.
We decided to try a relatively standard, distributed platform utilizing Designer/2000 Release 1.3.2 for the creation of the database and the screens, Oracle7 Release 7.3.3 for the database, and Oracle WebServer 2.1 as the production environment on the front end. This architecture appealed to us for several reasons:
Once again, we used a pilot project to test our theories about the new technology and the feasibility of our proposed production platform. We decided to develop an Internet product that would allow our customers to transmit financial information for proposed financial transactions to us via the Internet. The product would be capable of two-way communication: In addition to transmitting the credit applications to us, a customer could get an update on the status of the application as it moved through our credit-approval process. The approval conditions and several other pieces of information would also be sent back to the customer via the Internet.
The only client component the customer would need in order to access our system would be a Web browser and Internet access. Because all of the software would be resident on our server, new versions could be easily supplied to our customers all over the world. The next time they signed on, they would automatically access the new software.
We named the product CopelcoNET; started development in March 1997; and finished five months later, in July. We did load testing and string testing for six weeks and put the product into beta testing at a customer's site in October 1997. We made several minor modifications to the product, including adding reports, simplifying the menu structure, and moving some fields on the screens to simplify input. We developed a Web-enabled help system using RoboHELP, from Blue Sky Software (www.blue-sky.com), and the product went live in November 1997.
We were able to obtain 80 percent of the code generation by using Designer/2000 Release 1.3.2. We tried to use the generated screens as much as possible, because they were robust, well documented in the repository, and quick to generate. The remainder of the coding consisted of some development in SQL, PL/SQL, Java, and JavaScript: The menus were coded in Java, some of the master/detail tables were created in PL/SQL, and the reports were hard-coded in SQL. However, the fact that the database and interface screens were largely generated by Designer/2000 enabled us to bring to market a revolutionary product in a remarkably short time. In total, the project required five months of development and about six weeks of testing.
For the production environment, we decided to use IBM 325 machines as the Web servers and a Micron Net Frame as the database server, all running Windows NT. The database server has 20 gigabytes of disk space, 760 megabytes of RAM, and 4 Intel Pentium Pro 200 processors. The total cost of the production system was about $60,000.
CopelcoNET has been in production for several months and has been extremely robust, with only one minor bug in the code since the system went live. We attribute this success to the extensive use of the generated code, which has proven to be bulletproof. The application is always available (except for the two hours each day when data is loaded), easy to use, and easily scalable, thanks to the Web-server and database-server architecture. While proving our theories about code generation and the production platform, we were able to provide our organization with a leading-edge product in a short period of time at a relatively inexpensive price.
The only real difficulty was mapping the 4GL Oracle front end to the legacy 3GL Open Basic back end. Mapping from the Open Basic files to the columns and rows in the database was a tedious process. In addition, we wrote and tested loader programs utilizing SQL*Loader. Once written, the programs made loading the tables a quick and easy process after the mapping was done. The team had excellent knowledge of both the database and the Open Basic files, which made the mapping a bit easier.
Now that this project is complete, we have abandoned Developer/2000 Forms and plan to use the distributed architecture with the thin-client approach. Since we used generated screens from Designer/2000 instead of Forms for the Lease Administration System, abandoning Forms was a necessary part of the overall strategy.
We are using Oracle Financials at the back end for our financial application, and we are currently well under way in a concurrent development project. We have a team working on the Oracle Financials side, and the developers (who have grown in number to about 20) are utilizing the technology we tested to build a custom front-end administration system.
Because some information resides in Oracle Financials and some needs to reside in the Lease Administration System, the plan is to meet in the middle, with information being pushed and/or pulled from the Lease Administration System to Oracle Financials. We have a team concentrating on building interfaces between the two applications where necessary and making the bridges between the two. The important thing is that the data resides in one place so that the database stays normalized, but it must be accessed from both places in a way that is transparent to the user.
We are also creating interfaces to our Oracle Human Resources system where necessary to provide employee information that will be used to set security levels. When we implemented our system, Oracle Financials was not supported in a Web environment, so we decided to run the financial and human-resources applications on a centralized HP-UX platform while putting the front end administration system into production, utilizing the same Web technology we developed for CopelcoNET.
With Oracle Applications 10.7 NCA and Oracle Applications Release 11, all the Oracle Applications, including Financials are now Web-enabled. We eventually intend to make our new system entirely Web-based.
Using the latest Web technology has enabled us to reduce development time (due to the 80 to 90 percent generation of code and screens), cut down on costs for the production environment (using the thin-client and commodity hardware approach), and develop a robust system in terms of disaster recovery. It also has provided us with an easily scalable platform that can be administered remotely.
We faced the challenges inherent in using a new technology. No one had yet used it on the scale we were attempting, and to date, I believe we are the only company to use the technology in this way on this scale.
It is always a risk to base an enterprise system on technology that doesn't yet have a track record. It was a leap of faith based on the product and the ability of our team, but through the hard work and innovation of a group of very talented and dedicated people, the risk paid off. We are scheduled to complete development in October 1998, and we are currently on time and under budget. These are the words that any company's management likes to hear.
Edward J. Baker (edbake@copelco.com) is vice president and chief information officer for Copelco Capital Inc. He has been with the company for 11 years and has been involved in systems for the past 6 years and utilizing Oracle technology for the past 3 years.