03 décembre

Livre Blanc

Ce livre blanc présente la philosophie de Carto-SI.
Elle est intéressante à connaître pour mieux appréhender le positionnement de l’outil dans son domaine. Pour prendre en main l’outil, consultez ensuite l’article “Prise en main”.

Sommaire

Bien démarrer avec Carto-SI

Cartographier un Système d’Information était jusqu’à présent une tâche difficile, à parfois en devenir un objectif inespéré des Directeurs des Systèmes Informatiques (DSI). 

Depuis plus de 13 ans nous avons rencontré pléthore de DSI. Tous sont arrivés au même constat  : “Cartographier un SI est une tâche longue, coûteuse et rarement réalisée avec succès.”

Il n’est pas rare qu’elle mobilise plusieurs consultants qui, finalement, proposent un livrable inexploitable (ou incompréhensible) et déjà obsolète car, et en parallèle, le SI n’a pas cessé d’évoluer.

L’objectif du DSI est de maîtriser son SI. Mais que signifie maîtriser son SI ? Est-ce connaître l’ensemble des informations qui constituent votre SI ? Certainement pas ! 

Nous pensons foncièrement qu’au-delà d’avoir les machines les plus performantes ou les développeurs les plus compétents, les directions DSI qui « gagnent » sont celles qui communiquent le plus efficacement. Il faut donc changer la manière dont les femmes et les hommes communiquent.

L’équipe Carto-SI se retrouve autour de cette citation :

«Les gagnants seront ceux qui restructurent la manière dont l’information circule dans leur entreprise.»

 – Bill Gates

Autour d’un produit simple et compréhensible par tous, Carto-SI propose de réconcilier les trois principaux acteurs  que l‘on retrouve généralement dans un système d’information.

  • Le métier 
  • Le développement applicatif
  • L’infrastructure technique

Dans le cadre de la mise en place de cartographies chez de multiples clients, les ingénieurs de Carto-SI ont longuement échangé et approfondi cette problématique.

Au-delà d’un outil efficace, Carto-SI vous propose une philosophie que nous allons tenter de vous transmettre dans ce livre blanc.

Notre objectif est de vous fournir les clés afin de cartographier votre système d’Information avec succès.

Une Cartographie Opérationnelle versus la Modélisation de votre SI ?

Carto-SI est une Cartographie Opérationnelle, elle permettra de représenter votre SI tel qu’il est réellement avec ses spécificités et ses incohérences afin de les corriger.

Cette approche est différente d’une modélisation qui vous contraint  à suivre et apprendre des concepts complexes, propre à une expertise, frameworks spécifiques et modélisations (TOGAF, Zachman, Archimate,  etc …  ).

Nous avons donc volontairement abandonné tous les concepts liés à la modélisation pour simplifier la démarche de cartographie.

Carto-SI est l’outil parfait pour mettre en place les orientations définies dans le schéma  directeur de votre société. Il est aussi un préalable à la réalisation d’un schéma directeur afin de partir d’une base fiable qui vous permettra  d’élaborer une meilleure stratégie. 

L’application permettra d’obtenir une photo de votre SI pour ensuite décider des choix organisationnels à mettre en place.

Il est donc un lien entre la théorie et la réalité opérationnelle de votre SI.

Une Cartographie collaborative

Nous savons aujourd’hui que la connaissance du SI est partagée  par plusieurs personnes de la société (chef de projet, MOA, MOE, directeur de projet, exploitant, Administrateur Système, etc.).

Toutes ces personnes peuvent contribuer à la remontée d’informations.

Dans cet état d’esprit, un outil de cartographie a pour vocation d’être partagé entre les différents acteurs du SI. Il doit aussi proposer une utilisation simple pour faciliter la diffusion des informations dans l’organisation.

