urbanisation-si.com

La rationalisation des applications est cruciale pour les organisations afin de maintenir leur agilité et d'optimiser les coûts. Cela est particulièrement important avant d'entreprendre une transformation digitale, telle que la migration vers le cloud ou le changement de votre système d’ERP. 

La rationalisation des applications est le processus d'organisation et de rationalisation de votre portefeuille applicatif pour accompagner au mieux vos objectifs commerciaux.

Avant de tenter toute transformation, vous devez vous assurer que votre paysage actuel est optimisé, sinon vous risquez non seulement de migrer des problèmes existants vers votre architecture cible, mais également de créer de nouveaux problèmes. La rationalisation des applications permet à l’entreprise de démarrer le processus de transformation au bon moment, avec la meilleure visibilité. 

Cependant, cela ne doit pas être un processus ponctuel. La rationalisation des applications doit être une habitude régulière pour répondre aux besoins de transformation continue exigés dans l’ère moderne.

Pour soutenir la rationalisation régulière et la transformation continue, vous avez besoin d'une solution comme l’outil d’architecture d'entreprise LeanIX, capable de suivre rigoureusement votre portefeuille d'applications et de vous aider à concevoir des feuilles de route pour la transformation.

Pourquoi la rationalisation est-elle importante pour la transformation ?

Rappelons-le, la rationalisation des applications est le processus d'organisation et de rationalisation de votre portefeuille applicatif pour accompagner au mieux vos objectifs commerciaux.

La meilleure pratique consiste à catégoriser chaque application selon la méthodologie TIME de Gartner :

Tolérer : accepter l'application dans son état actuel pour le moment

Investir : donner la priorité aux applications les plus stratégiques

Migrer : Trouver une autre application qui répond davantage à un besoin commercial

Éliminer : supprimer l'application quand elle n'est pas nécessaire ou souhaitable

Une fois que vous avez effectué cette catégorisation, vous pouvez :

• Supprimer les applications qui ne sont plus nécessaires
• Éliminer progressivement les applications nécessaires mais indésirables
• Remplacer les applications par d’autres qui conviennent mieux ou les migrer vers le cloud
• Utiliser le budget que vous avez économisé en investissant dans de nouvelles applications clés

Il est essentiel d'effectuer une rationalisation des applications pour garantir que votre portefeuille applicatif est optimisé et offre le meilleur retour sur investissement possible (ROI). Tout aussi importante est la nécessité de répéter ce processus régulièrement pour vous assurer que votre portefeuille s'adapte aux besoins changeants de votre entreprise.

Seulement 15 % des organisations effectuent une rationalisation des applications régulière, selon notre enquête sur l'optimisation des coûts informatiques en 2023.

Pour en savoir plus, téléchargez l'enquête complète.   

Les organisations qui effectuent une rationalisation des applications de manière régulière seront prêtes à relever tous les défis auxquels elles seront confrontées. Il est particulièrement important d'harmoniser votre portefeuille avant toute transformation digitale.

Transformation sans rationalisation

Imaginez que vous deviez déménager et donc emballer tous vos biens pour les transporter dans votre future maison. Dans le meilleur des cas, vous trieriez d'abord les objets pour voir ceux qui pourraient être jetés, puis vous emballeriez en toute sécurité ceux que vous souhaiteriez conserver.

De la même manière, une rationalisation des applications peut vous assurer que vous êtes entièrement prêt pour votre transformation avant de la commencer. Si vous ne le faites pas, votre transformation pourrait échouer.

Une étude célèbre du BCG a révélé que 70 % des transformations digitales échouent. La rationalisation des applications est essentielle pour vous donner la meilleure chance de réussir.

Sans rationalisation des applications, plusieurs conséquences : 

1 Des applications qui ne fonctionnent plus

Vos applications héritées ne sont pas conçues pour être aussi flexibles que les logiciels modernes et peuvent moins bien fonctionner, voire plus du tout. Une rationalisation des applications soumettra vos applications à des tests et déterminera si elles fonctionneront comme prévu dans votre nouveau paysage informatique.

2 Il est fréquent d’oublier l’existence de certaines applications 

Maintenant que l'utilisation d'applications SaaS au sein des entreprises est devenue monnaie courante, il est inévitable que certaines applications en cours d'utilisation ne soient pas documentées. La rationalisation des applications impliquera la recherche de ces applications "fantômes" et veillera à ce qu'elles soient prises en compte dans le cadre de votre transformation.

3 Certains coûts sont inattendus

De la mise à niveau d'applications qui ne conviennent plus post-transformation, aux coûts de migration inattendus liés à des applications non découvertes, vous n'aurez pas une estimation complète des coûts de votre transformation avant d'avoir réalisé une évaluation rigoureuse de votre portefeuille applicatif.

4 Réticence potentielle des employés

Un facteur majeur de réussite de votre transformation est lié à l'adhésion des parties prenantes. Un effort de rationalisation des applications aidera à justifier des décisions en toute transparence auprès de votre leadership et de vos employés. 

5 Problèmes réglementaires

Enfin, il est possible de réaliser une migration de données et constater que votre nouvelle architecture n'est plus conforme aux exigences réglementaires. Cela devient encore plus complexe lorsque l'on considère les différentes réglementations des régions du monde.

La rationalisation des applications ne s’arrête pas là

Pour optimiser vos chances de succès dans votre transformation, vous devez mener à bien un effort de rationalisation des applications. Cependant, trop souvent, les informations que vous découvrez pendant le processus sont immédiatement égarées une fois que vous avez terminé.

Conserver ces informations dans une base de données dédiée vous permettra de répéter les efforts de rationalisation des applications régulièrement, sans avoir à recommencer à zéro à chaque fois. 

Merci pour vos commentaires qui seront les bienvenus, ainsi que vos retours d'expérience heureux ou malheureux, qui pourront profiter à nos lecteurs.

"Il y a une illusion anthropomorphique qui s'installe avec les machines, avec le risque d'une manipulation considérable."

Serge Tisseron

[Cet article a été rédigée par un contributeur extérieur à la rédaction. Le site urbanisation-si.com ne le rémunère pas, et ce dernier n'a pas non plus payé pour publier ce texte. Le choix de le publier s'est donc fait uniquement sur des critères éditoriaux.]

La Documentation d'Architecture Technique (DAT) est un élément essentiel pour la réussite de vos projets informatiques. Elle vous permet de définir, de communiquer et de valider les choix techniques qui soutiennent vos services. Elle vous aide également à respecter les normes de sécurité, à optimiser les ressources et à anticiper les impacts.
Mais comment créer et maintenir une documentation d'architecture de manière efficiente, à jour et partagée par tous les acteurs de la DSI ? Comment éviter les documents Word, Excel et PowerPoint qui se perdent, se contredisent ou deviennent rapidement obsolètes ? Comment gagner du temps et de la productivité dans la gestion de vos projets ?

Dans le référentiel d'architecture du SI, il arrive parfois de trouver des photos de schémas
griffonnés à la main et que l'on a oublié de mettre au propre (source C4 model).

Vous reconnaissez-vous dans ce processus
de gestion de référentiel d’architecture ?

De nombreuses entreprises éprouvent des difficultés à mettre en place une documentation efficace en raison de problèmes de priorisation, de processus inadéquats, et du manque de cohérence dans la construction du DAT, qui est une pièce essentielle de la documentation.

Par exemple, elles vont utiliser : 

