Philippe Magne ( Arcad Software ) :

ARCAD SOFTWARE distribue depuis le 1erJanvier RDi en OEM (Rational Developper for i).
Son PDG, Philippe MAGNE nous parle plus en détail de cet accord, et du positionnement d'ARCAD SOFTWARE autour de ces produits.

Site 400 : Bonjour Monsieur MAGNE, parlez-nous de cet accord de distribution avec IBM, quelle est la nature de ce partenariat ?

Il s’agit d’un accord de type OEM. Autrement dit, depuis la version 8.9 de nos solutions, RDi est considéré comme faisant partie intégrante de l’offre Arcad. Il est livré par défaut au sein du poste graphique du développeur. Les clients n’ont pas d’acquisition directe à faire auprès d’IBM.
Au titre de cet accord, c’est ARCAD Software qui assure le support technique sur RDi. Les formations sont personnalisées. Elle intègrent à la fois les fonctionnalités d’Arcad et RDi.

Site 400 : Il s'agit d'un accord France ou plus large encore ?

Cet accord est un accord valable dans le monde entier. C’était une condition sine qua non pour nous, dans la mesure où nous avons des clients répartis dans plus de 32 pays différents. Il n’aurait pas été envisageable d’avoir à répliquer ce genre d’accord dans tous les pays où nous avons des clients. Nous avons été agréablement surpris par cette souplesse. Le côté amusant, c’est qu’IBM France va ainsi capter des revenus étrangers par notre intermédiaire.

Site 400 : Pourquoi ARCAD SOFTWARE souhaitait se positionner dans la vente de licence RDi ?

Pour plusieurs raisons :
D’abord pour des raisons économiques. Il était légitime qu’Arcad récolte les fruits de ce qu’il a semé depuis maintenant 7ans. Nous avons été parmi les premiers à pousser cet environnement par conviction. Puisqu’IBM nous a offert la possibilité de le considérer comme partie intégrante de notre offre, il est cohérent qu’il soit embarqué par défaut.
Ensuite, pour pouvoir fournir un service maximal autour de cette combinaison Arcad / RDi. Que ce soit en terme de compatibilité de versions, de support que de formation. Nous avons entre autre élaboré avec nos partenaires, des programmes de formation spécifiques. Nos relations étroites avec l’équipe de Toronto en charge de cet environnement nous permettront d’avoir une oreille attentive aux besoins d’évolutions recueillies chez nos clients. Par ailleurs, nous sommes les garants du bon fonctionnement permanent du couple Arcad / Rdi.
Enfin, parce que le positionnement dans les développements AS/400 a toujours été d’offrir le maximum d’aides en tous genres dans les tâches quotidiennes des développeurs. RDi fait partie intégrante de cette démarche. Les solutions Arcad et RDi sont littéralement fusionnées pour fournir un environnement de développement moderne, productif et structuré.

Site 400 : Où en sommes-nous des outils de développement sur System i ?

Cela fait pas mal de temps que les outils natifs SEU, PDM n’évoluent plus. Tous les investissements d’IBM se sont portés sur Wdsc puis Rdi. Grâce à RDi, IBM fournit un environnement moderne, à même de satisfaire les jeunes générations de développeurs et, par là même, d’attirer de jeunes recrues. C’est la condition sine qua non de pérennité des développements sur la plateforme. RDi est également un outil fort de convergence des cultures. La plupart des entreprises développant en Java ou PHP l’ont déjà adopté. Elles disposent ainsi d’une environnement commun à tous les développeurs.
Ces outils ajoutent de la productivité dans le temps. Certes, il y a une période d’adaptation et de nombreux développeurs continuent à mixer l’utilisation de l’ancien et du nouvel environnement. Mais de nombreuses fonctionnalités présentes n’existent pas dans les outils natifs (cf ci-après). Avec le temps, le fossé s’élargira de plus en plus.

Site 400 : Quels sont selon vous les arguments qui amèneront des clients à passer de WDSC à RDi ?