Jusqu’alors la cartographie n’était utilisée et visible que par les experts, les puristes et les  initiés (les Architectes, Directeurs de projet, Chef de Service, etc.). Depuis peu, nous observons qu’une nouvelle population en devient utilisatrice avec des compétences multiples. Les opérationnels (chefs de projets métiers ou fonctionnels, responsables d’infrastructure, DPO, Business Analysts…) peuvent désormais disposer d’une vision du SI. Ils sont aussi accès aux impacts entre les différents éléments, d’un accès simplifié au cheminement de la donnée et plus généralement à l’information dont ils manquent cruellement et qu’ils devaient glaner auprès des “sachants”.

Qu’est-ce qu’une APPLICATION ?

Nous proposons la définition suivante d’une application dans le cadre de la cartographie Carto-SI.

Définition : Une APPLICATION est un composant logiciel qui se déploie de manière autonome et qui rend un service à un utilisateur final ou à au moins deux APPLICATIONS  du système d’information.

Cette définition est celle que nous proposons à nos clients, elle est le fruit de nos différentes interactions avec leur SI.

Elle vous permet de réaliser  une cartographie selon une bonne granularité : ni micro, ni macro.

Par exemple, une application de comptabilité est une APPLICATION car elle a un cycle de vie propre à elle (se déploie de manière autonome)  et rend un service à plusieurs entités du SI.

 

Nous rencontrons régulièrement des clients qui s’interrogent sur la représentation de leur BDD.

Nous distinguons deux cas :

Si leur Base De Données n’est utilisée que par une seule  APPLICATION (cas le plus courant) elle ne devra pas être représentée comme une APPLICATION. Elle sera représentée comme un composant technique utilisé par une application (à voir plus tard) si le vous le souhaiter. 

 Si la BDD est utilisée par au moins deux APPLICATIONS, elle devient une APPLICATION  à part entière (souvenez vous de notre définition d’une APPLICATION), il faudra la représenter comme telle, nommer un responsable d’APPLICATION et tout changement de la BDD devra faire l’objet d’une communication vers les responsables d’APPLICATION identifiés dans le cadre d’une étude d’impact.

 

Dans le cas d’un ERP (Enterprise Ressource Planning ) ou PGI (Progiciel de Gestion Intégré), Carto-SI propose une représentation permettant d’aller toujours plus loin dans l’étude d’impact.

Un ERP est constitué d’un composant principal et de plusieurs modules (ou applications) dépendants de ce dernier.

Chaque module/application est indépendant et a un cycle de vie indépendant.

Le module principal est une APPLICATION et chaque module est également une APPLICATION.

Le module de comptabilité peut être déployé de manière autonome sans impact sur le module principal, il répond à toutes les caractéristiques d’une APPLICATION. Il faudra nommer un responsable et tout changement de ce module devra faire l’objet d’une communication vers lui.

Qu’est-ce qu’une étude de dépendance ?

Définition : Une dépendance est simplement l’information qu’un composant a besoin d’un autre composant pour fonctionner.

Par exemple, une APPLICATION métier peut dépendre d’un LDAP (dans le cadre de l’authentification).

Une étude d’impact se fait donc à travers les dépendances déclarées par un être humain.

Nous précisons un « être humain » car le fait qu’une APPLICATION dépende d’une autre APPLICATION ne peut pas être détectée automatiquement. Le sens du flux technique ne permet pas de le savoir.

Exemple : Une application A envoie un fichier à une Application B. 

Techniquement nous aurons une ouverture de flux allant de A vers B. Comment déterminer en cas d’incident technique sur cet échange laquelle entre l’application A et B sera perturbée.

Il peut y avoir deux cas possibles : 

A impacte B : par exemple, l’application B à besoin de ce fichier pour mettre à jour des informations.

B impacte A : par exemple, L’application A à besoin d’exporter des données pour purger sa Base De données et rester performante.

Seuls les responsables applications des APPLICATIONS A et B peuvent déterminer le sens de la dépendance.

Maîtriser son SI passe par la maîtrise du changement. 

