The most important part of the Proof of Concept is that it goes all the way through the mountain, or in application development terms, all the way from the user interface to the backend data service and back.

If your data service is data in relational tables and you will be using the ADF technology stack (ADF Business Components and ADF Faces), the part of your Proof of Concept that demonstrates the technology is fairly straightforward.

However, if for some reason, you decide to not use ADF Business Components or you want to base your business components on something other than relational tables, things get more complicated. It might be that your data service is based on Web Services or API code in C++, Java, or PL/SQL. In this case, you will need to demonstrate that you can retrieve data from your data service, display it on the screen, modify it, and successfully store the changes in the backend data service.

You might also have user interface requirements that require more advanced components such as trees, graphs, or even drag-and-drop functionality for the end user. If that's the case, your Proof of Concept user interface needs to demonstrate the use of these special components.

There might also be other significant requirements you need to consider. Your application might have to use a legacy authentication mechanism such as a database login. Another possibility is it might have to integrate with legacy systems for authorization or customization, or you might need to support accessibility standards allowing your application to be used by people with disabilities. If you have these kinds of requirements, you have to evaluate the impact on your project if you can't meet them. If they are critical to your project's success; you need to validate them in a Proof of Concept.

The ADF technology obviously works. Hundreds of organizations have already followed Oracle's lead and built big enterprise applications using Oracle ADF. It is very straightforward to use the ADF framework with relational tables; the framework handles all of the boring object-relational mapping, allowing you to concentrate on building the actual application logic.

You are likely to inherit at least some of the data models from a pre-existing system, but in rare cases, you will be building a data model from scratch for a brand new application. JDeveloper does allow you to build data models, but Oracle also has other tools (for example, SQL Developer Data Modeler) that are specialized for the task of data modeling. Either way, the ADF framework does not place any specific restrictions on your data model—any good data model will work great with ADF.

But your requirements are special, of course. Nobody has ever built an application like the one you are about to build—that's the essence of a project: to do something non-trivial that has not been done before. After all, if you didn't need anything special, you could just pick up a standard product off the shelf. So, you need to consider all of your specific requirements to see if ADF can do it.

ADF can still do it. The ADF framework is immensely powerful as it is, but it also allows you to modify the functionality of ADF applications in myriad ways to meet any conceivable requirement. For instance, if you have to work through a data access API, you can override the doDML() method in entity objects, allowing you to say, "Instead of issuing an UPDATE SQL statement, call this API instead." If you need to work with existing web services for modifying data, you can create data sources from web services.

However, you shouldn't just take my word (or anybody else's word) for it. Building an enterprise application is a major undertaking for your organization, and you want to prove that your application can meet the requirements.

The development speed of a task mainly depends on three factors: the size of the task, the complexity of the task, and the speed of development.

The size and complexity of the task is given by your requirements. It would be a rare project where all of the requirements are exactly known at the beginning of the project, but if you have a set of detailed requirements, you can make a good estimate of the project's size and complexity.

The speed of development will be the greatest unknown factor if ADF is new to you and your team. Using your previous development tool (for example, Oracle Forms), you were probably able to convert your knowledge of project size and complexity into development effort, but you don't yet know what your development speed with ADF will be.

Your relationship with your development tool will go through a number of phases—not unlike a romantic relationship. Using the terminology of some of the countless relationship coaches on the Internet, we can identify three phases of a relationship:

During the infatuation stage, your development speed is fairly high. You will be building the types of functionalities illustrated in the tool tutorials—fairly simple stuff that the tool supports really well.

After this stage comes power struggle. You want to implement some specific functionality and the tool simply refuses to cooperate. During this stage, your development speed drops (and your frustration rises…).

Assuming that the relationship between you and your tool survives this phase, you can move on to the co-creativity stage. This is where you understand the tool: you know its strengths and how to overcome its weaknesses. During this stage, your productivity recovers to the initial level and continues to grow to a higher and higher level.

Graphically, it will look as shown in the following figure:

If you have to provide an estimate of development speed very early in the project, you can use your initial development speed as an approximation of the productive development speed you will eventually reach. However, if you do this, you must be aware of the period of lower productivity before you start climbing up with your full productive development speed.

The outcome of the Proof of Concept is not an architecture in the form of boxes and arrows on a PowerPoint slide. David Clark from the Internet Engineering Task Force said, We believe in running code—and that's what the Proof of Concept should deliver in order to be credible to developers, users, and management: running code.

If you want to convince your project review board that ADF is a viable technology, you need to bring your development laptop before your project review board and perform a live demonstration.

Additionally, it is a good idea to record the running Proof of Concept application with a screen-recording tool and distribute the resulting video file. This kind of demo tends to be watched at many places in the organization and gives your project visibility and momentum.