COBOL Software Modernization

From Principles to Implementation with the BLU AGE Method

Franck Barbier, Jean-Luc Recoussine

• Publisher: Wiley-ISTE
• Year: 2015
• Print ISBN: 9781848217607
• eBook ISBN: 9781119073222
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Nowadays, billions of lines of code are in the COBOL programming language. This book is an analysis, a diagnosis, a strategy, a MDD method and a tool to transform legacy COBOL into modernized applications that comply with Internet computing, Service-Oriented Architecture (SOA) and the Cloud. It serves as a blueprint for those in charge of finding solutions to this considerable challenge.

1

Software Modernization: a Business Vision

1.1. Software-based business

As of today, there is a great paradigm shift. In past decades, software was the unavoidable way to “automate business” in the logic of cost and time savings, productivity, and better quality in product and service delivery. More recently, “software became recognized not just as an automation tool but more broadly as a strategy for providing products and services not yet offered” [FAV 11]. In other words, nowadays, software is a non-removable part of products and services. Software may be embedded in a car, for instance, leading to attractive functionalities (assisted parking). Another example could be a jewel reseller who is able to provide online authenticity certificates for its products through its accession to a trustable international organization in charge of regulating such certificates (respect of laws sale tracking, etc.). In both cases, software delivers some business added value.

Companies whose primary activity is selling software are reputed to provide intangible goods [POP 11]. The distinction between these and other companies is tending to disappear. Car manufacturers of the future will thus, instead of selling “a car”, sell “a computer” and hardware/software interoperating with an engine, a chassis, an interior, a steering wheel, etc. Jewelers will probably be in a similar situation due to the irreversible interpenetration between the Internet and business activities.

The shift is the fact that the business model of “modern companies” is changing, critically relying on software. In this context, transforming car engineers into software engineers would be a huge challenge, or, in the opposite way, a very bad idea; this is the same for jewelers. So, new business models have to be invented to tame software.

From a software engineering viewpoint, we mean it is important to build software differently and beyond this to have software evolution under control because of proliferation. In this line of reasoning, most of the classical software providers still suffer from handmade practices. Introducing these practices in non-software companies might be a nightmare. Software divisions of future companies will include software builders/maintainers or not. In the negative case, at least, business analysts and innovators will constitute these divisions to offer differentiating, and thus competitive, goods and/or services. Finally, stand-alone software will no longer exist to the benefit of cooperative pervasive (more or less big) software components irrigated by the Internet.

1.2. Information-driven business

The value coming from software is the computed information. Forthcoming software-based business models must then focus on information-as-a-revenue and try to diminish the costs generated by software creation, maintenance and utilization.

Today’s entrepreneurship success is thus strongly ruled by information. As an immediate result, organizations (companies, administrations, etc.) continuously grow their dependency upon information and thus information technology (IT).

In this context, business processes increasingly rely on high-end information: undisruptive availability, liveliness, sharpness, easy digestion (even “digestibility”), rich semantics and creation of meaningful knowledge from computed information.

Business processes are powered by information systems whose criticality, optimality and dynamicity, i.e. efficiency in short, are key concerns of business analysts, software project managers, software architects and software developers. These people think about and maintain applications on a daily basis, which are edges of an ill-delimited graph, even imbroglio, of information channels (hardware and software). Over the years, nobody has the global overview of this graph. Worse still, everybody wonders why this graph does not collapse as a paper castle built from a card game. The rule of the game is now clear: the crash of the information graph is the straightforward bankruptcy of the organization.

Figure 1.1 shows a common vision of information and information systems in organizations. On the right-hand side, the computer layer not only goes on providing operating means for business automation, but it must also be a booster.

Figure 1.1. Information as an ever-rising value in organizations

1.2.1. Adaptation to business

Information systems are an abstract view (Figure 1.1, left-hand side) of software applications and databases, middleware platforms, operating systems and related hardware (servers, mainframes, personal devices and computers) and infrastructures (power feeding, server cooling, networks, both local area networks and wide area networks, etc.). In essence, information systems constitute a logical view, which focuses on the immaterial assets of computer environments: information, its structuring, organization, production and delivery means.

