Lilian Duchêne

Dans cet article, nous allons aborder l’identification et l’évaluation des « stacks technologiques » d’un parc applicatif tel que recommandé par TOGAF dans la Phase D de l’ADM (Technology « stack » – cfr cet article sur theopengroup). Cette phase aide à structurer et documenter l’architecture technologique.

Ce que nous verrons dans cet article :

1. Les stacks technologiques
2. Décisions sur base de ces données ‘orientées IT’
3. Visualiser les données IT
4. Conclusion

Les stacks technologiques

Les critères spécifiques d’évaluation que nous verrons plus loin, sont basés sur les principes d’architecture afin d’analyser les technologies actuelles et d’identifier celles obsolètes ou nécessitant une mise à jour. Sur base du résultat de ces analyses, on sera en capacité d’:

• Identifier les stacks technologiques pris en charge côté architecture ;
• Évaluer la maturité de l’entreprise dans la gestion de ces stacks, indépendamment de tout contexte « client » ;
• Évaluer la dette technologique, voire l’obsolescence de ces stacks ;

Stack technologique (Pile technologique) : Il désigne l’ensemble des technologies utilisées pour construire et faire fonctionner une application. Il cible l’architecture de l’infrastructure. Il comprend généralement les logiciels, les frameworks/middleware, les langages de programmation, les serveurs, les outils de gestion de base de données, les environnements d’exécution et les plateformes d’infrastructure nécessaires au développement, à l’exécution, au déploiement et à la maintenance d’une application.

Remarque : Le stack technologique est divisé en deux parties principales :

• le front-end (côté utisateur), qui est ce que l’utilisateur voit et interagit avec l’application via son navigateur web par exemple et,
• le back-end qui est le côté serveur de l’application où se déroulent le traitement des données, les calculs et les opérations de stockage.

Un stack technologique est donc décrit sur base des données suivantes : 

• Framework / plateforme spécifique, 
• Langage de développement
• Technologies sous-jacentes
• Sytème de gestion des bases de données (SGBD)
• Système d’exploitation (OS – Operating System)

Pour évaluer un stack technologique, plusieurs critères essentiels doivent être pris en compte pour s’assurer que l’application réponde aux besoins spécifiques de l’entreprise tout en restant flexible, évolutive et sécurisée. 

Pour évaluer un stack technologique, plusieurs méthodes existent. Dans cet article je vous propose une série de critères basés sur la méthode TIME de GARTNER¹ :

• Évaluation de la dépendance du stack technologique aux RH, qui maintiennent et améliorent ce stack, et donc les applications qui y sont associées. Cela permet de déterminer si sa gestion et son amélioration sont exclusivement sous la responsabilité d’une personne, ou si elles sont réparties sur un groupe de personnes.
• Évaluation du temps, de l’effort et du risque associés à l’amélioration ou à la modification fonctionnelle ou technique du stack technologique ou de ses applications. Ceci inclut l’effort nécessaire pour intégrer des applications et évaluer la difficulté ainsi que la fiabilité des tests.
• Évaluation du niveau de support des produits logiciels utilisés dans le stack technologique et la pérennité des fournisseurs. Cela permet d’examiner la qualité du support offert pour les logiciels au sein de ce stack et évaluer la stabilité et la durabilité des fournisseurs.
• Évaluation de la conformité à la direction architecturale et aux normes actuelles de l’entreprise. Cela permet de contrôler si le stack technologique respecte les orientations architecturales actuelles et les standards définis par l’IT de l’entreprise.
• Évaluation de la fiabilité et de la stabilité du stack technologique, y compris la disponibilité, la tolérance aux fautes et la capacité de récupération. Cela permet de mesurer sa performance en termes de fiabilité et de stabilité, en prenant en compte la disponibilité, la résilience et la récupérabilité.
• Évaluation de la sécurité et de la capacité avec laquelle le stack technologique protège les informations contre l’accès ou l’extraction non autorisés. Cela permet d’examiner comment il sécurise les informations, les données et les fonctions pour prévenir leur utilisation ou extraction non autorisées.
• Évaluation de la capacité d’adaptation / personnalisation du stack technologique pour répondre à des besoins métiers et techniques spécifiques. Cela permet de mesurer les possibilités d’évolution ou de personnalisation du système pour satisfaire à des exigences métiers et techniques particulières.