Pouvoir identifier l’intégralité des briques de son SI est une chose mais pouvoir identifier de manière ciblée la partie de son SI impactée par un changement en est une autre, c’est ce que propose Carto-SI de faire.

La performance d’un SI est proportionnelle à sa capacité à changer et à innover, Carto-SI permet de réaliser de réelles études d’impact par le biais de la notion de dépendances.

Tout comme dans un SI, les différents types de composants de Carto-SI dépendent les uns des autres, cette dépendance est transverse à tout le SI et nous avons naturellement des tâches métier qui dépendent des APPLICATIONS qui elles-mêmes dépendent des composants logiciels et techniques.

C’est ainsi qu’avec Carto-SI vous pouvez connaître l’impact qu’un serveur peut avoir sur le business de votre société.

Une étude d’impact se fait donc à travers les dépendances déclarées par un être humain.

Nous précisons un « être humain » car le fait qu’une APPLICATION dépende d’une autre APPLICATION ne peut pas être détectée automatiquement. Le sens du flux technique ne permet pas de le savoir.

Exemple : Une application A envoie un fichier à une Application B. 

Techniquement nous aurons une ouverture de flux allant de A vers B mais comment déterminer en cas d’incident technique sur cet échange laquelle entre l’application A et B sera perturbée.

Il peut y avoir deux cas possibles : 

A impacte B : par exemple, l’application B à besoin de ce fichier pour mettre à jour des informations.

B impacte A : par exemple, L’application A à besoin d’exporter des données pour purger sa Base De données et rester performante.

Seuls les responsables applications des APPLICATIONS A et B peuvent déterminer le sens de la dépendance.

Maîtriser son SI passe par la maîtrise du changement. 

Pouvoir identifier l’intégralité des briques de son SI est une chose mais pouvoir identifier de manière ciblée la partie de son SI impactée par un changement en est une autre, c’est ce que propose Carto-SI de faire.

La performance d’un SI est proportionnelle à sa capacité à changer et à innover, Carto-SI permet de réaliser de réelles études d’impact par le biais de la notion de dépendances.

Tout comme dans un SI, les différents types de composants de Carto-SI dépendent les uns des autres, cette dépendance est transverse à tout le SI et nous avons naturellement des tâches métier qui dépendent des APPLICATIONS qui elles-mêmes dépendent des composants logiciels et techniques.

C’est ainsi qu’avec Carto-SI vous pouvez connaître l’impact qu’un serveur peut avoir sur le business de votre société.

Les Flux

Il est courant que nous soyons interrogés voire interpellés sur la notion de flux.

Cette notion n’est à pas confondre avec la notion de dépendance.

Contrairement à la notion de dépendance,  la notion de flux est très bien connue par l’ensemble des opérationnels que nous rencontrons, ils ont généralement une parfaite  connaissance de l’ensemble des flux inter-applicatifs et une vision précise de leur fonctionnement.

Pour Carto-SI, la notion de flux donne une information sur la nature de la dépendance au même titre que le code ou le nom, la criticité des échanges, la technologie de l’échange (FTP, SFTP, HTTP, HTTPS, etc.), sa fréquence ou encore le sens, qui, de surcroît, peut être, soit technique par la vue réseau, soit fonctionnel.

Toutes ces informations sont à renseigner au bon niveau de la cartographie et nous pensons que sa place est dans la dépendance. Pourquoi ? car c’est une information « micro », et bien qu’importante au niveau des opérationnels, elle reste secondaire pour la vision « macro », la vision du DSI.

La vision Macro d’une DSI doit permettre de répondre aux interrogations suivantes :

« Comment circule la donnée dans mon entreprise ? »

« Quels seraient les impacts d’un changement d’une brique de mon SI ? »

« Qui utilise la donnée IBAN dans mon SI ? »

Et à ces interrogations, nous savons que la notion de dépendance apporte une réponse, ce que ne fait pas la notion de flux.

