Articles de la série :
- Partie 1 – Fragmentation
- Partie 2 – Résistance au changement
- Partie 3 – Réorganisations, fusions et acquisitions et migrations
- Partie 4 – Justification et approches
- Partie 5 – Tout relier ensemble
Dans sa série complète de blogues sur la rationalisation des candidatures, l’invité spécial Stephen O’Grady a passé en revue les mérites de la rationalisation des candidatures pour relever les défis de la fragmentation qui affectent de nombreuses organisations. La série perspicace de Stephen a passé en revue l’histoire de la fragmentation des débuts des mainframes à l’ère moderne, les causes courantes de la fragmentation et pourquoi elle peut être si difficile à éradiquer, ainsi que l’importance de corriger la fragmentation ainsi que plusieurs méthodes pour y parvenir.
Plusieurs méthodes de défragmentation et de rationalisation des applications sont disséminées tout au long de la série de blogues, incluant des approches telles que les migrations lift-and-shift versus les migrations rationalisées, ainsi que la conteneurisation des applications. Après avoir terminé la série de blogues, nous avons rassemblé nos idées et décidé que résumer toutes les recommandations en un seul billet ferait un joli épilogue. Et comme toujours, nous avons décidé d’aller plus loin en résumant toutes les recommandations disséminées tout au long de la série de blogues de Stephen et en les analysant dans le contexte de diverses stratégies de gestion des risques.
Quelle est la meilleure approche?
Nous commencerons par la question que nous imaginons être au cœur de tout le monde : parmi toutes les recommandations incluses dans la série de blogues, quelle est la meilleure approche?
Comme toujours, la réponse est que ça dépend.
Cela dépend de plusieurs facteurs, tels que le volume et les types d’applications, les technologies internes et les compétences en TI, le niveau actuel de dette technique, l’appétit au risque et la tolérance au risque. Je souligne que, par-dessus tout, le facteur le plus important demeure la volonté des entreprises d’accepter qu’elles ont déjà un problème.
Par exemple, si une organisation a déjà accumulé un niveau d’endettement technique assez élevé, elle peut choisir de régler le problème sur-le-champ. Cependant, si la même organisation a aussi un appétit élevé pour le risque, la décision peut être prise de suivre la voie la plus rapide et de régler le problème plus tard. De plus, si cette même organisation dispose aussi d’une plateforme robuste de virtualisation et de diffusion d’applications, cela peut rendre certaines options, comme la conteneurisation, beaucoup plus faciles que si l’organisation installait tout directement sur les postes de travail des terminaux (c’est-à-dire sans virtualisation).
Peser les options
La série de blogues partage de nombreuses méthodes et approches pour relever le défi de la fragmentation des applications. Certaines de ces méthodes ont bien fonctionné, d’autres ont très mal fonctionné.
Plus haut, j’ai mentionné que l’appétit au risque et la tolérance au risque jouent un rôle dans la détermination des meilleures options pour une organisation. Poursuivons sur cette voie pour organiser les méthodes de gestion de la fragmentation, selon les stratégies particulières de gestion des risques : évitement, tolérance, transfert, atténuation et acceptation.
Évitement du risque
L’évitement des risques vise à empêcher que ce risque survienne dès le départ. Dans un monde idéal, c’est la meilleure stratégie; cependant, des facteurs comme le temps, l’argent et les ressources peuvent ne pas rendre cela faisable. Les stratégies d’évitement des risques tendent – au mieux – à se concentrer sur l’établissement et le respect des processus appropriés (et, dans les pires cas, à ne rien faire pour éviter de faire la mauvaise chose, mais c’est un tout autre débat pour une autre fois); Les principes suivants devraient être inclus comme principes fondamentaux de tels processus :
- Établissez régulièrement des forums métier-TI où les groupes d’affaires peuvent exprimer leurs besoins (évitez d’exprimer des solutions sous forme d’exigences), ainsi que le plan des dirigeants TI pour répondre à ces exigences de manière efficace et à un coût raisonnable. Cela renforce la confiance bidirectionnelle selon laquelle les groupes d’affaires verront leurs besoins satisfaits de manière à maintenir l’architecture informatique et les normes technologiques.
- Établir des normes TI concernant la validité des applications (par exemple, pas plus d’une version en retard sur la version actuelle et avec pour objectif d’être toujours à jour) et une architecture d’application standard comme cadre approuvé dans lequel toutes les applications doivent s’intégrer. L’entreprise devrait adopter cette approche de la monnaie des applications, et les TI d’entreprise doivent avoir le droit d’allouer les coûts de soutien aux groupes d’affaires qui ne se conforment pas.
- Favoriser un sentiment de propriété au sein des groupes pour lesquels le changement est recherché, où les gens ressentent que l’acceptation d’un changement proposé est leur choix, et peut-être même leur idée. En général, les gens comprennent où sont les faiblesses dans leur entreprise et sont désireux de changer, mais ils ont souvent besoin de sentir que leur changement ne peut pas être imposé; Il faut que ça donne l’impression de venir de l’intérieur.
- Associer les rôles et exigences des utilisateurs aux fonctions de l’application; cela nécessite un engagement adéquat entre les utilisateurs du département et les TI corporatifs, afin que les besoins des utilisateurs soient satisfaits et que toutes les fonctionnalités soient connues et comprises par les TI. Ainsi, lorsque de « nouvelles » exigences apparaissent (qui ne sont pas nécessairement nouvelles du tout), l’inventaire complet des exigences et des applications est connu; Notez que cet inventaire devrait également inclure un propriétaire désigné pour chaque demande. Astuce de pro : envisagez d’utiliser un modèle Kano pour capturer/modéliser les besoins d’affaires en organisant en indispensables, satisfaisants et plaisirs. Cela peut donner du contexte aux besoins de l’entreprise et aider à prioriser les décisions.
Transfert des risques
Le transfert de risque vise à transférer le risque à une autre entité, par exemple lors de la décision d’engager une solution SaaS, auquel cas le risque est transféré au fournisseur qui fournit le service. Les stratégies de transfert de risque impliquent généralement une sorte de contrat à l’acte où les responsabilités opérationnelles continues sont gérées par un fournisseur tiers; Voici quelques-unes des solutions les plus populaires :
- Engager une solution SaaS peut être attrayant puisqu’elle transfère toute la responsabilité (et les risques) au fournisseur SaaS pour maintenir ses applications constamment à jour et mises à jour, le fournisseur SaaS soutiendra toujours son application, et la plupart des applications SaaS sont accessibles sur n’importe quel appareil et n’importe quel réseau (c’est-à-dire toujours disponibles). Les défis potentiels incluent l’interopérabilité avec d’autres applications internes, les préoccupations concernant la sécurité/la sensibilité des données, ainsi que des préoccupations potentielles liées à la disponibilité continue de nouvelles fonctionnalités.
- Faire appel à un fournisseur de services gérés (MSP) permet aux organisations de garder leurs propres systèmes en interne tout en transférant toutes les responsabilités opérationnelles (et les risques) au MSP; dans ce cas, toutes les données restent en interne, et le client contrôle la feuille de route pour ses applications TI et son paysage. Les défis potentiels sont que l’organisation reste responsable des éléments d’architecture/ingénierie (par exemple, la sélection et la mise en œuvre de nouvelles applications) et la qualité des MSP peut varier considérablement.
- Engager un fournisseur de services infonuagiques (CSP), tel que Microsoft Azure ou Amazon Web Services (AWS), transfère toutes les responsabilités (et risques) de l’infrastructure matérielle sous-jacente au CSP. Notez que cela ne transfère que les responsabilités et risques du matériel au CSP, mais le client peut toujours rester responsable de supporter et de gérer le système d’exploitation, les plateformes (middleware) et les applications; Cela dépend du fournisseur et de la nature des conditions d’engagement. Des défis potentiels peuvent survenir si l’organisation héberge certaines applications/systèmes à l’interne et d’autres applications/systèmes dans le nuage, selon la connectivité entre le nuage et le centre de données où se trouvent les applications/systèmes internes.
Atténuation des risques
L’atténuation des risques vise principalement à diminuer la probabilité que le risque survienne et/ou à diminuer son impact s’il survient, par exemple lors de l’utilisation de solutions à haute disponibilité (HA) et/ou totalement redondantes. Voici quelques techniques que nous avons vues utilisées dans différentes organisations :
- Permettre aux départements de tracer leur propre chemin, en fonction de leur compréhension de leurs besoins uniques, afin de s’assurer que les besoins de tous les groupes d’affaires seront satisfaits. Dans ce modèle, les TI jouent un rôle consultatif tout en maintenant l’infrastructure et les plateformes sous-jacentes dans ce qui est essentiellement un modèle IaaS et PaaS pour l’entreprise. L’autorité décisionnelle concernant les applications et les versions incombe aux groupes d’affaires, et les fonds et ressources continus nécessaires à la maintenance des demandes proviennent des groupes d’affaires.
- « Conteniser » l’application, c’est-à-dire que l’application réside dans un environnement hérité (conteneur) mais que le conteneur réside en réalité sur une plateforme moderne (OS) et gère les interactions entre les applications à l’intérieur du conteneur et la plateforme à l’extérieur du conteneur. Cela permet aux applications héritées de rester intactes, mais n’empêche pas les plateformes de soutien d’être maintenues à jour. Notez que cette stratégie est souvent satisfaisante pendant un certain temps (années); cependant, finalement, un moment est atteint où l’application héritée doit être mise à jour. Néanmoins, l’utilisation de contenants offre souvent suffisamment de temps pour qu’une solution appropriée soit planifiée et mise en œuvre.
- Mener des initiatives périodiques de gestion du cycle de vie des applications, où (par exemple) tous les 3-4 ans les groupes TI et d’affaires se réunissent pour examiner les nouveaux besoins d’affaires et les applications disponibles pour répondre à ces besoins, identifier des applications à retirer en fonction de besoins d’affaires obsolètes, identifier des applications à rationaliser pour celles offrant des fonctionnalités en double, et déterminer comment les exigences non satisfaites, y compris l’acquisition potentielle d’une nouvelle ou des nouvelles applications. Cette initiative périodique devrait également inclure une feuille de route définie conjointement entre les TI et l’entreprise pour passer de la situation actuelle à un portefeuille rationalisé d’applications sur une infrastructure bien supportée; Le calendrier de la feuille de route devrait englober le délai entre ces initiatives.
Acceptation du risque
L’acceptation du risque prend la décision consciente d’accepter le risque, généralement parce que la probabilité et/ou l’impact du risque est perçu comme très faible, par exemple lorsqu’une décision est prise de maintenir tous les systèmes dans un seul centre de données, sans centre de données DR. Il se peut aussi que la probabilité et/ou l’impact soient suffisamment élevés pour être préoccupants, mais ne l’emportent pas sur les coûts durs et doux qu’une autre stratégie de réponse au risque entraînerait.
- Continuez à maintenir des applications héritées pour éviter des défis tels qu’une nouvelle courbe d’apprentissage pour les utilisateurs finaux, l’investissement de temps et d’argent dans la mise à niveau vers un nouveau système, et d’autres perturbations. Cela inclut le choix de ne pas accepter de modifications à la plateforme d’hébergement afin que l’application puisse continuer à fonctionner telle quelle sans avoir besoin de mises à jour. Bien que ce ne soit généralement pas souhaitable, c’est une solution valable si la nécessité d’éviter toute perturbation potentielle l’emporte sur l’augmentation progressive des fonds, du temps et des ressources pour soutenir les applications héritées.
- Adopter un modèle de rétrofacturation où les applications héritées continuent d’être prises en charge, et les coûts de support de ces applications sont facturés au centre de coûts des groupes d’affaires qui utilisent l’application héritée, plutôt que d’être facturés à l’informatique. Cela exige que les TI disposent d’un système pour suivre et capturer l’utilisation continue des ressources de calcul par les utilisateurs hérités de l’application, et d’attribuer une valeur monétaire (coût) au calcul de l’utilisation des ressources, et que (par exemple) un rapport trimestriel soit fourni aux groupes d’affaires concernés pour détailler ces coûts. Cela peut aussi nécessiter que du matériel dédié et/ou des machines virtuelles soient alloués à ces groupes d’affaires (selon la granularité du système de suivi des facturations), plutôt qu’à des matériels ou machines virtuelles multi-locataires. De plus, cela va de pair avec le suivi de la dette technique et la compréhension du coût total de la dette d’une application, afin de s’assurer que les coûts de propriété durs et souples sont pris en compte.
Organiser des stratégies de gestion des risques de cette façon peut aider une organisation à identifier celles qui conviennent le mieux à son organisation, ainsi qu’à adopter des stratégies de gestion des risques cohérentes qui s’alignent sur l’appétit et la tolérance au risque de l’organisation, ainsi qu’avec les technologies, compétences et la maturité des processus internes.
Ferroque Systems a fait face à ce genre de défis à de nombreuses reprises et les a abordés via certaines des solutions décrites ci-dessus; Si votre organisation fait face à des défis similaires, nous sommes convaincus de disposer de l’expertise nécessaire pour vous aider à comprendre le problème et à définir et/ou mettre en œuvre la solution la plus appropriée pour votre organisation.
