iSeries architects (was: framework question)

> In my experience, iSeries architects are some of
> the best designers in the world.

I think we can identify several distinct realms involved in iSeries
programming:
1) Packaged software, sold and supported by an ISV
2) Home-grown software, designed and supported by in-house staff
3) In-house modifications to packaged software

I believe that when Joe thinks about iSeries software, he sees (1)
above.  When I think about iSeries software, I think about (2) and
(3).  I am certainly not elite; not even having a university degree,
but I think it is fair to say that virtually none of the home-grown
software has seen the hand of an architect of any sort.  It tends to
evolve by means of maintenance and the occasional large project.
Database tables aren't particularly normalised, error handling is an
afterthought and security isn't.

In a feeble attempt to steer the thread back toward the charter ('This
list is devoted to the discussion of Java techniques specifically as
they apply to the AS/400 and iSeries',) I have personally encountered
this 'design as a byproduct of coding' in the way that Java tends to
be added to an existing RPG-based system.  Individual RPG programs are
gutted and turned into stored procedures in order to quickly give the
Java team the ability to use the business rules without having to
rewrite them in the UI layer.  On the surface, this seems like a Good
Idea, but the lack of overall architectural supervision means that the
stored procs aren't cohesive in terms of being reused from the green
screen side (this is very easy to do if the SP uses a service program)
or even viewed as a real part of the application by the rest of the
team (the RPG folk.)

So.  When an organisation is moving toward the web, and there is a
small pool of Java talent (like an intern), how does the RPG shop
find/grow an architect who can encompass both sides of the new
paradigm?  Or will the semi-controlled chaos of 'design as byproduct'
continue?  If it does continue, will the resulting application be more
fragile because of the addition of Java?  Is 'so-so' OO Java better
than 'so-so' procedural Java?  Can an RPG guy like me ever do better
than 'so-so' procedural Java?  Can I learn and really use OO when I'm
mostly doing RPG on a day-to-day basis?  Stay tuned for the next
exciting chapter...  :-)
  --buck