Se débarrasser de Pacbase (et des AGL) – Partie 1

Tags:

Avant tout, les points de vue que j’exprime ici me sont personnels et ne reflètent pas nécessairement les points de vue de mes employeurs passés, présent et futurs.

 

Cas type :

Une Organisation utilise un AGL (Atelier de Génie Logiciel) pour développer et maintenir une partie de son parc d’applications. Pour des raisons diverses, cette Organisation veut se débarrasser de cet AGL. Une des raisons peut être que l’éditeur de cet AGL veut arrêter de le supporter, mais il y a de nombreuses autres raisons possibles.

Quelles que soient ces raisons, et pourvu que les applications développées avec cet AGL soient destinées à perdurer à l’avenir, l’Organisation doit choisir une nouvelle technologie cible (ou plusieurs) et une façon de l’atteindre. Essayons d’envisager la stratégie de choix d’une technologie cible.

1) Stratégie de la stabilité dans le temps

Si la stabilité dans le temps est un des buts principaux l’idée est, au moins, de ne pas reproduire la situation actuelle dans le futur. Choisir comme cible un nouvel AGL qui risque de tomber dans la même impasse que l’AGL courant est à coup sûr une idée étrange (la vie est parfois étrange, le business aussi…).

Peut-on éviter de choisir un AGL ?
Une des premières idées quand on se met à penser à une cible est : et si on cherchait un AGL qui fait en gros la même chose que notre AGL actuel – ce qui garantirait une conduite du changement minimale – mais qui a une bien meilleure perspective d’avenir ?
Quelle que soit la technologie de développement nous utilisons des outils. Et on utilise/utilisera de plus en plus d’environnements logiciels. Finalement, comment peut-on faire la différence entre un AGL et des outils composant un environnement de développement logiciel ?
– Un AGL, historiquement, offre un moyen de modéliser de l’information et de générer du code source “terminal” à partir de cette information, information qui est donc de fait un modèle du code. Pour les AGL historiques, le code généré n’est pas lisible facilement par un développeur : ça ne fait pas partie de ses finalités et il n’est pas destiné à être maintenu directement sans passer par l’AGL.
– Un environnement de développement logiciel, via les outils qui le composent, aide à gérer les processus de développement et à stocker les artefacts de développement, donc le code source, d’une manière organisée et sécurisée.

La principale, et grosse, différence entre les deux est q’o peut se débarrasser relativement facilement d’un environnement de développement logiciel sans perdre d’information puisque les codes sources, et tous les autres éléments d’information comme les paramètres par exemple, ont été fabriqués par l’homme et sont toujours disponibles et lisibles. Ce n’est pas vrai dans le cas d’un AGL puisqu’une partie de ces informations et la manière de les interpréter est caché dans des boîtes noires : générateurs de code non accessible (sauf pour l’éditeur), structures de référentiel de données non publiques, etc.

Une alternative aux AGL historiques serait d’utiliser une approche plus ouverte de la génération de code – Model-Driven Development (MDD/MDA) – en utilisant une boîte à outil comprenant un modeleur, des règles de modélisation et un moteur de génération de code. Ceci amènerait plus ou moins l’Organisation à développer son propre AGL. Indépendamment des avantages et inconvénients d’une telle solution (voir par exemple MDE shuffled again), il serait délicat de faire ce choix sans englober dans le périmètre visé l’ensemble du portefeuille applicatif et non seulement le sous ensemble lié l’AGL dont on veut sortir.

Finalement, la stratégie de stabilité dans le temps amène soit à cibler une technologie déjà présente dans le portefeuille des technologies de développement, soit à ajouter une nouvelle technologie à ce portefeuille.
Ajouter une nouvelle technologie de développement au portefeuille existant, à une époque où les entreprises chercher plutôt à réduire ce portefeuille, nécessite une argumentation forte. Assurément, trouver une solution de remplacement pour un AGL vieillissant n’est pas en soi une raison suffisante, et remplacer un AGL mourant par un autre AGL n’est pas une bonne idée du tout…
…du point de vue de la stabilité dans le temps ! Mais il peut y avoir d’autres perspectives offrant un autre point de vue : ce sera le sujet d’autres billets sur ce blog.

Stabilité dans le temps : le cas Pacbase

Regardons la situation de Pacbase sous l’angle de la durabilité dans le temps. Je prends Pacbase pour illustrer la question des AGL parce que c’est une question actuelle (en 2013) et que je connais un peu le sujet. J’aurais pu illustrer le sujet avec un autre AGL : ça n’aurait pas changé fondamentalement mon argumentation.

