Après le dernier séminaire organisé par Novalys chez Sybase, je me suis rendu compte que beaucoup de clients se posaient cette question et que finalement, les réponses étaient assez confuses. Il en ressortait plutôt que rien ne pressait et que l'on pouvait attendre.

Parallèlement, je ne compte plus le nombre de clients PB qui décident ou envisagent de re-développer leurs applications en .net/C#. On pourrait peut-être leur éviter de faire une grosse bêtise...Comme ont fait ceux qui on redéveloppé leurs applications en Java il y a quelques années...et qui aujourd'hui doivent se demander quel est l'avenir de leurs applications.

Je souhaiterais donc lancer cette discussion afin que nous mettions au point, tous ensemble, un argumentaire sur l'intérêt de migrer les applications PB en PB.Net, et d'adopter PB.net comme nouvel outil de développement pour les applications.

Il serait bon aussi d'avoir un argumentaire sur l'intérêt de passer (rester?) à PB 12.5 classic, car, je crois que cette approche est aussi très intéressante dans certains cas.


Voici quelques idées comme base de départ pour PB.NET :

1-    La fin des dinosaures – avoir des applications plus actuelles.
PB.net introduit la notion de développement d'applications à IHM très riche en se basant sur la nouvelle technologie de Microsoft : WPF, pour la construction d'interfaces graphiques. En passant à PB.net, il devient donc possible d'avoir une application reposant sur les tous derniers standards en matière d'interface graphique et offrant un confort et une "expérience" (commes disent les anglosaxons) d'utilisation bien meilleurs. S'il est vrai que Pb à loupé le tournant Web dans les années 2000, le virage Applications riches des années 2010 a été très bien négocié.
L'intérêt est donc de donner une IHM plus actuelle à nos applications afin que leurs utilisateurs n'aient pas l'impression d'utiliser des antiquités comme outils de travail. On peut aujourd'hui dire que les applications Win32 et dans une moindre mesure les applications Web, ressemblent à des dinosaures de l'aire informatique pour des utilisateurs de smart phone et de tablettes graphiques (soit une très grande partie de la population active).

L’autre intérêt est de pouvoir fournir des applications compatibles avec le « touch » qui va devenir très populaire avec l’arrivée de windows 8 et la migration massive de nos PC en portables-tablettes dès la fin de cette année.

Cette approche a aussi comme intérêt de redorer le blason des équipes de développement et de la DSI en montrant qu’ils sont capable de développer des applications dernier cri et pas seulement de maintenir des antiquités.

2-    Résoudre les problèmes de déploiement
Beaucoup de clients font le choix de développer des applications avec une interface Web (HTML) afin de limiter les problèmes de déploiement et de mise à jour.

Pour le problème de déploiement à grande échelle, il est vrai que le mode Web (HTML) reste le meilleur et que PB ne nous fournit pas vraiment de solution pour y remédier (Appeon, Web forms… arrivent à résoudre ce problème partiellement en permettant de déployer les applications sur des postes Windows utilisant IE comme navigateur. C’est encore très limité et difficile à expliquer au PDG qui vient de recevoir un Ipad ou un Iphone pour Noel…). Seules des solutions telles que le cloud computing et des clients citrix universels semblent se détacher du lot, mais à des coûts assez importants et il n’en reste pas moins que l’IHM des application n’est pas forcément adapté à son support et que les utilisateurs sont souvent un peu déroutés. Seul feu HTMLBridge permettait de déployer sur n’importe quel navigateur, mais la migration d’applications existantes était très longue voir impossible dans la plus part des cas. Le produit était plus adapté au développement de nouvelles applications ou de nouveaux modules.

Dans un grand nombre de cas, le principal problème est surtout le problème des mises à jour. PowerBuilder  permet de résoudre ce problème depuis l’adoption de la technologie winforms/smartclient en PB11. Pas besoin donc de passer à PB.net pour résoudre ce problème mais cela permettra aussi de le résoudre.

3-    Eviter les coûts de changement de technologie obligeant à un re-développement.

Beaucoup d’applications développées avec PowerBuilder couvrent un domaine fonctionnel important et nécessiteraient de très gros moyens financiers pour être redéveloppées. Les DSI n’ayant pas connus l’heure de gloire du client serveur, ne se rendent pas compte que les « nouveaux » langages de développements n’apportent pas du tout le même niveau de productivité que les L4G+ tels que PowerBuilder. Ainsi le coût d’un redéveloppement sera dans certains cas plus de deux fois supérieur au coup de développement initial de l’application PowerBuilder. Un développement Offshore permettra de limiter les coûts de développement mais augmentera sensiblement les coûts d’AMOA pour finalement arriver à un résultat pratiquement équivalent en matière de budget.
Le fait de migrer en PB.Net est beaucoup moins coûteux (quelques semaines suffiront en fonction de l’objectif défini). On est très loin des dizaines d’années hommes à investir sur certaines applications.

4-    La réactivité

En dehors des problèmes de coûts se posent le problème du temps. Redévelopper une application va prendre beaucoup de temps.
De même, faire évoluer une application PowerBuilder  prend beaucoup moins de temps qu’avec les autres technologies.
L’agilité est aujourd’hui mise en avant comme élément clé de la réussite d’une entreprise. Il y a donc tout intérêt à rester avec PowerBuilder.

5-    La pérennité