As a metaphor, information systems are similar to a set of services offered by a town: municipal libraries, book loans, magazine consultation, buses, green car renting, kindergarten children’s entertainment events, etc., with related synchronicity, e.g. bus schedules fit to libraries’ working hours, children’s entertainment events, etc. In such a context, town citizens do not care about librarian and bus driver salaries, fuel in buses, libraries’ heating, etc.

In this line of reasoning, it has always been tempting, even healthy, to isolate information from its physical implementation. This approach aims at better considering information-as-a-service. Instinctively, information consumers do not pay attention to computing environments being hardware or software.

Designers of information systems thus have the permanent difficulty of guaranteeing and maintaining high-quality services wrapping information processing. The difficulty mainly lies in hiding intrinsic problems from piled (hardware and software) layers and recurrent failures. As an analogy, a bus drivers’ strike would probably diminish the quality of the town’s services to citizens.

For a long time, the ideas of architecture and urbanization have taken a prominent place in IT. It is important to notice that we consider architecture or urbanization of information systems in a logical way. As discussed before, information systems are mind views while in practice bits move about within circuits. Thus, information pieces, building blocks, etc., have virtual connections, links, etc., whose awareness is a key aspect of information management at large. Architecture is related to software that powers information systems, while urbanization is a macroscopic wrapper including information channels, forms, circulation, restitution, etc. Both urbanization and architecture act as a basis for, respectively, information systems and applications. Cartographic representations of these (sample in Figure 1.2) can be made more or less explicit, depending on their rational nature. Rationality aims in essence at controlling useless complexity.

Figure 1.2. Urbanization and architecture

As an analogy, Figure 1.2 shows the case of tourist flow management for the Eiffel Tower. Urbanization (right-hand side, top of Figure 1.2) copes with transportation infrastructure in connection with tourist visit routes and coarse-grained throughputs. Architecture (right-hand side, bottom of Figure 1.2) is concerned with “solutions” (e.g. signage). Information boards about visit routes are components of a chosen architecture to perform tourist flow management “at runtime”. Services rely on components, for instance, displaying on boards the next times of bus, boat, subway, etc., arrivals at closer transportation stations.

Gradually, information system designers face newer challenges. While architectures take time to become optimal, nowadays, they are expected to be/become variation-prone. Today’s economical contexts (globalization, trend reversals boosted by the Internet and consumers’ zapping) call for changing business: practices and processes at the organizational level. At the underlying level, information and logic engraved in information systems are surely subject to modifications as well. While organizations may require business practices and processes to rapidly adapt, information systems do not have the same latency. Re-architecturing is above all an offline activity. Fortunately, not all business adaptations involve re-architecturing, but information systems must be thought by designers to cushion business shocks: that is the new deal.

Returning to the case of tourist flow management for the Eiffel Tower, re-architecturing could be the review of the existing information systems for dealing with sporadic phenomena (e.g. cold/heat waves) or frequent events (e.g. sport shows), which may increase or decrease the presence of tourists. The case of a heat wave may, for instance, call for fit-like-a-glove services: boat traffic and arrivals to the Seine river embankments have increase to allow people to refresh themselves on the water when departing or arriving. In other words, customers will prefer boats to the detriment of subways, buses, etc.

So, nowadays, since architecture variability cannot be ignored, information systems should gain more flexibility. Typically, architecture components must, on demand, collaborate in a different way and/or extend collaborations with third-party components often unknown at design time. As mentioned in the introduction, service-oriented architecture (SOA) is a solution principle, but a lot of progress is expected in this research field.

In [BAT 14], it is especially revealed that acting on architectures is often infeasible due to excessive complexity. The difficulty to sort out business logic from this complexity is high. Instability of architectures (the contrary of variation-prone) is thus the phenomenon when interventions in architectures’ inner workings generate long periods before recovering stability.

As an overview, business pressure is such that information systems must demonstrate a kind of real-time evolvability. In this scenario, attenuating the adherence between information systems (as the immaterial value of organizations) and computer facilities (both hardware and software) seems to be a perpetually renewed challenge. The well-known weakness of information systems is their poor reactivity in terms of requirement adaptation while, in contrast, today’s business is subject to very frequent variations, even shocks. In other words, long-term strategies related to information management poorly comply with volatile short-term business activities.

1.3. The case of tourism industry

