Ateko en profondeur Ép. 1 : Modélisation des applications à l’aide de CSDM (avec CAE)

Dans cette classe de maître, Maxime Carrier (chef de pratique ITOM chez Ateko) explique comment utiliser le cadre de travail CSDM v5 de ServiceNow pour combler l’écart entre les opérations TI et les affaires. Découvrez comment trouver le « juste milieu » pour la granularité des instances de service et choisir entre une approche de modélisation axée sur les applications ou axée sur les services.

Nous sommes ravis d’accueillir Denise Morrison, gestionnaire ITOM chez CAE, un chef de file mondial de la formation dans les domaines de l’aviation et de la défense. Denise partage un regard sans filtre sur la transformation CSDM concrète de CAE. Regardez pour découvrir comment CAE est passée d’une confusion organisationnelle à une clarté absolue en corrigeant les noms de services et d’offres qui se chevauchaient, comment elle a collaboré à travers les équipes pour modéliser manuellement ses applications « joyaux » les plus critiques avant d’automatiser le tout, et comment elle a considérablement amélioré ses rapports de billets d’incident et de changement en définissant correctement les services, les offres et les instances.

Transcription:

Maxime : Bonjour et bienvenue à la session d’aujourd’hui où nous examinerons comment modéliser les applications d’affaires à l’aide du cadre CSDM de ServiceNow. Mon nom est Maxime Carrier, et je suis le chef de pratique ITOM chez Ateko. Je serai accompagné de Denise Morrison de CAE, qui est la gestionnaire ITOM, pour la visibilité et la santé ITOM. Je vais maintenant laisser Denise se présenter et parler un peu de CAE.

Denise : Merci, Maxime. CAE est une entreprise d’aviation à la fine pointe, en fait. Comme l’indique la diapositive, ils sont devenus un partenaire de confiance en matière de sécurité avancée et de préparation aux missions. Pour les piliers de l’aviation civile et de la défense et sécurité. Ils sont impliqués dans la formation des pilotes en vol, et ce, tant dans l’aviation civile, qui correspond en fait aux compagnies aériennes commerciales, que dans la défense et la sécurité, où ils forment les pilotes de la défense. D’accord. Et aussi leur programme de formation par simulation. Il est à la fine pointe. Il est en constante évolution, et il est mondial. Il a donc une empreinte à travers le monde.

Maxime : Oui, c’est vrai. J’ai vu des installations dans plusieurs aéroports lors de mes voyages. Donc… Et pour ajouter à ce que tu viens de dire, Denise, les simulateurs de vol sont vraiment superbes. Je les ai vus à vos installations.

Donc l’idée derrière cette présentation est de savoir comment obtenir une CMDB orientée services en suivant la dernière version de CSDM, soit CSDM v5. Donc, l’ordre du jour d’aujourd’hui sera le suivant. Premièrement, un aperçu de CSDM, un survol rapide de ce qu’est CSDM. Nous aborderons ensuite l’approche souhaitée lorsque vous voulez commencer à modéliser vos applications. Êtes-vous une entreprise davantage axée sur les applications ou sur les services? Troisièmement, nous passerons à ce que nous appelons le « juste milieu » (sweet spot) de l’instance de service. Et puis quatrièmement, c’est là que Denise parlera de la façon dont CAE modélise ses applications d’affaires et passera en revue deux exemples. Et enfin, nous parlerons des meilleures pratiques de modélisation.

Donc, un aperçu de CSDM. Le défi d’aujourd’hui, même aujourd’hui en 2026, c’est que les clients ont encore du mal non seulement à maintenir une CMDB saine, mais aussi à atteindre ce que nous appelons une CMDB orientée services. Bien qu’une CMDB traditionnelle offre un inventaire clair des actifs techniques comme les serveurs, les bases de données, les intergiciels (middleware), etc., elle ne capture pas pleinement la façon dont ces composants soutiennent vos services d’affaires. Cela crée un écart entre les opérations TI et les consommateurs d’affaires.

Donc à droite, sous les opérations TI, nous avons des exemples de ce que nous découvrons quotidiennement chez les clients. Que ce soit sur site (on-prem) ou dans le nuage (cloud). Et à droite, sous les utilisateurs d’affaires, eh bien, vos employés et vos clients externes consomment vos applications d’affaires, n’est-ce pas? Et vos services d’affaires de haut niveau sont généralement les ventes, les services de paie, les courriels, les services financiers, etc.