• Diagrams.net anciennement Draw.io (A lire > diagrams.net ou draw.io : outil en français gratuit pour dessiner des diagrammes ; mais quel est véritablement son spectre d’utilisation ? La réponse dans notre test.) ou PowerPoint pour les schémas applicatifs et techniques,
   
• Excel pour la cartographie des flux et des interfaces et le référentiel des matériels,
   
• Word pour le document de synthèse, la description de plus haut niveau des Web Services, les Use Cases et la volumétrie...

Les corrections et les améliorations se font fréquemment en urgence, ou bien il faut rapidement implémenter la solution et l’on verra plus tard pour la documentation.

Ce processus de tous les dangers adopté par la grande majorité, consistant à faire d'abord et à documenter ensuite, va entraîner une perte de contrôle et donner naissance à du shadow IT (partie de l’IT non maîtrisée ou inconnue), comme des flux ouverts alors qu’ils ne devraient pas, ou des machines sur lesquelles on ne sait pas ce qui est installé. En cas de crise, cette situation risque de devenir très problématique.

Lors d’une précédente mission d’un projet d’urbanisation du SI pour une grande administration, pendant l'audit visant à recenser les applications, à la question "quelles sont les applications hébergées par ce serveur ?", on nous a répondu "les personnes qui s’en occupaient sont parties, on ne sait plus à quoi il sert, mais comme il est connecté à notre SI, on n’ose pas l’arrêter, de peur des impacts, donc on le laisse tourner…".

Alors que faut-il faire ?

Un processus idéal implique de documenter avant de mettre en œuvre (source : Uncia).

Une documentation de qualité a plusieurs avantages : elle rassure les acteurs de la Direction du Système d'Information (DSI), structure les projets en fournissant un cadre de travail, et sert de base de partage d'informations. Sans documentation adéquate, il est difficile de s'assurer du respect des règles, tout comme il serait risqué de construire une maison sans plan.

La documentation d'architecture idéale est sans erreurs ni incohérences, lisible par tous les acteurs de la DSI, à jour, versionnée pour suivre les évolutions, et explique les décisions prises. Elle doit s'intégrer dans un écosystème permettant de cartographier l'ensemble du système d'information et de devenir la source de vérité pour les acteurs de la DSI.

Le DAT, qui est au cœur de la documentation, doit être structuré et interconnecté avec d'autres documents, tels que les schémas applicatifs, les cartographies des flux, les référentiels matériels, et les documents de synthèse. Il est crucial que les acteurs de la DSI aient accès à un référentiel documentaire partagé en mode collaboratif, centralisé, complet, versionné, regroupant les règles du SI, la cartographie, le DAT, et le catalogue des produits.

C4 model

Avant de présenter un outil particulier pour documenter l'architecture technique, intéressons-nous au C4 model.

Le C4 model, créé par Simon Brown et popularisé depuis 2018, permet de visualiser de manière simplifiée, mais rigoureuse, l’architecture logicielle, en se basant sur la décomposition structurelle en Conteneurs et en Composants. Comme on peut le deviner, les « C » sont en fait au nombre de 4, avec en amont le Contexte et en aval le Code.

Le C4 model permet de représenter les relations entre ces différents éléments, voire avec les utilisateurs, en proposant plusieurs points de vue (ou plutôt plusieurs niveaux de zoom). Le C4 model peut être utilisé pour la conception, de préférence collaborative, de systèmes logiciels, puis pour la documentation. L’intérêt d’une bonne documentation vient d'être rappelé plus haut.

Contexte, Conteneurs, Composants, Code

• Contexte (niveau 1) : périmètre et environnement du système logiciel ; relations avec les utilisateurs et avec les autres systèmes.
• Conteneurs (niveau 2) : décomposition du système logiciel en conteneurs qui peuvent être déployés et exécutés de manière indépendante (applications, bases de données).
• Composants (niveau 3) : décomposition des conteneurs en composants interdépendants –
  c.-à-d. non déployables indépendamment (high-level building blocks).
• Code (niveau 4) : dernier niveau de représentation de la conception avant le code source ; comment les composants sont implémentés : classes, interfaces, objets, fonctions, etc.

Les 4 "C" - niveaux - du C4 model (source : C4 model)

Les 3 premiers niveaux utilisent les 5 mêmes éléments de base dans les diagrammes :

• Les personnes, les systèmes logiciels, les conteneurs, les composants et les relations.

Les personnes peuvent être des acteurs, des rôles, des personnages (personas) et seront représentées par des bonshommes. Les systèmes, conteneurs et composants seront représentés sous forme de blocs rectangulaires imbriqués (sauf les bases de données). Pas de surprise : les relations seront représentées par des flèches, avec des descriptions correspondant au sens des flèches de préférence. Une description pertinente permettra de savoir si une flèche représente une dépendance ou un flux de données entre deux éléments.

Cette forme de représentation est tellement peu contraignante qu’il sera parfois difficile, de prime abord, de distinguer ces 3 niveaux de représentation. L’usage est d’utiliser une couleur différente pour chaque type d'éléments, bien qu’il n’y ait aucune obligation. On peut aussi arrondir les angles. Ajouter une légende sur chaque diagramme est fortement recommandé.

Exemple de légende des niveaux 3, 2 et 1 du C4 model

Quant au niveau 4, il n’y a pas de représentation particulière pour le Code : il est recommandé d’utiliser une notation standard existante, comme un diagramme de classes UML ou un Diagramme Entités-Relations.

Seuls les diagrammes de niveaux 1- Contexte et 2- Conteneurs sont recommandés dans tous les projets, car compréhensibles par un large public. Les diagrammes des niveaux 3- Composants et 4- Code sont optionnels, car ils s’adressent à un public d’informaticiens (architectes, analystes-concepteurs, développeurs).

L'éditeur français Uncia vous propose
une solution cousue main

Le C4 model n’impose pas d’outil particulier. Uncia est une solution innovante se présentant sous forme d’une plateforme web payante qui vous offre un cadre documentaire homogène pour tous vos projets. 

Avec Uncia, vous pouvez :

• Personnaliser votre environnement selon vos besoins et vos préférences,
   
• Éditer des schémas applicatifs interactifs et lisibles,
   
• Spécifier les ressources matérielles qui portent vos services,
   
• Éditer des documents de synthèse clairs et complets,
   
• Créer des synergies entre les équipes de la DSI avec le mode collaboratif,
   
• Exporter les données vers votre outil ITSM (IT Service Management software)
  pour gérer les ouvertures de flux et les approvisionnements,
   
• Cartographier très finement le SI et identifier les ressources critiques.

Comment fonctionne Uncia ?

L'effort en pourcentage à fournir pour réaliser les différentes parties d'un DAT (source : Uncia).

Uncia fonctionne selon un principe simple : vous saisissez les informations relatives à vos architectures techniques dans des formulaires adaptés, et Uncia se charge de générer automatiquement les documents correspondants.

Par exemple, si vous voulez créer un schéma applicatif, il vous suffit de renseigner le nom du projet, le périmètre fonctionnel, les applications impliquées, les flux échangés, etc. Uncia va alors produire un schéma clair et interactif au format C4 model, que vous pourrez modifier, annoter, partager ou exporter selon vos besoins.

De même, si vous voulez créer un document de synthèse, il vous suffit de sélectionner le projet concerné, et Uncia va extraire les informations pertinentes du référentiel pour rédiger un document complet et cohérent, qui contient le schéma applicatif, le schéma matériel, la liste des ressources, la politique de sécurité, etc.