Pacbase est un outil initialement développé par une société de service française pour encapsuler le développement COBOL dans un AGL. Pabase a ensuite été acheté par IBM et fait maintenant partie du portefeuille de solutions de Rational. Pacbase est principalement (mais pas uniquement) utilisé par quelques grosses sociétés françaises qui l’ont choisi il y a de nombreuses années. Cependant, même si le produit est reconnu de bonne qualité et efficace et que sa conception repose sur des principes MDD toujours d’actualité, personne ne choisirait Pacbase aujourd’hui parce que c’est un environnement qui date.
D’un point de vue business pour un éditeur logiciel, le revenu engendré par ce produit repose maintenant uniquement sur les contrats de maintenance et ne peut donc que décroitre dans le temps au fur et à mesure que les clients migre vers d’autres technologies. Pourquoi les clients quittent cette technologie ? Principalement parce que les développeurs et experts Pacbase ont pris/prennent leur retraite : ils sont aussi “vieux” que la technologie ! En parallèle, les experts Pacbase chez Rational prennent aussi leur retraite. Donc ce produit voit ses coûts de maintenance augmenter (productivité et formation des mainteneurs) et ses revenus diminuer… Faut-il faire un dessin ?!
D’une certaine façon, même IBM a besoin de produits durables économiquement en terme de ratio revenus/coûts.

So, IBM announced the end of Pacbase maintenance in the next years. And proposed… nothing clearly as a replacement! Let’s describe roughly the technology core target solutions as I understand them:
a – EGL: a new language/CASE tool. A brand new one!
b – Rational Programming Pattern (RPP): a new CASE tool which reproduces Pacbase design/generation mode inside a COBOL development environment

How to understand IBM’s solutions to get rid of Pacbase? How does it fit to the Company sustainability strategy?

IBM/Rational business problem
The goal here is to make money with software solutions. It’s Rational business: no surprises here.

The first idea (the “a” solution) is then probably to merge several dying captive markets into a new bigger and dynamic one. Pacbase’s customers is one of these markets, but there are other ones (ex: VisualAge series users). One idea behind EGL is probably: let’s offer an up to date CASE tool which brings business oriented design facilities and high productivity for the technical development side. Not a bad idea from a theoretical business viewpoint, but a hard to sell one from market adoption and vendor dependency ones… Not even to mention the modernization path from old CASE tools application portfolio towards a brand new technology !!!

The second idea (the “b” solution) is probably focused on the other end of the problem: how to lower the Pacbase disengagement costs? That means, from business side, how not to offer customers an opportunity to think about their dependency to IBM’s solutions in offering a smooth transition from Pacbase to other IBM’s development technologies? There are three keys here:
– COBOL: as Pacbase generates COBOL, the solution must target COBOL and IBM’s COBOL well-known development tools
– Change management: Pacbase’s developers are used to Pacbase’s facilities such as data dictionary, macros, etc. The idea here is to give equal facilities into a COBOL environment
– Remove the necessity to do massive Non Regression Test after the migration processing by providing in the end exactly the same COBOL code as obtained from Pacbase
This plan sounds better than EGL for customers but… What is the gain for IBM to replace Pacbase by a Pacbase-like CASE tool? And where is the sustainability aim?
And I even don’t mention the technicals problems cause that is not in the perspective I choose here…

Company’s problem
The Company has a Pacbase team, big or small, and Pacbase programs, some or a whole bunch. Programs have to be maintained, frequently or not, in an IT ecosystem that goes away from Pacbase technology each day a bit further. And Pacbase developers have to be replaced as they retire one after another, and tend to become more and more expensive. Even if the technology itself gives full satisfaction, the Pacbase stream is less and less sustainable… IBM’s Pacbase retirement announcement may just be seen as a booster for that trend.

Are IBM’s alternatives to Pacbase solutions to be taken into account? At what conditions?
Well…
EGL sounds like: how about to redevelop your IS with a fantastic new tool? It can be seen as a marvelous perspective, or not. But it’s a “forget and build from scratch” modernization path. A fun path, but not really a smooth one…
RPP sounds like: it has the color of Pacbase, the smell of Pacbase but it’s not Pacbase. So what? Won’t we at least have the pleasure to drink until just before being drunk? And what is the point of maintaining Pacbase-like practices limited to Pacbase practicers that will retire soon or sooner? And by the way, why IBM would maintain RPP if they don’t want to maintain Pacbase ? Wouldn’t it be easier to keep on going with Pacbase?
Not very convincing.

Let’s go back to the sustainability generic consideration: the Company should probably either move from Pacbase towards an already acquired and mastered development channel, either take the opportunity to build a new development channel with a new technology or a new way to work with an existing technology.
The first option leads to move towards COBOL and COBOL current Company’s practices (shortest move) or towards Java (hardest one).
The second option leads to adopt EGL: a very high level challenge!, or to adopt RPP provided that this embedded CASE tool may be used to also boost “non Pacbase” COBOL development, and possibly other technologies (notably Java), productivity: a very good challenge also!

My opinion: as far as sustainability is a goal, for Pacbase the move to COBOL is the best one.

Featured image taken from: http://www.uponor.fr/a-propos-d-uponor/uponor-comme-partenaire/sustainability.aspx