Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 01/02/04 

Date: Fri, 2 Jan 2004 14:14:11 +1300

"Doug Scott" <dwscott@ieee.org> wrote in message
news:VA.000003bf.006c5817@ieee.org...
> Peter,
>
> > After some consideration I have reached the following conclusions:
>
> We went through a similar line of reasoning ten years ago is determining
the strategy for a large UK
> financial. However, the conclusions differed:
>
> > 1. SOME businesses will continue to use COBOL (I believe it will be
mainly
> > for Batch processing.).
>
> As I've said, the tools industry has moved on, and I doubt that even OO
COBOL will be able to provide a
> resource-rich development environment which people like MS and Borland do.

Agree completely. Not only has the tools industry moved on, but the next
generation of tools will be even better. I see OO COBOL as useful for
component manufacture (of Business Components). However, it is NOT
essential.
>
> Cobol does batch processing very well. C does it very poorly, so you might
well be right there.
>
> Batch processing may not continue to be done in Cobol, though. With the
provision of large online
> databases, the only uses of batch processing will be for analytical
purposes, and something like SAS is
> better suited to that.
>

I have reason to believe that Batch Processing will be rendered redundant
within 20 years. (See my post in this thread).

> > Distributed systems through Client Server and the Corporate
> > Intranet will remove the need for Report runs off a central mainframe.
>
> Well, we were already there twenty years ago. And a change in management
/centralised/ everything again
> (there's nowt so queer as folk).
>

Yes, I agree there has been a see-saw between centralised and distributed
systems. (I have been part of both camps and realise the benefits and
pitfalls of both approaches.) However, the Networks of twenty years ago were
not the Networks of today, and the Networks of today are a pale precursor of
the Networks of tomorrow. The die is now cast and distributed systems will
win.

(There is too much behind this to go into here, but, basically, people want
control of their own areas (including the data and processing of it). They
have the ability and tools to give them what they want, and this obviates
the need for a centralised IT facility, other than for clerical,
administration, and Network maintenance, (most of which will be outsourced
anyway...). Corporate reporting will be achieved via the Intranet (a simple
subset of the Network) and everything will be real time.

Networked Management is proving more effective than the old hierarchical
model, and modern Managers are capable of letting departments have
responsibility for their own data and the processing of it, provided it is
also available to Central Management. The Network facilitates this on a
Global basis which we certainly couldn't envisage 20 years ago.

> If you have to produce monthly statements, then by definition it's a batch
run to print them. And if
> you're doing that, the most efficient way to do bulk printing is to
centralise it.
>

That one is arguable in the future. I agree that currently it is the case
for many corporations.

(I already receive statements from three Companies by e-mail, and it is
efficient and effective. My Banks (both here and in Europe) support online
banking and I can produce a statement from them any time I want one, as well
as being able to view transactions up to the current date, and control
transfers, Direct Debits, etc. It wouldn't bother me if they never mailed a
monthly statement (they do, but it is purley because that is
traditional...How much longer?)

> Finally, distributed systems are over-complex to manage and an incredible
waste of users' time and money.
> Who manages a computer better - an amateur user or a professional
operator? How many operators do you need
> to run a billion-dollar site? Compare that to the estimate of, say, an
hour a day for 10,000 users.
>

I disagree. Besides, even if you were right, who is to say they will ALWAYS
be "over-complex to manage and an incredible waste of users' time and
money"?

(I remember EXACTLY the same criticisms being levelled at "computerization"
back in the '60s when mainframes started to proliferate. Whether they were
expensive and wasteful (compared to the highly underpaid teams of clerks who
did the job previously) was completely irrelevant. If your competition had
one, you had to get one. What price competitive advantage <G>?)

Many corporations are finding it isn't so.

> > the role of "bespoke software generation"
> > will decline to the point where it will simply involve plugging a few
> > standard components from the Corporate component repository into
standard
> > desktop software.
>
> I remember an engineer tell me back in 1964 that this was going to happen,
except that he said it would be
> hardware-based. It never arrived, but I'm willing to concede that the
large ERP products are managing to
> sell their message to senior management more and more. The trouble is that
they require an awful lot of
> tailoring because every company works differently, and there could be a
reaction to the inordinate amount
> of learning and twiddling to get a package into a useful state. I don't
know - it could work, or there
> could be a reaction saying "dammit, I paid for all that functionality I
never needed, and never will
> need."
>

I am not suggesting this scenario will arrive without pain...<G>

What was said in 1964 was far-sighted. Your Engineer wasn't so wrong when
you look at what is on chips today.

However, the fact that something failed to materialize (in your view)
before, doesn't NOT mean that it can't happen EVER.

"Previous performance is no guarantee of future results. Consult your
Adviser." <G>

> But I don't think it will ever be a case of plugging in software to a
base package. Businesses, even
> within the same industry, are too different. I've seen these packages be
adopted, and then quietly
> abandoned to be replaced by in-house developed stuff.
>

Maybe... it is early days yet for CBSE.

I have some personal experience of this which supports my contention.

> > (OO, which COBOL seems to have missed the boat on, is one
> > of the major facilitators of this capability.)
>
> Well, XML is a better contender for interoperability, and it doesn't
mandate OO.
>

I have yet to see a component written in XML. It is good for transporting
messages between OO interfaces.

> > When another report is required, most Businesses are not
> > going to accept that a COBOL programmer is required to write it.
>
> You're really going back into the ark with that one. We haven't used
programmers to prepare reports for
> years - we use a report program generator which allows users to select
fields from a data dictionary and
> report on them, with the reports automatically formatted.
>

Excellent! However the same is not true for the majority of sites using
COBOL.

> > Because of tradition, these
> > sites will support COBOL, but as the pressure comes on from cheaper
> > alternatives, they will slowly disappear (or transmute into something
other
> > than what they are today...)
>
> I don't know what you mean by "cheaper alternatives", but I will agree
that Cobol is fighting a rearguard
> action which it could well lose, regardless of its merits.
>
> > (d) Many CEOs are wanting to get back to the Business they are in, and
> > resent the huge budgets we have seen for in-house IT departments. If
your
> > business is Insurance (for instance...) you may resent spending 15% of
your
> > turnover on maintaining in house IT facilities
>
> Wow. 15% of their turnover! The IT department deserved to be sacked. Most
UK insurance companies spend
> between 3% and 7% of turnover on IT - and 7% was a waste.

I consulted to Norwich Union for several projects. An excellent Company. I
believe their IT budget (across ALL areas, General, Investment, Life and
Pensions, was around 10% of turnover, prior to their flotation. I am sure it
has come down since, as one of the things we needed to do for flotation was
combine data from many different systems, so we could calculate what each
Policyholder (soon to become Shareholder) was entitled to.

Pete.

Relevant Pages

  • Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL
    ... Cobol does batch processing very well. ... Batch processing may not continue to be done in Cobol, ... > Intranet will remove the need for Report runs off a central mainframe. ...
    (comp.lang.cobol)
  • Re: Wireless Audit Reports
    ... -- your report is only as accurate as the time period for which your audit ... Ad-hoc networks are frequently overlooked and area ... vulnerability management needs. ... Download FREE whitepaper on how a managed service can help you: ...
    (Pen-Test)
  • YOUR media at work
    ... Networks continue to ignore NY Times' military analyst story, ... media military analysts and the Pentagon on April 20, ABC, CBS, and NBC have ... ABC, CBS, and NBC -- have still not mentioned the report at all, according ... to a Media Matters for America search* of the Nexis news database. ...
    (rec.sport.pro-wrestling)
  • Re: Crash near Miami, FL
    ... The TV networks will report a fiery explosion before ... Any pilot that allows the aircraft to remain in this dangerous flight realm is asking for problems. ... Of course, it appears that the subject aircraft flew several miles after takeoff and was then reported to be in flames and a wing came off prior to the actual crash, so I doubt that your comments have any bearing whatsoever on this crash. ...
    (rec.aviation.ifr)
  • Re: Wireless Audit Reports
    ... I can say that anyone looking at the report will get cross-eyed as each section of each floor has between 20 and 70 networks and it really is too much data for anyone to glance at and gain a sense of. ... access point and allow a laptop to join it. ... You have an option to go with a managed service or an enterprise software. ...
    (Pen-Test)