Les cas d’utilisation les plus typiques auxquels nous sommes confrontés sont, par exemple, si un serveur tombe en panne, quels services d’affaires seront impactés? Encore une fois, cette cartographie verticale entre votre infrastructure et vos services est super critique. Un autre cas d’utilisation : quel est le coût total de livraison de notre plateforme de ventes? Ce que cela signifie, c’est que pour offrir des services de ventes, il y a un dossier d’affaires (business case) derrière cela. Et pour remplir cette capacité d’affaires, je devrais dire, eh bien, nous devons livrer et implanter des applications d’affaires. Et le troisième point, quels services sont affectés par ce changement planifié? Donc, lorsque vous effectuez vos changements normaux, vous allez, par exemple, créer des changements de type infrastructure où vous devez appliquer des changements à certains serveurs, des bases de données SQL, différents intergiciels. Lorsque vous créez ces changements, nous voulons être en mesure d’évaluer le risque en conséquence et automatiquement, devrais-je dire. Et pour ce faire, vous devez créer la cartographie entre vos applications d’affaires sous la forme d’une instance de service et vos applications déployées sous la forme d’intergiciels, soit des bases de données, IIS, etc.

Rapidement, je suis sûr que la plupart d’entre vous sont déjà familiers avec cette terminologie, mais CSDM signifie Common Service Data Model (Modèle de données de services communs). Donc, comme j’en ai parlé, les services communs touchent les courriels, les finances, les RH, les services aux employés. C’est fondamentalement tout ce qui est offert à vos consommateurs, que ce soit à l’interne ou à l’externe. Et le modèle de données est super critique. Il vous donne des directives sur l’endroit où les données devraient résider dans l’environnement. Toutes les tables sont prêtes à l’emploi (out-of-the-box), elles sont toutes prêtes à être consommées, mais il est important pour les clients de suivre les bonnes relations et les bonnes classes pour que vos CI (éléments de configuration) soient créés et cartographiés. Par exemple, les applications d’affaires résident dans cmdb_ci_business_app. Alors, quel est le plan directeur pour votre CMDB? Donc, comme je l’ai dit, CSDM est un cadre de travail standard qui organise vos données CMDB en connectant votre technologie directement aux résultats d’affaires. Il cartographie toute la chaîne, de l’infrastructure sous-jacente, ce que nous appelons aussi la pile applicative, en passant par les applications, jusqu’aux services d’affaires que les utilisateurs consomment.

Quelles sont les valeurs d’affaires typiques et les plus évidentes? Eh bien, d’abord et avant tout, les rapports. Avoir ce cadre de travail cohérent où les données résident dans des emplacements spécifiques de la CMDB permet d’obtenir des informations cohérentes et fiables sur vos services et produits numériques. Il est donc plus facile de faire des rapports, il est plus facile de créer vos vues de base de données. Par exemple, donnez-moi tous mes incidents où une instance de service particulière a été liée en tant que CI et je veux aussi inclure une classe de CI particulière faisant partie de la pile applicative. Donc, donnez-moi tous mes CIs où une instance de service a été associée et où j’avais du SQL dans la pile applicative.

Une autre valeur d’affaires est ce que nous appelons la rationalisation. Cela vous permet de déterminer la performance d’une application d’entreprise, et la gestion du portefeuille d’applications (APM) est maintenant désignée sous le nom de EA (Architecture d’entreprise). Vous êtes donc capable d’exécuter des choses comme le coût total de possession, qui est un livrable relevant davantage de l’architecture d’entreprise, mais le fait d’avoir ce cadre en place et les données résidant dans les bonnes tables/classes permet à l’EA de faire une telle rationalisation.

Une autre valeur d’affaires est ce que nous appelons la réduction des audits. Vous voulez être en mesure d’identifier rapidement les services d’affaires affectés, n’est-ce pas? Donc, lorsque vous avez vos services d’affaires identifiés avec le bon ensemble d’offres de services d’affaires (BSO) qui dépendent ensuite de vos instances de service, vous êtes en mesure de dire que si je crée une panne et que je spécifie une instance de service particulière, je serai alors en mesure d’identifier quelles offres de services d’affaires sont affectées. Et si j’ai des applications dépendantes qui s’appuient sur cette instance de service, je le verrai également dans ma vue de dépendances. Donc, la valeur d’affaires GRC (Gouvernance, Risque et Conformité) alignera les processus d’affaires pour réduire les risques et assurer la conformité. Il s’agit donc de s’assurer que les données résident dans les bonnes tables.

Une autre façon de voir ou de mettre les choses en perspective est de regarder cette diapositive. J’aime la façon dont cette diapositive représente le fait que vous avez différents types d’applications d’affaires : certaines sont achetées, d’autres auxquelles vous êtes abonnés, d’autres que vous bâtissez à l’interne. Indépendamment de votre application d’affaires, celle-ci aura, selon le type (à l’interne, sur site ou déployée dans le nuage), une empreinte dans votre environnement. Cette empreinte est normalement représentée par l’environnement : Prod, QA, Dev, etc. Et la plupart des clients commenceront toujours par la Prod. Et vous devriez toujours concentrer vos efforts sur la cartographie de vos instances de service de production en premier, évidemment, à moins que le client ne crée réellement des changements avec des instances de service hors production. Si c’est le cas, vous devrez alors cartographier les environnements appropriés.

