John Michelsen, CTO de CA : "le SaaS nous a rendu responsables du développement de nos logiciels"

John Michelsen, le CTO de CA Technologies, lors de CA World.

Lors des différents Keynotes, CA a beaucoup parlé du nouveau modèle Devops et de l’accent mis par la société sur le rapprochement entre développements et exploitation. Ou en êtes-vous de ce rapprochement et comment cela se traduit-il au niveau produits ?

John Michelsen: En fait nous nous appliquons à nous-mêmes le modèle Devops et nous avons s fusionné nos équipes internes d'exploitation et de développement. Au niveau produits, ce ne sont pas moins de 3 produits qui nous permettent d’adresser cette tendance.  Il y a tout d’abord CA LISA Service virtualisation [modélisation et simulation d’applications pour optimiser le développement et le test], CA LISA Release Automation [ pour l’automatisation des changements de configurations entre le développement, la préproduction et la production] et CA LISA Pathfinder [capture de données depuis des environnements de production afin de les réutiliser pour bâtir des services virtuels, des suites de tests…]. Et on peut même ajouter un 4 ^e produit si l’on inclut les solutions de service delivery en Cloud.

AppLogic ne figure pas dans cette liste, alors qu’il pourrait y avoir sa place…

J.M.: Applogic est un composant d’infrastructure et il est sa propre plate-forme. Il est d'ailleurs utilisé à cet effet par de multiples entreprises et services providers comme RackSpace ou Bull. Cela créerait de la confusion chez les clients si nous venions à lier nos outils de livraisons d’applications à une plate-forme spécifique. Les outils de développement doivent supporter toutes les plates-formes du marché et pas seulement la nôtre. Donc nous maintenons la séparation entre les lignes de produits pour que notre message ne soit pas brouillé pour nos clients.

Une intégration aurait pourtant permis d’accélérer le déploiement des applications ?

J.M.: En fait il y a eu beaucoup de débats en interne. C’est un choix difficile pour nous, mais cela nous permet de réussir avec nos outils Devops même si AppLogic n’est pas choisi par le client et vice-versa. Lier les deux produits aurait un risque CA LISA est bien adapté pour simuler des environnements qui sont sous le contrôle de l’entreprise. 

Qu’en est-il des éléments qui ne sont pas maîtrisés en interne comme un service de paiement en ligne ou une API Cloud ?

J.M.: En fait LISA est plutôt bon à ce jeu aussi. Et le mot magique est contrôle. Lorsqu’une équipe de développeurs n’a pas le contrôle d’un élément cela la ralentit. Il faut donc lui donner la maîtrise de l’ensemble des éléments qui composent une application y compris, par exemple, des API tierces. Ce que font nos clients lorsqu’ils construisent un environnement est de choisir parmi notre catalogue de simulation de services virtuels. Et c’est à partir de ces composants simulés qu’ils reproduisent leur environnement.

Lorsque CA a développé Mainframe Chorus, vous avez dû développer une interface graphique web complète. Lors de votre Keynote vous avez parlé du développement d’une plate-forme commune pour vos applications SaaS. Avez-vous l’intention de faire converger les travaux d’interface réalisés pour Mainframe Chorus avec ceux menés dans le cadre du développement de votre plate-forme SaaS?

J.M.: Ce travail vient tout juste de commencer. Notre groupe mainframe a construit l’interface Chorus et le groupe distribué a développé l’interface graphique pour les applications SaaS. Je suis désormais en charge des deux organisations et donc en charge de veiller à la convergence des interfaces utilisateurs des produits Mainframe et SaaS et plus encore. Développer des éléments d’interface convergents sera assez rapide, c’est en fait l’histoire de quelques mois. Ce qui sera plus long est l’adoption de ces nouveaux éléments dans les applications, ce qui va prendre des années. La plupart des produits auront migré d’ici 3 à 4 ans. Il faut une génération de logiciel pour modifier en profondeur l’interface ou le back-end d’une application.

Quels sont vos plus gros challenges pour la migration de vos applications en mode SaaS?