La vision « micro » d’un opérationnel doit répondre aux interrogations suivantes :

« Dans le cadre de l’échange de l’information SALARIÉ entre l’application A et B qui est l’émetteur de la donnée ? »

« J’ai besoin d’ajouter un champ sur un fichier que je manipule qu’elle serait l’impact et qui dois-je contacter ? »

Et à ces interrogations, nous savons que la notion de dépendance apporte une réponse alors que la notion de flux, pas toujours…

Dépendance vs Flux

Il faut noter que la notion de dépendance est une notion plus simple et qui n’introduit pas d’ambiguïté. Cette notion pourra être facilement partagée entre les acteurs métiers et les acteurs de l’infrastructure technique.

La notion de flux est limitée aux acteurs du développement applicatif, elle n’est pas nécessaire pour les métiers et les acteurs de l’infrastructure technique.

Toutes ces raisons font que dans Carto-SI nous parlerons principalement de dépendance.

NB : Il existe une exception cependant dans la partie métier.

Il est laissé à la discrétion des utilisateurs de définir ce que signifie la flèches entre les tâches d’une activité. Elles pourront donc signifier une suite d’actions à réaliser dans une activité par exemple. Cette souplesse est autorisée car elle n’influe pas nos études d’impact.

Qu’est-ce qu’un responsable d’application ?

Dans Carto-SI, nous n’avons qu’un responsable par Application car nous pensons que : 

  • “lorsqu’il y a plusieurs responsables, il n’y a pas de responsable”
  • et que si le Responsable d’application est en congés ou en déplacement, il conserve le rôle de Responsable d’application. (si des communications doivent être redirigées pendant son absence, cela est à gérer hors Carto-SI)

Cette notion est importante dans la mesure où elle permet d’identifier clairement la personne à contacter dans le cadre d’échanges concernant un sujet opérationnel d’une Application.

NB : Cette notion ne doit pas être confondue avec la notion de notifications concernant la vie d’une application (cette dernière fait l’objet de discussion dans le cadre d’une éventuelle évolution)

Domaine de la DSI vs Domaine métier 

Dans un système d’information cohabitent deux types d’organisation : 

  • l’organisation de la DSI
  • l’organisation Métier

Ces deux organisations ne sont pas à confondre, elles ont souvent un rythme de changement différent.

L’organisation de la DSI correspond à la manière dont les applications sont réparties. Dans Carto-SI, nous le nommons le DOMAINE de la DSI.

L’organisation  Métier, qui est plus complexe car organisée en sous-domaines et connaît un rythme de changement plus fréquent (réorganisation liée à l’arrivée d’une autre direction/ fusion acquisition, etc …), elle correspond à la manière dont les services métiers se répartissent les tâches. Dans Carto-SI, nous la nommons le DOMAINE METIER.

Chaque DOMAINE a ses compétences : 

Le DOMAINE de la DSI aura le savoir de tout l’écosystème applicatif

Le DOMAINE MÉTIER maitrisera les tâches métiers, autrement dit les tâches liées au business de l’entreprise.

Il est donc naturel que dans Carto-SI, nous ayons choisi de lier les APPLICATIONS aux DOMAINES de la DSI et les Tâches aux DOMAINES MÉTIER.

Le lien entre ces différents niveaux de domaines est traduit par la réponse aux questions suivantes :

« Quelles applications sont utilisées pour la réalisation d’une tâche métier »

-> Un lien de dépendance sera créé d’une Tâche vers chaque APPLICATION.

« Quelles tâches métier sont réalisées avec une application »

-> Un lien de dépendance sera créé de chaque Tâche vers l’APPLICATION en question.

Par exemple, si l’entreprise possède un service RH qui utilise deux applications gérées par la DSI, il faudra créer un DOMAINE de la DSI nommé “RH”, auprès duquel seront attachées les applications, puis un DOMAINE MÉTIER nommé “RH”, auprès duquel seront attachées les tâches. Il faudra ensuite lier chaque tâche listée à chaque application concernées.

