There will be a *new* tool, within a few years that will impact your
development. It's reality. It's gonna happen. So plan for that in your
design strategy so as you rip out one layer and replace it, it will have a
minimal impact on your overall solution.
But let's realize one thing here. The degree of ripping and replacing is
what's important, and IBM does more retooling than necessary to meet new
technology business needs. For example, more than likely HTML version xyz
will be coming out in the next couple years. I would *expect* change to
happen to the application stack. And like you say, if you built the stack
with the right tiers then the changes will be less invasive (i.e 15% of your
application, the View, needs to change). The issue I have with IBM's
approach is they ask you to change 50% to 60% of your application stack with
the introduction of technologies (i.e. introduce a new business language -
EGL) vs. capitalizing on RPG and just adding a new View. Now EGL wouldn't
be such a bad new thing as it provides benefit to non-iSeries customers, but
it is also being done INSTEAD OF a native framework on the IBM i that would
allow the M and C of MVC to stay in RPG vs. requiring the C to be EGL (hope
that string of sentence letters makes sense :-).
In the end we will always have
I can sometimes leverage the small things I pick up on the way to produce a
better solution but I never assume that I am done.
I'll wake up tomorrow and find out that EGL is now replaced with the NBT
(next big thing). I am fine with that. Innovation results in constant
change. I am cool with that as well.
But you miss my point. Of course consultants are fine with technology
changing (which both of us are). We actually enjoy the challenge of trying
to make the NBT work within an existing organizations current software
family. We *can exist* because technology changes so much. We can make
good money by trying out a majority of the solutions out there and
determining what collection of tools will work best for the next 5 years.
The issue is that changing technologies significantly adds very little value
to the business. As I see it the business cares about making sure they have
easy interfaces for their customers and employees. This means that only the
user's *interface* to the server should be the only thing changing and NOT
the majority of the application stack (i.e. adding a new business/controller
language of EGL on top of RPG).
FWIW, I believe EGL (based on Joe's description of it's extensibility) is
built in this fashion (finally) of allowing the View to be torn out and
replaced with very little effect on the Controller and Model. Unfortunately
it is still a risky venture for RPG shops because of IBM's track record of
trial and error - we are forever guinea pigs.
Could IBM do better in laying out a long term development tool strategy? I
don't think so.
Sure they could develop a much better system for long term. They could
build the View layer once (using all the supporting technologies they used
for EGL), document the interface to that View layer and then allow it to
seamlessly talk to the varied servers they have along with the Controller
and Model code already written in the langauges on those servers.
I get the feeling we are settling for what is popular in the general IT
marketplace vs. demanding something better from a company (IBM) that was
able to do it 20 years ago and could still do it today it their ideas were
allowed to be put into the marketplace.
Aaron Bartell
http://mowyourlawn.com
On Tue, Jul 15, 2008 at 10:26 AM, Pete Helgren <Pete@xxxxxxxxxx> wrote:
midrange.com