J.M.: Le plus gros challenge pour passer au SaaS est que les équipes de développement doivent désormais se préoccuper de l’exploitation de leurs logiciels. Exemple type l’architecte en chef de Siemens, qui est l’un de nos clients, était présent lors de ma session hier et il a posé cette question : pouvez vous faire en sorte que je n’ai pas à redémarrer mes serveurs chaque fois que vous m’envoyez une mise-à-jour, car j’ai des contraintes de disponibilité de 99,999%.

Les développeurs ne se préoccupaient pas de cela jusqu’alors. Ils écrivaient le logiciels et disaient et alors: "il faut rebooter… c’est facile de rebooter". Le problème était que les développeurs ne devaient pas exploiter leurs propres logiciels. Avec le SaaS, CA doit désormais exploiter ses propres logiciels et il nous avons dû apprendre toutes ces choses, comme la sauvegarde, la disponibilité, l’élasticité, le stockage des données... Jusqu’alors nous n’avions pas vraiment à nous en occuper. C’était nos clients qui exploitaient les infrastructures pour faire tourner nos logiciels. Le SaaS nous a rendus responsables de bien plus que le développement du code et a au passage soulagé les clients du poids de l’exploitation. C’est une bonne chose, mais c’est aussi un challenge.

A ce propos, les applications SaaS doivent souvent être exploitées sur des infrastructures dont l’échelle n’est pas comparable à celle des infrastructures d’entreprises. Par exemple, Là où une base de données traditionnelle suffisait pour un déploiement en entreprise, il faut désormais des bases de données en cluster, des bases en mémoire, des bases no SQL… Est-ce aussi vrai pour CA et quel impact cela a-t-il sur la façon dont vous concevez vos logiciels ? et Cela peut-il avoir un impact à terme sur les configurations supportées pour les versions non SaaS de vos applications ?

J.M.: Six de nos applications tournent déjà sur notre plate-forme SaaS. Nous avons déjà du revoir notre infrastructure pour les raisons que vous évoquez. Nous avons déjà dû éclater le stockage des données de certaines de nos applications, qui historiquement se faisait sur une base de données Oracle, entre des bases no SQL comme Cassandra et Oracle, car ces nouvelles bases de données géraient les données mieux qu’Oracle.

De plus, on ne pouvait de toute façon plus conserver toutes nos données dans Oracle, car il ne tenait plus la charge. Car nous avions par exemple l’habitude de jeter 95% des données que nous collections dans des produits comme APM, puisque tout ce dont nous avions besoin était d’offrir un dashboard sur 5 mn. Mais maintenant avec la capacité de traiter les Big Data, on se rend compte qu’il y a sans doute de la valeur dans ces données donc on doit les conserver afin de fournir de meilleures informations analytiques. On gère désormais des péta-octets de données.

CA a la réputation d’acheter beaucoup de sociétés mais aussi d’échouer à les intégrer. Il semble que la politique de la société évolue, votre CEO ayant annoncé l’intention de CA de se concentrer sur le développement interne de logiciels. Quel impact cela aura-t-il sur votre politique d’acquisition ?

J.M.: Mike [Michael Grégoire, le nouveau CEO venu en décembre de Taleo, N.D.L.R.] ne dit pas que CA n’achètera plus de société. Il dit qu’il ne veut pas tout acheter. Il n'est pas injuste de dire que pendant plusieurs années, CA a oublié d’inventer et de créer ses propres technologies et n’a basé sa capacité d'innovation que sur des acquisitions. C’est ce que nous nous efforçons de changer. Mike dit à tout le monde en interne que les acquisitions ne sont pas un moyen de réparer des stratégies défaillantes. Il faut que nous développions nous-même ce qui nous est nécessaire. Et ci quelqu’un en externe arrive avec une idée que nous n’avons pas eue et qui nous semble intéressante alors oui nous pourrons envisager une acquisition.

Mais il est désormais hors de question de corriger des erreurs stratégiques par des acquisitions. C’est à mon sens une approche intelligente. Il y a aussi les technologies que nous estimons intéressantes d’avoir dans notre portefeuille et pour lesquelles nous ne pouvons nous différencier. Dans ce cas les approches de partenariats comme avec SAP sur le MDM sont parfaites. SAP avait la meilleure solution et nous avons fait alliance avec eux. Pourquoi développer une solution MDM alors qu’un partenaire est prêt à travailler avec nous en OEM.