[Openroad-users] Comments please

[Betty & Karl Schendel]

At 9:15 AM +0000 10/31/07, Frank Barratt wrote:
>Hi, I am going to be a bit candid with this but 
>we have a consultant who is looking at replacing 
>our current application written in OpenROAD with 
>"more up to date technology" his words.
>,,,
>Option 1- Continue Using OpenRoad and Tuxedo
>
>Advantages
>1. ...
>2. ...
>3. XXXXXXX (a company working with Ingres) has 
>developed tools for code analysis and migration 
>to
>OpenRoad Applications Server which have been used to assist other companies
>faced with the same situation as we have with 
>XXX. However a proof of concept exercise would 
>be required to
>ensure an XXX migration...

Just as same would be required for consultant's suggested option,
and the AS migration is a hell of a lot safer.

>
>Disadvantages
>1. The OpenRoad product is viewed as a 
>constraint. It is a “thick client”, requiring
>software delivery to PC’s, it is vendor specific and not standards based,
>also the developer skills base is in decline.

so? so?  so? and probably not relevant.

>2. Discussions have been facilitated with 
>Ingres, however XXX remains to be convinced this 
>new supplier has serious
>intentions to develop the product in any major way going forward.

How is XXX's lack of convincing, YOUR problem?  It's bullshit anyway,
unless something changed in the last 2-3 months, OR is absolutely
central to the long range plans of Ingres Corp.
There were some very exciting discussions at a March engineering summit
that I was able to listen in on, and all the most interesting ones
involved OR in one way or another.

>3. XXX do not believe the OpenRoad server is the 
>correct way to move XXX away from thick client 
>technology

Assuming this is a good thing?  why?  "thin client" is a fad that
is fading anyway.  It has plusses and significant minuses, like
server load and presentation limitations (the world seen thru the
porthole of a browser is not my idea of nirvana).

>  and
>using the Ingres product would also involve 
>third party consultancy and additional licensing 
>costs,
>neither of which are required for this customer 
>for new developments in Java / WebLogic.

A bold enough statement, which I disbelieve.  I suspect that the true
statement is "would involve fees that go into someone else's pocket
other than mine".

>4. While Tuxedo has a place in XXX and serves it 
>well in the transaction management arena it is 
>not able to
>offer non proprietary, standards based 
>interactions with other applications and systems.

dunno if this is relevant or not.

>5. Other systems are coming on line and wanting 
>to interact with XXX - and the answer is always 
>if they can talk to a
>Tuxedo service XXX can write one for you. This 
>has already impacted the XXX system, where 
>significant extra licensing costs were incurred 
>in acquiring a
>XXXXXXXXXX Tuxedo adapter and is presently 
>impacting XXX, which is being developed by a 
>third party who want to 6. A detailed analysis 
>of the XXX client code is a pre requisite for re 
>writing the application,
>however there are no doubts as to feasibility 
>and manageability of a migration to Java and 
>.NET environments.

Re the last, sez who?  I would have major doubts, myself.
Tuxedo can be a problem, but one would think that a dynamic SQL service
would cover most of the complaints.  There may be a problem here,
but one doesn't fix a problem with X by rewriting Y;  one fixes X.

>7. The down side of moving entirely away from 
>Ingres products is the re write of XXX,
>however XXX has in recent releases been made 
>deliberately more modular in its design (FB 
>Comment - no it has not)
>with recently added new functionality, such as XXXX Applications.

So?  even assuming the truth of the vendor statement, it's still a
rewrite, and rewrites are ALWAYS ALWAYS ALWAYS more costly than
the consultant says.  Sometimes there are good reasons for rewriting,
but it will cost a ton and take a long time.  (and is always always always
best done by the original developers, who have hopefully learned
a thing or two about the app since the first version.)

>
>Option 2 – Web Enabling XXX functions
>XXX proposes the introduction of BEA WebLogic 
>server, Java and .Net which will “web enable” 
>XXX functions.
>Advantages
>1. Applications will make calls to XXX 
>processes, services and data using the Simple 
>Object Access Protocol (SOAP).
>SOAP is an Extensible Markup Language (XML) 
>protocol allowing applications to exchange 
>information over
>Hyper Text Transfer Protocol (HTTP).

This is not an advantage.  This is a technology description.
XML and SOAP are technologies, and weak enough ones at that.
I would put this in the disadvantage column myself.

>2. WebLogic is already deployed as part of other 
>XXXXXXXXXXXXX applications supported by XXX and 
>is enterprise site licensed
>when used in the XXXXXXXXXXXXX account, meaning 
>there are no new licensing costs.