Et puis, vous pouvez voir clairement qu’il y a un lien entre votre instance de service et votre infrastructure, n’est-ce pas? Serveurs, routeurs—donc tout votre équipement télécom—bases de données, pare-feux et répartiteurs de charge (load balancers). Donc, un bon exemple de répartiteurs de charge dans vos cartes lorsque vous faites du Service Mapping, c’est si votre application est basée sur le Web et qu’elle est à l’interne, je dirais que 95 % du temps, cette application aura une charge répartie. Donc pour votre point d’entrée, il suffit de mettre votre service de répartition de charge, et cela ajoutera automatiquement l’infrastructure sous-jacente dans votre carte.

D’accord, alors qu’est-ce que CSDM v5 apporte au client? Eh bien, la fonctionnalité la plus distinctive, je dirais, ou le plus grand avantage, c’est la façon dont v5 a créé des sous-classes sous l’instance de service. Et c’est le point numéro quatre de ce tableau, la modélisation étendue de l’infrastructure. Vous êtes maintenant en mesure de créer des instances de service de type télécom pour les modules TSOM. Vous êtes en mesure de créer des instances de service plus raffinées, spécifiques aux API, spécifiques à l’intégration. Cela ajoute donc un peu plus de granularité à votre cartographie et à votre modélisation. Il existe un Service Builder (Constructeur de services) qui vous permet de créer des services en suivant un assistant guidé. Le petit bémol avec le Service Builder, c’est qu’il ajoutera deux champs supplémentaires à vos services d’affaires : le pipeline de catalogue et un autre champ lié au catalogue. Vous devez donc vous assurer que ces deux champs sont remplis si vous décidez d’activer le Service Builder. Donc, pour simplifier les définitions, il définit plus précisément, vous savez, avant nous avions quelque chose appelé service technologique, maintenant c’est appelé services de gestion technologique. Donc, à mesure que CSDM évolue avec le temps, n’est-ce pas, certains termes comme services applicatifs, instance non-service, vont changer. Mais le cœur du CSDM, le domaine, tout reste le même. Donc, la v5 met l’accent sur la simplification et la clarté, conçue pour abaisser la barrière à l’entrée. Je vais donner plus de détails sur ce point.

D’accord, qu’est-ce que je veux dire par une modélisation axée sur les applications par opposition à celle axée sur les services? Donc, si nous avons un client qui veut adhérer à CSDM, et honnêtement, tous les clients devraient adhérer à CSDM, parce que beaucoup de modules s’attendent à ce que les données soient dans la plupart de ces tables. Mais quoi qu’il en soit, lorsque vous commencez votre aventure CSDM, certaines entreprises auront une mentalité davantage axée sur les applications. Par exemple, si vous voulez intégrer un serveur pour ces entreprises, elles diront toujours : « Eh bien, ce serveur sera lié à quelle application? » Elles sont donc très concentrées sur les applications d’affaires et les applications déployées dans l’environnement. D’autres clients auront une orientation plus axée sur les services. Par exemple, quels sont les services que nous offrons à nos utilisateurs finaux? Quels sont les services exposés que nous avons actuellement? Un exemple d’une telle entreprise pourrait être une compagnie de télécommunications ou un fournisseur de téléphonie mobile, où ils exposent toujours différentes offres et services, par opposition à une entreprise où, à l’interne, encore une fois, c’est plus axé sur les applications.

Donc, si vous voulez commencer avec une approche axée sur les applications, vous voudrez vous connecter à votre équipe d’architecture d’entreprise, n’est-ce pas? Vous devez identifier quelle est la source de votre application d’affaires. Typiquement, l’entreprise aura une solution EA, comme LeanIX ou Sparx, et c’est la source par laquelle vous voulez commencer. Et si vous voulez faire une intégration, honnêtement, vous ne devriez synchroniser que les applications d’affaires et ne pas tenter de recréer une cartographie entre, disons, un modèle d’architecture pour… ou des solutions EA. ArchiMate est ce que je cherche, n’est-ce pas? N’essayez pas de synchroniser ArchiMate avec CSDM. Ce n’est pas une chose facile à faire, et j’ai vu cela échouer, donc nous ne recommandons pas de le faire.