Uncia vous permet également de réutiliser les données existantes pour créer de nouveaux documents. Par exemple, si vous avez déjà saisi les informations relatives à une application dans un projet, vous n'avez pas besoin de les ressaisir dans un autre projet. Uncia va automatiquement récupérer ces informations et les intégrer dans le document correspondant.

Quels sont les bénéfices d'Uncia ?

Diagramme d’application web réalisé avec l'outil Uncia au format C4 model.

Uncia vous apporte de nombreux bénéfices, tels que :

• Une uniformisation de la documentation d'architecture technique,
  qui facilite la communication et la compréhension entre les différents acteurs du projet,
   
• Une sécurisation du respect de la politique de sécurité de votre organisation,
  depuis la définition des architectures jusqu'à la préparation des mises en production,
   
• Une optimisation du temps et des ressources, grâce à l'automatisation des tâches répétitives et à la réutilisation des données existantes,
   
• Une intégration dans le workflow de votre DSI, grâce à une API ouverte
  qui permet de connecter Uncia à vos outils de gestion ITIL,
   
• Une meilleure maîtrise du SI, grâce à une vision globale et détaillée
  de vos architectures techniques et de leurs impacts,
   
• La gestion des règles d'urbanisme qui ne se limitent pas seulement à la structure physique d'un système, mais qui définissent également des règles de communication, de segmentation du réseau, et de gestion des flux. Cette approche globale garantit une meilleure gestion de la complexité du SI,
   
