Entretien avec John Goodson, CTO de Progress

« OpenEdge et Pacific ont une fondation commune »

A l’occasion d’Exchange 2014, la rédaction s’est entretenue avec John Goodson, CTO du groupe, sur les interactions entre OpenEdge et la plate-forme Pacific, sur les évolutions d’ABL et sur les différences entre les versions 11.4 et 11.5 d’OpenEdge.

LeMagIT.fr : Comment s’insère Pacific Application Server for OpenEdge dans votre catalogue produit ?

John Goodson : La façon la plus facile de voir Pacific, car il existe un peu de confusion autour  de cette offre, est de la considérer comme la marque qui entoure nos services cloud. Des éléments d’OpenEdge motorisent nos services cloud. Les deux sont donc très connectés. OpenEdge est certes réservé à nos clients traditionnels, mais nous nous attendons à ce qu’ils évoluent et migrent leurs applications vers le cloud. Et c’est ce qu’ils font avec la technologie Rollbase de notre plate-forme Pacific. Et Rollbase s’appuie sur un serveur d’applications très puissant. [Avec Pacific Application Server for OpenEdge], nous avons développé un nouveau serveur d’application, très scalable et rapide, qui s’exécute en conjonction de Pacific et de Rollbase. Il permet à nos clients existants d’OpenEdge qui veulent développer un cloud privé, ou encore ceux dans un environnement sur site, d’utiliser le même composant. La fondation est la même.

LeMagIT.fr : Il n’était pas possible de migrer aussi facilement vers le cloud ?

J.G : Lorsque vous décidez d’utiliser le cloud, il y des choses que vous devez prendre en compte qu’il n’est pas nécessaire de retenir on-premise. Par exemple, si vous êtes un ISV, et vous déployez votre application auprès d’une dizaine de clients, vous aurez une dizaine d’instances, une par client. Lorsque vous déployez dans le cloud, vous aurez une instance de votre serveur d’applications qui doit être totalement multi-tenant. Les clients stockent leurs données dans une unique base de données, et nous devons nous assurer qu’ils ne peuvent pas voir les données des autres. C’est pareil pour un serveur d’application : nous devons nous assurer que les clients sont protégés via cette approche multi-tenant. Pour résumer, de nombreux changements technologiques sont nécessaires dans ce type d’environnement. Ce que nous avons fait avec Pacific Application Server for OpenEdge et qui aide à adopter ces contraintes de multi-tenant, multi-threat, multi-sessions.

LeMagIT.fr :  Comment allez-vous convaincre votre base installée OpenEdge de migrer vers le cloud ?

J.G : Nous avons aussi beaucoup de clients Pacific qui ne sont pas OpenEdge. Et nous avons également beaucoup de clients OpenEdge qui ont développé des applications satellites au-dessus de leur existant métier mais les ont déployées dans le cloud. Un de nos clients, qui dispose d’un ERP très spécifique, souhaitait également se doter d’un CRM. Il a développé ce CRM avec Rollbase sur Pacific, mais a laissé son ERP sur OpenEdge. Son CRM en revanche exploite la même logique métier que son ERP. Dans ces cas, l’ERP est toujours déployé ainsi, et l’instance est déployée dans un cloud privé. La plupart de nos clients OpenEdge, presque 75%, choisissent le cloud privé, par rapport au cloud public.

LeMagIT.fr :  Ils partagent la même fondation, la même base de données. Comment Progress va-t-il gérer la compatibilité ?

J.G :  Le gros de nos investissements dans nos plates-formes a été injecté dans l’intégration. Nous nous sommes assuré que les produits de notre portefeuille soient bien compatibles. Quelle que soit votre architecture, nous sommes sûrs qu’avec Rollbase, en cloud privé ou public, vous pouvez accéder aux mêmes données métiers stockées dans OpenEdge. Et inversement : utiliser OpenEdge pour accéder aux données d’Rollbase.

LeMagIT.fr :  Comment allez-vous pousser les entreprises à migrer vers OpenEdge 11.4 alors que la version 11.5 n’est pas très loin et propose des améliorations clés comme par exemple l’intégration des règles métiers de Corticon au cœur de la solution ?

J.G : Revenez deux ans en arrière. A cette époque, nous n’avions pas la mobilité, le BPM, Corticon, Rollbase. En même temps, notre base clients est très large et ils ont des besoins différents. Nos clients qui ont des besoins en termes de mobilité n’en ont peut-être pas avec Rollbase. Ils ne souhaitent utiliser que nos produits dédiés à la mobilité. Mais certains peuvent également utiliser les deux. Nous ne souhaitons pas avoir de longs cycles de releases, nous ne voulons pas faire attendre nos clients. Nous avons mis en place un programme agressif qui leur garantit que dans deux ans, nous allons leur fournir toutes ces fonctionnalités : un BPM intégré, Corticon, Rollbase, accès en mode déconnecté pour la partie mobilité… Aujourd’hui, si vous prenez AWS, des releases sont disponibles à un rythme hebdomadaire. Avec la méthodologie agile que nous avons mise en place, nous soutenons le fait que certains de nos clients peuvent  choisir 11.4 et  n’ont pas à migrer vers 11.5. Nous allons supporter les anciennes versions plus longtemps, et leur laisser plus de temps pour choisir la bonne version. Mais si on écoute certains clients, ils veulent migrer rapidement. Mais si vous faites le choix d’intégrer la version 11.4 à partir de 11.1, nous garantissons à ces clients que nous allons supporter plus longuement leur version, comparé à ce que nous faisions auparavant.

