Introduction

The digital economy is expanding faster and faster. This results from recurrent advances in information technology (IT). There is a virtuous circle such that, in turn, more and more (often unpredictable) innovative usages boost IT. These usages are social and, in a broad sense, economical. More generally, the impact of IT on business is immense nowadays.

In this dynamical context, two decades ago software became the premier economy sector in terms of revenue. Substantial overturning occurred: the progress and multiplication of operating systems (LINUX, Windows, OS X, etc.) and associated product lines (e.g. mobile variants), the development and increasing re(use) of open-source software, outsourcing in developing countries, etc. United States and Europe tried to keep their advanced positioning through "differential software engineering": inventing new programming languages like Java or C#, new software development approaches like agile development, model-driven development (MDD), new software architecture paradigms like service-oriented architecture (SOA) and related middleware like Java Enterprise Edition (Java EE) or .NET and new computing paradigms like mobile computing, cloud computing or Internet computing as the superset of all modern computing paradigms.

However, a great paradox persists, as technological entry costs, human involvement, the acquisition of new technologies and take-up initiatives, etc., are not easily and straightforwardly controllable. In other words, the great majority of people and teams in software development continue to use "old" technologies. First, a very good reason for this is that information systems on the top of these cannot be thrown overboard. Second, development hides maintenance. Challenges relate to software evolution not to software creation, especially from scratch. Seacord in [SEA 02] highlights this point as follows: "For large enterprise systems, a strategy of design for evolvability is a need. This approach does not distinguish between development and maintenance; maintenance is simply continued product development".

Therefore, there is a natural temporal gap between the emergence of any high tech software. and its daily use with total conviction and ensured return on investment.

In this sector, COmmon Business-Oriented Language (COBOL) remains a representative programming language. Namely, in 1997, 310 billion lines of software were in use and more than 220 billion lines were in COBOL (source: Wikipedia). Beyond this, five billion lines of new COBOL were developed every year, nowadays leading to an incommensurable mass of code. In fact, most enterprise software today is based on legacy technologies because COBOL had this ever-contested lead role. More recently, programming in (newer) COBOL also continues to have an impact on software architecture due to COBOL's inevitable "adaptation" to the Internet. Unfortunately, what also comes up with older COBOL is a set of specific infrastructures (computers called "mainframe computers" or "mainframes" for short), proprietary operating systems and middleware platforms, for instance Customer Information Control System (CICS); COBOL professionals who have a very particular background, culture, state of mind, etc., were/are also a great component of the overall COBOL influence on today's running software.

As observed, COBOL is thus not a closed world without any link to the Internet computing in general. That is the reason why going on with COBOL is always technically possible. Strategically, COBOL software evolution strongly depends upon proprietary solutions that limit interoperability in reasonable costs, innovation and liberty in general, to better adapt information systems to business. There is indeed an increasing demand for reactivity: IT, information systems must leverage the business instead of, as it often happened in the past, being a source of inertia. Most data and applications are business-critical. Rapid changes in business require software and information systems with higher adaptation capabilities. With this new reality, it is not certain that COBOL computing is the strategic track to be followed.

Nowadays, the worldwide COBOL offer is "modern". COBOL may run on any operating system with seamless Internet integration. In spite of this modernity, the COBOL offer attempts to create a technological continuity between the legacy COBOL code and that newly produced. Furthermore, it also intends to keep cultures, practices or states of mind as-is; these issues are deeply discussed and strongly called into question in this book. More precisely, there is a renewal of expectations for IT users and stakeholders, software as a service (SaaS) especially, that may conflict with, not COBOL as a tool, but COBOL as a vehicle for old-fashioned ideas.

This book, COBOL Software Modernization, is not a front-end attack against COBOL. The reason for this is that COBOL has brought a lot of value to the initial integration of business in computers. With the Internet in particular, the way doing business has, however, changed in a radical manner that highlights COBOL as a very debatable technological solution. Accordingly, this book puts forward the idea of software modernization, in general, which may benefit from two proven technologies: MDD and SOA. This book strives to create the glue between the two in a ready-to-use "development + maintenance" technological framework.

I.1. Behind software modernization is "modernization": the car metaphor

Changing is not a natural way of being. People tend to be conservative. However, modernization without motivation and expected progress makes no sense. Changing is merely a fear of people in everyday life. Changing contexts, environments and practices is also disturbing. To that extent, software has the particularity of accentuating this phenomenon through the incessant appearance of "new" technologies. By analogy, one may, however, wonder why I would change my 1960s car for a 21st-Century (electrical, hybrid, etc.) vehicle?

Rationale for change might be:

- cost savings (oil consumption); - sustainability (pollution); - safety (traffic rules have changed, encountered cars are "modern", (young) driver behaviors are not the same, etc.); - technology issues: car parts are no longer available or they must be fabricated in a (costly) tailored way; mechanics are few or would likely be retiring. In short, obsolescence problems a rise on an exponential scale; - today's route burdens, traffic jams contradict with the driving spirit of cars from the 1960s; - etc.

Arguments for no change are: keeping the driving style, the driving emotion, the driving needs and sensations 1960s cars provide and passionate drivers' desire.

In business, any trade-off between "change" and "no change" often relies on survival. In software, old technologies often possess interesting features like robustness or stability, which may compensate benefits announced by high technologies' evangelists and promoters.

The car metaphor leads us not to view modernization as a panacea, but as an opportunity. Inserting an electrical engine into a 1960s car is definitely not the solution. Nonetheless, why not an electrical car provided that driving requirements are assured? Novelty and innovation in such a car might bring out unimagined pleasure. Why not?

In this car metaphor, 1960s car drivers are "legacy people" in IT. Driving style, emotion, needs or sensations match their business intelligence engraved for a long time in their applications. Modernization thus amounts to the adaptation of the contemporary (to-be-bought) car to their company's driving spirit instead of the contrary. Business intelligence pervades the soul of legacy people. technology is just a means.

This book is above all the end-to-end integration of human concerns in software modernization, considering modernization at large as a real vocation. In that area, COBOL has influenced people beyond technology. In the car metaphor, COBOL is probably one the most successfully adopted car product lines of the 1960s.

I.2. COBOL

The authors of this book were COBOL programmers. However, for a long time, they have changed to object orientation (OO) in general, and Java in particular. The history of programming languages and their design shows that, with time, psychological relations between languages and developers emerge. Developers adhere to languages, adopt them and eventually love (defend) them. In this scenario, there was/is an affective link between COBOL and COBOL programmers. The understanding of this intimate relationship is an important issue when subscribing to the idea that COBOL-based information systems are dinosaurs whose life is unsuitable in today's IT.

In fact, what are the reproaches against COBOL? Its historical programming style is probably far from the canon of modern code structuring. In this context, the common understanding of the expression "structured programming" is mostly associated with the class of Pascal languages: Ada and later OO languages that offer the top-level vision of "structuring". Is COBOL "structured"? Yes, undoubtedly it is. Beyond, it has/keeps sexy shapes, i.e. the language has fairly intelligible constructs. There is a clear organization of a program in divisions:...