Deciding how much to build at a time

If you are building a new system to support a process that has not had IT support earlier, you can build it in one large chunk or in several smaller chunks. The advantage of the large chunk is that you only have to spend resources on one go-live process. On the other hand, if something does not work, you might have developed hundreds of screens with a wrong approach and have to change them.

If you are replacing an existing system (for example, an Oracle Forms-based system), you need to decide if you want to attempt a "big bang" replacement of the entire old system with a new one or if you want a phased approach. As it is much easier to run one system than to run two, some people prefer the "big bang" approach. The problem with this approach, however, is that it carries a much larger risk. If the new system does not perform satisfactorily in the production environment or if unexpected errors pop up, you risk the entire business grinding to a halt while the IT guys work out the kinks in the new system.

Based on my experience, I generally recommend a phased approach, thus building smaller chunks of functionality at a time. If you are building a new system, this approach allows you to find any potential problems early and implement corrections cheaply before you are too far down the road. If you are replacing an existing system, it pays to think carefully about how to run the systems in parallel and accept a bit of extra complexity in order to avoid the risk of business-threatening catastrophic failure.

Deciding how much to build yourself

When you look at the requirements, always ask yourself: "Might someone else have needed this before?"

The complete Oracle palette contains a lot of products, and it might make more sense for you to use Oracle's content management rather than build your own. Similarly, you might want to leverage the advanced layout and customization features of Oracle WebCenter rather than build your own portal framework.

If the Oracle license cost places these products out of reach, look to see if you can integrate cheaper or free frameworks instead of building everything yourself.

Deciding how to integrate

Finally, you need to decide how you want the system to integrate with external systems. As an ADF application uses modern three-tier architecture, you have three places to integrate. They are as follows:

Frontend integration in the browser requires good knowledge of JavaScript. It is possible for your ADF application to exchange data with other web applications through the use of JavaScript in your ADF application and/or the other web application. However, this type of integration tends to be rather brittle and subject to various problems due to different JavaScript implementations in different browsers.

Integration on the middle tier is the typical way a modern web application interacts with other applications. Most often, this is done by having your application consume the web services offered by other applications or by your application offering web services to other applications. This can be done in an ad hoc fashion via a portal framework such as Oracle WebCenter or via a central integration point in Service-Oriented Architecture (SOA). You can also use various messaging protocols and servers to connect applications.

Integration on the database is often the way you integrate with legacy systems. These systems often do not offer modern web service interfaces but can access a database. If your new ADF application is replacing an existing Oracle Forms application, it is often easier to integrate in the database for the period of time when both applications will be running.