Nous pensons que ce sont les nouvelles fonctions qui pousseront les clients à migrer. […] Certains seront forcés d’adopter les technologies que nous proposons [notamment pour moderniser l’expérience de leurs utilisateurs, NDLR]. Nos clients vont saisir les opportunités que nous leur offrons.

LeMagIT.fr :  Les clients doivent donc choisir la version la plus adaptée à leur besoin et leurs exigences technologiques ?

J.G : exactement.

LeMagIT.fr :  Quelles recommandations faites-vous donc ? Quelle version pour quel cas d’usage ?

J.G : 11.5 s’adresse notamment aux entreprises qui cherchent des niveaux élevés de scalabilité, migrer vers un modèle Cloud et attendent de nous une réponse au multi-tenant. Si vous n’en avez pas besoin, il se peut que vous n’ayez pas besoin de migrer vers le 11.5. Mais de considérer la 11.4. Nous avons de nombreux clients avec des bases de données très volumineuses. Leur problème : garantir une activité 24/7 et sauvegarder leur gigantesque base, et cela prend un dizaine d’heures. Ils peuvent commencer à segmenter cette base avec le multi-partitioning de tables de la 11.4. D’autres ont commencé à utiliser nos composants mobilité avec la 11.2, mais ont un besoin en matière de mode déconnecté. Ces clients n’ont pas d’accès Internet permanent, comme ceux qui ont des usines éloignées. 11.4 propose cette option d’accès déconnecté. Cela est vraiment lié aux besoins des clients.

LeMagIT.fr :  Quelles sont les versions d’OpenEdge aujourd’hui les plus courantes ?

J.G : plus de 50% de nos utilisateurs utilisent la version 11 et particulièrement la 11.2. Pour 40%, il s’agit de la 10.2. Une minorité, ce sont des versions antérieures. Une typologie assez courante.

LeMagIT.fr : Existe-t-il un futur pour le langage ABL ?

J.G : Les capacités d’ABL sont très étendues. Je viens de parler à des utilisateurs historiques du langage : l’un dispose de 10 millions de lignes de code ABL, un autre 5 millions et un 3^e , 3,5 millions de lignes de code ABL. Ils ont investi fortement dans le langage pour leur logique métier. En revanche, les développeurs encore étudiants souhaitent davantage travailler sur la programmation orientée objet. Avec OpenEdge et Pacific, nous avons décidé que Javascript était un langage stratégique pour nous, notamment pour nos solutions mobiles.  Si vous utilisez OpenEdge Mobile, c’est du Javascript, les seules compétences dont vous avez besoin ne sont pas liées à ABL, mais à Javascript. C’est pareil pour les autres composants de la plate-forme. Rollbase génère du Javascript.  Nous comptons standardiser autour d’ABL et de Javascript. Mais ce que nombre de personnes ne savent pas, nous avons également doté ABL d’une approche objet. Si vous sortez de l’université et connaissez Java or C# par exemple, vous savez comment fonctionne la programmation objet. Les nouveaux développeurs pourraient ainsi être intéressés par l’approche objet. Cela est autant supporté que l’approche procédurale du langage.

Notre stratégie est de supporter ABL, car il existe d’importantes bases de code, nous allons le faire évoluer et pousser cette orientation objet. Mais nous allons également supporter Javascript et Node.JS.  Nombreux sont ceux qui développent des interfaces utilisateurs à partir d’un front-end Windows, par exemple. Et ils ont des besoins en matière de haute performances. Ils veulent ainsi un middle-tiers Node.JS, car avec sa nature asynchrone, il permet d’avoir une interface ultra-rapide. Nous supportons cela : un client.NET, un middle-tiers en Node.JS et la logique métier en ABL.

LeMagIT.fr : Mais que pensez-vous alors de la qualité du code généralement produit en Javascript ou Node.JS ?

J.G : Il y a deux ans, il n’y avait pas autant de sophistications, dans Javascript, peu apprêté pour les entreprises. Nous avons constaté un engagement fort de la part d’éditeurs pour améliorer les performances. Node.JS en lui-même est une amélioration de Javascript pour proposer des fonctions pour les entreprises.  Cette capacité à proposer l’asynchronisation aux entreprises était nécessaire. La communauté Node.JS a travaillé à faciliter et à accélérer le développement d’applications. Il est désormais un langage de première classe dans notre plate-forme et nous souhaitons donner le choix à nos clients.

LeMagIT.fr : Quelles sont vos ambitions en matière d’intégration continue ?

J.G : Rollbase dispose de fonctions de tests unitaires, ainsi que d’autres permettant de déployer une application très simplement. Mais il reste encore des nombreux pans de l’intégration continue que nous ne supportons pas et pour lesquels nous nous reposons sur des partenaires. Dans les prochaines années, nous allons en intégrer davantage tout en multipliant les partenariats.