Passer de WDSC à RDi n’est pas vraiment le problème dans la mesure où il s’agit à la base du même environnement. Les différences principales entre les deux sont la présence d’un designer d’écrans intégré, remplaçant officiel de SDA. Le produit est en outre beaucoup moins lourd à installer et requiert moins de CPU pour tourner. Au passage, il a cependant perdu sa capacité à maintenir du code Java. Les développeurs Java devront donc choisir entre Eclipse et RAD (Rational Application Developer) pour remplacer Wdsc.
A noter également que les utilisateurs n’auront pas bien le choix puisque le support de Wdsc prendra fin officiellement au 30 Avril. Passer des outils 5250 à RDi requiert plus d’arguments. Les développeurs nous opposent souvent le fait qu’étant très habitués aux outils 5250, ils perdent du temps dans ce nouvel environnement. Certes, la familiarisation de l’environnement entraîne forcément une perte de productivité temporaire. Mais les gains sont également au rendez-vous. De nombreuses fonctionnalités apportent un net gain d’efficacité. Citons par exemple l’affichage du code source sur 50 lignes et plus, la possibilité de maintenir simultanément plusieurs parties d’un même code source, un comparateur de sources avec colorisation des lignes, les résultats de compilation intégrés dans le source, un débogueur capable de prendre en charge de manière dynamique n’importe quel job (Interactif, batch, Java, Triggers), etc, etc. La liste est longue. Ces arguments techniques sont très concrets.

Site 400 : Comment ressentez-vous le marché actuellement et considérez-vous que WDSC a convaincu vos clients ?

Oui, nos clients qui ont franchi le pas sont parfaitement convaincus et nous comptons tout de même plus de 1 000 licences déployées. Les équipes qui ont pris le parti d’adopter WDSC ne reviendraient certainement pas en arrière.
Cela ne représente cependant qu’une partie de la clientèle. Il reste encore du chemin pour convaincre les autres. L’arrivée de RDi devrait y contribuer. Les utilisateurs sont à présent convaincus d’une chose, c’est qu’un jour ou l’autre ils devront franchir le cap.

Site 400 : Comment expliquez-vous que WDSC ait pu, comme l'ILE d'ailleurs, ne pénétrer le marché que fort récemment ?

Parce qu’il n’y a pas de communauté d’utilisateurs forte dans notre pays, qui suit et adopte toutes les évolutions technologiques de la plateforme. Certains de nos clients sont toujours à la pointe, mais ils sont loin d’être une majorité. Il y a à la fois un manque d’intérêt et un manque d’information. De nombreux développeurs n’ont pas bien perçus l’intérêt de ces changements ou ne savent pas les « vendre » à leur hiérarchie. Ils manquent d’information et de formation. J’en profite pour saluer ici les initiatives de Site400 qui contribue à combattre cette situation.
Avec le temps, les choses évoluent positivement et de nombreuses entreprises qui ne remettent pas en cause la plateforme sur le long terme sont maintenant prêtes à franchir ce cap. Wdsc et maintenant RDi, L’ILE dans un autre registre, sont les deux éléments de l’avenir des développements sur la plateforme AS/400. Il devient urgent d’y investir du temps.
Site 400 : Quels sont vos objectifs 2010 dans ce domaine ?
Convertir au moins 300 des 1 000 utilisateurs que nous avons déjà, mais surtout convertir ceux qui n’ont pas franchi le cap de Wdsc en leur disant : « pensez aux générations futures ! Si vous voulez avoir l’espoir d’attirer de jeunes développeurs, ne leur faites pas l’affront de leur imposer SEU ».

Site 400 : Comment vos propres logiciels vont-ils fonctionner avec Rdi ?