• Validation en temps réel des règles. Par exemple, si un architecte essaie d'établir un flux FTP entre deux composants, le système génère une notification instantanée pour l'informer que cette action enfreint une règle spécifique. Par contre, un flux SFTP (SSH) est autorisé (diagramme d'exemple ci-dessus). Cette approche proactive renforce la conformité et permet l'apprentissage des règles au sein de l'organisation,
   
• Interconnectivité des Documents de manière à ce que toute modification dans l'un puisse avoir un impact sur d'autres. Par exemple, si un schéma applicatif est modifié, cette modification peut automatiquement mettre à jour les informations relatives aux flux de données, garantissant ainsi la cohérence et la traçabilité des changements.
   
• Automatisation de la Matrice de Flux. Par exemple en automatisant la tâche de création, souvent fastidieuse, on va réduire les erreurs humaines et garantir que les informations sur les flux de données sont toujours à jour,
   
• Référentiel Centralisé. Il rassemble non seulement les données de base de la documentation, mais il intègre également des catalogues de produits, permettant aux architectes de savoir quels produits sont autorisés pour une utilisation spécifique. Cette approche centralisée offre une visibilité complète sur l'ensemble du SI,
   
• Intégration d'APIs. Uncia peut s'intégrer avec divers outils et services externes, tels que Draw.io, Excel, Word, Service Now, et AWS. Cela signifie que les données peuvent être extraites ou mises à jour automatiquement à partir de ces systèmes, ce qui facilite la synchronisation de la documentation avec les changements dans l'infrastructure et les applications. Uncia supporte tout type de cloud public et privé. Le cloisonnement 100 % étanche entre les bases de données de clients différents est garanti,
   
• Gestion des Services Requests pouvant être déclenchées en fonction des modifications apportées à la documentation. Par exemple, une modification dans la matrice de flux pourrait automatiquement déclencher une demande de modification dans un pare-feu pour refléter ces changements,
   
• Catalogue de Produits, aidant à garantir que seuls les produits autorisés sont utilisés
  dans le SI, ce qui renforce la sécurité et la conformité,
   
• Consommabilité via des APIs permettant des intégrations avancées,
   
• Automatisation des Workflows offrant des cycles de relecture, la gestion des commentaires, et le suivi des modifications. Cela accélère la validation des DAT et réduit les délais.

Conclusion

Le rôle de cet article est de redonner à la documentation d'architecture technique la juste place qu’elle mérite dans vos projets. Le C4 model permet une représentation visuelle simple, mais puissante, de cette architecture, en proposant 4 niveaux de zoom plus ou moins détaillés. Uncia, qui s'appuie sur le C4 model, est une solution innovante qui va au-delà de la simple documentation en offrant des fonctionnalités avancées : automatisation, interconnectivité et intégration avec d'autres outils, pour simplifier la gestion de l'architecture technique, renforcer la conformité, et améliorer la sécurité des systèmes d'information.

Merci pour vos commentaires qui seront les bienvenus, ainsi que vos retours d'expérience heureux ou malheureux, qui pourront profiter à nos lecteurs.

"Faute de valeur supérieure qui oriente l'action, on se dirigera dans le sens de l'efficacité immédiate. Rien n'étant vrai ni faux, bon ou mauvais, la règle sera de se montrer le plus efficace, c'est-à-dire le plus fort. Le monde alors ne sera plus partagé en justes et en injustes, mais en maîtres et en esclaves" 
Albert Camus

Les différents niveaux d'architecture répondent à différents niveaux de préoccupations et ont des publics différents. Le cadre d'architecture et le référentiel doivent aider à garantir que ces architectures soient stratifiées et synchronisées, afin qu’elles forment une vision cohérente et équilibrée de l'ensemble de l'entreprise. 

Les niveaux d'architecture selon TOGAF
(diagramme UML de package réalisé avec Modelio Open Source)

La dénomination des niveaux a été influencée par
“The Open Group Architecture Framework” (TOGAF). 

Une entreprise a une structure complexe et généralement hiérarchique, et l'on doit créer des architectures à des niveaux discrets de cette structure. Cette hiérarchie d'architectures est analogue aux hiérarchies d'objectifs et de capacités, et s'aligne intuitivement sur les divisions au niveau stratégique, programme et projet. Dans une petite organisation, il est possible de créer une architecture unique qui couvre le niveau stratégique et les niveaux de projet ou de capacité, mais dans une grande entreprise, au moins trois niveaux distincts sont généralement nécessaires :

• Stratégique - Long terme, de l'ordre de 3 à 5 ans,
   
• Tactique - Moyen terme, de l'ordre de 1 à 2 ans,
  
  
• Solution - Court terme, de l'ordre de 6 à 12 mois.

Les architectures Stratégiques

Exemples d'Architectures Stratégique, Tactique et de Solutions
(diagramme UML de package réalisé avec Modelio Open Source)

Elles décrivent des plans et des initiatives stratégiques et s'exécutent généralement pendant des années. Les architectures stratégiques fournissent des plans à long terme, qui sont généralement des visions de l'avenir sur une période de trois à cinq ans.
La période peut être plus longue pour les industries ou les entreprises qui ne sont pas affectées par des environnements dynamiques et perturbateurs. Les architectures stratégiques doivent prendre en charge ou s'aligner sur les objectifs stratégiques de l'entreprise.

La technologie de modélisation stratégique dispose d'un certain nombre d'outils qui peuvent être utilisés, tels que le diagramme “Balanced Scorecard”, qui peut aider à identifier les objectifs liés à l’IT.

Diagramme "Balanced Scorecard" (diagramme réalisé avec Visual Paradigm)

Les architectures Tactiques

Exemples d'Architecture Tactique intégrant des architectures de solutions
(diagramme UML de package réalisé avec Modelio Open Source) 

Elles décrivent des plans intermédiaires qui aident à partitionner les architectures de niveau Stratégique en groupes gérables.

Elles peuvent généralement durer un certain nombre d'années et représenter une feuille de route au niveau du portefeuille applicatif ou des étapes sur la manière d'atteindre les objectifs exprimés dans les architectures Stratégiques auxquelles ils se rapportent.

Elles agissent comme un cadre pour l'organisation au niveau des solutions et assurent que les capacités sont développées et qu'elles créent finalement de la valeur métier. 

Les diagrammes de “Roadmap” peuvent être utilisés à tous les niveaux de l'architecture Tactique, y compris les Architectures d'Entreprise, d'Information, d'Application et de Technologie, montrant le séquencement temporel des actions au niveau d'un portefeuille applicatif ou d'un programme.

Exemple de diagramme de "Roadmap" (diagramme réalisé avec ADOIT:CE)

Les architectures de Solutions

Elles décrivent des projets spécifiques ou des activités au niveau des capacités qui peuvent généralement être réalisées en quelques mois, plutôt qu'en plusieurs années. D'un point de vue métier, elles se concentrent généralement sur un problème ou une opportunité particulière. De même, d'un point de vue technique, elles impliquent généralement une tranche des domaines de l'information, des applications et de la technologie, mais peuvent, dans certaines circonstances, nécessiter l'examen d'un certain nombre de ces domaines. 

Les outils doivent aider au niveau de l'architecture de chaque Solution, de la définition des buts et objectifs métier et de leur mise en relation avec les composants d'Information et d'Application, et de Technologie qui sous-tendent les applications. 

L'architecture Métier peut être définie et gérée à l'aide de profils UML (ensemble de stéréotypes, tagged values et contraintes OCL). Cela permet de créer des “Drivers” (représentations des conditions motivant une organisation métier à définir ses objectifs et à mettre en œuvre les changements nécessaires pour les atteindre), des buts et des objectifs, qui peuvent être démontrés aux parties prenantes à l'aide de diagrammes, de matrices et de documentation, publiés automatiquement à partir des modèles.

Des générateurs de schémas de RDBMS et de scripts SQL à partir de diagrammes de classes UML aident à travailler avec l'architecture de l'Information, et les éléments créés peuvent être liés à l'architecture métier. 

Les services applicatifs, les applications et les interfaces peuvent être modélisés, et leurs relations entre eux et avec les éléments des architectures métiers et technologiques peuvent être définies et représentées par des liens de traçabilités entre des artefacts de modélisation appartenant même à des notations différentes, comme ArchiMate, BPMN, DMN, UML…

Les services technologiques, les nœuds et dispositifs technologiques peuvent être gérés et, le cas échéant, peuvent être dérivés du Modèle de référence technique. 

Les outils doivent gérer les exigences architecturales, qui peuvent être liées aux éléments qui composent entreprise, processus métier, fonctions, applications, technologies et autres architectures spécifiques. 

Un framework agile (Kanban, Scrum…) peut être utilisé pour gérer ces projets et garantir que la valeur métier est livrée en temps opportun.

Mais au fait, y a-t-il une norme pour représenter
les architectures Stratégiques et Tactiques ?

Vous n'en avez peut-être jamais entendu parler, mais cette norme existe et se nomme BMM (Business Motivation Model). Il s'agit d'un modèle de motivation métier qui fournit aux entreprises un ensemble de notations normalisé par l’OMG (Object Management Group), pour l'élaboration de plans métier. Il permet de modéliser ce que l'entreprise souhaite réaliser, comment y parvenir, les impacts potentiels, les ressources, etc.

Voir nos articles consacrés à la norme BMM de l'OMG à la fin, dans les compléments de lecture.

Exemple de diagramme BMM (diagramme réalisé avec Visual Paradigm)

Et l'apport d'ArchiMate ?

La stratégie et les éléments de motivation d'ArchiMate ont été inspirés en partie par BMM.
Bien qu'un mappage entre de nombreux éléments de motivation d'ArchiMate et les concepts BMM soit possible, BMM fournit une description plus détaillée de la motivation, tandis que le langage ArchiMate vise à couvrir un large champ et à interconnecter différents domaines.

Voir nos articles consacrés aux éléments de stratégie et de motivation d'ArchiMate à la fin, dans les compléments de lecture.

Diagramme ArchiMate de la couche Strategy, représentant les objectifs (Goals),
les résultats attendus (Outcomes) et les principes (Principles) (diagramme réalisé avec ADOIT:CE)  

La traçabilité comme assurance de l'alignement stratégique

La traçabilité occupe une place transverse et traverse toutes les strates d’architecture.

Il existe plusieurs outils, dont la matrice des relations et les diagrammes de traçabilité, qui peuvent être utilisés pour montrer les relations entre les éléments des architectures d'entreprise, afin de s'assurer qu'ils contribuent tous de manière démontrable à la réalisation des objectifs stratégiques. 

Matrice de Relations entre Exigences et Cas d’Utilisation et une vue de ces relations
(diagramme réalisé avec Enterprise Architect)
    

Le diagramme de Traçabilité fournit une vue hiérarchique des connexions d'éléments, permettant de visualiser et d'interroger la traçabilité au fur et à mesure qu'on accède aux éléments dans le modèle. Cet outil est particulièrement utile, car un modélisateur choisira souvent de masquer les relations du diagramme, mais en sélectionnant un élément dans le diagramme et en visualisant ses connexions dans la fenêtre Traçabilité, toutes ses relations seront révélées.

Exemple d'outil de traçabilité (diagramme réalisé avec Enterprise Architect)

Conclusion

Pour ne plus souffrir des modèles opérationnels, qui ont subi des changements progressifs et non structurés au fil du temps, devenant souvent des obstacles à la mise en œuvre de leur stratégie, les entreprises ne devraient plus commettre l'erreur d'appliquer leur stratégie de bas en haut (bottom-up), comme si, lors de la conception d’un bâtiment, on s’adressait en premier aux ingénieurs spécialisés dans les fondations.

Pour une entreprise, une approche de haut en bas (top-down) permet de se restructurer, de ne pas risquer de s'éloigner de la réalisation de ses objectifs à long terme, et de respecter l'alignement stratégique. 

"Toute idée devient fausse au moment où l’on s’en contente."

Alain

Compléments de lecture

BMM (Business Motivation Model)

• BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
  
  
• BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, …
  
  
• Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
  
  
• Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
  
  
• Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques

ArchiMate

• ArchiMate la synthèse : les éléments de motivation
  
  
• ArchiMate en condensé : les éléments de stratégie

Outils d'Architecture d'Entreprise

• Essai et évaluation de Modelio : est-il un bon outil de modélisation ?
  
  
• Visual Paradigm : l’eldorado du consultant en quête de présentations dorées, mais est-il un bon outil de modélisation pour l’architecte d’entreprise, voici notre test
  
  
• ADOIT:CE pour la gestion de l’Architecture d’Entreprise
  
  
• Archi (archimatetool) : essai et analyse de cet outil ArchiMate français gratuit sous Windows, Linux et Mac OS
  
  
• Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants

L’omniprésence et la protéiformité de l’IA, comme le RPA (Robotic Process Automation) ou les chatbots, déclencheraient-elles une disruption et feraient-elles naître une Architecture d'Entreprise augmentée ? L’IA a-t-elle un rôle à jouer dans les décisions des comités de direction ?

Un ancêtre de l'IA, pour les cinéphiles

APIsation, plateformisation, données “chaudes”, données “froides”, données "tièdes"...

L’APIsation et la plateformisation de l’entreprise alliées à l’urbanisation du SI participent à l’intégration de l’IA dans les applications.   
Les données “chaudes” représentent le référentiel des entités métier, les indicateurs de pilotage et sont persistantes dans des bases SQL avec un accès en quasi temps réel. Les données “froides” sont le résultat de l’archivage dans d’autres espaces de stockage, sans contrainte de temps de réponse. Entre les deux, les données "tièdes", issues du rapprochement des deux types précédents, offrant rapidité et quantité et appartiennent au domaine du Big Data qui alimente les algorithmes de l’IA.
L’Architecture Réactive, basée sur les évènements, les APIs et les microservices, fait partie des fondements pour déployer de l’IA.

Les cycles d’évolution des technologies étant de plus en plus courts, l’open source devient incontournable. De même l’open innovation permet d’innover en mettant en œuvre une collaboration entre les grandes entreprises et les start-ups avec les incubateurs, les hackathons, les financements…
L’externalisation des compétences techniques comprend des risques, notamment sur la maîtrise de la sécurité, des savoir-faire, mais aussi sur l’évaluation éthique. Intégrer une brique fournie et maintenue par un tiers dans la chaîne opérationnelle pose le souci de voir partir le savoir-faire métier, car en effet, même si les données appartiennent à l’entreprise, les algorithmes et les modèles appartiennent en général aux fournisseurs. Ils peuvent donc acquérir et consolider le savoir-faire métier de plusieurs entreprises clientes pour le vendre ensuite à des entreprises concurrentes ou l’exploiter eux-mêmes.

La dimension éthique pour les entreprises réside aussi en partie dans leur capacité à s'approprier le développement de solutions et à traiter le plus en amont possible les questions de traçabilité et d'explicabilité des algorithmes. La question d’acceptabilité des modèles est cruciale aujourd’hui. S’il est indispensable de faire appel à l’expertise extérieure (dynamique évolutive, sujets très pointus…), le contrôle est indispensable. Internaliser les outils d’IA demande des compétences, car il est rare de trouver un outil open source sur étagère qui réponde complètement aux besoins de l’entreprise. C’est en général une bonne base, mais elle doit être adaptée à chaque contexte. Il faut faire beaucoup d’assemblage et souvent un peu de développement, donc il faut avoir les compétences en propre.

Du Machine Learning dans la gestion de projet

L'analyse prédictive peut fournir des conseils au chef de projet pour atteindre le meilleur résultat possible, basé sur ce qui a fonctionné dans les projets antérieurs.
Les chatbots servent d'assistants de projet. Ils peuvent prendre en charge des tâches subalternes, telles que l'organisation des réunions, contrôler la performance en fonction des références de base, rappeler aux équipes projet les activités programmées.

La planification basée sur l'lA pourrait inclure les leçons apprises des projets antérieurs et suggérer plusieurs calendriers possibles, en fonction du contexte et des dépendances. Par ailleurs, les plans de projet pourraient être adaptés et recalibrés en quasi temps réel sur l'historique des performances de l'équipe et l'avancement du projet. Le système pourrait même alerter le chef de projet des risques et des opportunités, en utilisant l'analyse des données de projet en temps réel.

Dans son évolution, l'IA pourrait convertir les cartes mentales (mind map) créées par les équipes projet en ontologie métier, en tirer des tâches reliées entre elles et il ne resterait plus qu'un pas à faire pour arriver à des modèles BPMN.
La mise en œuvre de l'apprentissage automatique (Machine Learning) dans le management de projet permet l'analyse prédictive et corrective, visant à fournir au chef de projet des alternatives pour la prise de décision.

Le comité de direction augmenté, une utopie ?

Les dernières études en la matière mettent en évidence un usage de l’IA au niveau tactique, plutôt qu’au niveau stratégique de l’entreprise, c’est-à-dire essentiellement dans l’amélioration des processus opérationnels de l’entreprise.

Voir nos articles :

• Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
• ArchiMate la synthèse : les éléments de motivation - 2
• ArchiMate en condensé : les éléments de stratégie - 3

Les récents progrès pourraient laisser penser que de tels modèles pourraient trouver une application dans la prise de décision stratégique, voire prendre les décisions stratégiques elles-mêmes lorsqu’on les utilise dans un conseil d’administration.
La perspective qu’une IA puisse influer dans les décisions stratégiques appartient encore au monde de l’utopie. Comme tout un chacun, la compréhension des décideurs d’un problème, de son contexte et de sa résolution, s’appuie notamment sur leurs connaissances, leurs expériences et leurs énactions.

L’essence même de la prise de décision stratégique est définie par un manque d’informations, une incertitude élevée et une forte interdépendance avec les acteurs de la décision : autant de caractéristiques qui rendent assez improbable le fait de confier les décisions stratégiques d’une entreprise à une IA.
Les biais des DG seraient alors remplacés par les biais des jeux de données, qu’ils proviennent de biais cognitifs, du surapprentissage, d’échantillons, de sélection, de valeurs aberrantes ou surreprésentées.

Les disruptions tous domaines confondus impactant le décisionnel relèvent par nature même de l’imprévisibilité et sont inmodélisables. Aucun modèle prédictif n’a pu, ne serait-ce qu’entrevoir, l’ubérisation. Sûrement parce qu'ils sont basés sur des données qui ne sont plus de premières fraîcheurs, tombant rapidement dans l’obsolescence.
Les entreprises entamant leur transition numérique doivent composer des équipes aux triples compétences : métier, informatique et mathématiques, sous la direction d’un CDO (Chief Data Officer).

La gouvernance doit constamment faire de la prospective, afin de maintenir ses informations sur l’IA devenu domaine hautement stratégique. Le rôle de l’architecte d’entreprise peut être renforcé par celui d’un architecte des données (CDO Chief Data Officer) au service de la création de valeur et donc de l’IA. Il apparaît ainsi nécessaire que le CDO possède une solide culture en matière d’IA, afin d’éclairer les discussions de la gouvernance sur ce sujet stratégique.

Conclusion

En termes de recherche fondamentale, les avancées et les percées se succèdent, aboutissant peu à peu à des applications opérationnelles. La veille, la vision et la prospective stratégique sur ces sujets de recherches technologiques restent essentielles pour se préparer aux disruptions majeures à venir.
Nous avons déjà pris l’habitude d’utiliser notre smartphone comme "prothèse cognitive", et cette capacité ne va faire que s’étendre et sûrement aux instances décisionnelles des entreprises.

“Sur la route, il y avait déjà des bandes réfléchissantes, maintenant il y roule des voitures intelligentes.”
Marc Escayrol

Compléments de lecture

• Exemple de méthode d’Architecture d’Entreprise d’un grand cabinet de conseil : EAM Enterprise Architecture Management de McKinsey
   
• Le rôle de la prospective pour une entreprise innovante et résiliente
   
• Les meilleurs articles sur l’architecture d’entreprise, ses méthodes et ses outils, découvrez quels sont les articles les plus lus de notre blog
   
• Les règles d'urbanisme du SI : maîtriser les échanges inter-applications
   
• Mais dans la vrai vie, qu'est ce qu'il y a dans les règles d'urbanisme du Système d'Information ?
   
• Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?
   
• Urbanisation du Système d'Information : créez l'évènement !

“Demain ne sera pas comme hier. Il sera nouveau et dépendra de nous. Il est moins à découvrir qu’à inventer” dixit Gaston Berger, l'inventeur du terme prospective. Pour renforcer ses capacités d’innovation, sa résilience et ses processus métier, l'entreprise doit non seulement surveiller le monde qui l’entoure, mais aussi mettre en œuvre des scénarios prospectifs contribuant à établir ses stratégies.

Démarche transversale en plein essor, la prospective offre une capacité d'analyse qui simule des avenirs possibles sur une question donnée et dans un champ spatio-temporel délimité.

Compte tenu de la mouvance d’un monde empli d’incertitudes, la survie d’une entreprise est étroitement liée à sa résilience. Il va s’agir de sa capacité à s’adapter rapidement aux événements néfastes, aux épreuves et aux échecs, tout en maintenant son activité économique, en protégeant son personnel et ses valeurs. Se remettre sur les rails après une situation difficile ne suffit pas, il faudra prendre de la hauteur, appréhender le contexte et lancer une démarche de prospective stratégique de manière à tourner l’entreprise vers l’avenir et à favoriser l’enclenchement d’une innovation de rupture nécessaire à son adaptation et à sa résilience.

De quoi parlons-nous exactement ?

Pour éviter toute confusion et pour la clarté de la suite de cet article, commençons par définir des concepts qui semblent similaires, mais en y regardant de plus près, qui présentent bien des différences tout en étant complémentaires.

L’anticipation

Terme générique, l’anticipation rassemble les méthodes de prédiction, de prévision et de prospective.

La prédiction

La prédiction concerne un futur déjà écrit en extrapolant des connaissances existantes. La méthode est une heuristique basée sur le fait qu’en première approximation le futur présentera des similitudes avec le passé. Par exemple, le Big Data et le Machine Learning permettent d’identifier des corrélations statistiques implicites dans les données, augmentant la somme de connaissances pouvant être extrapolées sur une période future. 

La prévision

La prévision concerne les futurs probables, où les scénarios représentent des hypothèses implicites ou explicites sur lesquelles sont basées les projections obtenues par extrapolation et/ou interpolation mathématiques faisant explicitement intervenir la variable temps. 

Prévoir un futur probable consiste alors à recueillir et à interpréter les résultats produits par le modèle en déplaçant la variable temps à une valeur située dans le futur.

Si certaines hypothèses se vérifient avec le temps, on aura des certitudes sur des événements à venir. On pourra alors adopter une posture déterministe en planifiant des actions pour s’y préparer.

La projection

Les projections sont des extrapolations de tendances d’un phénomène correspondant à des estimations quantitatives sur des périodes déterminées à venir. Différents outils existent comme l’analyse de séries chronologiques basée sur la modélisation des tendances passées tenant compte d’hypothèses.

Exemple de projections utilisant l'analyse de série chronologique (https://www.inspq.qc.ca/jasp/accueil)

On peut aussi utiliser la microsimulation qui a pour objectif de représenter un système dynamique composé d’entités possédant des propriétés soumises à des événements avec une certaine probabilité de modifier leurs valeurs.

La prospective

Se préparer à l'incertitude

Contrairement à la prévision, avec la prospective, on est dans une posture proactive, on se prépare à l’incertitude du futur en produisant des scénarios contrastés (disruptifs, de crises, de mutations, de solutions) pour le décisionnel, le management de l’innovation et le management stratégique.

La démarche prospective se situe en amont de la stratégie dont elle éclaire les choix en balayant un plus long terme, au moins 10 ans. 

En stratégie d’entreprise, la démarche de prospective consiste à réaliser des diagnostics, à élaborer des scénarios nominaux ou alternatifs et à émettre des recommandations. Les étapes de planification des risques et de proposition de visions temporelles vont aider aux décisions stratégiques sur le long terme, réduire les incertitudes face à l’avenir et enfin légitimer les actions entreprises. 

L’étude prospective peut être basée sur la veille consistant à identifier les données les plus seyantes sur les changements dans le monde, les mutations émergentes, les ruptures technologiques et l’ensemble des événements futurs pouvant potentiellement avoir des impacts importants.  

André-Clément Decouflé, prospectiviste et auteur de nombreux ouvrages, parle de néologisme créé pour définir une méthode d’analyse des problèmes de décisions basée sur les discontinuités introduisant des ruptures de tendances plutôt que de se fonder sur les expériences passées, l’analogie ou l’extrapolation. Le processus de décision doit intégrer une multitude de contextes futurs pour pouvoir intégrer à moindres risques les incertitudes susceptibles d’impacter la pertinence de la solution retenue.

Le but de la prospective est de raconter des histoires sur les futurs possibles issus des répercussions des choix présents, autrement dit, d'anticiper de manière la plus efficiente qui soit les évolutions d’une organisation. 

Concrètement, les scénarios prospectifs peuvent être rédigés textuellement ou être basés sur des méthodes formelles comme les matrices des impacts croisés ou la méthode DELPHI.

La matrice d'impacts croisés

La matrice d'impacts croisés modélise les influences directes entre des événements (éléments ou variables). Schématiquement, l’impact direct d’un événement ek sur un autre em est représenté par une flèche partant de ek et arrivant à em. 

Exemple de graphe montrant les variables impactantes et impactées

Pour simplifier, le même poids (égal à l'unité) 1 est attribué à toutes les relations directes existantes ; l'absence de relation entre deux événements est symbolisée par le chiffre zéro. L'examen porte sur les combinaisons deux à deux de tous les événements retenus, il en résulte une matrice booléenne carrée M dont l'élément générique est :

• ekm = 1 si l'élément ek de la k-ième ligne a une influence directe sur l'élément em de la m-ième colonne.
• ekm = 0 si l'élément ek de la k-ième ligne n’a pas d’influence directe sur l'élément em de la m-ième colonne.
• ekk = 0 car ek ne peut s'influencer lui-même, directement.

En tenant compte des influences directes, la somme (Σekm ; m-1…) de la ligne k de la matrice M comptabilise le nombre de variables influencées directement par ek : est ainsi mesuré le pouvoir moteur (ou indice d'influence) de ek.

L'indice de dépendance de em se mesure par la somme (Σekm ; k=1…) de la colonne m. C'est le nombre de variables dont em subit directement l’influence.

Exemple de matrice des impacts croisés correspondant au graphe précédent

La méthode DELPHI

DELPHI est une méthode systématique qui a été reprise dans la méthode agile Scrum et rebaptisée “planning poker” pour réaliser les estimations des user stories.

La méthode consiste pour une problématique donnée à interroger un groupe d'experts lors de plusieurs tours. À chaque nouveau tour, le questionnaire est enrichi des réponses précédentes.

L'objectif est de mettre en évidence les consensus, mais aussi les divergences. Les consultants doivent expliciter et argumenter leur raisonnement augmentant le résultat en qualité et fiabilité.

La méthode des scénarios prospectifs

Michel Godet ancien titulaire de la chaire de prospective stratégique au CNAM, a conceptualisé la métaméthode des scénarios : “La méthode des scénarios vise à construire des représentations des futurs possibles, ainsi que les cheminements qui y conduisent. L’objectif de ces représentations est de mettre en évidence les tendances lourdes et germes de rupture de l’environnement général et concurrentiel de l’organisation.”

Les scénarios n’ont pas besoin d’être probables, mais ils doivent mettre en évidence des marges de manœuvre réalistes pour les acteurs qui désirent construire l’avenir qu’ils ont choisi.

Les innovations technologiques, les conflits, le climat… constituent des hypothèses disruptives contribuant à la conception des scénarios divergeant d’un scénario tendanciel, c’est-à-dire correspondant aux tendances actuelles.

La prospective décisionnelle fait intervenir la systémique puisqu’elle implique la comparaison, soit de solutions à efficiences identiques en faisant ressortir la moins chère, soit l’inverse.

Des récits concrets de l’avenir sont conçus en se basant autour des incertitudes principales qui modèlent la trame environnementale future.

Un scénario peu probable peut se révéler extrêmement productif en permettant de forcer l’imagination, de stimuler la discussion et d’attirer l’attention d’acteurs spécifiques. Souvent l’imagination et la faculté de représentation faisant défaut, l’approche scénaristique va permettre de concrétiser les futurs possibles. Ainsi les incertitudes, la complexité et les changements de paradigme peuvent être entièrement gérés. Les scénarios offrent une modélisation de situations complexes et virtuelles en les explicitant suffisamment pour, par exemple, des architectes d’entreprise, afin qu’ils puissent les analyser et mesurer les éventuels impacts sur les stratégies. Ces trames constituent de parfaits supports à la projection des acteurs dans un environnement volontairement impacté par d’importants changements. Pour que la représentation du futur soit incitative pour les experts à s’impliquer, il faut qu’elle soit plausible, cohérente et que le raisonnement inductif soit d’une grande rigueur.

Les scénarios tendanciels sont des scénarios de référence, ils envisagent l'évolution plausible, ils sont sans surprise. Ils correspondent à une poursuite des tendances actuelles, sans rupture majeure, et intègrent des facteurs de changements déjà connus dont la probabilité est certaine.

Partant de ces scénarios tendanciels, d'autres scénarios lui sont confrontés sur la base d'objectifs à atteindre et/ou de contraintes nouvelles prévisibles.

Les scénarios des futurs possibles d'après Vincent Enjalbert (https://lecercledesdeveloppeurs.files.wordpress.com)

Les scénarios prospectifs exploratoires partent d’une situation connue, initiale, pour explorer progressivement le futur. Les descriptions qui en sont faites, correspondent à des images très contrastées (scénario idéal, scénario catastrophique, scénario alternatif) et permettent d'étudier les processus d'évolution qui conduisent à l'une ou à l'autre de ces situations. 

Ces scénarios contrastés sont donc destinés aux hypothèses de rupture, ayant ou non un degré de probabilité faible, mais dont l'impact est potentiellement important.

Exemple de modélisation de scénarios exploratoires de l'impact de l'évolution du climat sur le littoral (Alliance nationale de recherche pour l'environnement)

Les scénarios normatifs partent d'une norme de désirabilité (image souhaitable ou non). Le processus de modélisation est inverse aux scénarios exploratoires, puisqu’on remonte du futur vers le présent. Le cheminement est alors construit de façon rétrospective. Ils éclairent davantage les risques de ruptures et les moyens à mettre en œuvre pour parvenir à des objectifs prédéfinis (éviter telle situation ou atteindre telle autre).

Conclusion

Évidemment, la prospective ne consiste pas à regarder dans une boule de cristal, dans le but de deviner l'avenir, mais entend influer sur l’avenir, c’est une ouverture de l’entreprise vers l’extérieur. Une fois choisi le scénario le plus pertinent et plausible, elle oriente sur la dynamique à mettre en œuvre pour que son déroulement ait lieu.

Elle est source d’inspiration pour l’innovation dans la mesure où l’entreprise tente de s'approprier les changements du monde qui l’entoure : ruptures technologiques, nouvelles réglementations, crises, etc.

La prospective permet aux directions générales d’expliciter des domaines aux perspectives indéfinies et qui risqueraient de dégrader les processus métiers.

La résilience dépend de l’innovation et un bon moyen d’innover c’est encore de mettre en œuvre une démarche de prospective.

Mais attention, il ne faut pas oublier que l’avenir peut être très surprenant.

« Le pétrole est un liquide minéral dépourvu de toute utilité. De par sa nature, c’est un liquide gluant et nauséabond. Le pétrole ne peut être employé d’aucune façon, sauf à lubrifier les roues des charrettes indigènes. »

CONCLUSION DE L’ACADÉMIE DE SAINT-PETERSBOURG, après l’envoi d’une mission russe à Bakou en 1809.

“Regarder un atome le change, regarder un homme le transforme, regarder l’avenir le bouleverse.”

Gaston Berger

Compléments de lecture

1. BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
    
2. BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, ...
    
3. Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
    
4. Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
    
   
5. Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques
    
   
6. Modélisation métier : méthode des processus métier orientés objectifs
    
   
7. Le Machine Learning est il aux moteurs de règles métiers (BRMS) ce qu’une chute d’une météorite géante fut pour l’extinction des dinosaures ?

Les référencements, l'intégrations des nouvelles lois, les innovations des concurrents, la pression des clients ou des actionnaires amène à mettre en place des fonctionnalités rapidement au détriment de la conformité des règles d'urbanisme du SI.

Le projet doit financer la ( "quick and dirty" ) solution à court terme ainsi que la migration vers la situation cible.

Cette migration, qui n'est pas soumise aux mêmes contraintes de planning, a pour but de restaurer la capacité du système à être flexible.

De cette façon, le besoin d'être réactif est satisfait et la capacité à le rester est maintenue.

La rentabilité du projet ne peut être remise en cause par le financement de la situation cible, sinon on pourrait se poser la question si le projet est réellement rentable ?

Comment seront gérer les surcoûts dus aux difficultés de maintenance et d'évolution engendrés par cette solution non conforme ?

Rhona Maxwel

@rhona_helena

"Une idée fixe aboutit à la folie ou à l'héroïsme"

Victor Hugo

Articles conseillés :

Édicter des règles d'urbanisme du SI c'est bien, les faire appliquer c'est encore mieux.

Les règles d'urbanisme du SI : maîtriser les échanges inter-applications

Mais dans la vrai vie, qu'est ce qu'il y a dans les règles d'urbanisme du Système d'Information ?

Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

Plus la mise en œuvre des règles se fait en amont et apporte des solutions aux projets, plus grande est l'efficacité .

Les règles concernant le management de l'urbanisation abordent les aspect organisation, formation, mesure de la progression dans l'urbanisation, insertion de l'urbanisme dans la gouvernance et fixent les instances légitimes pour étudier les aspects d'urbanisme.

On le sait, sans le contrôle, on risque que les règles ne soient pas appliquées, car bien souvent les chefs de projets les voient comme des contraintes et des coûts supplémentaires.

Voici quelques solutions pour faire appliquer les règles d'urbanisme de SI :

• formation des acteurs projets
• livrable spécifique d'urbanisme dans la méthodologie d'entreprise
• coaching des équipes
• participation des urbanistes aux phase cruciales des projets
• bilan de fin de phase
• utilisation comités spécifique
• audit projet

Toute la subtilité, consistera dans le positionnement du curseur entre les exigences et leurs contrôles, l'incitatif et le répressif, entre la règle et les exceptions.

Rhona Maxwel

@rhona_helena

"Un moment de patience peut préserver de grands malheurs, un moment d'impatience, détruire toute une vie."

Proverbe chinois

Articles conseillés :

Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ?

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

A l'intérieur d'un Système d'information, les échanges de données entre blocs fonctionnels n'appartenant pas au même domaine ne se font pas en point à point mais passent par l'intermédiaire du domaine fonctionnel « Zone d'échanges ».

Une solution consiste à mettre en place un bus logiciel ( ESB Enterprise Service Bus ).

Les enjeux majeurs de l'urbanisation des SI sont la flexibilité, l'évolutivité et la maintenabilité des SI.

Au niveau de l'architecture applicative, les blocs applicatifs issus de la cartographie applicative doivent communiquer entre eux par envoi de message traduit généralement dans un langage pivot c'est-à-dire le langage métier commun à tous les domaines de l'entreprise.

Une des règles de l'urbanisme des SI est qu'un bloc possède une interface offerte à l'extérieur pour qu'elle puisse communiquer avec lui.

Ces interfaces se traduisent bien souvent par des services. Les blocs applicatifs se branchent sur un intermédiateur bien souvent un bus logiciel (ESB Enterprise Service Bus et pas Encéphalopathie Spongiforme Bovine).

L'intérêt est multiple. Un seul adaptateur est requis pour connecter un bloc sur le bus et pouvoir communiquer avec les n-1 autres blocs au lieu des n x (n - 1)/2 liens si on devait les relier tous directement en point à point. Le gain est énorme sauf si cela coûte plus cher de développer un adaptateur spécifique que de mettre en place toutes les combinaisons de liens possibles.

Heureusement les ESB du marché (open source ou commerciaux) sont livrés avec tous les types d'adaptateurs sur étagère. Ils correspondent à tous les protocoles standards (HTTP, …) et permettent de faire des transformations faciles d'un modèle de données métier spécifique vers le langage métier pivot.

Les points d'attention concernent la scalabilité, la disponibilité et la redondance ainsi que les outils de monitoring (BAM Business Activity Monitoring), de diagnostique et de reprise sur erreur. Autre avantage, l'ESB permet de séparer complétement la partie logique de la partie technique. A charge de l'ESB de gérer les transformations des formats de données dans les 2 sens, l'acheminement, le routage, la sécurité, le reporting d'exploitation et les SLA (Service Level Agreement = contrat de service comme l'engagement sur les temps de réponse, …).

L'ESB peut être intégré avec un moteur de processus exécutable métier et un moteur de règle métier.

Le premier permet d'automatiser les enchaînement des activités humaines et informatisées et la réorchestration de ces activités de manière agile et flexible.

Le deuxième permet d'injecter des règles de routage dans le processus métier ainsi que des nouvelles règles métier liées à des évolutions du marché, de la concurrence ou légales.

Rhona Maxwel

@rhona_helena

"A ta naissance, tout le monde rit et tu es le seul à pleurer. Conduis ta vie de façon à ce qu'à ta mort tout le monde pleure et que tu sois le seul à sourire."

Confucius

Articles conseillés :

Urbanisation du Système d'Information : les points d'attention concernant les performances

Urbanisation du Système d'Information : les dangers des nouvelles technologies

Quels sont les axes de recherche et développement de l'urbanisation ?

Dans la démarche d'urbanisation, cela dépend de chaque organisation, les règles d'urbanisme d'un SI couvrent tout ou partie du spectre de l'urbanisation, certaines sont obligatoires et d'autres de simples recommandations.

Des règles portent sur la manière de définir les domaines fonctionnels. Elles prévoient de respecter les propriétés d'indépendance des blocs, de séparation entre domaines métier et domaine de support, …

D'autres règles d'urbanisme du SI traitent les cartographies :

• Quelles cartographies sont exigées ?
• Quelle granularité ?
• Quels outils doivent être utilisés ?
• Quels acteurs en sont responsables ?
• Quelles sont les fréquences des mises à jour ?

Ces règles s'appliquent aux principales cartographies :
 

• Cartographie fonctionnelle : elle décompose le périmètre de l'entreprise en domaines métiers. En principe cette cartographie évolue peu car elle reflète l'activité de l'entreprise et non son organisation . Cette cartographie est essentielle à l'urbanisme du SI car elle sert d'ossature à toute description et action sur le SI.
   
• Cartographie métier : elle décrit les étapes des processus métiers majeurs de l'entreprise et leurs principaux échanges. Le grain de description peut être variable. Certaines contraintes, par exemple d'ordre réglementaire, peuvent nécessiter une description fine des processus. Pour d'autres cas, un niveau plus agrégé est suffisant.
   
• Cartographie applicative : elle reporte de manière exhaustive les applications et leurs liens.
   
• Cartographie technique : elle reporte les infrastructure techniques qui supportent les applications (serveurs, réseaux, …).

Pour les projets, ces règles établissent le paysage dans lequel devront s'insérer leurs développements. Elles déterminent aussi les documentations qu'il faut mettre à jour pour actualiser ce paysage.

Concernant la mise sous contrôle des référentiels, des règles d'urbanisme du SI doivent stipuler :

• La nécessité de se raccorder aux référentiels existants
• Dans quels cas il convient de créer un référentiel
• Les règles de gestion de ces référentiels

Les règles d'urbanisme du SI pour la définition des cibles s'attachent à garantir l'existence de cibles métier et cibles d'urbanisme, sans interférer sur le contenu même de ces cibles. Des règles peuvent aussi prévoir les modalités de définition, de mise à jour et de validation des cibles fonctionnelles et techniques.

L'élaboration des cibles SI est l'occasion de lever la tête, afin de formuler les évolutions métiers sur le moyen/long terme et en déduire les adaptations du SI. La définition des cibles est le moyen d'améliorer l'efficacité dans la prise en compte des évolutions futures.

Les règles de construction de SI s'adressent aux projets. Elles vont leur garantir une bonne insertion dans le SI et une bonne capacité d'évolution. Par exemple :

• Obligation, pour un module, d'être dans un et un seul domaine métier
• Usage des référentiels
• Nécessité de distinguer ce qui outille les processus métiers, le décisionnel, la gestion des ressources, la sécurité, …
• Nécessité d'isoler les mécanismes d'échanges
• Règles d'architecture technique (technologie, composants, …)

Elles simplifient les projets, leur maintenance et leur appréhension par les acteurs SI

Rhona Maxwel

@rhona_helena

"Ayant médité la douceur et la compassion, j'ai oublié la différence entre moi et les autres."

Milarepa

Articles conseillés :

Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ?

La méthode top-down dans l'urbanisme du Sytème d'Information

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus

Quand les règles d'urbanisme ont été définies dans une démarche strictement top-down, il est à craindre des situations de blocage dans la mise en œuvre.

Le besoin de disposer d'un ensemble de règles provient toujours de la nécessité d'introduire une cohérence dans la construction du SI :

• pour définir un cadre normalisé de référence pour la gouvernance du Système d'Information.
• pour homogénéiser, si nécessaires, les méthodes de développement, lorsqu'il y a plusieurs directions fonctionnelles.
• dans le cadre de fusion de sociétés, pour définir les règles de construction des futurs systèmes communs.
• pour pouvoir disposer d'un ensemble de règles standardisées.

C'est le besoin de cohérence et d'efficacité qui assurera lui-même le rôle moteur de l'urbanisation du SI.

Quand les règles d'urbanisme ont été définies dans une démarche strictement top-down, il est à craindre des situations de blocage dans la mise en œuvre.

L'adoption des règles est un mécanisme progressif et cumulatif.

Les principes sur lesquels sont fondés les règles d'urbanisme sont :

• alignement sur les métiers
• cohérence
• modularité
• subsidiarité
• progressivité

Les règles d'urbanisme vont formuler ce qui exigé et ce qui est interdit, mais trop de contraintes n'est jamais bon et il faudra laisser suffisamment de souplesse aux chefs de projet.

Rhona Maxwel

@rhona_helena

"Nul ne sait ce qu'il peut faire avant d'avoir essayé".

Publilius Syrus 

Articles conseillés :

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ?

La méthode top-down dans l'urbanisme du Sytème d'Information

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus

Urbanisation du Système d'Information : créez l'évènement !