Is Ada being used in IS?

Is Ada being used in IS?

[Dale Stanbrough]

Given that Ada now supports decimal fixed point types, has a package
devoted to interfacing with Cobol and an IS annex, does anyone know
if these features are being used?


Just curious...


Dale

Re: Is Ada being used in IS?

[Jerry van Dijk]

In article <5pilt3$3an$1@goanna.cs.rmit.edu.au> dale@goanna.cs.rmit.EDU.AU writes:

>Given that Ada now supports decimal fixed point types, has a package
>devoted to interfacing with Cobol and an IS annex, does anyone know
>if these features are being used?

Well, the decimal fixed point type _is_ one of the main points about
the IS annex. And it's probably used somewhere.

<SOAPBOX MODE ON>

But that's a somewhat diffent question then the one in the header.

First is: what is the IS world ?

I spend the last 9 years exclusively in the IS world, mostly banking
oriented. During that time I worked for banks, insurance companies,
mortgaging firms, stock/option exchanges, brokers, accountants.
pension funds, lease companies, traders, intermediaries, etc...

What all these companies have in common is that their daily business
_RELIES_ on IT. Actually about 70% of the operating cost of a larger
bank directly or indirectly relates back to IT !

The second question is, what software are we talking about ?

Traditional mainframe batch/transaction systems ? Distributed/CSA
systems (ie, branche office support) ? MIS/EIS/DSS stuff ?
Interfacing systems (SWIFT and other interbanking systems, ATM's,
call centers, ...), Trading and Treasury systems ? Documentary
systems ? and so on.

Looking at the traditions mainframe systems most people seem to
equate with IS software, banking systems:

- have long life cycles (usually > 15-20 years)
- are medium to large sized (100 - 500 KLOC)
- are written in a limited number of languages (Assembler, PL/I, COBOL)
- manage very large volumes of business critical data
- interact with a lot of other in/external systems
- are subject to legal auditing
- had initial price tags into the billons of dollars, and require
  tens of millions a year for maintenance.

It will not come as a supprise that a lot of us in this field tend to
be a little conservative regarding employing 'new' technologies...

(note that as to foreign trading there currently is no alternative
to PL/I, since the 18-decimal accuracy of COBOL and Ada are not sufficient
in this area).

A lot of this software is at this moment being looked at critically:

- Are we looking at a situation of diminishing returns ?
- The Y2K problems
- (in europe) introduction of the Euro
- Re-architecting systems to facilitate re-use (usually through a
  'software factory' tooling approach) to decrease time-to-market,
  adapt to a global -24 hr- business enviroment, interface to new
  consumer technology (home-banking, smartcard, internet, call centers),
  etc, etc.
- How to combine the advantages of a three-tier CSA-like architecture
  with the low-cost, reliability and security of using terminals.

As building this software has required very substantial investments,
it is not about to be re-written, especially not by a young upstart
as Ada :-) That's why many of us feel that the current push by IBM
to save their (for banking purposes excellent) OS/2 platform by jumping
off the Java deep end is a _grave_ mistake.

However, reliability, quality and confidentiality also are a major part
of the banking business software processes (when was the last time
_you_ re-calculated your mortgage statement ? :-) so Ada does seem a
natural fit.

Then, on the other side, there are the popular desktop application. Within
the context of a bank, they are by itself not very interesting since they
are usually very small (< 1 millon $ development costs), have limited
business impact, and a small live cycle (1-3 yr, 5 at most). So, currently
tools like Powerbuilder, Delphi, Visual Basic, etc, are popular
implementation devices. However, the number of them seems to be growing
at a rabbits rate ("I'm not going to wait for a formal implementation")
so attention is focussing here too.

Questions:

- Where are Ada's best changes for introduction into this industry ?
- Is there sufficient support for it (people, tools, etc)
- How to overcome the negative image ("Ada, that's an obscure language
  of which the NRC study said it shouldn't be used for financial systems"
  to quote a recent remark by an IT manager of a large bank)
- What can _WE_ do ?

Before answering those questions (and turning this post into a full
size magazine article on IS strategy :-) I wonder if there is any
real interest in it here on C.L.A. or the Ada community at large ?

I admit I am often disturbed by seeing my choosen field of endevour
being put down with a 'shudder, Cobol' attitude. Not only does this
attitude completely ignore a technical field as facinating as, say,
embedded systems enginering (and I have spend 8 years as a naval
engineer in aeronautics, so I know what I am talking about here),
which has a very large impact on our global society, it is also a
insult to the thousands of capable software engineers working very
hard in this industry.

<SOAPBOX MODE OFF>

Dale, thanks for your question, I did have to get this out of
my system sometime <g>

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Is Ada being used in IS?

[tmoran]

>are usually very small (< 1 millon $ development costs), have limited
>business impact, and a small live cycle (1-3 yr, 5 at most). So, currently
>tools like Powerbuilder, Delphi, Visual Basic, etc, are popular
  The checking aspects of Ada can be very valuable even in small,
short term, projects.  A few years ago I used Ada 9x to merge and
clean a database for a company that retails securities price
histories.  Definitely a one shot, short term, smallish, deal, but
the checking features, including display of the source line that
raised an unexpected exception, was *extremely* helpful in purifying
some rather impure data.  (Not to mention any of the other advantages
of Ada.)