Arcad a développé des plug-ins autour de RDi. Elle propose toute une batterie d’outils venant enrichir cet environnement :
· Des références croisées, à la fois entre composants AS/400, mais aussi entre composants PC et composants AS/400,
· Des options de recompilations automatiques de masse,
· Une gestion d’environnements et de versions,
· Une gestion de scenarios de tests,
· Des outils de documentation d’application.
Sans oublier le seul émulateur du marché fonctionnant directement dans RDi et qui est accessible gratuitement depuis notre site web. A ce jour, nous comptons déjà plus de 2 500 utilisateurs dans le monde.
Info supplémentaire : RDi est mort, vive RD for Power. Ce n’est pas la première fois qu’un produit est rebaptisé alors même que son adoption par la clientèle est à peine enclenchée. Ce sera donc le cas pour RDi qui, depuis le 9 Février, s’appelle officiellement dans sa nouvelle version RD for Power. La différence notoire, c’est que cet environnement est commun au monde AS/400 et au monde Unix. Cela ne devrait pas forcément concerner beaucoup de clients…
Ainsi, après la banalisation du Hardware, c’est maintenant au tour des outils de développement d’être complètement banalisés entre les mondes AS/400 et Unix. Heureusement qu’il n’y a pas banalisation du système d’exploitation car dans ce domaine la supériorité technologique de l’OS/400 reste incontestable.

A noter qu’un événement important se déroulera le 26 Mars prochain dans les locaux d’IBM à Bois Colombes. Philippe Bourgeois fera une présentation complète de RD for Power et ARCAD présentera sa gamme d’outils autour de cet environnement. Pour s’inscrire, il suffit d’aller sur le site d’Arcad software en cliquant ici.

Gros plan technique, Nathanael BONNET( GAIA ) :   

Il parait évident de constater que l'arrivée de RDi change véritablement les choses. WDSC ne donnait pas entière satisfaction, tant pour le développement Java que pour le développement System i en raison de lourdeurs et d'un manque de performance.

Les développements Java étaient donc réalisés par le passé sous Eclipse, et les développements AS/400 vie SEU/PDM et occasionnellement WDSC.

La plus-value du produit concernait davantage les développements ILE que les développements traditionnels.

L'arrivée de RDi a changé la donne : certes il ne permet pas de faire du Java (en dehors de la version SOA dont le coût la limite aux seuls développeurs Java) ; mais il est rapide ! Le gain de performance permet d'ouvrir un membre source sans avoir à attendre plus que quelques secondes et de nombreuses fonctionnalités annexes qui font la force de l'outil sont passées en mode asynchrone.

Par exemple, l'option la plus utilisée à notre sens : la vue Structure d'un source, qui procure une vision arborescente de votre programme, le tout en lien avec le source. Le calcul de ces informations passe de plusieurs minutes avec WDSC (avec attente) contre quelques secondes en tache de fond avec RDi. Par principe, cela restera toujours plus lent qu'avec SEU, mais cet écart de performance est comblé par de grandes avancées en terme d'interface : la vue Structure déjà évoquée, le fait de pouvoir ouvrir en simultanée plusieurs membres sources, de faire des copier/coller façon "windows" ; mais également, une interface qui favorise réellement la lisibilité du code source : la coloration syntaxique des sources, l'affichage des messages de compilation dans le code source. Cela parait une révolution dans le microcosme System i, mais IBM n'a fait que se mettre à niveau des IDE actuels.

RDi m'apparaît désormais incontournable au niveau d'ILE, qui nécessite souvent de travailler en parallèle sur plusieurs membres source.

Les principaux obstacles à l'utilisation de RDi que l'on peut rencontrer au niveau des services étude, sont :

- une résistance naturelle au changement que l'on peut trouver en toute personne. Il s'agit d'une remise en question de l'ensemble des habitudes de développement, et pas uniquement d'utiliser un nouvel éditeur de source.

Il faut donc faire preuve à la fois de persévérance individuelle afin d'adopter de nouvelles habitudes, mais également de compréhension lorsque l'on travaille en équipe : le rythme de prise en main de l'outil par chacun n'est pas équivalent.