Donc, quelques points sous l’approche axée sur les applications. De quelles applications d’entreprise avons-nous besoin pour répondre à nos capacités? Si cela, disons, JDE subit une panne ou SAP, cela causera-t-il une perte de revenus? Quels sont les… Ce point vous aide donc essentiellement à identifier quelles sont mes applications MVP ou mes applications P1 que je veux commencer à modéliser en premier, ou du moins essayer de, je devrais dire attaquer, mais essayer d’identifier une liste d’applications qui sont soit P1, vos applications critiques, vos applications « joyaux », ou les applications les plus souvent consommées. Cela devrait vous donner une liste de, je ne sais pas, 20 à 50 applications, et c’est beaucoup plus faisable que de vous attaquer à votre liste complète d’applications, qui se compte par centaines.

Si je passe du côté de l’approche axée sur les services, vous voulez identifier quels services sont offerts par nos équipes de ventes, de marketing, de collaboration. Nous devons comprendre quels services… Si vous n’avez pas de CMDB pour commencer, vous pouvez toujours identifier les offres pour, disons, vos différents logiciels. Cela pourrait donc être une façon de voir les choses. Oui. D’accord.

Appliquer CSDM par étapes. Il y a plusieurs étapes à appliquer. Comme vous le savez, chaque étape vous demande d’identifier vos applications d’affaires. Pour chaque application d’affaires, vous devez avoir une instance de service correspondante ou plusieurs instances de service. Et idéalement, vous voulez les cartographier en utilisant Service Mapping, n’est-ce pas? Ça, c’est l’approche axée sur les applications. Si vous êtes axé sur les services, vous commencerez par identifier vos services d’affaires, vos services techniques, et vos offres de services techniques et d’affaires. Et vos instances de service. Si je continue avec l’approche axée sur les applications, l’étape « Marcher » (Walk), vous pouvez commencer à créer des groupes de CI dynamiques. Vous pouvez créer vos offres de services techniques (TSO) avec votre TS, le service technique. Et vous pouvez aussi commencer à créer votre portefeuille de services. Par opposition à l’approche axée sur les services, l’étape « Marcher », eh bien, vous vous assurerez que Discovery est en cours d’exécution. D’accord. Afin de cartographier les CI à vos instances de service ici. Et vous pouvez aussi créer des groupes de CI dynamiques.

Lorsque vous atteignez l’étape « Courir » (Run), la plus grande différence entre les deux approches est qu’à l’étape « Courir » sous l’approche axée sur les applications, vous commencerez à définir vos services d’affaires et vos offres de services d’affaires. Et sous l’approche axée sur les services, vous finirez par… Vous compléterez l’identification de vos applications d’affaires. Et la raison pour laquelle nous avons surligné cette phase est que nous estimons, après toutes les implantations CSDM que nous avons faites au fil des ans, que pour qu’un client bénéficie réellement de l’approche CSDM, il doit atteindre la phase « Courir ». Vous voulez commencer à créer des incidents, des problèmes et des changements en utilisant votre service, votre offre de service et le CI, n’est-ce pas? L’offre de service identifiera ce que le client essaie de consommer. Et le CI lors de la création est soit le poste de travail de la personne qui essaie de consommer cette application ou cette offre, ou si la personne qui crée le billet est suffisamment compétente pour essayer d’identifier la cause fondamentale lors de la création en sélectionnant une instance de service? Totalement acceptable.

Cependant, lors de la résolution de l’incident, si j’utilise un cas d’utilisation d’incident, nous déterminerons alors avec le niveau deux ou le niveau trois que la cause fondamentale a été provoquée par une autre application. Et c’est cette instance de service qui devrait être reflétée lors de la résolution. Donc, à la résolution, le CI devrait changer pour ce qu’est la cause fondamentale, qui est une instance de service, le plus souvent. Ou ça pourrait être une autre instance de service de nature technologique, ou une instance de service liée à une autre application d’affaires, n’est-ce pas? Donc, lorsque nous faisons des sessions de modélisation et que nous modélisons des applications en utilisant Lucidchart, par exemple, nous donnerons toujours le contexte. « Eh bien, ce modèle que nous venons de faire, voici les valeurs que nous mettrions sous service, offre et CI, d’accord? » Donc, mais pour ce faire, vous devez atteindre la phase « Courir ». Et ensuite « Voler » (Fly), vous pouvez créer vos capacités d’affaires, associer des items de catalogue à certaines offres, qu’elles soient techniques ou d’affaires, puis intégrer l’EA (architecture d’entreprise) et ainsi de suite. Mais c’est la phase la plus importante à mon avis.

Donc, lorsque nous faisons une mise en production, comme je l’ai dit, que vous commenciez par l’approche axée sur les applications, numéro un, ou l’approche axée sur les services, qui est votre autre numéro un, vous aboutirez toujours à la livraison de services, n’est-ce pas? Comme vous pouvez le voir ici, si vous créez votre application d’affaires, votre application d’affaires consommera toujours une ou plusieurs instances de service. Si vous commencez par vos services d’affaires, vos offres dépendent de votre instance de service, n’est-ce pas? Elles dépendent de la pile déployée de composants d’infrastructure qui rend une application consommable. D’accord. C’est tout ce que je veux mentionner à propos de cette diapositive.

