Prev: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
Next: Wildcat COBOL
From: HansJ on 31 Oct 2007 07:47
.... 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 :-(

Charles,
the trend is definitely going to replace existing individual
application with packaged software. If it makes sense or not is
another question, but I'd admit that in many cases it makes sense.
I have seen successful and unseccessfull attempts to replace large
COBOL applications with both packages (mostly SAP) and individual
developments. So there is no reason to use an unseccessfull example as
a general statement.
Regarding the tax dollars spent, no I'm not living in the US...

Regards HansJ

From: Pete Dashwood on 31 Oct 2007 09:43


<docdwarf(a)panix.com> wrote in message news:fg8hhd$mc$1(a)reader1.panix.com...
> In article <5opm2vFnnl68U1(a)mid.individual.net>,
> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>>
>>
>><docdwarf(a)panix.com> wrote in message
>>news:fg6u2d$qvk$1(a)reader1.panix.com...
>
> [snip]
>
>>> 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. :-)
>
> 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...)

>
>>
>>> 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.
>
> 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... :-)

>>
>>> This coolness 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.
>
> 'Over the top, boys... I'll lead the way!'
>

Ah, the exhilaration... !
>>
>>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 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."


From: Pete Dashwood on 31 Oct 2007 09:50


"HeyBub" <heybubNOSPAM(a)gmail.com> wrote in message
news:13ifknbime540d2(a)news.supernews.com...
> 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.

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."



From: Alistair on 31 Oct 2007 10:21
On 31 Oct, 00:16, docdw...(a)panix.com () wrote:
> In article <5opm2vFnnl6...(a)mid.individual.net>,
>
> Pete Dashwood <dashw...(a)removethis.enternet.co.nz> wrote:
>
> ><docdw...(a)panix.com> wrote in messagenews:fg6u2d$qvk$1(a)reader1.panix.com...
>
> [snip]
>
> >> 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. :-)
>
> Just like military officers have no problems leading their men over the
> tops of the trenches... and the Gallipoli-like results which may ensue.
>

Gallipoli was a disaster because of the prevarication of the officers
who failed to realise the dangers of being sniped upon by Turks on
surrounding hills. So they leisurely organised cricket matches rather
than marching off of the beachhead.



From: Alistair on 31 Oct 2007 10:24
On 31 Oct, 04:52, Robert <n...(a)e.mail> wrote:

> >If you live in the USA then sorry, it it your tax dollars at work :-(
>
> "Pessimist drowns in half empty bathtub." :)
>

And an engineer would point out that the bathtub is twice the size
that it needs to be.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
Next: Wildcat COBOL