On ne peut améliorer que ce qu’on connaît et ce qu’on mesure.

Quand la connaissance du système par ses développeurs est partielle et que la documentation manque de clarté, le code source constitue alors l’unique ressource, et il devient essentiel de comprendre celui-ci pour assurer la gestion et le développement du système. Obtenir un résumé de l’implantation du code pour ainsi visualiser la conception et le flux de l’application, est alors un moyen de comprendre les processus métiers. On se base pour cela sur les éléments suivants : Interfaces d’applications ; structures d’appels ; flux de données ; flux d’écrans ; sous-routines ; modèles de données ; traçage des variables.

La conclusion de cette étape consiste à produire, à partir de ces éléments, une documentation avec des diagrammes graphiques, flux d’informations, listes, annotations et aperçus de règles métiers, qui permette de partager l’information.

Il arrive souvent que l’applicatif entier soit trop volumineux pour en permettre sa compréhension approfondie ou pour y apporter des changements majeurs. Il est alors nécessaire et utile de diviser un système en sous-systèmes, en « aires applicatives ».
On regroupe alors les objets par domaine, ce qui simplifie la compréhension du système et permet la maitrise des opérations.

Accroître l’efficacité applicative, c’est résoudre les dysfonctionnements, les redondances, les trop faibles taux d’utilisation et les incohérences, et accroître la modularité du système. Il faut donc pour cela être en capacité de les identifier et les mesurer.
On cherche aussi à faciliter la maintenance évolutive en identifiant les conséquences d’une modification d’une partie du système d’information sur le reste du système. On repère les dépendances des applications (objets et variables) ; on trace de l’ensemble des utilisations d’une information donnée.

Il s’agit à ce stade de mesurer, surveiller et gérer de manière proactive la complexité des changements applicatifs, afin de prioriser les évolutions.
Il faut identifier où réside le code le plus complexe dans le système et planifier / prioriser les évolutions en conséquence, avec des critères objectifs de complexité par processus.

Les nouvelles recrues, les consultants des sociétés de services externes ne maîtrisent pas tous le code RPG, et la documentation, même graphique, n’est pas suffisante pour leur permettre d’intervenir en développements.
Une solution pour les aider consiste à traduire le RPG en texte structuré ou « pseudo-code ». Ce pseudo-code explique la logique du programme dans un anglais simple et clair, et permet à tous d’assimiler l’information à un niveau détaillé de l’application, sans dépendre de spécialistes RPG ou COBOL.

La cartographie est un outil clé et pour qu’elle le reste, sa maintenance et sa mise à jour sont indispensables. Pour cela, il est fondamental de construire une cartographie aux caractéristiques et règles de modélisation bien précises : exactitude, cohérence des modèles, complétude, uniformité du langage, clarté de diffusion et communication.