- un vrai investissement : l'outil est hautement personnalisable, via les actions utilisateurs (équivalent des options définies par l'utilisateur de PDM), mais aussi par les commandes paramétrables. Le fait qu'il soit très personnalisable, et que le programmeur puisse organiser lui-même sa vision des sources (via les filtres) fait qu'il peut y avoir comme conséquence un certain manque de repère. Le développeur ne sera plus guidé comme dans PDM par la suite bibliothèque - fichier -> membre. Il devra s'inventer lui-même son classement. C'est une liberté qui est nouvelle sur System i, et qui doit être prise en compte.

- un changement de mentalité par rapport à l'outil également : c'est un produit windows qui pilote maintenant les développements, c'est-à-dire un produit que l'on doit mettre à jour, qui a des bugs (nombreux pour WDSC), des procédures de mises à jour à planifier et centraliser lorsque vous possédez de nombreux utilisateurs.


Il est par ailleurs impossible à l'heure actuelle d'utiliser uniquement RDi, l'ensemble des produits de développements natifs n'ayant pas d'équivalent dans l'environnement RDi : SDA est toujours en Technlogy Preview même s'il semble stabilisé, RLU ne dispose d'aucun remplaçant. Il sera intéressant de suivre l'arrivée prochaine de RDPS qui semble combler ce manque.

Il est également impossible e visualiser un spoule (sauf à adjoindre le plugin de softlanding) etc ...

Enfin, un émulateur 5250 reste indispensable pour le développeur, qui doit souvent en préalable à ses développements, utiliser l'application existante pour analyser sa modification. Et également pour des besoins de tests.

Ces allers/retours constituent le plus gros problème de ressenti de l'outil actuellement. Toutefois, il faut bien distinguer l'activité de développement des autres activités (test par exemple). Et RDi se situe bien uniquement au niveau du développement.


A noter que le nombre important de plugins disponibles pour Eclipse permet d'ajouter des fonctionnalités plugin, principalement pour SQL ( Souvent Quantum DB).

En résumé, il faut accepter une baisse de productivité durant la phase de migration, élément classique de toute transition.

Les vrais gains de productivité se situent au niveau de la maintenance corrective ou évolutive.

Après 3 semaines d'utilisation (temps de maîtrise du logiciel), on peut facilement gagner 20 % de production sur la phase de réalisation.


Le point de vu Chef de Projet


« Lorsque l’on est confronté à un nouveau logiciel, on passe obligatoirement par des phases plus ou moins difficiles éventuellement accentuées par les conditions dans lesquelles ce passage se réalise (disponibilité, formation, etc…).

Le passage de PDM a RDi n’échappe pas à ces règles ne serait-ce que par le changement imposé par l’ergonomie de l’éditeur RDi par rapport aux écrans 5250. Il faut se familiariser avec le vocabulaire nouveau et apprendre à naviguer dans RDi aux travers des perspectives et des vues. Ainsi retrouver dans RDi des fonctionnalités appelées sur un écran 5250 de façon automatique n’est pas forcément immédiat.

Ensuite, il faut mémoriser toutes ces informations et assimiler leur fonctionnement pour une utilisation ultérieure rapide (plus particulièrement pour les équipes de développement qui travailleront en permanence dans RDI) ou simple (plus particulièrement pour les Chefs de Projet dont le niveau technique est plutôt transversal).

Pour un Chef de Projet, dans RDi, certains paramétrages ou filtres personnalisés qui viennent s’ajouter aux possibilités proposées en standard surchargent les vues et compliquent leur lisibilité.

En revanche, d’un point de vue Chef de Projet, RDI doit apporter au Equipes de développement des aspects positifs tels que :

- l’affichage multiple des sources en remplacement de l’ouverture multiple de sessions 5250 ;
- l’accès au gestionnaire de développement bibliothèques/objets/membres par un simple « clic » dans l’arborescence proposée.

De prime abord, RDi offre la possibilité d’accéder à des informations plus simplement que dans un contexte 5250 parmi celles avec lesquelles on est le moins familiarisées (fonction de gestion des travaux par exemple pour les Equipes Etudes et fonction « PDM » pour les Equipes Exploitation par exemple)

A noter également l’efficacité de la couche RDi dont on ne ressent pas l’impact par rapport une gestion directe sur un écran 5250. »