RE: New Development Project - What to do it in? -- MIDRANGE-L

Lets do some math:
15 people * ~60K average salary = $900k/yr
1/3 or a year --> $300K
est. 25% utilization --> $75K

That's a lot of money for a study.  Using WebFacing or PSC/400 you could be 
very close to version 1.0 for that much time and money.  Using LANSA or mrc or 
WebSmart or <<name the dev system>> you could be well on your way to a rewrite.

It is becoming apparent that in the object-oriented world, the structured 
methodology is dead.  Instead of "Do it right the first time", the mantra seems 
to be "Build it, learn from it, fix it".  

This actually resonates with me and seems to be a perfect application of the 
80/20 rule.  Spend the 20% NOW, get the 80% functionality out there, and then 
fill in the gaps!

Good luck . . keep us posted if you don't mind!

------------------------------

Message: 4
Date: Tue, 29 Apr 2003 16:46:42 -0600
From: "Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>
Subject: RE: New Development Project - What to do it in?

I'm part of a team of about fifteen (15) people who are studying this very
question.  In fact we've been studying it earnestly for about four (4)
months.  

The justification for so much effort on "what to do it in" is
because our plan includes replacing about 2,000 green-screen and other
programs in a full-service software application, which currently supports
thousands of public schools, nationwide.

We've settled on a browser as the primary client.  But we're still doing
some prototyping with Java applets, XML with Style Sheets and a JavaScript
runtime engine, as well as HTML.  We're currently supporting these prototype
efforts with both Relational-Web/RPG and Java Servlet/SQL database
interfaces.

In a project of this scope, perhaps more important than any particular
language or commercial IDE, is employing an architecture which separates
application components according to the user interface, database, and
application control logic.

We probably have at least 500 database maintenance programs to write.  A key
to our success will be coming up with a model that enables us to create
these programs quickly.  We're not using any commercial code generators,
here.

Tens of thousands of users will be supported by these programs.  Daily users
include students, parents, teachers, counsellors, accountants, bus drivers,
clerks, school administrators, district administrators, application service
providers who host multiple school districts on perhaps a single iSeries
server, and others.

In cases where multiple school districts are hosted on one box, the
"application execution environment" much connect the right user to the right
instance of the database.  We will be retaining the existing database.  In
this case multiple physical file members are used to record snap-shots of
the data according to fiscal year, and other parameters.

A member of our team coined the term "Application Execution Environment"
(AEE) to refer to a number of runtime features which will be shared across
all programs.  We need a common login/logout procedure, a shared menu
interface.  The interesting thing about the menu is that it varies according
to the "role" the user plays.  Any given user may play a number of different
roles, including being associated with more than one district or school.
The login procedures and menu system must support this.

All programs must share a few common data elements - user interface styling
preferences, for example.

It would probably be suicide to attempt this type of project using thick
client-server technologies.  The development, distribution, maintenance, and
support of a Visual Basic type client would kill us.

With this type of application, the runtime environment, productive
development models, performance, and scalability are paramount.  On the
other hand, when you're just playing around with your first GUI interface,
does it really matter what you "do it in?"

Nathan M. Andelin
www.relational-data.com 



THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH 
IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL 
AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW.  If the reader of this message 
is not the intended recipient, or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, downloading, storing or forwarding of 
this communication is prohibited.  If you have received this communication in 
error, please notify us immediately via email and delete the message from your 
computer files and/or data base.  Thank you.