Donc, quel est le « juste milieu » (sweet spot) lorsque nous menons des sessions de modélisation avec nos clients? Lorsque nous avons mené nos sessions de modélisation avec CAE, nous avons eu des discussions avec les architectes d’entreprise et les propriétaires d’applications sur le niveau de détail avec lequel nous voulions que nos modules d’application soient représentés sous forme d’instances de service. Et le but ici est de créer juste assez d’instances pour une gestion efficace des services TI. Par conséquent, le juste milieu est déterminé en posant les questions suivantes. Alors, comment atteignez-vous le bon nombre d’instances de service? Nous avons élaboré une série de questions qui nous aide généralement à identifier. Est-ce deux? Est-ce un? Est-ce cinq?

Laissez-moi donc passer en revue les questions typiques que nous posons. Un facteur commun concernant la consommation ITSM : une question serait : « Utiliseriez-vous un jour ces instances de service dans un billet de changement? » Par exemple, si j’ai une application qui est hébergée sur un nuage privé auquel vous êtes abonné, vous n’allez très probablement pas diviser vos instances de service en plusieurs. Vous en aurez juste une représentant la Prod de cette application. Et si le client dit : « Eh bien, nous avons plusieurs modules. » La question que vous devez poser est : « Utiliseriez-vous un jour une instance de service représentant ce module dans un billet de changement? » Si la réponse est non, généralement, une seule instance de service devrait suffire.

Un autre facteur commun concerne l’environnement. Avez-vous différents déploiements pour votre cycle de développement? Donc, si vous faites de l’ITSM pour le hors-production, vous devrez alors créer une instance de service pour la Prod, une instance de service pour le QA, et potentiellement pour le Dev. Un autre facteur est : sont-ils offerts dans différentes zones géographiques? Donc, si vous avez une application qui est déployée sur plusieurs sites, et qu’il est possible que vous fassiez un changement spécifiquement pour un site qui n’affecterait pas un autre site, vous devrez diviser votre instance de service représentant ces sites.

Le facteur : architecture/performance. Roulent-ils sur des piles technologiques différentes ou ont-ils des niveaux de performance différents? Si vous avez une application déployée qui possède des piles applicatives différentes—une pile de serveurs différente pour un module spécifique d’une application, et qu’ensuite nous savons clairement qu’il y a une autre pile déployée pour un autre module—vous devrez créer deux instances de service distinctes. Et très probablement, elles pourraient avoir des priorités différentes. Donc, si une instance de service tombe en panne, l’application est toujours consommable, mais ce sera peut-être juste une fonction particulière, n’est-ce pas? Cela pourrait donc avoir, disons, un P4. Et puis si un autre module tombe en panne, n’est-ce pas? Une instance de service, ce n’est plus consommable. C’est un P1.

Donc, un autre facteur : les dépendances d’application. Vos systèmes ont-ils des cycles de vie indépendants, ou les changements apportés à un composant exigent-ils instantanément des changements à l’autre? Un bon exemple de cela est que vous pourriez avoir une application qui a deux URL pour la consommer. Une URL vous donne un accès administrateur. Une autre URL donne l’accès typique aux employés, disons pour créer vos feuilles de temps. Il est possible de créer un changement sur la portion administrateur uniquement, ou un changement sur la portion employé, mais il est aussi possible de créer un changement qui affecte les deux. Dans ce cas, vous auriez une architecture d’instance de service à deux niveaux. Vous auriez une instance de service représentant l’application dans son ensemble, puis une pour l’administrateur et une pour l’employé. Et les deux dépendraient de la principale.

Donc, ce modèle du juste milieu est puissant parce que c’est le niveau minimum de détail requis pour répondre à vos questions opérationnelles les plus urgentes. Donc, si vous le voyez comme une analyse d’impact descendante (top-down) : un utilisateur signale un problème avec l’offre ERP SAP, vous remontez jusqu’à l’instance de service de production SAP S/4HANA ERP, et voyez l’infrastructure critique dont elle dépend. Ou ascendante (bottom-up) : si vous commencez par le bas, un changement planifié est prévu pour un serveur de base de données critique. Vous retracez pour voir s’il soutient l’instance de service SAP S/4HANA, qui soutient ensuite l’offre de service d’affaires ERP SAP. Vous connaissez alors et comprenez le risque d’affaires complet du changement. Donc, c’est soit que vous faites un changement sur l’application elle-même, donc le CI est l’instance de service, soit vous pouvez faire un changement d’infrastructure où le CI est le CI d’infrastructure réel, c’est donc soit le service qui descend, soit le CI qui remonte à l’application.

