Niels,
I agree with what you are saying concerning one framework builds on another.
<Niels>So when you select ASP/JSP/PHP/IceBreak/RPG/JAVA/RUBY/ etc. the key
question is no what they can achieve - because all deliver what they
promises.. No - the question is "what is our exit plan and how easy can we
replace this or that technology?"
Here is the point where I see a lot of traffic as of late, and I don't
necessarily agree with it entirely because there is more than one layer
involved. We as RPG developers should be building tiers so we never need an
exit plan from RPG/DB2/OS400 but instead only need exit plans for the UI
layer and not controller/businesslogic/DAO layers. Let me digress...
The reason we are seeing so much bandwagon hopping these days is because the
industry as a whole is trying to find the right UI to deliver it's
software. How many shifts have we seen (big and small) in just the
HTML/browser space alone that have caused ship jumping from one
language/platform to another? IT shops are doing full fledged migrations
away from the IBMi because it has an ugly screen, and instead of just trying
to address that one layer they choose to jump ship to an entire new stack
(i.e. .NET/Java/RoR/etc). This will inevitably bite that IT shop in the
butt because they are spending more time learning new things (and fixing
them) than actually meeting business needs. I do realize that a nicer
interface has become a business need in many cases, but so are a lot of
other things that then go by the wayside because software creation/maint
lifecycles take so long when adopting new frameworks for enterprise systems
(i.e. you get to learn most everything from the ground up all over again,
just like the first 10 to 15 years of learning RPG+DB2+OS400 and all of it's
tricks and nitpicks). The way to go is instead to first start modularizing
your RPG code and then stick whatever flavor-of-the-day-UI on the front of
those as it changes.
Some of my statements you might agree with (at least I would assume being
you know the value of RPG+DB2+OS400), but I just wanted to explain that it
isn't an entire software programming stack that we should be planning to
exit, but instead only the portions that have a high probability of change.
I have learned (the hard way) that being over zealous when you hold the
decision for staying or moving on with a language/platform is a dangerous
place to be. An "IT Architect" really needs to understand where the
business has been, where it wants to go, and how tiered software can make or
break a company and their new technology endevours.
Aaron Bartell
http://mowyourlawn.com
midrange.com
