[OT] System Conversion - An Overview

As an extension of an earlier thread regarding a COBOL-to-Java
conversion... some meanderings.

As noted, the core of such a thing is not a technology change, it is a
business process change and needs to be addressed both by those familiar
with the present process (what the COBOL system does) as well as those who
are familiar with the new technology's capabilities (what the Java system
can do).  Right off the bat there may be difficulties... those familiar
with the present process may respond with 'oh, we can do *that*, why
didn't you ask?' when the new-tech team begins its proposals.

I recall reading, someplace, a consultant who said he'd been approached by
a small insurance company in the early 1970s about converting their
current paper-and-pencil system to a state-of-the-art COBOL/CICS
green-screen system.  His off-the-record response was 'They wanted to
duplicate their current processes... they had no idea how using a computer
would change the way they work and the way they could work, essentially
they wanted an electronic version of their current system and nothing
more.'

In like manner... who has not seen a DB2 installation obviously designed
by VSAM-heads? All the overhead of an RDBM system, none of the benefits.

The greatest difficulty, I would say, in these situations is that either
marching-orders have already been given (some stinkwad, two-bit,
Corner-Office Idiot says 'That last Executive Retreat I went to in the
Bahamas - oh, the harsh burdens I bear for The Company! - taught that
COBOL's worthless and Java's the way to go.  Get it done!') or that those
with a particular dog in the fight (Preserve the Olde Wayse or New System
Now) are more interested in keeping discussion in areas that they know
about than in honestly learning something new.

(on my current site I do a lot of ad-hoc reporting and file-creation for a
PeopleSoft system that gets ftp'd off the Big Iron... when it started the
general attitude was 'Oh, that can't be done with COBOL'... and this has
changed to 'Oh, only *he* can do that with COBOL', an equally distasteful
view, I'd say)

All in all, it is usually a good thing to remember what Machiavelli had to
say about the introduction of new systems
<http://www.gutenberg.org/files/1232/1232.txt>

--begin quoted text:

And it ought to be remembered that there is nothing more difficult to take
in hand, more perilous to conduct, or more uncertain in its success, then
to take the lead in the introduction of a new order of things. Because the
innovator has for enemies all those who have done well under the old
conditions, and lukewarm defenders in those who may do well under the new.
This ness arises partly from fear of the opponents, who have the laws
on their side, and partly from the incredulity of men, who do not readily
believe in new things until they have had a long experience of them.

--end quoted text

DD

<docdwarf@panix.com> wrote in message news:fg6u2d$qvk$1@reader1.panix.com...
>
> As an extension of an earlier thread regarding a COBOL-to-Java
> conversion... some meanderings.
>
> As noted, the core of such a thing is not a technology change, it is a
> business process change and needs to be addressed both by those familiar
> with the present process (what the COBOL system does) as well as those who
> are familiar with the new technology's capabilities (what the Java system
> can do).  Right off the bat there may be difficulties... those familiar
> with the present process may respond with 'oh, we can do *that*, why
> didn't you ask?' when the new-tech team begins its proposals.
>
> I recall reading, someplace, a consultant who said he'd been approached by
> a small insurance company in the early 1970s about converting their
> current paper-and-pencil system to a state-of-the-art COBOL/CICS
> green-screen system.  His off-the-record response was 'They wanted to
> duplicate their current processes... they had no idea how using a computer
> would change the way they work and the way they could work, essentially
> they wanted an electronic version of their current system and nothing
> more.'
>
> In like manner... who has not seen a DB2 installation obviously designed
> by VSAM-heads? All the overhead of an RDBM system, none of the benefits.
>
> The greatest difficulty, I would say, in these situations is that either
> marching-orders have already been given (some stinkwad, two-bit,
> Corner-Office Idiot says 'That last Executive Retreat I went to in the
> Bahamas - oh, the harsh burdens I bear for The Company! - taught that
> COBOL's worthless and Java's the way to go.  Get it done!') or that those
> with a particular dog in the fight (Preserve the Olde Wayse or New System
> Now) are more interested in keeping discussion in areas that they know
> about than in honestly learning something new.
>
> (on my current site I do a lot of ad-hoc reporting and file-creation for a
> PeopleSoft system that gets ftp'd off the Big Iron... when it started the
> general attitude was 'Oh, that can't be done with COBOL'... and this has
> changed to 'Oh, only *he* can do that with COBOL', an equally distasteful
> view, I'd say)
>
> All in all, it is usually a good thing to remember what Machiavelli had to
> say about the introduction of new systems
> <http://www.gutenberg.org/files/1232/1232.txt>
>
> --begin quoted text:
>
> And it ought to be remembered that there is nothing more difficult to take
> in hand, more perilous to conduct, or more uncertain in its success, then
> to take the lead in the introduction of a new order of things.

Only if you're a sissy. REAL Men embrace change and have no problem with
being responsible for it. :-)

> Because the
> innovator has for enemies all those who have done well under the old
> conditions, and lukewarm defenders in those who may do well under the new.

And should be lobbying both camps with the promises of the new and
explaining how this change will benefit all concerned.

> This ness arises partly from fear of the opponents, who have the laws
> on their side, and partly from the incredulity of men, who do not readily
> believe in new things until they have had a long experience of them.

That's part of a leader's job; address their incredulity and convert it into
support. Part of the challenge is to motivate people to  be at worst,
non-committal ("Ok, let's wait and see..."), at best, enthusiastic,  to see
new systems.

Although there may be SOME parallels between Renaissance Italy and the
modern Business World, for the most part, they are different. Machiavelli
would be out of his depth in the politics, subtleties, and complexity of
modern Board Rooms.

Pete.
--
"I used to write COBOL...now I can do anything."

<docdwarf@panix.com> wrote in message news:fg6u2d$qvk$1@reader1.panix.com...
>
> As an extension of an earlier thread regarding a COBOL-to-Java
> conversion... some meanderings.
>
> As noted, the core of such a thing is not a technology change, it is a
> business process change and needs to be addressed both by those familiar
> with the present process (what the COBOL system does) as well as those who
> are familiar with the new technology's capabilities (what the Java system
> can do).  Right off the bat there may be difficulties... those familiar
> with the present process may respond with 'oh, we can do *that*, why
> didn't you ask?' when the new-tech team begins its proposals.
>
> I recall reading, someplace, a consultant who said he'd been approached by
> a small insurance company in the early 1970s about converting their
> current paper-and-pencil system to a state-of-the-art COBOL/CICS
> green-screen system.  His off-the-record response was 'They wanted to
> duplicate their current processes... they had no idea how using a computer
> would change the way they work and the way they could work, essentially
> they wanted an electronic version of their current system and nothing
> more.'
>
> In like manner... who has not seen a DB2 installation obviously designed
> by VSAM-heads? All the overhead of an RDBM system, none of the benefits.
>
> The greatest difficulty, I would say, in these situations is that either
> marching-orders have already been given (some stinkwad, two-bit,
> Corner-Office Idiot says 'That last Executive Retreat I went to in the
> Bahamas - oh, the harsh burdens I bear for The Company! - taught that
> COBOL's worthless and Java's the way to go.  Get it done!') or that those
> with a particular dog in the fight (Preserve the Olde Wayse or New System
> Now) are more interested in keeping discussion in areas that they know
> about than in honestly learning something new.
>
> (on my current site I do a lot of ad-hoc reporting and file-creation for a
> PeopleSoft system that gets ftp'd off the Big Iron... when it started the
> general attitude was 'Oh, that can't be done with COBOL'... and this has
> changed to 'Oh, only *he* can do that with COBOL', an equally distasteful
> view, I'd say)
>
> All in all, it is usually a good thing to remember what Machiavelli had to
> say about the introduction of new systems
> <http://www.gutenberg.org/files/1232/1232.txt>
>
> --begin quoted text:
>
> And it ought to be remembered that there is nothing more difficult to take
> in hand, more perilous to conduct, or more uncertain in its success, then
> to take the lead in the introduction of a new order of things. Because the
> innovator has for enemies all those who have done well under the old
> conditions, and lukewarm defenders in those who may do well under the new.
> This ness arises partly from fear of the opponents, who have the laws
> on their side, and partly from the incredulity of men, who do not readily
> believe in new things until they have had a long experience of them.
>
> --end quoted text
>
> DD
>

I have learned that we now have  around 860 contractors working on our "new"
system.  I put new in quotes because the current system was used for the
specifications for the new system. That 860 number is after they got rid of
a lot of SAP people.  They tried to replace one subsystem with 80% vanilla
SAP and 20% ABAP, but the vanilla SAP could not do even 60%.  All of this
just to say they no longer have COBOL and now have the new and improved and
20% to 30% slower state of the art Java. In one lunch room they have a huge
chart of system development processes and paperwork deliverables. If you
live in the USA then sorry, it it your tax dollars at work :-(

In article <5opm2vFnnl68U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:fg6u2d$qvk$1@reader1.panix.com...[/color
]

[snip]
 
>
>Only if you're a sissy. REAL Men embrace change and have no problem with
>being responsible for it. :-)

Just like military officers have no problems leading their men over the
tops of the trenches... and the Gallipoli-like results which may ensue.

> 
>
>And should be lobbying both camps with the promises of the new and
>explaining how this change will benefit all concerned.

That might be the case, as well... but for me, I will leave lobbying to
the lobbyists and selling to the salesfolk; they have their jobs and I
have mine.

> 
>
>That's part of a leader's job; address their incredulity and convert it int
o
>support. Part of the challenge is to motivate people to  be at worst,
>non-committal ("Ok, let's wait and see..."), at best, enthusiastic,  to see
>new systems.

'Over the top, boys... I'll lead the way!'

>
>Although there may be SOME parallels between Renaissance Italy and the
>modern Business World, for the most part, they are different. Machiavelli
>would be out of his depth in the politics, subtleties, and complexity of
>modern Board Rooms.

I'll take that as the Voice of Experience, one that spent much time in
Renaissance Italy.  I don't know many folks who spent time in modern Board
Rooms who have become Pope, as did Rodrigo Borgia.

DD

Charles Hottel wrote:
>
> I have learned that we now have  around 860 contractors working on
> our "new" system.  I put new in quotes because the current system was
> used for the specifications for the new system. That 860 number is
> after they got rid of a lot of SAP people.  They tried to replace one
> subsystem with 80% vanilla SAP and 20% ABAP, but the vanilla SAP
> could not do even 60%.  All of this just to say they no longer have
> COBOL and now have the new and improved and 20% to 30% slower state
> of the art Java. In one lunch room they have a huge chart of system
> development processes and paperwork deliverables. If you live in the
> USA then sorry, it it your tax dollars at work :-(

This echos what I've learned from long experience.

A large system designed from scratch will not work and cannot be made to
work. You have to start over with a working, smaller system. However, a
large system, produced by expanding the dimensions of a smaller system, does
not behave like the smaller system.

In a large system, malfunction, or even total non-function, may not be
detectable for long periods, if ever. The total behavior of large systems
cannot be predicted.

Some complex systems actually work. If a system is working, leave it alone.

In setting up a new system, tread softly. You may be disturbing another
system that is actually working.

On Tue, 30 Oct 2007 19:44:40 -0400, "Charles Hottel" <chottel@earthlink.net>
 wrote:

>I have learned that we now have  around 860 contractors working on our "new
"
>system.  I put new in quotes because the current system was used for the
>specifications for the new system. That 860 number is after they got rid of
>a lot of SAP people.

SAP people are usually very good, and very expensve. IBMers are just very ex
pensive.

>They tried to replace one subsystem with 80% vanilla
>SAP and 20% ABAP, but the vanilla SAP could not do even 60%.

SOA is about turning the old code into a Service, rather than rewriting it.

>All of this
>just to say they no longer have COBOL and now have the new and improved and
>20% to 30% slower state of the art Java.

SAP is written in C and ABAP, not Java. If it's only 20-30% slower, it's bet
ter than most
new systems, which are typically 2-3 TIMES slower. Tuning often produces dra
matic
improvements in speed.

>In one lunch room they have a huge
>chart of system development processes and paperwork deliverables.

In the old days, deliverables were things like Code Complete and Integration
 Testing
Passed. Now, deliverables are paperwork attesting to those milestones. Someo
ne should ask
why, if development was complete two months ago, they're still making code c
hanges.

>If you live in the USA then sorry, it it your tax dollars at work :-(

"Pessimist drowns in half empty bathtub."  :)

YOU could be one of those 860 contractors. If you can't beat 'em, join 'em.

<docdwarf@panix.com> wrote in message news:fg8hhd$mc$1@reader1.panix.com...
> In article <5opm2vFnnl68U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote: 
>
> [snip]
> 
>
> Just like military officers have no problems leading their men over the
> tops of the trenches... and the Gallipoli-like results which may ensue.

Death or Glory! THAT's the stuff for REAL men...

(I recently finished reading the best book on Gallipoli I have ever come
across. Obviously, this particular battle is woven into our culture and the
"Spirit of Anzac" is something we grow up with. Despite the courage and
tenacity shown by both sides, there is no doubt that it was a real tragedy
for all concerned. The book I just finished is called "Letters from the
coffin trenches" by Ken Catran. It is the best anti-war novel I have ever
read. Understated, doesn't preach, but has been extremely well researched,
and gives insight into the mores and attitudes of the times, both at home
and at war.)

The important point here is that in industry, when implementing change,
people don't normally die.

(Having said that, I have worked on two projects where team members DID die,
mainly as a result of work related stress. It made me think, and I have
never had this happen on any of my projects. Much as I may hate the thought
of being late or failing to achieve, the thought of people breaking down or
dying is far more repugnant...)

> 
>
> That might be the case, as well... but for me, I will leave lobbying to
> the lobbyists and selling to the salesfolk; they have their jobs and I
> have mine.
>

That's fine if you have the people... :-)
 
>
> 'Over the top, boys... I'll lead the way!'
>

Ah, the exhilaration... ! 
>
> I'll take that as the Voice of Experience, one that spent much time in
> Renaissance Italy.

I have a blue phone box, you know...

> I don't know many folks who spent time in modern Board
> Rooms who have become Pope, as did Rodrigo Borgia.

I heard that most Cardinals in the Catholic Church do Business Studies and
are required to put some time in managing aspects of the Church's financial
empire,(career progression?). Some are even Ivy League graduates (could be
Honorary Degrees...)

The modern Church, like modern Business, is a very long way from how things
were done in the Middle Ages.

Pete.
--
"I used to write COBOL...now I can do anything."

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:13ifknbime540d2@news.supernews.com...
> Charles Hottel wrote: 
>
> This echos what I've learned from long experience.
>
> A large system designed from scratch will not work and cannot be made to
> work. You have to start over with a working, smaller system. However, a
> large system, produced by expanding the dimensions of a smaller system,
> does not behave like the smaller system.
>
> In a large system, malfunction, or even total non-function, may not be
> detectable for long periods, if ever. The total behavior of large systems
> cannot be predicted.
>
> Some complex systems actually work. If a system is working, leave it
> alone.
>
> In setting up a new system, tread softly. You may be disturbing another
> system that is actually working.

Somewhat surprisingly, I actually agree with this. While I enjoy change and
large challenges, I think your analysis is pretty much on the button, Jerry.

One of the reasons I get excited about Web Services and OO components is
because you can implement them without the risk of destroying something else
which, as you say, could be working fine.

My experience bears out what you say about starting with a smaller system
and expanding it incrementally. Obviously, encapsulated building blocks
facilitate this.

Pete.
--
"I used to write COBOL...now I can do anything."