COBOL and the Enterprise Business Application Programming Legacy

by Jonathan Sayles, Micro Focus, LTD
Original Location: http://www.mfltd.co.uk/Education/USA/coboleg.htm

This article is about the real world of enterprise business application programming. It also happens to be about COBOL. COBOL is the de-facto enterprise business application programming language for large, complex systems with long shelf-lives. This has been the case for almost thirty years - and it will continue to be the case until a computing language comes along that fits the enterprise business application paradigm as well as COBOL. I’m not holding my breath. Solutions for the problems presented by the enterprise business application programming paradigm aren’t simple, cheap or easy. They cannot be addressed through words and theories, through marketing hyperbole or elite/self-absorbed seminars and conferences although countless thousands of anti-COBOL academics, vendors and products have tried. They can only be addressed by robust and mature technologies with strengths that map to the difficult and idiosyncratic needs of this paradigm.

The Enterprise Business Application Paradigm
Let’s start by understanding that enterprise business application programming as practiced throughout the United States is not computer science. Beyond running symbolic computing languages on computer chips, they share little in common. This means that what works well as computer science does not necessarily work at all in the corporate business world. Why?

Like many aspects of large businesses, corporate application programming is done in less than ideal conditions (see figure 1). Enterprise business application programming is driven by pragmatism, personalities, politics and economics. Differences between computer science and business programming are caused by organizational, financial and human factors - in other words, non-technical issues. Historically, technical solutions applied to organizational, financial and human problems only change problems. They do not solve problems. Enterprise business application programming is a unique and exceedingly complex problem domain. One that defies analogies to other (often simpler) problem domains. For instance, the ubiquitous comparison of the evolution of software programming to manufacturing and the industrial revolution and the analogy of the development of unique, complex business software with the repetitive manufacture of a single good is overly simplistic to the point of being useless.

So if enterprise business application programming is not easily categorized what then is it? Enterprise business application programming is that activity in an IT shop that maintains, enhances, supports and develops automated business processing of the following nature:

1. Enterprise Business Applications are large, very large and very, very large. Small enterprise applications are usually in excess of 200,000 lines of code. Medium-sized applications are between 200,000 and 1,00,000 lines of code. Large applications are commonly over 1,000,000 lines of code - with 6,000,000+ line applications not considered unusually large in many shops.
2. Enterprise Business Application rules are magnitudes of order more complex than trade show examples used to sell products and prove points at seminars and conferences. American business has never been more complex - application software which automates contemporary business logic is no less complex. Complex applications defy silver bullet solutions. “That which is by nature complex, cannot be simplified past a certain point.” Dr. Tim Martin, Hartford Graduate Center.
3. Enterprise Business Applications are long-lived - 10, 20 and 30 year-old business applications are common (the rule, not the exception)
4. Enterprise Business Applications are dynamic - During the time business applications spend in production they grow in complexity, and often evolve well beyond the original design and specification requirements. Contemporary business is so dynamic that the specifications often change (sometimes radically) before the application even gets into production.
5. Business Applications are critical - Serious financial and legal consequences can be the result of bad code. When applications ABEND they must be fixed quickly, and restarted. Support for the mission-critical attribute of enterprise applications must be integral to any technology solution - not an afterthought.
6. Business Application Data requirements are enormous - Single production files and databases measured in terabytes are not uncommon. Applications must be stable at high transaction and data access volume and capacity (often measured in millions of units-of-work per day).
7. Business computing architectures and technologies evolve and change - On top of the natural evolution of computing technology, while the binary logic of chips is immune to marketing hype, CIOs and systems designers seem genetically predisposed to it. This can manifest itself in disparate production technologies and architectures, all requiring support as described above.
8. Business comes first - Technology for technology’s sake is a concept which often gets introduced into corporate technology by individuals ever mindful of the value of a contemporary resume. These new technologies must be integrated into the working enterprise business application paradigm - rarely cheap or easy work
9. Enterprise business projects are usually understaffed and overworked
10. Enterprise business projects are evaluated by short-term standards - Causing managers to value bottom-line deliverables, Lines-of-code over quality of code, specific single-function deliverables over generalized, reusable functionality, speed of delivery and production deployment over quality of documentation and maintainability, etc.
11. Enterprise business projects often contain dysfunctional staff members and dysfunctional managers - The Dilbert comic strip while far-fetched in its brevity and caricatures (style), is not entirely off the mark in its substance. The author hails from a background in corporate application development and credits his experiences for many of the ideas and concepts in the strip.
12. Enterprise business programming is a lot of work - Millions of business programmers are needed to meet worldwide maintenance, enhancement, support and development requirements
13. Enterprise Business project teams suffer personnel changes - Individuals responsible for writing applications rarely maintain and support the systems they create once those systems go into production
14. I/S departments are unique - no two shops employ the same methods, standards and practices in developing, maintaining and supporting production code. As each unique shop evolves, it adopts its own “Best Practices” - which form the basis for systems support, production requirements and workflow. Every shop’s evolution and technical strategy represents legitimate and professional responses to real-world problems - hard fought, costly battles producing “Lessons Learned” - that are ignored or dismissed at great expense to the organization.
15. Production requirements rule - Production processing is what keeps a corporation in business. If the production database is down development pitches to a halt as key technicians drop what they’re doing and scurry to fix the problem...ditto if some vice president needs a new report. These “ER” style interrupts can represent a significant brain-drain and momentum killer for technologies that do not take them into account.

    ---

Figure 1. The realities of the Enterprise Business Application Paradigm - yesterday, today and tomorrow

