Le
cloud peut-il offrir une perspective de développement ou de
redéploiement des systèmes applicatifs « mainframe centric »
? - Y
a t-il un modèle économique viable pour la croissance et le
renouveau des systèmes existants – le « legacy »
les Systèmes applicatifs « mainframe centric » données , traitement batch et temps réel, volumétrie & capital en a/h
Les
grands groupes comme les entreprises moyennes ont construit leur
informatique dans les années 70/80 à une époque où les
technologies et les langages étaient encore peu développés. Coté
technologies les mainframes (essentiellement IBM System Z
aujourd'hui) avec des systèmes temps réel comme CICS et IMS, un
gros volume de batchs dont les chaînes de traitement occupaient la
nuit, lorsque les systèmes temps réel ne fonctionnaient pas en
24/24.
L'architecture
de ces Systèmes était alors entièrement résidente dans le
mainframe qui hébergeait les données, la business logic, la logique
de présentation et l'interface de présentation qui était
interprétée par les « green screen » ces terminaux
passif microcodés.
Depuis cette
époque le poste de travail s'est développé pour mettre toute
l'intelligence métier et sa présentation coté utilisateur. Le
terminal passif a disparu au profit des émulations. Les applications
distribuées se sont répandues comme une trainée de poudre à
l'époque du client/serveur, avec force redondance des données
d'entreprise sur les postes de travail et dans des serveurs
intermédiaires.
Les
AGLs de quatrième génération (NSDK, Uniface, PowerBuilder,
Access... ) les ERP (PeopleSoft, SAP..) ont conquis le terrain du
poste de travail, crée une nouvelle logique métier avec leurs
données métier. Du coup les données d'entreprise et les données
métiers (qu'on a souvent affublé du vocable « modèle métier
vs entreprise » ) ont nécessité une duplication et surtout
une synchronisation.
Il
en résulte une redondance importante, une complexité
pour le concepteur qui doit maintenir des langages des technologies
et des compétences séparées ainsi que pour l'exploitant qui doit
maintenir une cohérence globale. Au final, l'entreprise est donc
confrontée à une inertie dans les évolutions et des charges
croissantes pour maintenir cet édifice – sans compter un risque de
fragilité.
Depuis
2008, les cabinets conseils en architecture ont donc entonné une
nouvelle ode à la transformation, à la modernisation, à la
simplification : Plus facile à dire qu'à faire...
En
effet le capital travail investi dans ces legacy – mainframe comme
distribué – le nombre d'applications, de services métier ainsi
que la diversité des situations deviennent tels que la remise en
chantier de tout ou partie devient difficile et coûteuse alors que
la valeur ajoutée pour les métiers est nulle. Il n'y a plus
personne pour financer des investissements de transformation et comme
la rupture technologique et l'obsolescence des développements
d'application n'est jamais prise en compte dans les coûts
d'évolution. Il n'y a pas comme à La Defense une pression foncière
et un renouvellement constant de la demande due à la pénurie pour
apporter une capacité de financement de la démolition /
reconstruction.
Par
ailleurs, les agents économiques ont besoin de continuité.
Déménager coûte bien moins cher que changer de système
d'information. Il n'y a pas de chose plus difficile à faire en
informatique que de tuer un système applicatif. Le renouvellement
des technologies ne profite qu'à ceux qui les vendent. Les clients
ne savent pas se débarrasser des vieilles technologies car ils y ont
investi du savoir faire qu'ils ne peuvent plus jeter.
Pourtant,
demandez à un CEO ou un CTO de ces grands groupes comment ils voient
l'avenir. Ils vous répondront que les nouveaux modèles de
gouvernance passent par une rationalisation, une simplification et
une suppression des redondances à laquelle le cloud pourrait
apporter des solutions.
Quel
est le modèle ? Déplacer le tas de poussières dans le nuage –
ou re-développer les process métier dans le cloud ? Combien ça
coûte et qu'est-ce que cela m'apporte ?
Il
existe deux types d'offres dans le cloud : Plateform as a
service ou Paas, et Service as a software ou Saas.
Dans
le Paas, l'entreprise continue à maintenir ses applications mais
sous traite toutes les autres opérations une fois qu'il a livré ses
composants. Dans le Saas toutes les étapes de la conception jusqu'à
l'exploitation sont sous traitées et le service est vendu sous forme
d'abonnement.
Développer
en Saas des applications d'entreprise n'est pas forcément simple car
les offres de Saas sont restreintes au CRM, la RH ou à des fonctions
d'infrastructure comme le mail ou la vidéo-conférence. Elles ne
sont pas adaptées au cœur de métier .
Par
ailleurs même si c'était le cas, sans renouveau pour les métiers,
le coût d'un redéveloppement comme nous l'avons vu est
incroyablement lourd. Le Saas n'a donc aucun intérêt pour une
simple migration technique.
Reste
donc le Paas : en temps que fournisseur de services mutualisés
le fournisseur peut abaisser les coûts d'infrastructure, mieux gérer
les compétences et maintenir une expertise de haut niveau dans le
maintien des socles techniques, la surveillance, la non régression
etc... Il y a donc un potentiellement un intérêt financier et pour
la gouvernance
Comment passer d'un modèle où tout est internalisé à un modèle où tout est fourni en Saas ?
Il
y a bien sur des résistances : Coté métier, on ne faisait pas
toujours confiance aux informaticiens maison, on peut douter que la
confiance en un acteur externe soit immédiate. Coté IT, on va
lutter pour sa survie. L'arrivée des nouveaux modèles vient après
les premières expériences d'externalisation, et elles n'ont pas
toujours convaincu de leur efficacité.
Mais
cette fois on ne touche pas forcément le développement, mais tout
le reste.
Pour
que cela réussisse il faut un acteur qui présente toutes les
garanties de continuité, mais surtout qui ait à la fois une
expérience éprouvée dans l'environnement externalisé ainsi qu'une
approche industrielle de l'intégration, du cycle de mise en
production et de toute la chaîne de services, support, gestion des
incidents et des demandes, surveillance, pilotage etc...
Et
pour que cela ait du sens, il faut repenser toute la chaîne de
développement qui porte bien souvent la principale responsabilité
dans la qualité de service global (les meilleures pratiques en
développement, tests d'intégration, tests de charge
éventuellement, et correction des livrables avant mise en
production)
Pour
que ça marche, il faut confier l'entière responsabilité des toutes
les étapes à un tiers de confiance et le juger sur la qualité
finale. C 'est à dire une TMA sur un périmètre et un service
de Paas pour l'intégration, la recette, la production. Le client
gère le contrat, vérifie la qualité de service et le cycle
d'évolution des demandes nouvelles et des incidents.
Quels sont les points sensibles du Paas ?
Lorsque
l'application externalisée en Paas est indépendante des systèmes
existants en interne, le risque est faible car il n'y a pas de
problématique de synchronisation. Mais lorsque les bases de données
ou le système transactionnel du back office doivent être cohérents
on a alors besoin de synchroniser des données et des traitements en
direct ou en différé.
Dans
tous les cas, la technologie doit garantir la délivrance et la bonne
intégration des flux.
Synchroniser
en différé fait appel à un ESB , un EAI ou de façon plus
rudimentaire à un automate d'échange de fichiers comme CFT. Les
données échangées sont intégrées par un identifiant de médiateur
et non sous l'identité du producteur de l'événement (un
gestionnaire back office, un commercial ..)
Mais
bien souvent pour donner une image cohérente des données
d'entreprise à tous les acteurs à un instant donné, il faut que
les données du Paas et de l'entreprise soient synchrones, sinon même
dans la même unité logique de traitement.1
Bien
sûr toutes les applications n'ont pas besoin d'un niveau de
synchronisation sans faille. Et si elles ne l'avaient pas en interne,
il n'y a pas de raisons pour que le Paas change le niveau
d'intégration. Mais dans le monde financier, et même dans un
système logistique la perte d'information peut être dramatique.
D'autre
part, lorsque des systèmes travaillent en parallèle sur le même
LAN, le temps de latence est très faible. Avec le Paas les temps de
latence vont allonger considérablement2
les transactions comportant un grand nombre d'échanges. Il faut donc
une infrastructure performante, rapide et qui donnent les mêmes
facultés de garantie de délivrance qu'en local alors qu'en Paas on
est sur un WAN planétaire.
Quelles sont les technologies qui peuvent dès lors apporter le même niveau de sécurité ?
vous cherchez un job ? allez voir jooble-fr.com
Suite prochainement....
1LUW
Logical Unit of Work est assurée par le two phase commit qui
garanti une mise à jour synchronisée de toutes les données
placées dans la même « transaction »
2Entre
un facteur 10 et un facteur 100
