Perform application maintenance faster and at lower cost

This comes in the form of

• Cost reduction,
• Improvement of the technical and functional control of the Information System,
• Optimization of development and maintenance processes,
• Reduction of technical debt,
• Digitalization of business processes.

It should be kept in mind that most of these issues are linked because the first obstacle to reducing costs and implementing agile processes is linked to the adherence of the technologies used with obsolete infrastructures, expensive to operate and / or not allowing to take advantage of new development tools and methods.

Rationalizing its system and methods requires technological modernization but without breaking the commercial dynamic of the profession because “sales go on during the works”.

The first step in rationalization consists in making an inventory which involves a technical and functional inventory of its heritage.

Regaining control of your applications requires knowledge of what is actually executed in production. This is not always the case especially on Mainframe environments.

The Mainframe Issue

Here are some questions to help understand the issue on Mainframe:

1. Do you have in production loads compiled with older versions of the compiler or with compilation options different from those in force today?
2. Do you have static linked programs in production with subroutines that may have evolved over time?
3. Do you have multiple versions of load in production libraries for the same source?
4. Do you systematically recompile all the programs that use a COPY when it is modified?
5. Do you have programs in production for which you no longer have the sources or for which you have several possible sources?

6. Have you kept unused programs or obsolete lines of code in the sources as a precaution?

If you answered yes to one of these questions or if you do not know how to answer it, it is likely that there are areas for improvement in your configuration management and maintenance processes.

The objective of configuration management is to allow a production to be completely reconstructed from application sources. Very few organizations are able to do this on Mainframe.

Modern environments

Among the applications developed in modern languages ​​like Java, there are a large number of tools and uses allowing to manage its inheritance well. However, for lack of time or means, we often do short term.

For example, to have an up-to-date non-regression repository allowing continuous integration, it would be necessary to set up an anomaly correction procedure consisting in starting by reproducing the anomaly with a test case which will enrich the repository before correcting the anomaly. Again, few people actually do that process.

Client / Serveur Heritage:

Client / Server assets are in between with most often applications managed in configuration managers but programming uses based on event languages ​​and often permissive which implies an explosion in the number of cases of triggering of a treatment. As the event programming was not standardized until late, we observe a duplication of processing when it would have been necessary to functionalize as much as possible to optimize and secure developments and maintenance.

Access to data is also often managed in a dispersed manner with queries sprinkled throughout the code, making it difficult to modify the data model.

Mixed Architectures

When the Client part developed in a Client / Server 4GL relies on a Server part on Mainframe, it is very difficult to have an end-to-end vision of the transaction which technically goes through different application and middleware layers and is moreover administered by several development teams.

It is difficult to stay on course. One should be rational and not be subjected to the “ayatollahs’ standards”.

With an experienced team that knows the applications very well, we can make some dead ends and the intuition of the developers will compensate for the lack of rigor. But all has a price and sooner or later, there will be retirement, resignation, mechanical wage inflation and resistance to change.

A good course of action seems to us to be taking advantage of technological contributions by implementing the technology and processes allowing to have an exhaustive view of its heritage and the interdependencies between the components so as to:

• Reduce the scope to only useful components,

• Easily locate the origin of an anomaly

• Identify all the impacts of a modification and reduce side effects or regressions

• Allow to outline the perimeter of a function to urbanize and improve a system

• Facilitate the skills development of maintenance teams

• Secure control of its applications

Technical Mapping

Technical mapping consists in collecting all the sources of all the components (Programs, sub-programs, JCL, Data, Copy, etc.) and drawing between them the cross references so as to identify for each component:

1. Components it needs,
2. Components to which it is necessary

Based on the TP and Batch entry points, the workshop delimits the useful perimeter of the components and products 2 lists:

• Missings (i.e. the list of components required but the source of which has not been provided)
• Unrefs (Non Referenced), i.e. the list of components whose source has been supplied but which are not invoked.

It is necessary to collect the sources of the Missings which potentially can draw references to many Unrefs objects.

Completing the list of entry points also allows you to reference components identified as Unrefs.

It is clear that this is an iterative process and that the number of iterations will depend on the quality of the configuration management.

Functional Mapping

We can complete the Technical mapping with a Functional mapping which consists of listing functions or business applications.

The granularity of this census is an important element to allow the exploitation of this information. Functionally describe the function or application and isolate the entry point(s).

Synthesys

The entry point associated with each function or application makes it possible to exhaustively list the components that support it by applying cross-references from the Technical mapping.

Cross-references being cross-technology, we can follow an end-to-end transaction from the Client / Server Front or Web to the Table of the DB2 database on Mainframe via the CICS transaction developed in COBOL.

Technical and Functional Mapping Diagram:

We can “score” the function or the application from a technical, functional or financial point of view so as to objectify a macro master plan which will allow application by application to define an optimum target.

Diagram of the rationalization process:

The implementation of such a repository makes it possible to facilitate Corrective and Evolutive maintenance operations across the entire portfolio.

For the Correction, we will more easily identify the origin of the malfunction by isolating the list of instructions which manipulate the data structure in which we have located an anomaly and we will be able to navigate in the program sources by following the calls.

We can measure before implementation, the impact of the proposed correction on the components that uses the resource that we are modifying, in order to limit side effects.

For the Evolutionary, the technical scope of the function that we want to develop is directly available. It’s easier to identify the best place to implement evolution.

Les impacts des modifications sur les autres composants sont directement disponibles et permettent d’anticiper les effets de bord et facilitent la prise en compte des modifications nécessaires.

Ces analyses pouvant être menées en amont, l’estimation des charges sera plus fiable et la mise en œuvre plus économique.

Diagram of the stages of Application Maintenance:

Having such a repository also makes it possible to automate a certain number of repetitive operations that a developer performs throughout the project.

For example, we can generate JCLs or data refresh scripts based on data modified by a program or a set of programs (All programs executed by the same JCL for example).

It is estimated that a developer spends 15-20% of his time refreshing test data. The gains can be substantial.