Les cycles de l’Obsolescence du Système d’Information passent de 10 ans à 2/4 ans.
Toute entreprise, éditrice de solutions logicielles ou disposants d’applications coeur de métier, est naturellement confrontée à des problématiques d’obsolescence de son Système d’Information et de ses solutions logicielles.
L’accélération de cette obsolescence peut être un vrai frein au business face à une concurrence féroce, de plus en plus organisée et disruptive. Le schéma ci-dessous décrit les différents indicateurs Business, Technique ou RH qui font du Système d’Information, d’un progiciel ou d’une application coeur de métier un système Obsolète.
Dans ce contexte, pour les sociétés victimes d’obsolescence, deux solutions s’imposent à elles :
La première consiste à repartir de zéro, tout réécrire, les spécifications, les règles métier, les IHM et parcours clients avec trois difficultées majeures : la capacité à financer ce bigbang, le risque de perdre des règles métier en cours de route et la capacité à assurer un Time To Market.
La seconde alternative consiste à utiliser des méthodes et outils qui se veulent moins radicaux tout en permettant de continuer à valoriser l’existant. Ces outils que sont le revamping, le portage de code automatique, etc. ne sont pas des solutions miracles mais des solutions de compromis pragmatiques permettant d’obtenir des premiers résultats très rapidement.
Par la suite, nous allons faire un retour d’expérience sur l’une de ces technologies de modernisation pour des logiciels écrits, il y a quelques années, avec les frameworks MFC et WTL.
Résoudre les problèmes d’obsolescence des applications écrites en Microsoft MFC/WTL
Précisons le contexte de ce retour d’expérience : un éditeur de progiciels a réussi, il y a plus de 10 ans, à devenir leader sur son marché au moyen d’un logiciel répondant parfaitement aux besoins métier de ses clients. L’excellence fonctionnelle de leur produit a permis à cette entreprises d’acquérir 70% du marché Français dans leur domaine métier.
Depuis quelques années, leur progiciel, un client lourd écrit avec les Frameworks Microsoft MFC et WTL, se faisait attaquer de toute part par de nouveaux acteurs proposant des solutions plus “Modernes”, avec de nouveaux parcours clients et des interfaces de type “Web 2.0”.
En l’état, il était impossible pour cet éditeur de rester concurrentiel : chaque nouvelle fonctionnalitée ou implémentation de parcours clients était très coûteuse et l’ergonomie et l’IHM en général restait connotées années 90.
Pour cet éditeur, il n’était pas envisageable de réécrire complètement leur progiciel pour des raisons budgétaires (estimation de 7000 h/j de développement non chargés) mais également pour un soucis de réactivité vis à vis de la concurrence.
La solution de compromis qui a été imaginée a été d’utiliser un Wrapper MFC/WTL vers du QT : on substitue au Framework Microsoft MFC/WTL, un Framework équivalent, basé sur Qt. Avec pas (ou peu) de modifications de code existant, QT va permettre de moderniser les IHM du Legacy..
Cette solution présente plusieurs avantages :
- – Pas (ou peu) de modifications du code existant : on ne risque pas de perdre de règles métier et pas besoin de réécrire des spécifications.
- – Permet de passer l’ensemble de l’application (400 écrans) sous le framework QT :
- — Personnalisation des styles des composants et fenêtres possibles (Thèmes QSS), avec un rendu proche des CSS3 et du Web 2.0.
- — Permet nativement un portage multi-os de l’application (Linux, Windows, Mac).
- — Le code produit au final est beaucoup moins “lourd” et plus simple à maintenir.
- – Les deux Frameworks (MFC -ou WTL- et QtMFC) peuvent cohabiter au sein de l’application et permettre ainsi un portage incrémental, faisant ainsi fonctionner l’ancien code avec le nouveau code et les nouveaux parcours clients créés :
- — Les développeurs peuvent continuer à utiliser leurs habitudes MFC (même si non recommandé)
- — Les nouveaux développements pourront être fait en Qt (le langage nécessite beaucoup moins de lignes de code qu’avec les MFC/WTL). Il est également intéressant de pouvoir utiliser des composants QT évolués “clef en main”.
Le schéma suivant représente un exemple de transformation graphique que l’on peut obtenir sans toucher au code. Les maquettes ont été fournies par un designer Web.
Deux méthodes peuvent cohabiter pour l’intégration de ces nouveaux design :
1/ Soit on utilise les Style Sheets de QT de manière automatique pour le relooking :
Les vues existantes décrites dans des fichiers .RC sont traduites automatiquement dans des vues Qt permettant d’appliquer un QSS et de personnaliser facilement par la suite ces vues via le designer QtDesigner.
2/ Soit Il est possible d’intégrer des Webview (HTML/JS et CSS) qui vont pouvoir appeler le code natif legacy.
Avant : Une fenêtre MFC classique : Widgets peu évolués, fond gris, tree view,…
Après : La même fenêtre entièrement basée sur des styles QSS
Comme dans toutes solutions de compromis, il existe quelques limitations :
Le look des composants externes pour lesquels les sources ne sont pas accessibles (type ActiveX) peuvent être intégrées, mais pas “wrappées”. L’activeX reste fonctionnel mais le look reste “en l’état” ou nécessite une modification plus spécifique du code existant.
En résumé, voici les avantages (et inconvénients) de la solution de Wrapping des classes MFC/WTL :
« + » Possibilité d’intégrer un design de type “Web 2.0”
« + » Possibilité de faire cohabiter le code du Legacy avec des nouveaux parcours client écrits directement en QT
« + » Moins de lignes de code des nouvelles fonctionnalitées écrites en QT pour une maintenance plus facile
« + » Les règles métier du Legacy ne sont pas perdues
« + » Obtention de résultats très rapidement afin d’assurer un Time-To-Market
« + » On ne touche pas au code source du Legacy
« + » Portage Multi-OS natif (Linux, Windows et Mac) grace à QT
« + » On supprime tous les bugs liés au framework MFC/WTL
« – » Les ActiveX ne sont pas “Wrappables” sans les sources
« – » Ne corrige pas “automatiquement” les bugs “métier” existants du Legacy
En conclusion, pour ce retour d’expérience, l’application de l’éditeur est portée en 40 jours (développement + tests unitaires) contre les 7000 jours prévus initialement !
Epilogue.
Tout portage d’une application Legacy reste un projet à part entière. La complexité de l’exercice réside évidemment dans les technologies utilisées mais pas uniquement : les outils et process mis en oeuvre ainsi que l’organisation sont des éléments importants à prendre en compte.
Il n’y a pas de solutions miracles mais il faut garder en tête qu’il existe des alternatives au bigbang et à la réécriture complète de votre legacy (et pas uniquement pour les applications MFC/WTL).
Ces alternatives permettent une transformation en douceur, de continuer à faire fonctionner votre business tout en gagnant du temps afin d’assurer un portage efficace vers une cible technologique moderne, pérenne, industrielle et scalable.