Problématiques à résoudre

Les services métiers de Carto-SI

Carto-SI n’est pas un outil de modélisation, notre objectif est de proposer une Cartographie opérationnelle de votre SI et pour la partie métier nous avons toujours le même état d’esprit.

Nous avons donc délibérément simplifié l’approche métier afin de garder une granularité permettant de rester efficace.

Pour représenter l’aspect métier de Carto-SI, nous vous demandons donc de décrire la liste des Activités de votre entreprise ainsi que la liste de tâches pour chaque action de votre SI.

Une activité est par exemple « Le recrutement de cadre », cette activité est composée de tâches telles que :

  • Rédaction de la fiche de poste
  • Validation par les managers
  • Communication sur les réseaux sociaux
  • Études des cv reçus 
  • Prise de contact téléphonique 
  • Prise de rendez-vous 
  • Entretien RH
  • Entretien opérationnel 
  • Proposition/Validation contrat 
  • Préparation arrivée nouvel employé 
  • Accueil du nouvel employé  

Il est important de noter que les tâches sont liées au DOMAINE MÉTIER. Il est courant que dans une activité, plusieurs entités métiers interviennent dans la même ACTIVITÉ mais dans des tâches différentes.

Dans l’exemple ci-dessus, la tâche « Proposition/Validation contrat » est réalisée par le service juridique et la « Préparation arrivée nouvel employé » est réalisée par les Services Généraux de la société. 

Les tâches  sont liées entre elles par un lien de dépendance. Le lien entre le monde métier et le monde de l’application se fait au travers d’une dépendance entre une tâche et une APPLICATION. Grâce à cette dépendance nous allons pouvoir déterminer l’impact des APPLICATIONS sur le business de l’entreprise.

Suivre la donnée dans votre Système d’Information

La notion de donnée est un point capital pour la DSI, dès le début de la conception de Carto-SI nous avions en tête d’aider nos clients à améliorer la gestion de la donnée.

Le RGPD est venu comme un accélérateur vers cette démarche et nous a permis d’aborder cette notion plus facilement avec nos clients.

Tout d’abord, il est important de préciser que dans Carto-SI, la donnée se balade uniquement entre applications.

Vouloir représenter le chemin de la donnée autrement est une tâche hautement difficile et ne correspond (à ce jour) à aucun cas d’utilisation remonté par nos clients. 

Nous proposons deux notions simples pour représenter la donnée dans votre SI.

La première (la plus macro) est la notion d’OBJET APPLICATIF qui correspond à un flux de données échangé entre deux APPLICATIONS, par exemple vous pouvez imaginer des échanges XML, JSON ou EDIFACT.

Si vous observez plusieurs flux de données de format ou de contenu différents autour du salarié nous vous conseillons de créer des OBJETS APPLICATIFS distincts.

Cela permettra de remonter cette incohérence et de mener les travaux pour la solutionner.

La deuxième notion est la notion de DONNÉE, elle est une approche plus fine.

Une DONNÉE peut être une adresse, un nom, un login, un numéro de téléphone et même plus sensible comme une orientation politique, sexuelle, etc …

Elle vous permet de lister l’ensemble des DONNÉES qui circulent dans votre SI et de simplement les lier aux différents OBJETS APPLICATIFS décrits précédemment.

Ainsi vous serez en mesure de répondre à la question suivante : 

 » Comment circule le login dans mon système d’information »

Dans le cadre de la RGPD nous nous appuyons sur la notion de DONNÉE et OBJET APPLICATIF pour réaliser les registres de traitement et PIA demandés par la CNIL.

Intégration les éléments techniques

L’objectif de Carto-SI est aussi de « réconcilier » les différents acteurs du Système d’information, il faudra aussi bien rapprocher le monde applicatif du monde du métier tout comme les applicatifs du monde de la technique (infrastructure/exploitant, etc…)

