RE: Wasting half a trillion dollars?

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Umm... that is pretty much what 
we are doing (actual deployment):

1.  Browser-based apps for external systems that 
need less features and less performance. 

2.  Fat-client, stateful systems with industrial 
database servers for the internal systems.  There 
is actually less and less discussion of migrating 
these any time soon.  Cooler heads are prevailing.

3.  Means to feed item one from item two without 
exposing item two to unwarranted security risks.  
XML is great for this.  XML is showing up more 
and more as was predicted in the interfaces among 
otherwise encapsulated systems.

The rest is resource management.

We don't see Java in the picture much here.  We 
don't usually need it.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Charles Reitzel [mailto:creitzel@mediaone.net]


I think one needs to look at actual deployment and use cases to get a good
handle on where the ERP apps are going with browser based solutions.  A few
facts: 

1) The bread and butter is still in the fat client.  That's where the
installed base is.  It takes  years to migrate these things (hardware and
software upgrades, training costs, contingency planning, etc.).

2) Although desktop management tools have improved, the fat client is still
very expensive to maintain.  To quote Dave Barry, "I am not making this up."
And, yes, last I checked, even the non-profits want to reduce overhead.
This is all definitely overhead.   Folks will look hard at web based
solutions for new applications or new use cases.

3) Not all users use all the features of these application suites.   The
classic example of where it pays to do something on the browser is self-help
401K and health plan applications.  Only folks in HR need the full
functionality, decidedly fat client.  If you can avoid many of the
aforementioned costs with a web deployment - and you can - many will pay
additional development costs and sacrifice some usability.  So fine, give 50
people in  5 offices the full, native GUI interface.  Give 5000 people in 50
offices the limited web interface.

4) Java applets and Active-X can fill in some of the blanks.  In the Content
Management space, I have recently seen a few products successfully use
either Java applets or COM controls in IE to provide something resembling a
GUI.   For example, Interwoven has a decent XML instance document editor
implemented as a Java applet.  I saw another that provides some basic HTML
formatting (Bold, Bullet, etc.) in a text entry form via Active-X.   It can
be made to work for certain key pieces.  The rest is HTML + Javascript
dogfood in front of the same app server as the fat client.

Altogether - not pretty, but not terrible either.

A separate, compelling argument for web based solutions is extranets.  This
is a done thing for supply chain, purchasing, etc., etc.  Web base apps do
make inter-organization integration (say that 3 times fast) easier
technologically.

Finally, there are a bunch of plain socket apps out there.  These tend to be
easily ported between Win32 and Unixen.   So your <simplisticSolution> has
been around for a while now.  Indeed, the basic interoperability of TCP/IP
and other web protocols is perhaps the greatest reason why Linux has done so
very well.

I don't think we are really talking about fat or thin clients.  A browser is
pretty darned fat.  I think we are really talking about dynamic code
deployment and update - preferably portable.   So far, Java is winning this
game, with Javascript coming in second.  The only other contender,
client-side XML, isn't really happening yet.