Réussir le passage à l’IT en mode service

A lire sur: http://connect.emc2.fr/reussir-le-passage-a-lit-en-mode-service/

Ajouté le 13 janvier 2014 à 23 h 46 min

Le passage d’un mode traditionnel de fourniture de l’IT à un mode service, avec la facturation correspondante aux métiers, peut se faire sans le Cloud. Mais ce dernier constitue une opportunité opérationnelle susceptible de faciliter cette transformation.

Le passage de la fourniture traditionnelle de l’IT à un mode service est une priorité pour les entreprises, très importante, sinon critique pour 70 % d’entre elles dans la région EMEA, selon une récente étude IDC réalisée pour EMC et VMware. A la clé, 47 % des DSI sondées dans le monde entier, pour cette étude, y voient la perspective d’économies, mais aussi, à 43 %, celle d’une meilleure satisfaction des utilisateurs finaux. Côté métiers, 48 % des sondés attendent un meilleur alignement de l’IT sur leurs besoins, et 45 % une plus grande efficacité.

Mais l’une des principales difficultés tient à la définition de l’approche, celle d’un catalogue de services et d’une tarification. Eric Chicha, Directeur Global Services Senior d’EMC France, explique que le passage au Cloud, entièrement ou partiellement, en interne, en public ou en mode hybride, constitue là une opportunité : « c’est une facilité opérationnelle qui permet d’optimiser les coûts et de rationaliser une informatique traditionnelle, pour passer à un IT délivré et facturé comme un service. »

Analyser le patrimoine applicatif

Là, la première étape constitue à identifier les éléments du patrimoine applicatif à faire migrer en mode Cloud : « une vision claire des applications et de leurs dépendances à d’autres serveurs ou composants est essentielle. » Ce qui requiert une analyse non pas statique mais dynamique du patrimoine : « il est très difficile de découvrir que certaines applications peuvent appeler d’autres composants par la seule analyse des exécutifs résidant sur les serveurs. D’où le besoin de suivre l’exécution des applications pour observer les liens entre les architectures physiques d’exécution. »

Et d’illustrer par l’exemple : « l’un de nos clients s’est inscrit dans une trajectoire de virtualisation de ses 400 applications, réparties sur 1 200 serveurs physiques. Un volume suffisant pour qu’il soit humainement difficile d’obtenir une vision claire de la manière dont ces applications s’exécutent sur les serveurs. » L’étude dynamique de l’environnement a duré trois mois, afin de tenir compte des traitements part lots à périodicité élevée, en s’appuyant sur la solution Adaptivity.

Hélas, relève Eric Chicha, « beaucoup d’entreprises se lancent ne serait-ce que dans une architecture virtualisée sans avoir nécessairement le réflexe de faire cette analyse, » essentielle pour définir les priorités et identifier les applications qui, pour certaines, n’ont pas de vocation économique à être virtualisées.

Cette analyse est aussi indispensable que la définition de la plateforme, avec l’architecture cible et la pile technologique sur laquelle elle s’appuiera, avant de passer à la virtualisation, paquet par paquet, tout en précisant les procédures d’exploitation et en assurant la formation des personnels, depuis l’exploitation jusqu’au développement en passant par l’outillage.

Définir un catalogue de services

Le second volet, à conduire en parallèle, touche à la constitution d’un catalogue de services. En commençant par le plus bas niveau : « le provisionnement d’une machine virtuelle capable d’exécuter différentes charges, par exemple, » explique Eric Chicha. Et là, un conseil : « inutile de chercher à réinventer ce qui existe déjà. AWS est un modèle pour toutes les DSI qui veulent aller vers l’IT en mode service. » Cela ne signifie pas que suivre ce modèle soit trivial, ni qu’il corresponde complètement aux exigences de métiers et de services de la DSI : « l’économie des directions informatiques est généralement basée sur un partage de coûts variables. Or les fournisseurs externes facturent suivant un niveau de service. La difficulté consiste donc à offrir un service lisible en comparaison de concurrents externes tels qu’AWS, à un prix fixe. » Un véritable tour de force. D’autant plus que l’infrastructure interne est susceptible de fournir des services qui ne seront pas tous consommés. Un défi auquel sont confrontés les fournisseurs de services Cloud public, mais en bénéficiant d’un levier d’échelle.

Mais l’expérience peut s’avérer utile : « la problématique est bien connue des utilisateurs de mainframes, habitués à la planification de la capacité et au partage des coûts. » En outre, certains clients d’EMC choisissent d’y déporter leurs coûts fixes, par exemple en achetant des capacités de sauvegarde externe… en mode service : « il peut s’agir de capacité seulement, ou du service complet. »

La question des développements

Eric Chicha tient enfin à insister sur la question clé, mais pas forcément toujours identifiée, des développements : « de plus en plus de clients prennent des ressources Cloud pour les développements et la qualification, avec l’avantage de la flexibilité. » Ici, les environnements utilisés dans ce cadre ne sont pas, par construction, les mêmes que ceux utilisés pour la production. « D’où le concept de DevOps, qui permet d’aligner ces environnements et renforce ainsi la valeur ajoutée de la virtualisation. Toute modification de l’environnement de production sera de fait répercutée immédiatement sur ceux de développement et de qualification. » Une approche qui fluidifie le cycle de vie des applications mais qui a aussi ses limites : « dans ce cas-là, on ne peut plus s’appuyer sur des fournisseurs de cloud externes, à moins que leur infrastructure ne soit totalement alignée avec celle dont dispose la DSI en interne. »