hmmm d'après ce que tu dis plus haut, les critères de choix classiques ont été retenus tout de même (coût + iso-fonctionnel) :
- constat d'une perte de compétence et d'un coût élevé pour se la réappropprier, au détriment d'une efficacité à prendre en compte de nouvelles évolutions si j'ai bien compris (réticence à investir sur un système plus forcément très maîtrisé et qui s'est classiquement complexifié au cours du temps ne serait-ce que par la diversité des cas de gestion maîtrisés par un faible nombre d'experts)
- coût non négligeable du système faisant hésiter à s'en séparer mais signant son arrêt de mort dès lors qu'un axe de résorption a réussi à démontrer son efficacité (félicitations pour tes retranscriptions précédentes ayant montré la démarche pour gérer la période transitoire et éviter les régressions tout en accompagnant les évolutions sur la période ; pour moi c'est un très bel exemple de conduite du changement tant du point de vue utilisateurs que du côté organisation des équipes de développement)
- maintien de l'efficacité des mainframes en terme d'exploitation par des procédures de livraisons maîtrisées et prises en compte au titre du projet; je suppose ? Historiquement, c'est le point fort de l'approche mainframe (et le point faible initial des "systèmes ouverts") de prendre en compte l'exploitabilité et la maîtrise des mises à jour dès le début des développements (c'est plus cadré, fruit de l'expérience mainframe qu'il aura fallu 20 ans à récupérer côté systèmes ouverts avec un peu d'ITIL au passage) : clairement entre la gestion des paquets de toute bonne distribution GNU/Linux et les EAR côté Java_EE, c'est tant l'admin système que l'admin applicatif qui sont contents pour la gestion des changements.
Le fourmillement de serveurs est aujourd'hui un peu plus gérable et la virtualisation donne des pistes pour mutualiser sans risque (au prix d'utiliser un marteau piqueur pour enfoncer une punaise mais bon... ça évite au moins l'approvisionnement d'un nième serveur et permet d'utiliser les ressources matérielles au mieux de leur capacité en séparant besoins applicatifs et besoins matériels).
Je suppose que pour l'instant la virtualisation est gardée pour "la prochaine étape" ? (de toute façon des serveurs d'applis ça se mutualise/démutualise facilement quand c'est bien prévu au départ).
[^] # Re: Plateforme
Posté par BAud (site web personnel) . En réponse à la dépêche Outils de transcodage COBOL vers Java du projet NACA publiés sous GPL/LGPL. Évalué à 5.
- constat d'une perte de compétence et d'un coût élevé pour se la réappropprier, au détriment d'une efficacité à prendre en compte de nouvelles évolutions si j'ai bien compris (réticence à investir sur un système plus forcément très maîtrisé et qui s'est classiquement complexifié au cours du temps ne serait-ce que par la diversité des cas de gestion maîtrisés par un faible nombre d'experts)
- coût non négligeable du système faisant hésiter à s'en séparer mais signant son arrêt de mort dès lors qu'un axe de résorption a réussi à démontrer son efficacité (félicitations pour tes retranscriptions précédentes ayant montré la démarche pour gérer la période transitoire et éviter les régressions tout en accompagnant les évolutions sur la période ; pour moi c'est un très bel exemple de conduite du changement tant du point de vue utilisateurs que du côté organisation des équipes de développement)
- maintien de l'efficacité des mainframes en terme d'exploitation par des procédures de livraisons maîtrisées et prises en compte au titre du projet; je suppose ? Historiquement, c'est le point fort de l'approche mainframe (et le point faible initial des "systèmes ouverts") de prendre en compte l'exploitabilité et la maîtrise des mises à jour dès le début des développements (c'est plus cadré, fruit de l'expérience mainframe qu'il aura fallu 20 ans à récupérer côté systèmes ouverts avec un peu d'ITIL au passage) : clairement entre la gestion des paquets de toute bonne distribution GNU/Linux et les EAR côté Java_EE, c'est tant l'admin système que l'admin applicatif qui sont contents pour la gestion des changements.
Le fourmillement de serveurs est aujourd'hui un peu plus gérable et la virtualisation donne des pistes pour mutualiser sans risque (au prix d'utiliser un marteau piqueur pour enfoncer une punaise mais bon... ça évite au moins l'approvisionnement d'un nième serveur et permet d'utiliser les ressources matérielles au mieux de leur capacité en séparant besoins applicatifs et besoins matériels).
Je suppose que pour l'instant la virtualisation est gardée pour "la prochaine étape" ? (de toute façon des serveurs d'applis ça se mutualise/démutualise facilement quand c'est bien prévu au départ).