Re: The Relative Importance of Web Development


"Paul Raulerson" <Paul.Raulerson@xxxxxxxxx> wrote in message
news:465a6e92$0$4016$bbae4d71@xxxxxxxxxxxxxxxxxxxxxx
Perhaps Pete - but I sure don't see the backend processing moving to the
web or web-like technologies any time soon. :)

Yes, I agree it's hard to imagine that. Nevertheless, I see a time (and
within my lifetime) when batch processing will be as relevant to data
processing, as collating punched cards into separate hoppers is today.

There would BE no backend processing if everything currently done in the
back end office was done online when the transaction occurred. The main
reasons we developed backend processes was to ensure that the performance of
the highly visible front end remained acceptable. This meant hiving off the
accounting functions to "overnight" and batch. IF these functions were
acrrued as transactions occurred, there'd be no need to do this...

The new systems being designed are transaction oriented and most of them
have a web presence.

Batch is primarily a sequential process and we are coming into an era where
data will be retrieved instantly in any required sequence without batch
processing. The argument that batch is necessary for huge volumes doesn't
stand up to careful inspection. The distributed nature of networked
processing means there is no need to queue data on files; simply split it up
and process it wherever available capacity exists. If a million transactions
occur "now", then process them now.(Hey, you might need a million
processors, but so what? With a network, you have almost unlimited capacity
for processing. (Bandwidth is another story, but that is being solved even
as you read this...))

Consolidations and summarisation are things that can occur as background
processes, and some of the new data retrieval methods wouldn't even need to
do that; you want the total widgets sold in the last x days? Retrieved
instantly and summated on the spot by distributed processors and lambda data
functions. (No "sequential" scan of records in the sense we understand for
batch rocessing.) There are facilities on the horizon that will cause major
rethinks in the way we process data. I know it won't happen next week, but
it WILL happen. The separation bewtween front and back offices will first
become blurred, and then disappear altogether. And the Net and the company
intranet will be the transport mechanism.

If Jimmy in Canada, and myself in NZ, can both access a function in San
Franscisco, over thousands of miles, exactly as if it was simultaneously on
both our machines, in under 2 seconds today, how long do you think it will
take in 5 years time? How long will it take before components runnning as
web services provide everything you need to run a business? Eventually you
will only need data storage (more for your own peace of mind than as an IT
necessity) and access to the Network.

Access to the network; no IT department (other than to service your own
network nodes and keep everything running) and within 10 years most of the
Western world will have general coverage on wireless networks running at 10
times the speed of broadband today. I'm using a 7MB broadband connection to
write this, and that is considered fast here, where most broadband is still
under 5MB, but a local provider here in Tauranga is covering the whole of
the Bay of Plenty with 54MB wireless broadband and getting a very good
takeup on it. (Unobtrusive small antennas are springing up on hilltop farms
around the area; for rural people this a major service.)


But speaking of new technologies, what do you think about the
MicroFocus/AcuCobol merge? Any possiblity something really good will come
out that?

Depends what you mean by "good" :-)

For COBOL it could be an extension for a few years (I still stand by 2015 as
the end of it for serious commercial processing). As I've said here before,
COBOL just isn't the right paradigm for todays processing. It's not the
fault of the language or the people who sell it; it's just reality. You
COULD write all your components in COBOL but why WOULD you when you can do
it in C# or Java for nothing, with no runtime fees, have total
interoperability of your objects using DotNET, and free training and
support?

For me, it's a no-brainer. The main thing that kept me with COBOL was the
huge investment in it over many years (and my affection for it :-)). I can
leverage all of that with C# so that was the final clincher.

COBOL is predicated on the assumption that programs will be monolithic and
maintained. Source code is everything. That is not the modern approach. I
use object code I didn't write, and I share my objects with other people.
None of us has any problem with that. Stepping up to web services means it
can be done globally.

In the next week or so I will be publishing a downloadable desktop app that
uses the AVS web service to process a sample database of addresses (in
batch, ironically enough :-)). Normally, I would be sweating it, building a
distribution disk, copy protecting it, and then writing a CD for everyone
who wanted to use it. No more. Now it is a simple DotNET application
(written in C#) downloadable in seconds, that can automatically upgrade
itself without intervention from me or the user (if I want it to do that)
and I only have to ever keep ONE copy of it current.(The one on my web
server).

Both AcuCOBOL and MicroFocus are reputable companies who produce good
products. There were probably some stables around who produced good working
horses when Henry Ford started his first production line. I'm sure they
weren't bothered by the first machines that rolled off the line. But where
are they today? Early automobiles were hideously expensive, the highway
system was virtually non-existent, and there was no network of nationwaide
gas stations. I remember a quote from Agatha Christie in the early 20th
century who said she would never be rich enough to buy an automobile nor
poor enough not to have servants...

The fact is that cars are a different paradigm from horses. So is the
Network different from the COBOL paradigm.

Cars inherited the Earth; time will tell whether the Network gets to do so
(although I believe it already has; for instance I can't see me developing
any new systems that don't have a network presence) Why lock yourself into a
desktop (and limit your market by doing so) when you can have true platform
independence and access to a full market? My new apps will run on Linux,
Unix, Windows or Mac (As long as they have implemented the DotNET framework
appropriate to that platform); I couldn't do that with COBOL.

Pete.



.

Relevant Pages