Ok...
sounds like more of a lack-of-disadvantage than an advantage to me,
but whatever.

>3. Java technologies will provide replacement 
>applications with a modern browser based look 
>and feel.

Definitely a disadvantage.  Why would I want to trade in my desktop
and try to do my work inside a browser?  I've never caught on to the
*user* benefit here.  Plenty of IT-department benefits as far as
deployment, but no user benefit whatsoever IMO.

In addition to the look-and-feel DISadvantages, my experience is that
java+browser based apps are slower than tectonic drift, unless VERY
carefully and cunningly written.

>This technology aligns internal Intranet 
>applications with XXXXXXXXXXXXX existing 
>Internet applications such as XXX.
>.NET will also be used where the richness of the 
>user interaction and / or complexity of 
>processing does
>not lend itself to a browser based application. 
>It is envisaged this will cover a few selected 
>areas
>of business functionality including the existing 
>Visual Basic applications already targeted for 
>re write in .NET
>(these are XXX and XXXX, which are closely 
>integrated with XXX). .NET components will also 
>use web services as their means of interacting 
>with centrally managed processes and data.

"We'll replace your Openroad fat clients with .NET fat clients.
It will be ever so much the same, er I mean better."

>4. The use of the XXX OpenRoad client will be 
>run down over time, with its business logic 
>processing being moved to the
>WebLogic layer with front end applications 
>mostly handling just the presentation functions.
>WebLogic is the logical choice to web enable XXX 
>due to out of the box integration with Tuxedo 
>and existing corporate
>licensing agreements for use in the XXXXXXXXXXXXX estate.

Not an advantage.  Just a process description, unimpressive.

>5. webLogic is already deployed as part of other 
>XXXXXXXXXXXXX estate. XXX has already produced 
>web services
>using Java / WebLogic so that XXX clients can 
>access XXXXXXXXXXXXXs and perform location based 
>XXXXXXXXXXXXX and
>so the technologies are already deployed to 
>production environments and developer skills 
>widely available.

A claim which may or may not be true.
Even if true this doesn't overwhelm me with excitement.

>6. Greater responsiveness to business change 
>requirements – a business area can be updated 
>without a
>complete application upgrade. More functional 
>releases possible in shorter timeframes,
>and reduced development and operating costs.

And this is different from OR how?  Unless the current OR code is
astonishingly bad and really does need rewritten, you can "respond"
to a "business change requirement" by updating that part.  The
"complete application upgrade" refers only to deployment and is a
red herring.  The last sentence can be just as true or false
regardless of implementation.

>7. XXXXXX charges will apply to new and enhanced 
>services offered as a result of adopting this 
>strategy.
>Savings are expected through lower unit 
>production costs for releases by using standard 
>and up to
>ate technologies and reductions in support overheads by using common products.
>
>No Disadvantages!!!!!!

There had better be a hell of a productivity gain to overcome a
3+ year rewrite schedule by these "lower unit production costs".
As for support, I've always thought the common products argument
was basically a BS one.  Support problems tend to be volume related
or app quality related rather than variety related, IMO.
If you have 10 crap apps all based on "common products" you still
have a support problem.  If you have 10 working apps that are all
done in different technologies, there's no support problem.
This is a favorite consultant gambit because it sounds so
plausible, like using the same screw type everywhere, and it's BS.


I'll be real blunt here:  all of this reads to me like the MAJOR
advantage of this option #2 is that it pipes all the money into the
new consultant's pocket.  Nope, no disadvantages there!
Especially when it's going to take 3 years!  (And, if I am
wrong and the consultant isn't doing the actual rewrite,
it's still good news because they will be long gone when the
reimplementation fails.  AND, by that time, all the current
managers will be in disgrace or fired, so they can be called back
in to propose the new latest fads of the day!  No disadvantages!)

There may in fact be good reasons for replacing the current OR
system, I don't know.  I'll say that for sure I haven't seen any
of those reasons yet.  App replacement should be based on the
unsuitedness of the existing app, and not on technology arguments.
If the existing code is unworkable crap, get rid of it, and then
one can argue over fashions in technology.  (I'm not into
tech fads myself, but most consultant types seem to be.)
If the existing code is basically OK, keep it.  Sounds to me
like the real problem area is tuxedo services, maybe someone
should be focusing on making a generic data delivery service
instead of emitting drivel about SOAP and XML and clicking
your heels three times...

Karl