Les technologies de développement actuelles sont très volatiles. Il en sort une nouvelle tous les mois, et elle meurt souvent tout aussi vite. Le plus gros problème de toutes ces technologies, c’est qu’elles ne permettent jamais de migrer vers d’autres. C’est le dur constat que font les développeurs d’applications Web qui ont développé leur application en HTML 3 ou 4 et qui se voient contraints à ne pas pouvoir la faire évoluer car cela nécessiterait de tout redévelopper au niveau de la logique applicative. Seuls le plus prévoyants pourront garder les règles métier  s’ils ont bien partitionné leur développements, mais cela ne fait pas grand chose.
Ont en est même arrivé à ce que certaines technologies soient obsolètes avant d’être utilisé. J’ai ainsi eu un client qui a demandé à faire un chiffrage du redéveloppement d’une de ses applications PowerBuilder en .net (qui dans son esprit voulait dire interface web). Les différentes sociétés lui faisant le chiffrage ont optés pour une interface en Silverlight, dernier fleuron de la technologie Web de Microsoft. Le problème est que Microsoft, quelques mois plus tard, a commencé à émettre l’idée de ne plus investir sur cette technologie et de se focaliser sur le HTML5 à la place. Mon client aurait donc eu une application obsolète et ne pouvant plus évoluer avant même d’être livré !

Sur l’aspect pérennité il faut cependant nuancer. Si votre application doit être déployée en client-riche, alors migrer en PB.net représente un réel apport, WPF faisant partie intégrante de Windows.
Si vous compter un jour déployer votre application en client riche mais sur le web (parce que vous déployez en extranet par exemple), alors il vaut mieux rester en PB classic. L’intérêt du PB classic est qu’il y aura toujours moyen de garder le même code source pour des environnements cibles différents. Aujourd’hui une même application PB classic peut être migrée en Winforms (via compilation C#), en Webforms (via compilation C#), en HTML/activeX (via appeon), en WPF (en passant à PB.net). Ca laisse rêveur les utilisateurs d’autres technologies…et cela ne vous oblige pas à fournir la même interface utilisateur à tous vos utilisateur en la nivelant par le bas comme c’est le cas avec les applications Web/HTML aujourd’hui.
Grace à PB.net, PB classic a aussi pu évoluer et il devient désormais possible d’adapter les IHM de nos applications pour les rendre beaucoup actuelles et beaucoup plus agréables.

Powerbuilder existe depuis plus de 20 ans et a su évoluer jusqu’à devenir un des meilleurs outils de développement .net sur le marché. Quid des autres technologies jetables ?
Le fait que des sociétés telles que SAP aient décidé d’investir sur Powerbuilder est particulièrement rassurant sur son avenir.


6-    Plus de limitation technologique

PB.net étant un langage .net, il permet d’utiliser n’importe quel objet .net écrit dans n’importe quel langage .net. Il devient donc possible d’intégrer des composants utilisés dans d’autres applications ou développés par d’autres sociétés.
PB.net offre toutes les possibilités des autres langages .net puisque tous reposent en réalité sur un même langage commun généré avant la compilation.
Il devient donc possible de coder en powerscript.net des fonctionnalités qui obligeaient jusqu’à présent à avoir recours à d’autres langages tels que C++ ou C#. Je pense surtout à la manipulation de données XML très utilisée pour les échanges d’information B2B.
Enfin, le PowerScript.net ajoute de nouvelles possibilités au PowerScript en l’enrichissant  de façon significative au niveau de la programmation orientée objet. Cela ne touche qu’une minorité de développeurs, mais c’est un plus pour tout ceux qui ont développés un framework avec PB et sur lequel reposent leurs applications.

7-    Trouver facilement les ressources pour les développements.

PowerBuilder existe depuis 20 ans et un grand nombre de développeurs le maîtrise aujourd’hui.

Beaucoup de client mettent en avant le fait qu’il est difficile de trouver des compétences Powerbuilder pour leur développement. Leurs équipes internes ayant souvent pris du galon et ayant déserté les activités de développement.

Il faut aussi reconnaitre qu’un grand nombre de développeurs PowerBuilder travaillent aujourd’hui avec d’autres technologies (java et .net principalement). Il reste cependant une grande commuté de développeurs PowerBuilder qui n’échangeraient leur outil de développement pour aucun des autres outils actuels. C’est d’ailleurs grâce à eux que PowerBuilder est toujours présent et qu’il a eu la possibilité de pouvoir évoluer. Sybase a en effet pu investir sur PowerBuilder voyant avec étonnement  l’attachement des équipes de développement de ses clients à cet outil.

PowerBuilder arrive même à convaincre de nouvelles équipes. Un module de SAP est en effet en cours de développement en PowerBuilder ! ! !

L’avantage de PowerBuilder est que les développeurs sont généralement des développeurs expérimentés ayant de nombreuses années d’expérience et ne commettant donc pas les erreurs de débutant s en matière de développement et surtout en matière de rigueur et de méthodologie.
Les développeurs expérimentés ont aussi l’avantage de développer beaucoup plus rapidement permettant ainsi de finir les projets dans les délais pour un coût finalement équivalent, voir moins cher. La règle n’est bien sûr pas toujours vraie, mais elle est tout de même rassurante.

Les développeurs expérimentés sont aussi particulièrement bien qualifiés pour encadrer des équipes de développement, ayant eux-mêmes une grande expérience en la matière. Il devient donc facile de former des équipes intégrant de jeunes développeurs qui apprécieront tout particulièrement de pouvoir mettre en pratique  leurs connaissances en matière de nouvelles technologies (WPF, .net) pour des applications migrées en PB.NET. Le fait de migrer en PB.NET apporte donc la possibilité de motiver les plus jeunes développeurs et de les mettre en avant sur les aspects « nouvelles technologies » de Powerbuilder.