This is a short description of the real world of enterprise business application programming...lots of work, not too much play, very little that is cool...lots of batch systems - large, enormously complex, critically coordinated batch systems...lots of complex transactions...dozens of external system interdependencies - sharing hundreds of files and databases...programs that are modified, revised and reused hundreds of times, by the entire spectrum of procedural-coding talent, over decades...little in the way of standards, documentation, and exposed semantics...lot’s of extremely technical issues that must be dealt with in real time, or bills are not paid, checks are not cut, financials are incorrectly reported and bad business results.

The individuals working in this paradigm are the ones responsible for keeping corporations out of chapter 11. They represent the true knowledge-base of the automated business functions in an organization. By and large they do their work using COBOL programming skills, writing and modifying COBOL programs. COBOL as a business computing language is the only single language that stands up to the complex, rigorous and idiosyncratic requirements of figure 1. Other languages may handle a few of the items. But only COBOL, having evolved out of the enterprise business application paradigm to meet the needs of corporate developers has the following characteristics:

Self-documenting

• COBOL is an English-like, readable, self-documenting programming language. Large, complex, and long-lived application development projects benefit from COBOL’s self-documenting syntax and semantics. Maintenance and production support-related tasks benefit, particularly when done by I/S technicians who are not the original application authors (see most items from figure 1).

Simple

• COBOL is a simple language that encourages a simple, straight-forward programming style (K.I.S.S.). Programmers develop large complex applications by coding many simple procedural constructs instead of writing sort staccato bursts of impenetrable, terse code. This facilitates maintainable, production-enabled programs for large, long-lived, dynamic, complex applications. (see most items from figure 1).

Non-proprietary(portable)

• COBOL is far and away the most portable language. Because independent COBOL committees legislate formal, non-vendor-specific syntax and semantic language standards, COBOL applications can be developed, ported, down-sized, upsized, re-hosted, reused and right sized to every operating system on every hardware platform - PC, Network, mid-range, mainframe, every flavor of Windows, every flavor of Unix, AS/400, VSE, OS/2, DOS, VMS, Unisys, DG, VM, MVS, you name it, COBOL’s been there, done that. (see items 7 and 13)

Efficient

• COBOL has a 30 year history of successfully running production, and a 20 year history of optimizing compiler technology, which by now is sophisticated to the point of object code reengineering for greatest run-time efficiency specific to given hardware platforms. (see items 5 and 6)

Scaleable

• Through COBOL’s availability on all common I/S run-time environments, and through Non-Proprietary CALL USING constructs COBOL applications can scale up with loose or tight coupling - and O-O message binding. Complex business data processing activity which is supported by huge COBOL applications (millions of lines of code) is common and maintained through this simple, scaleable construct. (see items 1, 2, 4 and 7)

Universal

• Between 2,000,000 and 3,00,000 IT programmers worldwide can code COBOL. COBOL solutions do not require hard-to-find, expensive consultants to develop, maintain and support them. Through the efforts of the ANSI committee COBOL programs written in Germany run on mainframes from Deli to Santa Cruz to Manhattan. COBOL is the one common denominator in an ever-increasingly fragmented software world. (see items 9, 12, 13, 14)

Open

• COBOL integrates and can converse with all other 3GLs (C, PL/I Fortran, etc.) all 4GLs (CA-Eztrieve, FOCUS, Visual Basic, PowerBuilder, Delphi), assembler languages (ALC), pure and hybrid O-O languages (Smalltalk, C++...), API-based technologies (Windows SDK, DCE, ORBs...), relational (aka Client/Server) DBMSs, non-relational DBMSs (IMS, CA-IDMS, Total), object DBMSs, and all pointer-based and sequential file systems. (see items 4, 7, 14)

Complete

• In spite of its simplicity and in addition to its business orientation COBOL is “computationally complete” - and can be used in applications that run the gamut from simple batch reporting to complex transaction and windowed systems across all industries and business and computing requirements. (see item 8)

Mature and extensible

• COBOL has thousands of 3rd-Party products from hundreds of companies with upwards of thirty years of support for the COBOL market. Hundreds of products exist in the critical areas of application testing, performance monitoring, debugging, application analysis, maintenance, production support and code reuse. It’s 1996 and still new COBOL compilers, development and support tools are announced every quarter. (see most items above)

Maintainable

• COBOL is a language with a 30 year (not 30 month, not 30 week) proven track record for application maintenance, enhancement and production support at the enterprise level. It is a language entirely suited for source-level modification and revision by heterogeneous development teams. It is not a language specifically constructed for application development. COBOL blankets the entire application lifecycle - not just an inky-dinky portion. (see item 15)

Reliable and Proven

• Perhaps most significantly COBOL is used in more production systems and has a more proven and reliable production history than all other business languages combined. (see most items above)

Why COBOL?
COBOL evolved from the business development paradigm, and as a single language is uniquely suited for business application development, maintenance and production support. This is not to say that COBOL is all you need to create contemporary business applications. Nor is it to say that COBOL is the best solution for every class and type of business application. But if you are developing enterprise-level - large, complex, long-lived production systems, that will be maintained by a heterogeneous group of developers - COBOL is still the best language to protect your investment in business and future-proof your systems.

Jonathan Sayles, Mr. Sayles has published books and articles on topics such as relational database, client/server development, application development workbenches, Visual Basic, PowerBuilder, DB2, Oracle, and SQL. He has been editor of the DB2 Journal, and the Relational Database Journal. Mr. Sayles has spoken at Powersoft, Fawcette (Visual Basic), Micro Focus, XDB, DCI, IBM, and DBExpo international conferences, as well as hundreds of regional conferences. As a technical consultant, Mr. Sayles has worked in over 80 of the Fortune 1000 shops in the last 10 years.