COBOL Systems

In IT history, there is at least one parallel with SWC in the large. Surprisingly, it is the concept of systems written in COBOL developed according to the methodology of structured specifications. A key part of the structured specification and design are dataflow diagrams (DFD)(see Figure 4). DFD is a network of autonomous processes communicating via data stores (or files). Such COBOL systems can be characterized as a batch version of software confederations in the large.

Figure 4: DFD for a salary computation

COBOL-based systems have the structure of a network of autonomous programs implementing the processes (peer applications). Every autonomous program has as its input an n-tuple of files (datastores) and as an output another m-tuple of files/datastores.

What are common features of the software systems written in COBOL with SWC in the large? If the input data stores (files) are available, the output data stores (files) can be generated or modified autonomously — independently on other processes. Processes in COBOL programs are conceptually close to autonomous components in SWC, especially in this key feature.

Some further similarities between COBOL systems (we can call them batch confederations) and software confederations can be found also in the way the batch confederations are developed (i.e., in the corresponding software processes). The COBOL-masters created parametrizable processes as e.g., universal input reading and checking programs, report generating programs, various data transformers, etc. That was the main reason for COBOL's enormous success in programming history. The paradigm of batch confederation was the basic of the wonderful stability of the systems written in COBOL.

The most convincing proof of the stability of systems written in COBOL is the Y2K problem. It has appeared during the solution of Y2K problem that systems written in COBOL were used in the enterprises for many years without any maintenance. We cannot otherwise explain that there was an enormous need for COBOL programmers for the adaptation of COBOL programs to the new century (to be able to work with the year 2000 and more). Such an enormous lack can hardly be due to the peak of maintenance effort connected with the Y2K problem. In other words: the systems have been working without any problems for a very long time. Such a stability is often a dream only for present software systems. Let us note that reusability of COBOL programs was also (by some researches) better than reusability of object-oriented programs (Finch, 1998).

It is surprising how little have been this feature of COBOL appreciated by the software development theoreticians. They express themselves contemptuously about COBOL at all and especially about dataflow diagrams. Note that some constructs such as dataflow diagrams are planned for a new version of UML.

The above discussion indicates that many software theoreticians did not recognized the COBOL's main advantages. The theoreticians have enforced e.g., the use of object-orientation in situations when it disabled the application of the bath confederations. It has important consequences: Ideologized object-oriented view trying to expel from OO methodics dataflow diagrams spoils the knowledge needed for the development of large systems. The trend towards software confederations goes outside the research oriented to object-orientation (components based object-orientation inclusive).

It can lead to some improper managerial measures. Harry Sneed e.g., described during a discussion at Software Maintenance and Reengineering 2002 Conference (Budapest, April 2002) a case, when the CIO as well as the CEO of a large company insisted on the application of "modern" object-oriented paradigms during the development and maintenance of COBOL programs. They were surprised that even young new programmers were unable (did not will) to do it. Fortunately for the company, the programmers were wiser than the managers were.