Trouvez donc la bonne granularité de l’instance de service. Le niveau de détail dans votre instance de service est le facteur unique le plus important pour une vue de dépendances utilisable. Si c’est trop haut niveau, disons que j’ai SAP et que je n’ai qu’une seule instance de service pour SAP Prod, vous ne serez pas en mesure de comprendre la carte parce que vous aurez beaucoup trop de CI dans votre carte, et ce n’est pas consommable ou compréhensible par une personne qui regarde ces données. Et si vous voulez tirer parti de la fonction « rafraîchir les services impactés » comme le fait automatiquement la gestion des changements, si vous mettez SAP comme CI, vos CIs impactés, à mon avis, sont beaucoup trop vastes, et cela va un peu à l’encontre du but d’avoir un aperçu significatif de ce qui est impacté. Utilisez plutôt une instance de service ou un module avec un plus petit ensemble de CIs dans votre pile. Donc, Cas d’utilisation numéro un. Voulais-tu peut-être parler un peu de cette application, Denise, et de ce que nous avons fait?

Denise : Oui. Je veux d’abord aborder, Maxime, la façon dont nous avons commencé, car au début, nous étions strictement axés sur les applications. Nous avions, vous savez, l’architecture d’entreprise impliquée et ils nous ont vraiment donné une direction. Ils nous ont fourni un ensemble de nos applications les plus critiques pour la phase un. Et ce modèle est un exemple de l’une des applications critiques que nous avons modélisées en utilisant CSDM. Et nous avons défini le service d’affaires, les offres, ainsi que les services applicatifs. Et comme vous pouvez le voir en haut, il y avait aussi, vous savez, parce que ces applications touchent à d’autres applications. Eh bien, elle touchait une autre application qui était une offre de service technique. Et nous sommes encore en maturation. Je dirais que nous sommes peut-être encore des tout-petits, pas tout à fait, vous savez, pleinement matures en CSDM. Mais grâce à Ateko et à toi, nous y arrivons. Nous y arrivons tranquillement.

Cette application en particulier avait un hôte de plateforme. Et à partir de cet hôte de plateforme, il y avait plusieurs applications d’affaires en dessous. Et cela, comme vous pouvez le voir, consommait plusieurs services et instances applicatives. Et celui-ci en particulier a définitivement plus que juste la Prod. Et comme tu l’as mentionné, nous avons posé ces questions, tu sais, « Est-ce que ce service pourrait potentiellement être impliqué dans un incident ou une requête de changement? » Et nous avons dû déterminer cela avec les propriétaires de produits, les propriétaires d’applications, pour diriger la façon dont nous allions modéliser cela.

Maxime : Oui. Et te souviens-tu lorsque nous menions ces sessions de modélisation avec le propriétaire de l’application? Une chose utile que nous avons faite a été de… Regardons les exemples de billets passés, n’est-ce pas?

Denise : Oui.

Maxime : Comment consommez-vous cette application aujourd’hui en cas d’incident et de changement? Et comment pouvons-nous améliorer votre expérience et votre analyse de risque en développant davantage la phase « Voler » du CSDM?

Denise : Oui. Et si tu passes au cas suivant, nous avons en fait une partie de ce que nous avons fait lors des sessions où nous avons dit, d’accord, nous avons regardé les incidents et les changements. À quoi cela ressemblait-il aujourd’hui avant de le modéliser? Comment était-ce utilisé? Comment était-ce représenté sur les formulaires? Et puis, après avoir modélisé cela avec CSDM, les CIs de services et d’offres plus raffinés sont entrés en jeu. Et en fait, cela s’est amélioré dans nos rapports. Nous avons dû faire des articles de la base de connaissances (KB) et des courriels pour annoncer ce qu’auraient été les anciennes cartographies sur un incident et un changement, et ensuite ce que les utilisateurs feraient après CSDM, ce qui serait indiqué après cela. Et cela s’est également avéré être un catalyseur dans l’adaptation de CSDM. Donc…

Maxime : Ouais. Donc, un cas d’utilisation, disons que nous prenons ServiceNow comme exemple. Donc, je sais que dans la présentation PowerPoint des exemples de modélisation que ServiceNow fournit, ils utilisent l’hôte de plateforme et l’application dans la table des applications d’affaires pour identifier les modules, n’est-ce pas? Et les modules sont vraiment ceux qu’un client a fournis. Donc, disons que vous avez ServiceNow comme hôte de plateforme, puis ServiceNow ITSM ou ServiceNow Incident, et puis vous aurez votre instance de service ServiceNow Incident. Ça fait donc beaucoup d’instances de service et d’applications d’affaires à créer. Et non seulement cela, si vous créez tout cela, est-il vrai que chez CAE, dans votre gestion des changements, nous allons créer un changement sur Incident, et puis nous voulons vraiment refléter le changement sur Incident en utilisant une instance de service représentant Incident, n’est-ce pas? Donc, avant, où il est écrit « Incident réel », vous appliquiez une offre appelée ServiceNow Prod.