The sector of tourism is indicative of the increasing and inescapable intertwining between IT and business. Gallo and Krupka in [GAL 08] argue “(…) travel companies will face the need to introduce in-depth changes to their business strategies in order to adapt to the changes affecting their customers. (…) The development of new products and services and the adaptation of the offer to global customer trends require a great deal of innovation” (emphasis ours). In reality, as in many other sectors, tourism to a great extent relies on IT to support this innovation. Nonetheless, IT can also be a source of possible setback when companies are slowed down by rigid information systems.

As an illustration, Figure 1.3 shows what might be an economical process whose aim is the customization of travel offers for new customer profiles, namely singles. Invariably, the creation of new business services leads to new software services (and their tricky connection with what is existing). At the bottom of Figure 1.3, software evolution is caught in a cost vise. Two contradicting requirement streams drive changes: innovation in scope and daily business. Experience especially shows that change implementation is a source of regression. Namely, one may observe what follows: what works perfectly at a given time after months of effort can spontaneously become out of order. As an illustration, the addition of new services for singles is both an extension and a modification (coupling with the existing architecture’s components). To get the job done well, modification may call for “adaptation” in existing components. Afterward, these do not serve the daily business (unexpected failures) while they did before. The expected innovation and its associated revenues may then be significantly penalized by the impossibility of driving software evolution in a timely manner under controlled costs.

Figure 1.3. IT and software evolution positioning in the fluctuating tourism industry

In all business sectors, in people’s minds, IT is often rightly considered as an aspirator of financial resources. That is true when IT is no longer observed as a business developer. Moreover, people outside the IT world do not understand why IT is costly (a euphemism) while, par excellence, it is the technical field where competition is fiercer, innovations are bigger and, accordingly, costs linked to hardware/software parts (e.g. open-source software libraries) are increasingly lower.

Regarding the tourism industry, it should benefit from both the Internet (as an ever unbound marketplace) and IT advances, which together reshape the Internet-based possibilities of doing business. Nonetheless, over the years, the tourism industry has been unsettled by the Internet, which created an excessive, even confusing, offer with an exacerbated competition. In fact, the globalization of tourism business diminishes sales margin, relying on adaptive information systems not to miss pioneering revenue opportunities.

New players, new deals, new rules of the game, etc., appear in quasi-real-time. The paradox is that IT makes possible this liveliness, while software applications must accordingly behave differently to cushion new business events. Ultimately, this leads us to ask developers to change code and in the worst case to reformat software architectures. The latter is both a source of stress and risk and, unfortunately, software crash before reaching a new stable situation, which, in turn, does not meet the very last business expectations. This infernal circle can only be broken with flexible software frameworks.

Tourism players, such as hotel chains, tour operators, tourism agencies/organisms/consortia, transporters and car rental companies, are involved in both business to customer (B2C) and business to business (B2B) commerce. For instance, hotel chains may buy excursions from tour operators while the latter buy bedrooms from these chains.

New players are, for instance, health centers because a confirming trend is the fact that customers associate travels with the possibility of care: dental care, plastic surgery, fitness, etc. Another trend is the possibility of collaborating with real estate agents, which can supply different kinds of accommodation, and thus multiply the types of lodging on offer.

New deals can be joint and/or bulk purchasing, subcontracting, product/service sharing, partnership with price comparison Websites, etc.

The new rules of the game are, for instance, the fact that end customers include implicit concerns when ordering travels. These are security, sustainability, privacy, responsible tourism, etc. In the best case, such values might be transformed into paying services, which probably require collaboration with specialists. In the worst case, these values may be in contradiction to cheap offers.

Intuitively, from a software viewpoint, it turns out that, a minima, tourism applications must be able to exchange data. Beyond this, we may simply imagine, for example, the connection between a health care center soft...

Table of contents

• Cover Page
• Contents
• Title Page
• Copyright Page
• Acknowledgments
• Acronyms
• Introduction
• 1. Software Modernization: a Business Vision
• 2. Software Modernization: Technical Environment
• 3. Status of Cobol Legacy Applications
• 4. Service-Oriented Architecture (SOA)
• 5. SOA in Action
• 6. Model-Driven Development (MDD)
• 7. Model-Driven Software Modernization
• 8. Software Modernization Method and Tool
• 9. Case Study
• Bibliography
• Index