John brings up some interesting points.

At my current client we're getting incredibly close to production for our
first ADF 11g application, and its a corker at 1 page! (ok, there's a bit of
sophistication in that 1 page app, but still only 1 page).  I'm sure a 1
page app would be a poster child for your needs Shay, it's even got a
spinnng icon! ;-)

In adopting ADF my client has taken the recommendation on board to start
small and build up skillsets, resources and similar.  However like John
indicates, the adoption of ADF is slowed by other peripheral activities,
tools etc.  WLS has certainly been a learning curve.  The introduction and
setup of SVN is another, and its disruption of the current change control
processes.  I've also put a lot of emphasis into teaching teams to do
proof-of-concepts to see how things do and can work, as well as how to write
design documents that assist the ADF development process.  This all takes
time.

There have also been 3 other main limiters in our ability to do more:

1) the organisation has a substantial Forms legacy system + other systems to
maintain; these continously pull team resources away. ADF is still niche,
not core to their dev strategy purely because of the scale of the legacy
system
2) there are virtually zero other ADF resources available internally and
externally in the local market. Java resources are somewhat available, but
to be honest I'm not overly keen to introduce them as they're first reaction
to ADF is usually immature
3) continous issues of Forms is more than capable of providing "good-enough"
solutions in many cases, so where to focus for the next ADF application
without rewriting something Forms is already doing well?

In saying # 3, my client does have a number of upcoming projects which will
lead on from a heady 1 page application, which will be particularly suited
to the web delivery ADF is capable of, and in turn more excitingly tailor
fitted to the new task flow features.  We're hoping for at least 2 pages in
the next app! .... logon, logoff ;-)

I guess why I wanted to post in reflection of John's timely comments is the
adoption of a new technology into an organisation can often be a large
undertaking which has little to do with the actual technology at hand, it's
the peripheral issues that take a lot of time, and often requires somebody
who is keen to see it succeed with a long term outlook.  This is why at
times I've taken pains to indicate to Oracle, that beyond providing demos on
features and similar, you need to assist organisations (for free ;-) in
sloting JDev into the existing internal mechanics of the organisation
(remember my rant about SVN + JDev? - it's not about SVN, it's about changes
to change control procedures that was a pain point for us in adopting JDev)
.... but that's also why this group exists.  In addition given there are now
so many "successful" legacy systems installed unlike 10 years ago, new
technologies need to be incredibly good to dethrown their predecessors in a
zippy fashion, even with a lot of bells and whistles.

Regards,

CM.