Donc, vous utilisiez déjà le modèle que nous avons à l’écran en ce moment, où vous dites : « Nous changeons quelque chose dans ServiceNow, » et puis la description décrira ce que c’est, ce qui explique pourquoi nous avons un peu opté pour ce modèle, où au lieu d’avoir plusieurs instances de service par module, nous en aurons une pour Prod, QA, et Dev, et ensuite nous aurons nos offres, qui sont vraiment ce que les gens consomment dans ServiceNow que nous serons en mesure d’utiliser dans un avenir rapproché, où nous créons un changement, ServiceNow Prod, et l’offre est la solution EA ou la gestion des événements, où nous activons une propriété qui peut affecter la façon dont les alertes sont traitées. C’est donc ainsi que nous avons conçu ce modèle, parce que vous utilisiez déjà ServiceNow Prod. Est-ce que c’est logique?

Denise : Oui, c’est logique. Et un autre point est que nous étions en fait dans un état de confusion. Parce que nous avions beaucoup d’applications où le service et l’offre portaient le même nom. Donc, avec ces services que nous avons définis plus haut niveau, puis en laissant l’offre pour l’application, et ensuite, bien sûr, le CI pour l’instance de celle-ci, cela en soi a apporté beaucoup de clarté à travers l’organisation.

Maxime : Super. Oui, vous voulez donc éviter les BSO redondants, qui ont le même nom que votre instance de service. Donc, j’ai montré ce modèle à d’autres clients, et ils l’aiment beaucoup. Donc, ce que nous avons conçu s’est avéré très utile.

Denise : Oui, en effet. J’appuie cela à cent pour cent. Oui.

Maxime : C’est super à entendre. Je vais terminer avec… Merci beaucoup, Denise, d’avoir fourni ce contexte incroyable. Je vais poursuivre avec les meilleures pratiques de modélisation.

Donc, la meilleure pratique numéro un, modélisez avec des gens, pas seulement avec des outils. L’automatisation, comme Service Mapping, est puissante, mais elle découvre ce qui existe. Vous avez besoin d’experts pour définir ce qui est important. Donc, comme nous l’avons fait ensemble, Denise, et Dieu sait que nous avons fait beaucoup de ces sessions de modélisation.

Denise : Oh mon Dieu, oui. Ouais.

Maxime : C’est chronophage au début, mais nous avons passé au travers de votre liste d’applications MVP. Vous avez dû planifier avec divers propriétaires d’applications, propriétaires de services, architectes d’entreprise, différents experts en la matière. Nous allons dans Lucidchart. Nous commençons à dessiner ce que nous avons vu ici, n’est-ce pas? Le bleu, ce sont vos applications d’affaires, le jaune, c’est votre instance de service, et le vert, c’est tout ce qui relève de la consommation de services. Donc, vos services d’affaires et vos offres de services d’affaires. Et ensuite, nous passons en revue toutes les questions que nous avons examinées il y a quelques diapositives. Consommez-vous dans ITSM? Avez-vous des piles applicatives différentes? Et ensuite, en groupe, nous nous entendons sur le juste milieu pour vos instances de service et vos BSO et services d’affaires. Et puis c’est écrit ici, menez toujours des sessions de modélisation de données avec les parties prenantes clés avant de tenter le Service Mapping.

Denise : Oui. 100 %. Oui.

Maxime : Le Service Mapping nécessite un point d’entrée pour les environnements sur site. Pour le nuage, c’est basé sur des balises (tags), mais pour le nuage, si vous avez une application qui possède des balises d’application différentes pour vos applications, vous devrez créer ces instances de service spécifiques. Donc, assurez-vous d’avoir défini le juste milieu avant même de tenter le Service Mapping.

Meilleure pratique numéro deux. Et je pense que c’est ma dernière diapositive. Nous avons conçu, entre CAE et Ateko, ce que nous appelons un arbre de décision pour la cohérence. Ce que cela signifie, c’est que lorsque nous regardons une liste d’applications qui est maintenue dans une solution EA, un Excel, ou n’importe où, nous devons comprendre : est-ce une application d’affaires, ou est-ce vraiment juste un service technique? N’est-ce pas? Donc, comment comprenez-vous cela? Nous avons établi une série de critères de sorte que si vous cochez ces critères, vous devriez avoir votre réponse.