Ces critères sont pondérés pour permettre de favoriser l’importance en matière de gestion donnée par l’entreprise pour tel ou tel critère. Leurs valeurs sont comprises entre 1-très faible et 5-très bien. À la fin, chaque stack fixe le ‘Technical Fitness’ des applications.

Remarque: Dans l’approche TIME, le technical fitness sera opposé au ‘Business fitness’.

Ci-après un graphique montrant la liste des métiers (1 ligne = 1 métier) et leurs dépendances technologiques (1 couleur = 1 stack technologique). Les chiffres montrent le nombre d’applications dans un stack. On part du principe que le basculement du vert vers le rouge se fait à la valeur 3. Vert=évaluation du stack > 3, Rouge=évaluation du stack < 3

En évaluant les stacks technologiques ainsi, nous pouvons au niveau architecture – généralement en Architecture Board – prendre connaissance de la criticité de l’IT vis-à-vis du fonctionnement de l’entreprise. Ici, sans avoir besoin de données métiers, on peut déjà se rendre compte de la manière dont l’IT est gérée par rapport aux différents métiers, et donc commencer à comprendre pourquoi tel métier est en rouge et pourquoi un autre non. Il est important d’accepter aussi que le sens de la couleur ‘rouge’ est différent de DANGER. En effet, le rouge est un signal, rien de plus. Aucun jugement de la gestion de l’IT ne pourrait être rationnel sur base de ce seul graphique.

Les couleurs indiquent le niveau de la dette technologique² . Plus la couleur tend vers le rouge, plus la dette technologique tend vers l’obsolescence technologique³. Cela signifie que le temps pour décider de migrer de technologie (et de comment migrer) se réduit de plus en plus dès qu’on tend vers le rouge.

Décisions sur base de ces données ‘orientées IT’

Au niveau d’un architecture board, il est vital de capturer l’expérience des changements IT précédents. En effet, sur base de cette connaissance, il sera alors possible d’établir des règles qui donneront du sens aux couleurs du graphique à la figure 1, telle que : l’entreprise a ‘n’ mois pour tolérer, ‘n+18 mois’ pour migrer ou encore ‘n+36 mois’ pour supprimer une technologie. Les chiffres sont bien entendu cités au hasard. L’important est de comprendre ici qu’il faut décider certe mais en connaissance de cause, et surtout de fixer des points de comparaison – maintenus par les règles – constant dans le temps. L’objectif est surtout de s’améliorer et de s’en donner les moyens.

Bien sûr, les stacks doivent être révisés une fois par an. Le changement des règles doit être justifié, communiqué et tracé (c’est-à-dire versionné et précisé sur les graphiques afin d’éviter toute comparaison hâtive). Ensuite, au moment de la mise en application de ces règles, des décisions s’en suivre et impacter ont de fait les décisions financières (budget de maintenance par exemple), les décisions RH comme la capacité de sourcing par stack ou encore les décisions sur le patrimoine (mobilier), par exemple revoir les contrats avec les éditeurs pour, par exemple, éviter une augmentation des prix si un éditeur voit que vous continuez à dépendre de lui 😉

Biensûr, je devine déjà vos commentaires sur le « comment décider sans connaître la valeur apportée d’une application à un métier ». Vous avez raison! Pourquoi prendre des décisions sans connaître l’importance d’une application pour un métier.

Selon moi, il est important de ne pas confondre continuité avec investissement. En se basant sur la figure 1, on peut prendre des décisions sur la continuité ou non d’une application. On parle alors de continuité de service, ce qui est plus approprié.

En d’autres termes, ce graphique illustre comment l’IT gère ses investissements passés. Il est évident que la valeur métier d’une application est cruciale, mais seulement lorsqu’il s’agit d’adapter, de changer et de migrer l’application vers une autre technologie. Mais quand est-ce le bon moment? C’est là que ces données se révèlent intéressantes. Elles nous permettent de repérer les risques de continuer à maintenir une application dans un stack spécifique. En effet, il faut considérer les couleurs comme l’image de l’énergie restant de l’IT pour maintenir un service. Si on est dans le vert foncé, l’effort sera maintenu pendant encore quelques années. Dans le rouge foncé, c’est difficile, tout effort est fatiguant. Donc pas de garantie que çà durera encore plusieurs années.

