Change Is Natural

One thing is certain in the commercial IT world (and in life in general): Change is natural. Business computer systems are digital models of an enterprise and all of its operations. As an enterprise evolves so must its computer business systems (models) evolve . When designing any business application, we must anticipate changes, both corrective and perfective , in those applications. We must identify those parts of the system that will most likely need maintenance in the course of the system's lifetime.

When speaking to new systems designers, I often use an analogy of design techniques employed by the design engineers who build automobiles. It is absurd to think of a new line of cars being built without anticipating one of the basic maintenance chores required of all fuel-driven automobiles: refueling. Imagine for a moment that the car designers (system designers) placed the fuel cap underneath the car, hidden by the transmission. Would we tolerate dismantling our cars' transmissions each time we needed to refuel our cars ? Of course not. This refueling (maintenance) chore was made easier by isolating those parts of the car that we need to reach to do this maintenance.

This is very similar to the design criteria that computer system designers must use. Thankfully, the original COBOL language designers knew this. When the COBOL language was first created, the CODASYL committee envisioned that the IT industry was fast changing and that most business systems would likely need to be modified during their lifetime. New hardware and new software development techniques were likely to follow. COBOL applications needed a way to adapt to ever-changing environments without causing chaos inside the enterprise systems development community. The solution was to make COBOL as adaptable as possible and to incorporate , inside the source program itself, whatever environmental documentation was required. This of course resulted in the Environment Division, one of four original Divisions still in the COBOL language. By isolating "all" the environmental dependencies of a COBOL application in one place, it was much easier to transport a COBOL application from one computer brand to another, from one operating system to another, from one database to another.

Today we take this concept for granted. Why should Microsoft Word behave differently on a Macintosh than on a Windows machine? In the late o1950s, however, this was a new concept just gaining popularity. Admiral Grace Hopper's contribution to the "birth" of COBOL is well documented. She was a member of the original CODASYL executive committee. A far greater contribution perhaps was her pioneering effort to develop and promote the concept of third-generation programming languages such as COBOL, Fortran, Algol, and so on. This allowed programmers to use a common, high-level set of instructions (higher than assembler languages). This high-level code was then translated (compiled) into the machine language of the particular hardware on which it would eventually execute. Further, to the point of adaptability, COBOL incorporated the CALL statement early in its development, as well as a COPY library source code facility. Later, the INVOKE statement was added as part of the object-oriented COBOL module.

These and other features in COBOL acknowledged the changing nature of computer business systems and anticipated the need for adaptability in COBOL language syntax. Rather than incorporate new COBOL syntax and data formats (borrowed from other programming languages) to map into every known programming language and database, COBOL simply chose to create flexible methods to interact with applications written in other languages and to pass data between modules effectively. You might say that the COBOL integrated development environment (IDE) is one of the earliest " open source" environments.

Another reason for COBOL's endurance lies in the large number of auxiliary tools available in a COBOL IDE: full-featured application development suites, code generators, software libraries, debuggers , conversion tools, compiler "addins," and so on. The sheer momentum over 43 years from so many programmers producing so many COBOL applications resulted in cottage industries of supplemental software to aid in the task of COBOL application development. No other programming language has such a robust IDE.