Read an Excerpt
Chapter 3: Seven Keys to Successful System GenerationIn the years we have been using Oracle Designer to generate Oracle Developer systems, we have learned that there are a few obstacles that can really hinder your development effort, but there are also some great opportunities to prepare the way for a very successful system development effort. We have organized some of our experience into a series of important areas that you need to consider, which we call "The Seven Keys to Successful System Generation." They are:
- Key 1: Management Support
- Key 2: Experienced Mentoring and/or Training
- Key 3: Infrastructure
- Key 4: Standards
- Key 5: Realistic Expectations
- Key 6: Designing for Generation
- Key 7: User Involvement
(1)Key 1: Management Support
So you're convinced that Oracle Designer is the way to go. You want to develop quality systems and do good analysis before you start to build the application. You're convinced you can generate most of your application. It's time to talk to your managerabout using the tool. "How much does the tool cost?" he asks. When you tell him, he exclaims, "But we've already spent all of that money for the other Oracle tools!" (strike 1). Next, you tell him that it is not easy to learn, and he will have to send all of his developers to at least two weeks of training. "I'm sorry, we don't have enough money in the training budget" (strike 2). Then you tell him that you will have to change the whole way you perform development to take advantage of the tool. "We've always done it this way, and it has worked so far! Who are you to tell me how to do system development!" (strike 3, you're out!). There are also user interface limitations that might concern your management. While these concerns can be addressed easily, this is often the initial response to the suggestion of using Oracle Designer.
If yours is the lone voice (or one of a few) in your organization that is convinced that using Oracle Designer to generate your system is the way to go, you may have your work cut out for you. It usually takes some changes in the way your organization develops systems in order to use the Designer tool correctly, and this is very difficult to do without management support.
For instance, you will have to have support to justify the increased software and training cost of using Oracle Designer. It's the management's budget that will be impacted, and they will have to be convinced if they are to defend the request.
In addition, quite often, your development process will have to change significantly. For example, you will probably need more information earlier in the development process than you are used to. You will have to prevent developers from hacking the generated code instead of learning how to use the generators to the fullest capacity. It can be very difficult to get all of the developers to do this if the management is not supportive.
There are sometimes limitations to what you can generate with Oracle Designer. It is much better to accept the limitations and design your system to fit within them. However, quite often your customers will want to do something that you cannot generate but that is not really critical to the system. Your system will be more successful if your management supports the idea of near 100 percent generation. If your management is unwilling to hold a hard line on this, you may find yourself doing a lot of post-generation modifications, which can reduce the value of many of the benefits of using the generators. With release 2, the limitations are fewer than with release 1.3, but some limitations remain.
If your management is not already convinced that you should be using Oracle Designer, you will need to arm yourself with as many arguments as you can to convince them that using Oracle Designer is in your organization's best interest. You can use some of the advantages we detailed in Chapter 2 to help you come up with these arguments. There are also many people in the Oracle development community who have had great success using Oracle Designer and who will give you information that will help you justify using the tool. Ask these people to share their experiences with you. You can talk to these people at users group meetings or post questions in Oracle Designer e-mail lists.
NOTE: The Oracle Development Tools User Group (ODTUG) e-mail lists are a great source for help in justifying the use of Oracle Designer. Many people who participate in the list will answer your specific questions as well as share their success (or failure) stories. These e-mail lists are also a great source for help with using the Oracle development tools. For information about becoming a member of ODTUG, check out their Web site at www.odtug.com.(1)Key 2: Experienced Mentoring and/or Training
Oracle Designer is a complicated tool. It is very difficult to use it without some sort of training or experienced mentoring. Usually, it is better to get both training and mentoring, but try to get at least one or the other.
To get the development staff up to speed with Oracle Designer, everyone will need some training! It is possible to learn how to use the tool without specific classroom training (by using the tutorial or trial and error), but this is not the best way to get your staff quickly up to speed. Someone who learns how to use the tool without classroom training may not understand the whole process, and this can lead to a less efficient use of the tool. There are many ways to perform most of the development tasks using Oracle Designer, and the first way that someone figures out how to perform a particular task may not be the best way. You can learn many techniques and tricks in a class that are hard to figure out on your own.
The development staff should begin their Oracle Designer training as close as possible to the time when they are going to start using the tool (this is called just-in-time (JIT) training). If the staff is trained six months before they use the system, they will probably forget much of what they learned and will have to learn it all over again when they are ready to use it. On the other hand, getting the training after they have almost finished the development does not help very much either (we have seen this happen!).
If a development organization is large enough, the easiest way to get JIT training is to schedule on-site classes when they are needed. Oracle Education, many training/consulting companies (like the one we work for), and many independent consultants are available to come to your organization's site to do the training whenever it is needed. If an on-site class is out of the question, try to get the off-site training for the developers scheduled as close as possible to the time of the actual development. (2)Experienced Mentoring
Oracle Designer is a very complicated tool. There are many ramifications to decisions made about administration, design, standards, etc., that cannot be understood without some experience. Because of this, it is very important to get help with the first Oracle Designer project. An experienced Oracle Designer consultant can steer developers around some of the pitfalls and help the development team get up to speed on the tool much more quickly than they could otherwise.
An experienced consultant can do the following:
- Help you to gain management support for using Oracle Designer based on real world success and failure experiences. (Key 1).
- Set up the environment and infrastructure to support Oracle Designer development (Key 3).
- Help you develop and enforce standards (Key 4).
- Set realistic expectations based on their previous experience (Key 5).
- Help you design the system so that it can be easily generated (Key 6).
- Give specific help for the problems that are encountered during development.
(1)Key 3: Infrastructure
The environment needed to support Oracle Designer is not a simple one. There are many complex management, environment, and infrastructure issues that need to be addressed correctly in order to generate systems successfully. The stability and robustness of the generation infrastructure is a factor that quite often separates successful system development efforts from unsuccessful ones. We will consider three major areas of infrastructure that need to be addressed:
- Repository installation and management
- Development environment
- Object libraries, templates, and template architecture
(2)Repository Installation and Management
Without a repository, you cannot use Oracle Designer at all! This may seem obvious, but quite often not enough emphasis is placed on making sure that the Oracle Designer repository is installed and managed correctly. An incorrectly managed repository can lead to performance problems with the tool, which can drastically reduce the efficiency of your developers. It can also lead to loss of data, which at best means that some development work will have to be redone; at worst it can introduce defects into your system. Your repository might become unavailable for a few days, which could have a major impact on your development schedule.
(3)The Repository Should Be Considered a Production Installation
There is quite often a big difference between a development installation and a production installation of an Oracle instance. In a production instance, more care is taken to make sure that there are good regular backups. Usually the production instance will use archive logging or mirroring (or both) to ensure that there is no loss of data if there is a disk failure. The DBAs will monitor the instance more carefully, performing proactive maintenance on the instance to keep the performance acceptable and to ensure that the instance does not go down. This is not always the case for a development instance. You should always consider the Oracle Designer repository instance as a production instance! It is running the production version of an important application that is used by many people. Quite often, your organization will lose as much money if it goes down as they would with many of the end-user production systems. Even if the rest of your environment is treated as a development environment with lower maintenance standards, you should make sure that the Oracle Designer repository instance is treated like a production instance.
As a production instance, the following should be in place:
1. The repository should be installed in an instance easily available to everyone on your development team. The connectivity between the server with the instance and the client machines that will use the tool should be stable.
2. There should be a regular backup of the repository. This can be done by having a regular backup of the whole instance or a backup of just the repository using the tools provided in Oracle Designer.
3. If possible, archive logging should be turned on, or the instance should be mirrored (either one or the other or both, at your DBA's discretion). This will prevent any loss of data in the case of a disk failure.
4. The DBA should monitor the instance for fragmentation and defragment the instance if it needs it.
(3)Have an Experienced DBA
An experienced DBA should create the instance and install the repository. While most experienced Oracle developers can install the repository; they may not know enough about your organization's infrastructure to do the best installation possible. Oracle Designer allows you to split the repository up into multiple tablespaces according to how the tables in the repository are to be used. An experienced DBA will know how best to use this feature to improve the performance of the tool. They will also make sure that the instance and repository is set up in such a way that it can be easily recoverable in the event of a hardware failure or corruption of the repository...