Prenons l’exemple d’une entreprise qui souhaite investir plusieurs millions d’euros dans un projet de rénovation de l’IT. L’importance de ce graphique prend alors tout son sens. En partant du principe que ce graphique représente la capacité de l’IT à adapter son parc applicatif, l’entreprise pourra évaluer ses risques opérationnels orienté IT. Avec ce graphique, ce sera très facile d’amener une décision.

Biensûr, la donnée métier reste importante pour évaluer pleinement le risque opérationnel de l’entreprise. C’est pourquoi nous pouvons encore aller un pas plus loin.

Visualiser les données IT

En effet, il est important d’inclure les aspects métiers dans les décisions technologiques, même avec des données partielles. Cela va garantir que les choix technologiques soutiennent bien les objectifs de l’entreprise. Les évaluations des stacks peuvent être par exemple alignés sur des aspects simples tels que l’impact métier des applications ou encore leur importance opérationnelle. La collaboration étroite avec les responsables métier est essentielle pour s’assurer que leurs perspectives sont prises en compte malgré le manque d’informations complètes. Cette approche favorise un meilleur alignement entre l’ITet les métiers.

Sur base de l’article précédent « Piloter la transformation d’un SI« , nous avons vu que les business capabilities sont un moyen pour assurer le pilotage d’un SI. Nous avons vu également dans les articles « Modéliser les business capabilities » et « Modélisation de capabilities » que les applications (ressources technologiques) sont identifiées lorsqu’une business capability est modélisée.

Dans notre article ici, nous assumons que les données IT soient résumer à une évaluation d’un stack. Toutefois comme montré à la figure 1, nous connaissons les applications au sein même des stacks. Le lien entre business capabilities et applications est donc connu et surtout sous contrôle en termes de qualité et de gouvernance. Nous pouvons donc visualiser les données IT sur un plan IT alors que l’évaluation métier n’est pas encore pleinement maîtrisée.

C’est ainsi qu’un plan d’occupation des sols peut devenir une carte la capacité de changement de l’IT. En alignant sur cette même carte le facteur de différentiation de l’entreprise au travers des business capabilities, on sera capable par exemple de visualiser le risque opérationnel d’une décision.

Conclusion

Je pars du principe que le changement IT est initié par des signaux qui permettent d’anticiper, et non de réagir. Dans ce cas, souvent l’historique des décisions permet de rassurer et d’identifier les impacts à court et moyen termes.

Montrer les données IT sous forme de graphique permet de raconter une histoire et d’identifier des tendances liées à la capacité de l’IT à évoluer. En étudiant la qualité de ces histoires au fil du temps, vous pourrez affiner des règles pour anticiper de mieux en mieux les changements du SI.

Il ne faut pas biensûr sur base de simple graphique conclure à un jugement du passé. C’est pourquoi assumons que le seul objectif est de capturer ces signaux. Ensuite l’enjeu sera de s’en servir au niveau stratégique pour amener une décision. Et c’est ce que nous venons de voir grâce à ce graphique créé sur base de données uniquement IT. Se limiter à ces données est un excellent moyen pour assumer une montée en maturité de l’architecture d’entreprise. Cela permet de soutenir un board IT dans ses décisions.

Nous verrons dans d’autres articles que l’architecture d’entreprise pourra encore aller plus loin dans son soutien.

---

1. TIME (Tolerate – Invest – Migrate – Eliminate) est une méthode de GARTNER, utilisée dans la gestion de portefeuilles applicatifs (Application Portfolio management). Cette méthode demande de récolter beaucoup d’informations autant techniques que métier. Pour avoir un aperçu de l’approche TIME, je vous recommande cet article Linkedin. D’autres sont disponibles, par exemple cet article linkedin, ou encore cet article ITANA. ↩︎
2. Dette technologique : Elle est une indication de comment l’IT gère la technologie sur base d’évènements internes. Cela doit montrer une indication sur le niveau de contrôle de l’IT par rapport à ces évènements internes. ↩︎
3. Obsolescence technologique : Elle montre une indication de comment l’IT gère la technologie sur base d’évènements externes ainsi que la manière dont elle arrive à en garder le contrôle. Lorsqu’on parle d’obsolescence élevée, cela indique que l’IT ne contrôle plus la dette technologique d’une application. ↩︎