Disons donc que vous commencez avec une liste d’applications dans un document Excel. Vous en avez, je ne sais pas, des centaines, peu importe combien vous en avez. Pour chacune de ces entrées, si vous êtes incapable de déterminer s’il s’agit d’une application d’affaires ou d’un service technique, passez en revue les questions suivantes. Si vous pensez que c’est une application d’affaires, le premier critère est : est-ce que c’est utilisé par des employés? Est-ce consommé par des partenaires ou des clients? Est-ce que ça soutient directement une capacité d’affaires ou un processus d’affaires? A-t-elle un propriétaire d’affaires désigné, n’est-ce pas, l’application d’affaires a clairement quelqu’un qui la possède. La pertinence, ce qui signifie qu’elle a des dépendances avec d’autres applications? Elle a une propriété, du soutien, etc. Possède-t-elle un impact opérationnel ou financier significatif?

C’est drôle, ce matin je regardais une liste, en fait, pour un autre client, et l’une des entrées était Adobe Acrobat. Adobe Acrobat, c’est quelque chose que l’on pousse sur le poste de travail de quelqu’un pour qu’il le consomme, n’est-ce pas? Ça n’a pas d’empreinte dans l’environnement. Ça n’a pas de propriétaire d’affaires. Il peut y avoir de la conformité logicielle autour, mais ce n’est pas une application d’affaires, n’est-ce pas? Le dernier critère : a-t-elle une ou plusieurs instances déployées dans l’environnement? Vous n’avez pas besoin d’avoir une base de données SQL, quelques serveurs ou un répartiteur de charge pour que quelqu’un consomme Adobe Acrobat. D’accord? Donc, en passant au travers de cette liste de vérification, je déterminerais alors qu’Adobe Acrobat n’est pas une application d’affaires. C’est un logiciel, n’est-ce pas? Il n’a donc pas sa place dans CSDM.

Si, toutefois, vous aviez une entrée dans la liste, disons Entra ID, qui réplique les informations AD vers Azure. Là, vous soupçonnez qu’il s’agit d’un service technique. Vous passeriez donc en revue les critères suivants. Est-ce consommé par d’autres services TI, applications ou infrastructures, et non directement par un consommateur d’affaires? Cocher cette case est généralement suffisant pour déterminer s’il s’agit d’un service technique ou d’une application d’affaires. Ce que cela signifie, c’est que vous commencerez dans le domaine de la conception (le domaine bleu du CSDM), ou vous commencerez directement dans la livraison de services (le domaine orange du CSDM). C’est ce que cela signifie. Application d’affaires ou service technique. Les deux finiront par aboutir à l’instance de service, soit dit en passant.

Un autre critère pour le service technique : fournit une capacité technologique fondamentale. Exemple : hébergement, base de données, API, réseautique, identité, gestion des accès, type de capacité technologique des services réseau. L’autre critère est : a un propriétaire technique ou de service TI désigné. Et finalement : impacte la disponibilité et la performance des services TI qui en dépendent. Un autre exemple, vous auriez Active Directory. Je ne consomme pas directement AD. Mais lorsque je m’authentifie sur mon portable Windows, AD roule en arrière-plan et me permet d’accéder à mon ordinateur. De plus, si AD tombe en panne, un grand nombre d’applications cesseront de fonctionner, n’est-ce pas? Donc, AD a évidemment un impact technique sur la disponibilité d’autres applications.

Et puis, une fois que vous avez déterminé s’il s’agit d’une application d’affaires ou d’un service technique, vous créerez un service applicatif pour l’application d’affaires. S’il s’agit d’un service technique, vous créerez alors un TSO, n’est-ce pas? Qui contiendra votre SLA, votre groupe de soutien, ce qui est spécifique à l’environnement (Prod, QA), etc. Et ensuite, l’offre de service technique contiendra une instance de service ou un service applicatif. Et ensuite, vous pourriez avoir une dépendance entre votre service applicatif AD, qui est probablement composé de plusieurs serveurs, et votre application déployée dépendrait alors de votre AD. C’est là que le lien prend tout son sens. Avant que je ne conclue, Denise, avais-tu des commentaires?

Denise : Non, juste un grand merci pour ta patience envers nous et envers tout le monde, parce que je sais que pour nous, étant au tout début, très immatures en matière de CSDM. Merci pour ta patience. Merci, tu sais, de t’être assis à toutes les sessions avec nos propriétaires de produits, ces sessions laborieuses. Mais oui, juste pour dire que nous sommes très, très reconnaissants envers toi et Ateko de nous guider dans notre parcours CSDM.

Maxime : Merci beaucoup pour tes commentaires, Denise. Je vais juste terminer avec ceci : c’est beaucoup d’efforts au début, mais l’effort en a définitivement valu la peine. Un grand merci donc d’avoir assisté, ou du moins d’avoir écouté cette session, devrais-je dire.