RE: Dropping the AS/400 as a Web serving platform -- MIDRANGE-L

> Our back end will
> remain AS/400 for some time.  But how long will that be, remains
> to be seen.
> When will business decisions based on getting more people to get the job
> done.  No matter how much business knowledge I have - if there are 5 more
> programmers for other platforms, other then the one I'm on.  Someone is
> going to do the math soon.  No matter how much the ROI is on the AS/400 -
> people will ignore that when they realize they can get more people faster
> and easier then they can find people like myself.  More are being produced
> every day from Colleges and universities.

An interesting point, but not without some serious flaws.  The argument
Andrew makes is that colleges are turning out developers who can use IIS and
JSP as opposed to programming on the AS/400.  For what?  Not for enterprise
level applications.

Give me a representative 10 AS/400 programmers and 10 college-produced
IIS/JSP developers, and I'm reasonably certain that there are more members
in the AS/400 group that understand basic business programming.  In fact,
given 10 AS/400 programmers and 100 IIS/JSP web application developers,
there will STILL be more actual business programming knowledge in the AS/400
group.

The AS/400 is not home to whiz-bang web applications.  But, in case anybody
hasn't noticed, whiz-bang applications aren't actually permeating the
business marketplace.  Instead, the majority of business web applications
seem to be storefronts - please correct me if I'm missing something here.
Frankly, I don't care if storefronts are written in VB (provided that the MS
machine has only token access to my AS/400!).  That's because the back end
still has to be something with reasonable performance and ROI.

The true wave of web-based business applications has yet to even hit us yet,
and a large part of that is because the platforms they're built on can't
handle the scaling.  Some of that is due to the architecture, but those who
know my stance on SQL will understand my reasoning there, so I needn't go
into it.  (But as a side issue, I'm reasonably certain that college
graduates who have taken the basic SQL courses don't have a clue what a LEFT
OUTER JOIN is, nor how to apply it in a business environment, so it's not
surprising that there are so many SQL performance problems in the industry.)
The other part is that somebody who has taken IIS, Java, JSP and SQL in
college doesn't know the first thing about designing a promotions and deals
database.  Or a forecasting module.  Or an MRP generation.  So while you
might see an amazon.com running on a SQL database (don't quote me, I have no
idea what they run), you won't see BPCS written in VB anytime soon.

In fact, you won't see an ERP package - or even a decent module - written by
a recent CompSci graduate anytime soon.  How many IIS/JSP developers are
APICS certified, I wonder?

Which leads to an interesting observation.  Rather than worry about turning
the AS/400 into a competitor for IIS, why not concentrate on designing
systems that take advantage of the undeniable strengths of the AS/400: its
incredibly fast, robust, highly scalable database, and it's unparalleled
reliability.  The AS/400 is the best platform for implementing business
rules ever designed, so why not use that strength, rather than diluting it
with things it doesn't do quite as well?

Let's start thinking about designing applications where the user interface
actually isn't tied to the database, where the UI can communicate via a
fast, flexible interface to the transaction processor.  This way, the user
can decide to opt for running the UI on their AS/400 (for lower volume
environments), or put a phalanx of web serving PCs in front of the box, with
full failover and load balancing.  The PCs do all the graphics and the
static web stuff (thereby offloading the AS/400) and delegate the access and
update of persistent information to the AS/400.

But this means designing clients and servers - true n-tier solutions.  Even
though we've been talking about it for decades, the truth is that, with
SQL-based client applications, we're actually moving away from that
particular Nirvana.  As more and more business rules find their way into the
client, there is less need for a fast server - instead, ALL applications run
like crap.  Once you've gotten your user to accept a 2-second wait, you can
write as bloated of code as you'd like.

I don't know.  I could be whistling past the graveyard here.  But I still
think the demise of the AS/400 is overstated and a bit premature.  Until I
start seeing LotusScript experts who can actually write a shop floor module,
I'm going to continue to recommend RPG and the AS/400 for business
applications.

Joe Pluta
www.plutabrothers.com