Hey, did you catch that redirect? The Toad World URL is now community.toadworld.com. Don't worry -- you'll still find all the same great content here (and more on the way). We're just in the process of giving our Toad World site some well-deserved love. Stay tuned for some more updates coming this way.
Meanwhile, enjoy community.toadworld.com.
A few things improve with age (like good wine), but most things deteriorate as time goes by. Technology typically follows the curve below that will be familiar to anyone who has owned an old car…
Once the initial teething trouble has passed, technology typically achieves a stable plateau where it stays for a long time. In the case of a car, physical wear will cause it to reach the breakdown point where reliability goes rapidly downhill, but IT systems are also susceptible to the same deterioration. There are many reasons that contribute to the breakdown point for IT systems: Operating system upgrades, changes to surrounding systems, increased user expectations and even the ability to attract and retain people skilled enough in the technology.
Many organizations today are looking at their Oracle Forms applications and wondering whether it is getting close to this breakdown point. Oracle Forms has lived longer than most IT tools, having moved from terminals to client/server to a three-tier architecture, and from character mode to graphical user interfaces. But users are increasingly finding the user interface dated and unattractive, it can be hard to integrate Oracle Forms applications in a modern IT infrastructure, and the Oracle Forms developers are slowly moving to new things or retiring.
There are three options for a Forms application today:
Doing absolutely nothing to maintain your running Oracle Forms application is not a good idea. The workstations where your users are running the application are continually being updated to newer operating systems, and you have to contend with new web browser versions and new versions of Java regularly. Doing nothing at all leaves you vulnerable to these changes, and unless you at least upgrade to the latest version of Oracle Forms, Oracle support can’t help you.
If you are still running Forms 10g, count yourself lucky that you didn’t experience any problems, because it’s been more than three years since the end of Oracle support.
If you are running Forms 11gR1, you’ve got another few months of premier support (until June 2014). After that, you’ll have to pay more for less – that’s the way Oracle Extended Support works.
Moving to Forms 11g means running the Oracle WebLogic application server. That’s a new skill to learn for your application server administrator, but if you are only running Oracle Forms, you will be using only a very small fraction of the features of WebLogic.
Contrary to what you might have been led to believe, there is no additional license cost for moving from Forms 10g on Oracle Application Server to Forms 11g on Oracle WebLogic. If you only want to continue to run your Oracle Forms application in a supported environment, you’re covered by your existing license. However, as soon as you use any new feature of WebLogic, you’ll have to pay for your WebLogic.
Have you seen one of the many “house makeover” TV shows? With slight variations, every episode of every one of them contain the same two things:
This is exactly what an Oracle Forms makeover should look like.
First, you remove a lot of the screen furniture. All Forms applications tend over time to gravitate towards “the one screen to rule them all.” This screen is crammed full of every field that every user could possibly need, using every last pixel of screen area. However, if you actually observe the users or add logging of individual elements to your Oracle Forms module, you will find that 80% of the time, your users are only using 20% of the elements on the screen. Create a copy of this massive screen where you remove all of the fields, checkboxes and buttons that are rarely used and make this the default screen. Then have an Advanced Mode button or separate menu item to invoke the overfilled screen.
Second, you change the color scheme. If your application is still using a retro-gray background like we did in the 80’s and 90’s, change the background color to white. Also, replace all your default Oracle Forms buttons with graphical image buttons with rounded corners and a modern look. Together, these two simple things will improve the visual appearance of your old Forms application dramatically.
If you need some specific modern user interface component to solve a specific need, you can even include a modern Java UI component as a Pluggable Java Component. You can google this term to find some worked examples.
Finally, you might choose to migrate your application to another technology. In the Oracle world, the two obvious options are Oracle ADF and Oracle Application Express (APEX).
In the Oracle Application Development Tools Statement of Direction (http://www.oracle.com/technetwork/issue-archive/2010/toolssod-3-129969.pdf) document, Oracle provides some pointers:
I recommend you read the entire Statement of Direction document as part of your decision process.
Because a straight 1:1 migration carries a cost, but does not provide any additional business value, you should avoid this. Instead, you should harvest all the low-hanging fruits you can as part of your migration. To do this, follow this six-step process:
Triage means to divide into three parts. For your Oracle Forms application, divide the module by business impact into crucial, important, and not important. You are likely to find that 20-30% of your Forms modules are not invoked even once a month, and might not need to migrated at all.
Pushdown is the process of going through the business logic in all the Forms triggers and PL/SQL libraries that contain your own code, and moving as much logic as possible into the database. If you move to APEX, the logic is going into the database anyway, and if you move to ADF, you save rewriting all the PL/SQL that can live in the database.
The rethink is the step where you step back from the old application and think about where you can add extra value to the users. Both ADF and APEX have many features that Forms didn’t have.
Then you build the shell of the new application. Concentrate on the outer part (menu etc.) and place all your existing Oracle Forms module inside <IFRAME> tags. Then you add the high value features you identified in your rethink and release the initial version of the application to your users.
With their feedback, you can finally do the stepwise migration of the Oracle Forms parts of the application until you have removed all trace of Oracle Forms.