Dans cette perspective nous permettons d’intégrer tous les composants techniques du SI.

Nous souhaitons savoir  : 

« Quelle application est hébergée par cette Base De Données »

ou 

« Quel impact sur mon métier aurait l’extinction d’un serveur. »

Les composants techniques seront liés les uns avec les autres et nous pourrons par le biais des Champs Personnalisés, enrichir les dépendances et les composants techniques.

Attention : pas d’objets applicatifs à ce niveau de la Cartographie.

Les différents environnements techniques (PROD, PRE-PROD, TEST, etc.) peuvent être intégrés dans la partie technique, autrement dit, une BDD de prod ou de préprod sera liée de la même manière à son application.

Cette notion de multiples environnements n’existe que dans la partie technique.

Pour les distinguer, vous pouvez soit utiliser un Champ Personnalisé soit choisir des couleurs différentes.

NB : Nous discutons actuellement sur l’évolution des composants de sorte à ce que nativement nous portions des notions techniques comme adresse IP, l’environnement, type de composants etc. … 

Les spécificités de mon SI dans Carto-SI

Nous partons du principe que vous restez experts dans tout ce qui est spécifique à votre Système d’Information.  Pour cela nous avons créé la notion de Champs Personnalisés, cette notion portera les particularités de votre Système d’Information.

Un Champ Personnalisé peut être affecté à tous les composants de votre SI.

Il peut être pour exemple le langage de programmation de l’application (JAVA, C++, C#, Python etc..).

Le champ pourra faire l’objet d’étude d’impact : « quelles applications sont développées en JAVA » .

Ce Champ Personnalisé pourra faire l’objet de statistiques : « Quelle est la répartition des applications par langages de programmation ?» 

Etablir une démarche itérative

Cartographier son SI, c’est d’abord pouvoir le connaître et le partager. Nous proposons une démarche itérative qui, à la fin de chaque étape, vous permettra d’en connaître plus sur votre SI. Chaque étape est un niveau de maturité qui vous permettra d’exploiter les informations récoltées  pour améliorer votre SI.

  • Lister les applications de son SI : 

Cette étape peut paraître triviale mais elle est essentielle. Lister les applications et décrire leur rôle dans le SI peut faire remonter des sujets importants. Il arrive souvent que nos clients constatent, à cette étape, qu’une fonctionnalité d’une application est en double dans le SI, ou qu’une application est mal utilisée ou détournée de son objectif initial et principal.

Nous pouvons même identifier les décommissionnements possibles d’applications non utilisées.

Lister et recenser les dépendances de son SI est une étape tout aussi importante. A l’instar des applications, décrire les dépendances peut mettre en exergue des dépendances à supprimer ou à modifier.

  • Ajouter les OBJETS APPLICATIFS

Cette étape vous permet d’apprendre la nature des messages inter-applicatifs.

  • Ajouter les DONNÉES

Cette étape vous permet de suivre de manière fine la donnée dans votre SI.

Une fois ces étapes réalisées, vous pouvez parallèlement intégrer les éléments techniques et les éléments métiers.

A chaque étape, vous découvrez votre SI et pouvez l’améliorer et surtout le simplifier.

Il est important de garder en tête que nous vous proposons un canevas et qu’il faut l’adapter en fonction des informations que vous pouvez le plus facilement obtenir.

Conclusion

Nous avons tenté de vous transmettre toute notre expérience à travers ce livre blanc. Cette expérience est issue de nos échanges avec les opérationnels que nous rencontrons. 

Nous aimons échanger, confronter nos opinions et évoluer pour finalement trouver des solutions.

Tout comme Carto-SI, notre vision évolue, s’affine et s’adapte aux problèmes que nous rencontrons. Nous espérons que ce livre blanc évoluera de la même manière, nous comptons sur vous pour nous faire grandir. Vos remarques, objections et questions sont les bienvenues.

 


Tags:

Share:

FacebookTwitterLinkedIn

0 Commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.