Is Oracle selling ADF has some "point and drop and the page is built" app? - ADF Enterprise Methodology Group

Message from discussion Is Oracle selling ADF has some "point and drop and the page is built" app?
Received-SPF: neutral (google.com: 208.97.187.133 is neither permitted nor denied by best guess record for domain of av...@avromroyfaderman.com) client-ip=208.97.187.133;
Message-ID: <d8697c7cbea0a8d8b7a5f1d1334bb0b9.squirrel@webmail.avromroyfaderman.com>
In-Reply-To: <4A3625E9.1010503@oracle.com>
References:
    <96d340ea-2ff9-4992-a582-423ce3a0e...@p21g2000prn.googlegroups.com>
    <4A3625E9.1010...@oracle.com>
Date: Mon, 15 Jun 2009 10:38:19 -0700
Subject: Re: [ADF Enterprise Methodology Group] Re: Is Oracle selling ADF 
 has some "point and drop and the page is built"  app?
From: "Avrom Roy-Faderman" <av...@avromroyfaderman.com>
To: adf-methodology@googlegroups.com
User-Agent: SquirrelMail/1.4.19
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Grant,

I was just emailing back and forth with Duncan about this issue. I'll
repeat here what I said there.

> However,
> what we do try to show is that not everyone in your organization has to
> know all the details about all of these technologies.

I agree wholeheartedly with *this*. But I don't think it always gets made
clear. Duncan was telling me about the Fusion Apps model: The vast
majority of Oracle Apps developers know very little Java. Instead, the a
cadre of fairly elite Java coders forms the OA Framework team, which does
almost everything that requires Java coding, in a sufficiently general way
that it can be declaratively adapted to specific instances. I think that's
a *great* way to proceed--in fact, it's the primary core of my "Extreme
Reusability" methodology--but it's *not* the way that I think most
customers would go after skimming the JDeveloper doc and collateral.

Take a look, for example, at the help topic "working productively in
teams." If this principle should be articulated anywhere, it should be
articulated there. But there's no mention of it--it's all about who
designs the EOs, who designs the VOs, and who designs the pages. (Not that
I don't think that's a useful division. But if you're not going to train
your whole team in Java, it's *certainly* not the most important
division.) Instead, I think a lot of teams have the following experience:

1) They go for ADF without having real Java knowledge *anywhere* on their
team, because they have the impression it's a 100%-declarative framework
(except maybe for a bit of scripting-style Java, which is trivial to learn
if you're familiar with *any* procedural language).
2) They try to build a real enterprise application.
3) They freak out.

Now, as a consultant, that process isn't all that bad for me, because Step
4 is usually, "They hire a consultant to pull them out of the fire." But
for the community generally, I think it would be better if people went
*in* to ADF knowing what they do and don't need. They don't need a team
full of Java experts, or even of solid Java programmers. But they are
going to need someone (or, if they're a big team producing a lot of big
apps, several someones--probably even more than that if they're a *huge*
team like Oracle Apps) to solve their Java problems for them. And if they
don't want to hire or train someone like this, they can at least move Step
4 earlier in the process.

Best,
Avrom
-- 
Avrom’s Java EE and Oracle ADF Blog
http://www.avromroyfaderman.com