urbanisation-si.com

urbanisation-si.com

Urbanisation SI


Découvrez pourquoi vous devez rationaliser votre portefeuille applicatif avant toute tentative de transformation numérique

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. 

 

rationalisation-portefeuille-application-leanix-04 

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.

 

urbanisation-si_logo

 

Neil Sheppard

LeanIX

 

 

 

 

 

 

"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.]

 

Compléments de lecture

 


12/03/2024
0 Poster un commentaire

Comment gérer efficacement votre documentation d'architecture technique ? Essayez le C4 model avec l'outil Uncia

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 ?

uncia-documentation-manuelle-01

 

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 : 

 

 

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 ?

 uncia-processus-ideal 

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.

C4model4levels

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é.

 

C4 model legend

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 ?

  uncia-structure-du-dat

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 ?

 

ExempleUncia

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.

 

 

urbanisation-si_logo

 

Rhona Maxwel

Thierry Biard

urbanisation-si.com

 

 

 

 

 

 

 

"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

 

Compléments de lecture

 

 


13/02/2024
0 Poster un commentaire

Quel outil ArchiMate pour modéliser vos architectures d’entreprise sources et cibles, évaluer les écarts, analyser les impacts et élaborer des trajectoires de transformation ? Obeo SmartEA S.1 Ep.1

En phase E "Opportunités et Solutions" de l'ADM TOGAF, Aya Dupuis, architecte d’entreprise, doit générer la feuille de route d'architecture, avec une analyse des écarts entre l'architecture de base et les composants candidats de la cible. Une bonne manière d'étudier et de synchroniser différentes solutions est d'utiliser un système de gestion de branches : c'est ce que propose l'éditeur français Obeo avec son outil SmartEA

 

obeo-smartea-nouveau-navigateur-url-differences-salesforce-chatgpt

   

Un acteur dûment authentifié peut accéder, via une URL, aux artefacts du référentiel d'AE.
Ses actions sont fonction des autorisations (prisme dans la terminologie Obeo SmartEA)
qui lui sont octroyées. Ici, Raphaël David, le DSI, visualise les écarts entre une solution commerciale
et une solution interne sur mesure.

 

Intégration de l'IA : développement sur mesure ou
solution commerciale augmentée avec des modules d'IA ?

 

La DG de l'institution de prévoyance ABIP doit tenir compte des menaces des pure players intégrant d’emblée l’IA dans tous leurs processus métier. Pour ne pas se laisser distancer par la concurrence et maintenir des tarifs constants, elle doit diminuer ses coûts de développement et d’exploitation.

 

Pour contribuer à l’atteinte de ces objectifs, il a été décidé en comité de direction, d’intégrer l'IA générative. L'exigence retenue portera sur l'automatisation complète du processus de ranking des mails pour la Relation Client, qui a mauvaise presse et qui doit redorer son blason.

 

Deux solutions seront à l’étude : un développement sur mesure et une solution commerciale augmentée avec des modules d’IA.

 

Pour que les différents acteurs puissent collaborer à ces solutions en ayant accès au référentiel partagé d'entreprise, Aya Dupuis a mis en place l’outil Obeo SmartEA associé à Obeo Information System Designer (ISD), outil open source destiné aux architectes techniques et aux concepteurs-développeurs (voir en annexe nos articles sur ISD). 

 

Comment travailler sur différentes versions
d’une même architecture ?

 

Pour ne pas se faire disrupter, une entreprise est fréquemment obligée d'innover en adaptant ses processus métier. Pour conserver l’alignement avec le Système d’Information, les architectes doivent proposer différentes branches du référentiel d’Architecture d’Entreprise. La validation d’une transformation passera par la mesure des écarts et une étude d’impacts dus aux changements.


Le meilleur moyen de gérer différentes implémentations possibles d’un même système repose sur les technologies de gestion de branches, comme on en trouve dans le framework open source Git, très populaire dans le monde du développement.

 

Les normes et standards de modélisation graphiques ont prévu une équivalence textuelle (voir en annexe notre article consacré aux diagrammes en tant que code). Aujourd'hui, la grande majorité des outils stockent leurs modèles dans des fichiers texte utilisant des formats exploitables, comme XML ou JSON.

 

Ainsi, en intégrant un système basé sur un logiciel comme Git, différents acteurs comme l’architecte d'Entreprise, l’architecte Solutions, l'architecte technique, l’expert métier… pourront accéder aux différentes branches du référentiel.

 

obeo-smartea-gestion-des-branches-git

 

   

Il est possible d'avoir plusieurs versions d'un même système
qui pourront converger vers la version courante si certaines conditions sont réunies. 

 

Obeo SmartEA, un outil branché !

 

Obeo SmartEA implémente un tel système et offre donc un mécanisme de branches permettant de gérer différentes évolutions de l'Architecture d'Entreprise à l'étude, mais pas encore validées, qui pourront être fusionnées ultérieurement dans la branche principale (master) du référentiel. 

 

Ainsi, chaque branche donne la possibilité de modifier une version donnée de l’architecture sans impacter les autres versions. Par exemple, la branche principale peut représenter l'état courant validé de l’architecture. Les autres branches, elles, peuvent servir à travailler sur des architectures cibles et, potentiellement, sur des architectures intermédiaires.


De cette façon, il est possible à tout moment de simuler puis de valider des transformations et des évolutions du référentiel, sans perturber la branche principale.

 

Créez une branche

 

Un conseil si vous envisagez différentes évolutions d’un modèle : essayez de prévoir, dans la branche source, une disposition de vos éléments qui permettra de mettre en valeur les changements. 

 

Pour créer une nouvelle branche, vous devez choisir une branche source. Dans notre exemple, il s'agit de partir de l'état courant du référentiel (branche master). 

 

obeo-smartea-nouveau-branche-master-vue-motivation

    

Aperçu de la strate Motivation de la branche master du référentiel d'AE.

 

La procédure de création est immédiate : il faut indiquer la branche source et saisir le nom de la nouvelle branche cible.

 

obeo-smartea-creation-branches-2

 

  

obeo-smartea-creation-branches-Salesforce-Cloud-IA

 

Vous récupérez ainsi dans la nouvelle branche le référentiel complet de la branche source. Vous avez alors la possibilité d'apporter toutes les évolutions que vous souhaitez.

 
obeo-smartea-nouveau-branche-ia-vue-motivation

     

Nouvelle branche (IA-RPA-No Code), créée à partir de la branche master modélisant,
au centre, les principes d’utilisation de l'IA générative, du RPA et du No Code
avec l’exigence, à droite, “Prioriser les messages clients”.

 

Analysez les écarts

 

Obeo SmartEA vous permet très facilement de visualiser les écarts : il suffit de dérouler le menu "Branche", qui se trouve à côté des menus Projet et Prisme.

 

obeo-smartea-nouveau-menu-analyse-ecarts

   

Lancez l'analyse en sélectionnant "Analyse d’écarts", puis indiquez les deux branches à comparer et cliquez sur "Analyser".

 

Il est possible de répercuter les différences de la cible sur la source en sélectionnant "Synchroniser".

 

obeo-smartea-nouveau-differences-ia-master

 

On retrouve dans la vue Motivation de la version à l'étude (IA-RPA-No Code)
les 3 principes et l'exigence supplémentaires (+ vert) par rapport à la version courante. 

 

obeo-smartea-nouveau-differences-ia-master-zoom

   

Zoom sur les différences entre la version à l'étude (à gauche) incluant l'IA, RPA et le No Code
et l'exigence "Prioriser les messages clients" et la version de base (à droite). 

 

Automatisation de la priorisation des messages
de la Relation Client : ChatGPT vs Salesforce

 

Le besoin est d'étudier les impacts d'un premier scénario consistant à réaliser l'exigence "Prioriser les messages clients" par un développement interne utilisant les API ChatGPT, le workflow No Code Make et la plateforme de développement No code HubSpot et un deuxième scénario utilisant des modules de la solution commerciale Salesforce intégrant de l'IA en environnement cloud. 

 

Aya Dupuis a créé deux nouvelles branches à partir de la branche IA (IA-RPA-No Code). Elles contiennent toutes les deux la même exigence à réaliser et se distinguent par leurs modèles ArchiMate représentant les diagrammes de mesure d'impacts des deux scénarios précédents.

 

Scénario #1 : l'association API ChatGPT avec le workflow No Code Make
et la plateforme de développent No Code HubSpotobeo-smartea-nouveau-branche-chatgpt-vue-technologie

    

Scénario 1 : création de la branche "chatgpt-make-hubspot".

Ici, un diagramme d'impacts montrant les composants applicatifs réalisant l'exigence.
Suivant les 3 principes liés à l'exigence (voir précédemment la branche IA), ils doivent utiliser
des logiciels No Code, du workflow (RPA) et de l'IA générative. Les technologies choisies sont :
la plateforme de développement No Code HubSpot pour les fonctionnalités sur mesure du CRM,
le workflow No Code Make et les appels aux API ChatGPT pour l'
IA générative.

 

Scénario #2 : Salesforce Cloud 

obeo-smartea-nouveau-branche-salesforce-vue-technologie

 

 

 

Scénario 2 : création de la branche "Salesforce".

Ici, un diagramme d'impacts montrant le composant applicatif réalisant l'exigence.
Les modules "Commerce Cloud" et "Service Cloud" de la solution commerciale Salesforce remplissent
bien les principes d'intégrer de l'IA, de Robotic Process Automation et  sont bien évidemment No Code !

 

Pour contribuer à la réalisation de l'exigence, chaque intervenant pourra accéder par exemple aux différences entre les deux scénarios, en lançant une analyse d'écarts.

 

obeo-smartea-nouveau-differences-chatgpt-salesforce

  

Exemple : liste des écarts entre la solution ChatGPT + Make + HubSpot en développement interne
et la solution commerciale Salesforce.

 

 

obeo-smartea-nouveau-differences-chatgpt-salesforce-zoom

 

 

Exemple : zoom sur le diagramme d'impacts, à gauche, de la solution ChatGPT + Make + HubSpot
en développement interne et, à droite, de la solution commerciale Salesforce.

 

Et réciproquement.

 

obeo-smartea-nouveau-differences-salesforce-chatgpt

  

Vue inverse : liste des écarts entre la solution commerciale Salesforce
et la solution ChatGPT, Make et HubSpot en développement interne.

  

obeo-smartea-nouveau-differences-salesforce-chatgpt-zoom

  

Vue inverse : zoom sur le diagramme d'impacts, à gauche, de la solution commerciale Salesforce
et, à droite, la solution ChatGPT + Make + HubSpot en développement interne.

 

La vue technologique de l’automatisation
de la priorisation des messages client

 

Chaque branche va pouvoir se développer en fonction de la collaboration de chacun des intervenants. Par exemple, Ethan Dubois, l'architecte applicatif, a pu accéder à la branche solution interne (chatgpt-make-hubspot) et cartographier les échanges entre les applications. 

 
Pour diminuer les coûts de développement, l’outil No Code HubSpot a été sélectionné. Grâce à cette plateforme, un composant de CRM avec des fonctionnalités sur mesure pourra être développé à moindre frais.

 

Après récupération des mails clients dans ce composant CRM, l’outil No Code de workflow Make enverra une requête à l’API de ChatGPT avec un prompt. Conçu par un "prompt engineer", il contiendra à la fois le message et les critères de priorisation formalisés par les experts métier. Ainsi, ChatGPT analysera le message et le classera par degré de priorité.

 

Ensuite, l’outil d’automatisation de process Make viendra récupérer la réponse et y ajoutera des étiquettes pour le ranking, avant de retourner l’ensemble en utilisant le composant CRM.

 

 

obeo-smartea-branche-chatgpt-flux-entre-applications

   

Aperçu d'une vue ArchiMate appartenant à la branche solution interne
et montrant les flux entre les composants applicatifs.

 

Répercutez la solution validée
sur la banche master de l'architecture de base

 

Les branches vont se développer par l'apport des différents intervenants. Une analyse des risques de chaque branche et ensuite une analyse comparative des charges de travail et des coûts permettront au comité de direction de trancher. Aya Dupuis devra alors synchroniser la branche master avec les différences de la branche validée.

 

obeo-smartea-nouveau-synchronisation-master-avec-chatgpt

  

Les pictogrammes surlignés permettent de sélectionner finement
les changements (à droite) à répercuter ou non sur la branche master (à gauche).

 

Conclusion

 

La phase E "Opportunités et Solutions" de l'ADM TOGAF prend en compte l'ensemble des écarts entre les architectures cible et de base dans tous les domaines d'architecture et regroupe logiquement les modifications en lots de travaux. Il s'agit d'un effort visant à élaborer une feuille de route la mieux adaptée.

 

Pour pouvoir gérer efficacement les exigences des parties prenantes, les opportunités, les solutions et les contraintes de mise en œuvre identifiées, Obeo SmartEA propose un référentiel collaboratif supportant un système de gestion de branches emprunté aux logiciels de versioning.

Chaque acteur peut apporter sa pierre à l'édifice en mesurant les écarts et les impacts des différentes solutions.

 

Après validation d'une solution en comité de direction, l'architecte d'entreprise pourra mettre à jour l'architecture de base en synchronisant la branche correspondante avec celle du scénario validé. 

 

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

“Le vieux monde se meurt, le nouveau monde tarde à apparaître
et dans ce clair-obscur surgissent les monstres.”

Antonio Gramsci

 

Annexe : compléments de lecture

 

 

       


28/11/2023
0 Poster un commentaire

Comment modéliser les niveaux (stratégique, tactique...) de l’Architecture d’Entreprise ?

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. 

 

togaf-niveaux-architecture-strategie-tactique-solution-01       

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

  

togaf-exemple-strategie-tactique-solution-02

  

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.

  

balanced-scorecard

    

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

    

 

Les architectures Tactiques

  

togaf-exemple-tactique-solution-03

  

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.

roadmap-diagramme

  

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.

  

bmm-business-motivation-model-exemple

  

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.

  

Strategic-Intent-Goal

  

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. 

  

traceability-relationship-matrix-relationship-view-simple

  

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.

  

traceability-window-usecase-server

  

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. 

  

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

  

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

Alain

  

Compléments de lecture

BMM (Business Motivation Model)

 

ArchiMate

 

Outils d'Architecture d'Entreprise

 


08/12/2022
0 Poster un commentaire

Démarche d’urbanisation du SI : les questions techniques, organisationnelles, voire existentielles

Comment documenter les strates Métier et Fonctionnel, une fois que l’on a les strates Application et Technique ? Un lecteur attentif de notre blog www.urbanisation-si.com, qui monte une cellule d'urbanisation dans une grosse entreprise, nous pose beaucoup de questions pertinentes, qui peuvent être séparées en deux catégories :
des questions techniques et des questions organisationnelles, voire existentielles.

question-mark-gc469bb40d_1280

 

Comment documenter les 2 strates hautes du modèle Cigref ?

 

"The Software Architect Elevator"

Bon, autant le dire dès le début, nous n'aimons pas le terme "cellule" pour désigner une équipe qui doit être ouverte à toutes les autres, de la Direction Générale jusqu'aux spécialistes systèmes et réseaux. A moins que vous soyez attiré par la vie monacale, essayez de trouver un terme plus adéquat.

 

P.S. Nous n’aimons pas non plus le concept de « Centre d’Excellence », qui sous-entend que les autres équipes sont médiocres.

 

Plus qu'un phare qui éclaire dans la nuit, une tour de contrôle, qui donne des instructions précises aux pilotes que sont les urbanistes et les architectures d’entreprise, serait mieux appropriée. Certains proposent plus pragmatiquement l’image d’un ascenseur*, qui effectue des allers-retours incessants entre le sous-sol et le dernier étage (oui, oui, nous savons tous quelle équipe est située au dernier étage).

 

*The Software Architect Elevator (O’Reilly, 2020), par Gregor Hohpe, co-auteur des Enterprise Integration Patterns (Addison-Wesley, 2012).

 

Le modèle en strates du Cigref

 

 

Les strates de l'urbanisation, selon le Cigref

 

Une cartographie est déjà faite pour les 2 strates basses du modèle Cigref :

  • la strate Application (quelques centaines d’applications, regroupées en zones d'urbanisme, avec les flux entre les applications),
  • la strate Technique (avec l'infrastructure mise en place et les technologies utilisées).

Effectivement, pour effectuer une cartographie de l'architecture existante, on commence généralement par les strates basses, sous la forme d'un inventaire élaboré.

 

Questions techniques

Comment documenter les 2 strates hautes du modèle Cigref ?

Les strates hautes sont effectivement plus difficiles à représenter.
La strate Métier est peut-être la plus facile des deux (c'est très relatif).
L'approche par les processus semble être la plus consensuelle.

On pourra distinguer deux niveaux :

  • les macro-processus, représentés généralement sous la forme de chevrons. Plusieurs chevrons imbriqués peuvent représenter la chaîne de valeur. On distinguera :
    • les macro-processus opérationnels, dits cœur de métier,
      qui constituent le véritable savoir-faire d'une entreprise,
    • les macro-processus de support ou de soutien
      (que l'on retrouve souvent à l'identique dans d'autres entreprises),
    • les macro-processus de pilotage, pour mesurer
      puis améliorer les macro-processus précédents.

 

processus-urbanisation-du-si 

Macro-processus de l'urbanisation du SI

 

  • les processus détaillés au niveau de chaque activité ou tâches. La représentation conseillée est la notation BPMN et il existe de nombreux outils gratuits pour faire cela.

bpmn-exemple-01

 

Exemple de diagramme de collaboration BPMN

 

La strate Fonctionnel est plus difficile à établir, surtout si l'on utilise des applications du marché (mais alors, cette strate sera-t-elle vraiment utile ?). Si vous développez vous-mêmes vos applications, ce sera peut-être plus aisé. C'est souvent un problème de granularité. Si vous appliquez un style d'architecture moderne comme celle des micro-services, alors ce problème est réglé : une fonction égale un micro-service. Oui, cette démarche d'urbanisation est simplifiée. En tout cas, il faudra au moins une fonction pour effectuer chaque activité ou tâche d'un processus détaillé dans la strate Métier.

 

cartographie-fonctionnelle-urbanisation-du-si-exemple-03

 

Exemple de cartographie fonctionnelle du SI

 

Comment définir et accompagner la trajectoire ?

Pas si vite ! Il convient d'abord de définir une architecture cible. Cette fois-ci, on commence généralement les strates hautes. Quels nouveaux processus métier mettre en place pour servir la stratégie de l'entreprise ? Puis quelles fonctions sont nécessaires ? Font-elles partie d'une application toute faite ou bien faut-il les développer ? Avec quel style d'architecture, en local ou sur le cloud et avec quelles technologies ? Voilà, vous avez défini votre architecture cible, déclinée sur les 4 strates du modèle Cigref.

 

Nous ne sommes pas des adeptes du big bang (bien que cela nous plairait, parfois, de pouvoir faire abstraction du passé : legacy systems, dette technique, etc.). Aussi, sera-t-il raisonnable de définir des étapes intermédiaires entre l'architecture existante et l'architecture cible. Méditez la citation à la fin de cet article. Ce sont donc l'architecture existante, les étapes intermédiaires et l'architecture cible qui définissent la trajectoire à suivre.

 

Comment apporter de la frugalité, de la sobriété, de la sécurité et de la résilience ?

Frugalité

 

Ce terme est encore peu employé concernant l’urbanisation du Système d’Information et l’Architecture d’Entreprise. Sans doute un synonyme de la réduction des coûts 😉 Pas sûr que l’on arrive, grâce à la démarche d'urbanisation, à faire plus avec moins. Ce que nous visons, c’est de faire mieux : que chaque euro dépensé le soit à bon escient ; que la décision de cette dépense puisse être justifiée de façon rationnelle.

 

Sobriété

 

En informatique et plus particulièrement en développement logiciel, la sobriété est bien souvent synonyme de réutilisation (des fonctions, des composants, des modules, des interfaces, des micro-services. etc.). Pour reprendre une formule clef de la méthode Praxeme (Praxeme, la bonne (méthode) à tout faire ?), il faut bannir la redondance : cela vaut notamment pour les données enregistrées dans des bases, qui sont trop souvent multiples.

 

Sécurité

 

N.B. La question originelle indiquait la sécurité informatique uniquement. L'approche par les processus métier permet aussi de renforcer la sécurité des personnes, puis des biens.

 

La sécurité résultait souvent d'une dernière passe effectuée toute à la fin de chaque projet. Il semble évident désormais qu’il faut prendre en compte la sécurité le plus tôt possible dans le cycle de vie d’un projet. En fait, la sécurité devient indissociable de la gestion des risques (TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?).

 

Résilience

 

La résilience est une des réponses adaptées aux questions de sécurité et surtout à la gestion des risques (le risque zéro n’existe pas : il faut prévoir des solutions alternatives).

 

Questions organisationnelles

Quels sont les objectifs du processus d'urbanisation du Système d'Information ?

  • Faire connaître le SI existant à travers la cartographie des processus métier et la cartographie applicative, ainsi que le plan de la gestion des risques.

  • Gérer les référentiels MOA des données majeures, ainsi que la mise en place d'outils de gestion de tels référentiels.

  • Elaborer des cibles fonctionnelles, applicatives, techniques, mettre en œuvre des systèmes de traçabilité et de mesure d'impact de la stratégie sur le SI.

  • Aligner l’architecture technique sur l’architecture métier selon les domaines traditionnels :
    • L’architecture conceptuelle ou métier,
    • L’architecture logique ou fonctionnelle,
    • L’architecture physique ou technique.

  • Maîtriser la complexité des flux en les décrivant, en normalisant les données partagées (format pivot), en mettant en œuvre un dispositif d'échange mutualisé.

  • Piloter l'urbanisation du SI et communiquer.

  • Maîtriser la construction du SI en intégrant l'urbanisme dans la gouvernance et les études amont, décider des règles d'urbanisme et les faire appliquer, élaborer les plans de migration.

 

Quelles sont les règles de l’urbanisation du SI ?

 

Questions existentielles

Quels sont les apports ?

  • Une méthode pour réaliser des processus ouverts pour les directions métier (MOA)

  • Des recommandations pour faciliter la réutilisabilité, l’évolutivité et la généricité des applications pour les maîtrises d'œuvre (MOE). Tout échange avec les partenaires se fait à travers un portail. La propriété de généricité d’entreprise étendue est remplie avec un seul et même portail pour les employés, les clients et fournisseurs, qu’il suffit de paramétrer selon des règles appropriées.

  • Une meilleure connaissance et une vue d’ensemble de l’existant, la modélisation des objectifs et processus métier, les architectures fonctionnelles et applicatives comme cadre de référence, une meilleure connaissance des projets.

  • Construire une cible fonctionnelle par une approche bottom-up, comme vu précédemment, ou top-down avec des process innovants en mode "open innovation" des startups.

  • Le processus de gouvernance permet d’inscrire l’urbanisme le plus en amont possible, permettant aux architectes d’intervenir le plus tôt possible dans les projets.

  • Un référentiel des processus qui est alimenté par leurs concepteurs, articulé avec le référentiel applicatif et les fonctions de la cible d’urbanisme, permettant une continuité entre les modèles de processus, fonctionnels et applicatifs.

  • Une meilleure intégration MOA et MOE permettant, entre autres, l’automatisation des processus métier.

 

Quel est le retour sur investissement (ROI) de l’urbanisation de SI

C’est celui d’une infrastructure caractérisée par un investissement à la création, puis par un coût d’entretien. Au début des surcoûts apparaissent ; viennent ensuite les économies réalisées :

  • la réduction des études amont,
  • l’anticipation des impacts des autres projets,
  • la réduction du périmètre des projets,
  • la réduction des études, des développements et de la recette,
  • la réutilisabilité de blocs applicatifs,
  • l’existence de règles permettant aux projets de se concentrer sur les aspects métier.

 

Dès que l’apport de valeur dépasse le cumul des surcoûts, le ROI est atteint.


Qui suis-je ?

Un urbaniste de SI est plutôt un ancien responsable de domaine métier, généralement transverse. Il peut avoir été à ses débuts un architecte logiciel ayant acquis une solide expertise métier au bout d'une dizaine d'années d'expérience au service de grands projets réussis. Dans les grandes entreprises, l'urbaniste du SI peut être rattaché à la DG, plutôt qu'à la DSI.

 

S’il est interne à l’organisation, il établit sa crédibilité personnelle avec le métier et les parties prenantes, il doit montrer la valeur de la démarche d’architecture, accompagnée de sa méthode. S’il est consultant externe, il doit démontrer sa crédibilité, ainsi que celle de la société de services qu’il représente.

 

Il doit établir la vue des besoins métier, formuler les perspectives explicites ou implicites de l’organisation, en utilisant par exemple l’outil “business model canvas”, qui présente la manière dont une organisation crée de la valeur et se l’approprie. L’objectif est de préparer la proposition de vision et de périmètre de l’architecture.

 

L’urbaniste du SI décrit les avantages quantitatifs et qualitatifs de la démarche d'urbanisation. Une des tâches est de définir les concepts d’architecture. Il s’agit de modéliser l’état actuel du métier, puis l’état souhaité, ce qui va servir de base à la conception du plan de transformation de l’organisation.

 

Les exigences des parties prenantes sont recueillies avec les méthodes standards d’analyse de documents, d’interview, de groupe de travail, de brainstorming et d’observation. Pour faciliter l’adhésion des parties prenantes, il faudra détecter les soutiens et les résistants au changement.

 

Les solutions possibles sont identifiées. La panacée passe par un brainstorming, une évaluation des dépendances, une estimation des coûts et une analyse des contraintes. L’objectif est de proposer plusieurs solutions, puis de concevoir la solution choisie et la mettre en œuvre (Les étapes d'un schéma directeur).

 

La solution acceptée doit être déployée. La mise en œuvre pouvant s’effectuer sur une période significative, un processus de gestion des changements devra être élaboré, dans une perspective de résolution consensuelle des conflits.

 

Où vais-je ? Dans quel état j'erre ?

 

ia-architecture-entreprise-hal

 

L’IA aura sûrement un rôle à jouer dans les décisions des comités de direction.

 

Architecte de la chaîne de valeur

 

L’avenir de l’architecture d’entreprise pourrait se trouver dans les patterns organisationnels modélisant les structures communes de plusieurs entreprises. Les limites du BPM (comme les processus métier dynamiques et ad hoc) sont trop souvent mises sous silence et doivent au contraire être référencées.

 

Dès lors, le champ des préoccupations d'urbanisme débordant le monde clos de l'entreprise, il faudra raisonner sur l'entreprise et son écosystème. Les flux, la gestion des grands référentiels, l'activation de services automatisés, de bases de connaissances, seront à situer dans un contexte élargi, où les mouvements stratégiques, partenariats, fusions, filialisations, acquisitions, externalisations, pourront redistribuer les cartes autour des composants urbanisés.

 

Les urbanistes, devenant architectes de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action. Il faudra se préoccuper de diffuser la culture du management par les processus, de faire passer le BPM dans la réalité : instituer des propriétaires de processus, gouverner l'amélioration et piloter les performances, pour que les processus répondent aux services qu'attendent les multiples parties prenantes, clients, usagers, partenaires, employés, actionnaires, sociétaires…

 
Catalyseur de cohérence

 

Les processus sont considérés comme une entrée, et l'urbaniste n'a pas de légitimité pour les optimiser, voire les remettre en cause.

 

Pourtant, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transverses, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : l'urbaniste sera le catalyseur de la cohérence, de la transversalité, et de la flexibilité.

 

Urbaniser le métier et architecturer l'entreprise tirent les urbanistes vers le haut, que leur référence s'appelle Urbanisme des SI, Architecture d'Entreprise ou Gestion des Processus Métier (BPM Business Process Management).

 

Ils ne doivent pas ignorer les évolutions techniques. Un miracle technologique se produira-t-il (attention aux effets de buzz) ? Une révolution technique donnera-t-elle l'agilité instantanée tant espérée ?

 

Les grandes entreprises, dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire multiple, protéiforme, à des contraintes de marché archi-mondialisé. Il leur faudra lutter férocement contre l'entropie et rechercher toujours plus d'agilité.

 

Architecte d'Entreprise augmentée

 

Dans le futur, tel un funambule, l'urbaniste devra maintenir l'équilibre sur une corde qui sera disposée malheureusement de plus en plus haut.

 

La gouvernance doit constamment faire de la prospective, afin de maintenir ses informations sur l’IA, devenue un 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.

 

Les entreprises entamant leur transition numérique devront composer des équipes aux triples compétences : métier, informatique et mathématiques, sous la direction du CDO.

 

Un jour peut-être, une bonne fée, nommée IA, apparaîtra avec sa baguette magique, et grâce à son omniprésence et sa protéiformité, comme le RPA (Robotic Process Automation) ou les chatbots, et déclenchera une disruption et fera naître une Architecture d'Entreprise augmentée.

 

L’IA aura sûrement un rôle à jouer dans les décisions des comités de direction (Architecture d'Entreprise augmentée, quelle influence de l’Intelligence Artificielle sur la gouvernance et la stratégie ?).

 

 

urbanisation-si_logo

 

Thierry Biard

& Rhona Maxwel

urbanisation-si.com

 

“Il n'y a pas de grande tâche difficile qui ne puisse être décomposée en petites tâches faciles.”
Shantideva, grand maître bouddhiste du VIIe siècle.

 

 

Compléments de lecture

 


22/11/2022
0 Poster un commentaire

Architecture d'Entreprise augmentée, quelle influence de l’Intelligence Artificielle sur la gouvernance et la stratégie ?

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 ?

 

architecture-entreprise-intelligence-artificielle-ia-hal-9000 

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 :

 

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.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“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

 


09/06/2022
0 Poster un commentaire

Exemple de méthode d’Architecture d’Entreprise d’un grand cabinet de conseil : EAM Enterprise Architecture Management de McKinsey

L’Enterprise Architecture Management (EAM) de McKinsey est une méthode pour gérer l’alignement de l’architecture informatique avec les besoins métier. L’EAM s’appuie sur un modèle en six couches, regroupées en trois domaines : le business model, le panorama applicatif et l’infrastructure.

mckinsey-enterprise-architecture-management-6-couches

Le modèle en 6 couches de l’Enterprise Architecture Management (Source McKinsey)

 

McKinsey et la réduction des coûts

McKinsey est un cabinet de conseil qui met son expérience, ses connaissances, ses méthodes et ses outils à la disposition de son réseau mondial, tout en développant des solutions originales et créatives, adaptées à chaque situation particulière, au service des intérêts de ses clients afin de définir et de mettre en œuvre une vision intégrée du changement.

 

McKinsey est mondialement connu pour ses préconisations en stratégie et plus particulièrement en méthode de réduction des coûts. Nous allons voir dans cet article que cette approche est évidemment bien intégrée dans sa méthode d’Architecture d’Entreprise.

 

Un peu de révision

L'architecture informatique (IT) d'une entreprise est une description formelle de ses applications et des données qui les prennent en charge, ainsi que des équipements et des services qui exécutent ces applications.

 

Le modèle d’Architecture d’Entreprise spécifie une solution alignée prenant en compte aussi bien l’humain que les processus, la technologie et la culture de l’entreprise, en répondant aux exigences de la transformation digitale.

 

L’un des enjeux de l'Architecture d’Entreprise est de simplifier la représentation du système, jugé complexe, de l’entreprise, afin de la rendre plus agile. 

 

Les applications sont généralement conçues et déployées pour répondre aux besoins d'une division ou d'une unité commerciale, sans tenir compte de l'impact sur l'architecture informatique globale d'une entreprise.

 

Les grandes entreprises possèdent un patrimoine informatique important et hétérogène, où du matériel, des applications et des processus incompatibles et souvent redondants, se multiplient d'année en année, dans tous les recoins de l'organisation, en réponse à des besoins spécifiques à court terme.

 

Pour créer une architecture informatique efficace, la DG doit créer un groupe de travail métier-informatique de haut niveau, qui assure la gouvernance et la responsabilité inter-organisationnelles. Les principales responsabilités de cette équipe sont d'examiner l'architecture informatique existante et de créer une base de référence pour la nouvelle initiative, de définir un processus garantissant que les systèmes et les projets seront conformes à l'architecture souhaitée, et d'identifier les opportunités à court, moyen et long termes pour des économies et des améliorations.

 

L'équipe doit inclure tous les groupes de parties prenantes clés, avec des représentants à un niveau suffisamment élevé pour prendre des décisions stratégiques.

 

Une transformation en 3 coups de baguette magique

Une approche en trois phases de la transformation digitale permet de minimiser les interruptions de l'activité de l’entreprise.

 

mckinsey-enterprise-architecture-management-3-etapes

 

Les 3 étapes de la méthode "Enterprise Architecture Management" (Source McKinsey)

 

Première phase : le grand nettoyage de printemps

 

mckinsey-enterprise-architecture-management-nettoyage

 

Décommissionnement d'applications et réduction de la complexité (Source McKinsey) 

 

Dans la première phase, la tâche pour le département d’Architecture d’Entreprise est d'identifier des cibles évidentes et de générer des gains rapides, grâce à des réductions de coûts qui contribuent à créer une dynamique pour des initiatives plus importantes. Comme pour un particulier ayant contracté des abonnements à des médias qu’il n’utilise plus, l’entreprise doit résilier les services et les licences dont elle n’a plus besoin.

 

Concernant les projets en cours, ceux qui apportent peu de valeur métier, on annule les non-conformes à la stratégie IT et l'on retarde ceux qui le sont. On doit repenser ceux qui sont liés aux objectifs majeurs métier, mais qui ne sont pas en adéquation avec la road map IT et continuer ceux qui la suivent. 

 

Les applications peu ou jamais utilisées doivent être décommissionnées. Différentes approches peuvent être nécessaires : en fonction de l'utilisation et des besoins, certaines peuvent être retirées immédiatement, d'autres remplacées par de nouvelles applications, et d'autres encore supprimées progressivement.

 

L'entreprise doit se concentrer sur les violations potentielles de l'architecture informatique au début de tout projet informatique ou lors de la sortie d'une nouvelle application. La nouvelle approche, qui consiste à évaluer les implications globales des violations, y compris leur éventuel coût supplémentaire, permet à l'entreprise de prendre en charge rapidement les nouvelles exigences métier, mais nécessite que toutes les violations qu'elles créent soient corrigées dans une phase ultérieure. L'entreprise peut donc évaluer les compromis coûts/avantages métier et informatique dans chaque cas, avant d'aller de l'avant avec les projets.

 

Deuxième phase : démêler les spaghettis

Réduire la complexité : la cellule d’Architecture d’Entreprise doit tout mettre en œuvre afin de simplifier l'ensemble de l'architecture informatique. Plus ambitieuse, cette étape est primordiale pour enrayer la multiplication des développements des applications sur mesure et pour initier une gouvernance pour la réalisation des objectifs d’architecture. Plutôt que d'essayer d’optimiser des éléments de la configuration informatique existante, il faut décider prioritairement s’ils sont vraiment indispensables. Une bonne pratique est de privilégier des systèmes prêts à l'emploi plus simples et la réutilisation de composants existants, qui peuvent répondre aux besoins de l'entreprise. 

 

Privilégier les solutions sur étagère

Des projets stratégiques entièrement développés sur mesure échouent à cause d’une sous-évaluation de la difficulté technique de réalisation. En effet, trop de projets adoptent la personnalisation comme première, option plutôt que comme dernière option.

 

Une entreprise ne peut pas faire en sorte que toutes ses unités métier adoptent immédiatement des applications standard et totalement non personnalisées, mais compte tenu des ressources limitées, l’entreprise devrait exiger des solutions prêtes à l'emploi dans la grande majorité des cas, permettant la personnalisation uniquement lorsque cela est absolument nécessaire, pour répondre aux exigences légales ou pour fournir des avantages concurrentiels significatifs.

Par exemple, les fonctions de support telles que la finance, la comptabilité, les ressources humaines et les achats, qui ne jouent généralement pas un rôle en concurrence directe avec d'autres entreprises, sont des candidats de choix pour réaliser des économies dans cette phase. 

 

Ne pas réinventer la roue

Trop d'entreprises dépensent de précieuses ressources informatiques pour réinventer la roue. Un examen sérieux du portefeuille de projets existant permettra probablement de découvrir un certain nombre d'opportunités, de réutiliser les solutions existantes et de créer un référentiel commun de services et de solutions.

 

Le passage à une architecture micro-services, qui décrit un système en termes de fonctionnalités métier dont il a besoin et la manière uniforme d'y accéder et d'interagir avec elles sous forme d’API (Application Programming Interface), est un élément important de cette évolution.

 

Standardiser les technologies

Dans de nombreuses entreprises, la grande diversité des technologies, y compris les langages de programmation, des systèmes d'exploitation et des outils d'intégration, nuit à l’efficience. Un examen attentif mettra en évidence les versions redondantes, les technologies non prises en charge et les outils non standard, qui devraient céder la place à des systèmes moins nombreux et plus universels. Les économies de coûts proviennent d'un approvisionnement plus simple et consolidé, ainsi que d'une diminution des dépenses d'assistance et de maintenance.

 

Supprimer la tour de Babel entre applications

Une équipe informatique peut consacrer une bonne partie de son temps à développer des interfaces de communications entre applications. Par exemple, une solution telle qu’un bus de services d'entreprise (ESB) peut améliorer l'intégration du système et minimiser la gestion fastidieuse des modifications locales.

 

Factoriser les systèmes qui font des traitements similaires

Différentes unités métier d'une même entreprise ont souvent leurs propres versions de systèmes fondamentaux, tels que les plateformes d'e-commerce. La conception d’une surcouche générique abstraite de ces systèmes au niveau de l'entreprise peut apporter des économies substantielles et rendre les processus plus simples et plus efficaces.

 

Certaines de ces opportunités de réduction des coûts nécessiteront des investissements, et chacune d'entre elles exigera une analyse de rentabilité solide.

 

Toutes ces bonnes pratiques ne montreront pas forcément un ROI positif. Ce qui importe, c’est que les responsables prouvent la plus-value métier de chacun de leurs projets. En moyenne on peut escompter un ROI de plus de 50 %, une réduction du time to market d'au moins 30 % et des avantages organisationnels notables, comme un meilleur alignement entre l'entreprise et l'informatique.

 

Troisième phase : disrupter le métier

En temps de crise, les entreprises doivent envisager de se transformer, voire de se réinventer complètement. L'informatique peut jouer un rôle central dans la mise en œuvre de grands changements, dans leur mode de fonctionnement et de mise sur le marché de produits ou de services. Les entreprises doivent envisager de changer leur informatique de manière plus radicale de manière à stimuler ou soutenir l'innovation stratégique et des domaines de croissance fondamentalement nouveaux. 

 

Évaluer des modèles de fonctionnement alternatifs

Un examen complet de la chaîne de valeur informatique doit identifier le niveau d'approvisionnement, d'harmonisation, de consolidation, de gouvernance et d'activation informatique nécessaires pour chaque capacité métier essentielle. Cet examen peut conduire à un nouveau modèle de plan directeur et d'architecture plus efficace pour l'informatique.

 

Par exemple, la gestion et la minimisation des risques, qui sont particulièrement importantes en période de ralentissement, dépendent fortement de l'obtention des bonnes données de l'ensemble de l'entreprise pour soutenir la prise de décision. Les responsables métier et informatique doivent travailler de concert pour concevoir le modèle de données qui favorisera les processus de décision les plus efficients.

 

Façonner l'avenir

Les chefs d'entreprise doivent travailler en étroite collaboration avec le service informatique pour explorer les investissements dans un large éventail de technologies émergentes, qui prennent en charge de nouvelles méthodes de travail, comme la gestion basée sur l’Intelligence Artificielle. 

 

Les déclencheurs de cette approche plus ambitieuse de la transformation architecturale peuvent varier d'une entreprise à l'autre. Pour une mutuelle par exemple, il s'agissait d'une fusion qui la propulsait dans le haut du classement de son secteur. Malgré cela, il était difficile de se maintenir avec deux modèles de fonctionnement différents reposant sur des systèmes d'information archaïques.

 

Après avoir défini un nouveau modèle opérationnel global intégré pour les assurés, les prestations, les cotisations, la gestion du cycle de vie des produits et les services antifraude, la mutuelle l'a mis en œuvre avec une architecture informatique rationalisée. L'impact a été considérable. Parmi de nombreux autres avantages, elle a réduit le temps nécessaire pour répondre à des appels d'offres pour les différentes branches professionnelles.

 

Conclusion

Au sein d’une entreprise, il peut y avoir beaucoup de gâchis.

L’EAM de McKinsey impose la recherche puis la suppression des contrats, licences et services qui ne servent plus et qui sont oubliés depuis bien longtemps. 

Les équipes projet doivent penser réutilisabilité ou progiciels du commerce, avant de se lancer dans des développements spécifiques très risqués. 

L’innovation doit être facilitée, grâce notamment à une collaboration étroite entre la DG, les responsables métier et informatique. 

Pour survivre aux disruptions, tout le monde sait qu’il faut une plus grande flexibilité, des délais de mise sur le marché plus rapides, des processus métier plus efficients. Un bon moyen d’y parvenir est de mettre de côté les méthodes du passé trop rigides et d'innover avec des méthodes en perpétuelle évolution. 

Cela a conduit les cabinets de conseils comme McKinsey, les ESN comme Capgemini (avec son IAF - Integrated Architecture Framework), ainsi que les grandes organisations à créer leur propre méthode d'Architecture d'Entreprise.

 

Une idée : pourquoi ne pas opérer des fusions, comme dans ce domaine des méthodes agiles avec Scrumban, en prenant ce que chacune a de meilleur ? Alors, à quand TOGEAM ?

 

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

“Durant 30 ans, en Italie, ils ont eu les Borgia, la guerre civile et la terreur. 

Cela a produit Michel-Ange, Léonard de Vinci et la Renaissance. 

En Suisse, ils ont eu cinq siècles de paix et de fraternité et qu’est-ce que ça a donné ? 

La pendule à coucou ! ”

Jean-Christophe Grangé

 

 

Compléments de lecture

 


05/05/2022
0 Poster un commentaire

Le rôle de la prospective pour une entreprise innovante et résiliente

“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.

prospective-analyse-des-futurs-possibles-1

 

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.

 

prospective-projections-analyse-séries-chronologiques-1-2Exemple 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

 

prospective-graphe-impacts-entre-variablesExemple 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.

prospective-matrice-impacts-croises

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.

 

prospective-identification-des-futurs-possibles-1-1Les 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.

 

 

 

prospective-exemples-scenarios-2

 

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.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“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 ?

22/03/2022
1 Poster un commentaire

Pour quelles raisons l’Architecture d'Entreprise prône la transformation ou dérivation des couches la composant ?

L'architecture d'entreprise qui inclut l'urbanisation des Systèmes d'Information ne cesse de prôner la transformation ou dérivation des couches la composant, stratégie en métier, métier en fonctionnelle, fonctionnelle en applicative et applicative en infrastructure à des fins d'automatisation, de traçabilité et de gouvernance. 

C'est la que rentre en jeu, l’Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture) qui repose sur la volonté de décrire précisément les besoins des clients par des CIM (Computational Independent Models) et la connaissance métier d’une organisation dans des modèles abstraits indépendants des plates-formes (PIM - Platform Independent Models).

 

Ayant isolé le savoir-faire métier dans des PIM, on a besoin soit de transformer ces modèles en d’autres PIM (besoin d’interopérabilité, migration vers un nouveau système, fusion de SI en cas d’acquisition d’une autre organisation, …), soit de produire ou de créer des modèles PSM (Platform Specific Models) ciblant une plate-forme d’exécution spécifique (pour améliorer la portabilité et augmenter la productivité).

 

Dans le cadre de l’IDM, les artefacts manipulés sont des modèles.

Ces types de modèles sont donc des méta-modèles.

Un méta-modèle est un modèle qui définit les concepts d'un modèle d'instance.

Cette relation est purement syntaxique. 

 

transformation-de-modèles-IDM-MDE-MDA-00.PNG

 

La Meta-Object Facility (MOF) de la norme OMG à quatre couches (M0, M1, M2, M3) est l’architecture de méta-modélisation.

 

Voir ci-dessous un article que j'avais consacré aux métamodèles :

 

 

Par exemple, le métamodèle de UML (Unified Modeling Language) est un modèle M2 du MOF.

De même, tous les langages spécifiques à un domaine (DSL Domain Specific Language) peuvent également être exprimé en modèles MOF.

 

Le noyau de MOF permet seulement d'exprimer des propriétés structurelles simples,

Associations similaires entre éléments, encapsulation, cardinalité, etc.

Le langage de contraintes d'objet (OCL Object Constraint Language) est un langage de contrainte déclaratif d’instructions ordonnées standard et un langage de requête, qui est utilisé pour associer des règles à des modèles.

Par exemple, on peut spécifier une structure, des invariants, des définitions et des pré/post conditions, des opérations MOF abstraites dans la langue OCL.

 

Voir mes tutoriaux sur OCL :

 

 

Le métamodèle de transformation contient trois éléments essentiels : source, cible et relation de transformation ou dérivation.

La relation de transformation est un ensemble de liens explicites entre les éléments de la source et le modèle cible.

Ces liens explicites jouent un rôle clé dans l’approche IDM.

Les relations entre les métamodèles définissent la structure des liens et des propriétés qu'ils doivent satisfaire et le méta-modèle de transformation, les liens qui doivent exister.

 

Une transformation de modèles est la génération d’un ou de plusieurs modèles cibles à partir d’un ou de plusieurs modèles sources.

 

Une transformation des entités du modèle source met en jeu deux étapes.

 

La première étape permet d’identifier les correspondances entre les concepts des modèles source et cible au niveau de leurs métamodèles, ce qui induit l’existence d’une fonction de transformation applicable à toutes les instances du métamodèle source. Cette correspondance se fait par l'établissement de règles. 
La seconde étape consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou d’exécution.

 

L’approche par modélisation consiste quant à elle à appliquer les concepts de l’ingénierie des modèles aux transformations des modèles elles-mêmes.

 

L’objectif est de modéliser les transformations de modèles et de rendre les modèles de transformation pérennes et productifs, en exprimant leur indépendance vis-à-vis des plates-formes d’exécution.

 

transformation-de-modèles-IDM-MDE-MDA-01.PNG

 

Une transformation endogène se situe dans le même espace technologique et les modèles source et cible sont conformes au même méta- modèle.

Par exemple transformation d'un modèle UML en un autre modèle UML

 

Une transformation exogène se situe entre 2 espaces technologique différents et les modèles source et cible sont conformes à des méta- modèles différents.

 

Par exemple transformation d'un modèle DMN ( Decision Model Notation )  en DRL (Drools Rules Language, le langage natif de règles métiers du moteur open source DROOLS).

 

taxonomie-transformation-de-modèles-IDM-MDE-MDA-02.PNG

 

Une transformation en série peut servir à réaliser une application ou un processus basé sur une série de transformations de modèles.

 

Par exemple : modèle de l'application au niveau abstrait, avec un modèle de composant abstrait, modèle PIM puis une projection du modèle vers un modèle de web services (SOAML) : PSM

 

Les types d’outils de transformation de modèles :

  • Langage de programmation « standard » : Ex : Java, pas forcément adapté pour tout, sauf si interfaces spécifiques, ex : framework Eclipse/EMF
  • Langage dédié d'un atelier de génie logiciel : Ex : MDG pour l’AGL Enterprise Architect, Langage de script de l’AGL MEGA, MDA Modeler IBM Rational, souvent propriétaire et inutilisable en dehors de l'AGL
  • Langage lié à un domaine/espace technologique : Ex: XSLT dans le domaine XML, AWK pour fichiers texte ...
  • Langage/outil dédié à la transformation de modèles : Ex : la norme QVT (Query View Transform) de l'OMG, le standard de l’industrie actuellement : ATL (Atlas Transform Language)

 

3 grandes familles de modèles et outils associés :

  • Données sous forme de séquence : Ex : fichiers textes (AWK)
  • Données sous forme d'arbre : Ex: XML (XSLT)
  • Données sous forme de graphe : Ex : diagrammes UML, outils : QVT, ATL, …

 

3 grandes catégories de techniques de transformation :

  • Approche déclarative : recherche de certains patrons (d'éléments et de leurs relations) dans le modèle source. Chaque patron trouvé est remplacé dans le modèle cible par une nouvelle structure d'élément. L’écriture de la transformation est « assez » simple mais ne permet pas toujours d'exprimer toutes les transformations facilement.
  • Approche impérative : proche des langages de programmation usuels, on parcourt le modèle source dans un certain ordre et on génère le modèle cible lors de ce parcours. L’écriture transformation peut être plus lourde mais permet de toutes les définir, notamment les cas algorithmiquement complexes.
  • Approche hybride : à la fois déclarative et impérative. La plupart des approches déclaratives offrent de l'impératif en complément car plus adapté dans certains cas.

 

Les référentiel pour stocker les modèles et méta-modèles utilise XMI (XML Interchange, norme de l'OMG). 

 

Les principales implémentations des langages de transformation de modèles ATL et QVT utilisent le métamétamodèle Ecore d'Eclipse qui est le standard de l'industrie. On retrouve tous les principaux concepts du niveau M3 UML du MOF  de l'OMG.

 

On trouve les métamodèles Ecore à peu près pour tout, les langages de modélisation normalisés (UML, SysML, BPMN, DMN, BMM, SOAML, ...) et même des langages open source comme celui de DROOLS, le moteur de règles métier, standard de l'industrie.

 

Voir mes articles sur Ecore : 

Les cadres d'architecture d'entreprise comme TOGAF (The Open Group Architecture Framework), Praxeme, ... énoncent des principes de dérivation des différents niveaux ou aspects. Mais aucune ne précise avec quels outils.

 

Alors, la question qui me tourmente, avez-vous ou votre organisation, mis en place des transformations de modèles et avec quels outils ?  

 

Rhona Maxwel

@rhona_helena

 

"Parmi les objets répandus au hasard, le plus beau c'est le cosmos. L'harmonie invisible est plus belle que le visible."

Héraclite d'Ephèse  

 

 

Articles conseillés :

 


18/11/2022
0 Poster un commentaire

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

L’année 2020 vient de s’écouler à tout jamais. Quel est le top 10 des articles les plus visités par nos amies lectrices et amis lecteurs de notre blog consacré à l’architecture d’entreprise, aux méthodes et aux outils, ainsi qu’à l’ensemble des aspects de la modélisation ?

 

meilleurs-articles-architecture-entreprise-methodes-outils

 

(Etude Accenture sur les leaders, développant les systèmes futurs et les retardataires [laggards], qui investissent dans l'innovation, mais ne parviennent pas à en tirer la pleine valeur.)

 

Pour entretenir le suspens, commençons par la dernière position.

 

10

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

 

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

 

Comme le suggère le titre de notre blog, la mise en œuvre de l’Urbanisation du Système d’Information et de l’Architecture d’Entreprise doit se faire avec méthode. Mais sans outil adéquat, l’application d’une méthode s’avère vite laborieuse.

 

Rappelons qu’il s’agit de mettre en place un référentiel d’architecture (généralement stocké dans une base de données) contenant des objets, qui seront ensuite utilisés pour créer des modèles (diagrammes, matrices, listes et rapports).

 

Les articles de notre blog concernant les outils rencontrant généralement un grand succès, en voici un concernant un outil intéressant, et pas seulement parce qu’il est gratuit.

 

Voir la catégorie Modélisation de système de notre blog :

 

 

9

L’Architecture Micro-Services expliquée à ma fille

 

L’Architecture Micro-Services expliquée à ma fille

 

Le nouveau style d’architecture pour concevoir des applications informatiques, voire pour urbaniser enfin le Système d’Information de l’entreprise.

 

Au lieu de dupliquer en entier des applications monolithiques, il s’agit désormais de distribuer, et même de dupliquer certains micro-services uniquement, sur différents serveurs. Tout en gagnant en flexibilité et en agilité, pour effectuer plus rapidement des changements, le plus souvent des améliorations.

 

Une application partitionnée en micro-services est plus robuste qu’une application monolithique. Un micro-service en panne ne bloque pas forcément toute l’application, qui devient alors résiliente.

 

C’est une évolution de la SOA (Service Oriented Architecture) : certains parlent de l’Architecture Micro-Services comme la SOA à grains fins. Elle ne remet pas en cause la SOA, mais propose des solutions techniques plus légères, souvent Open Source, comme RESTful notamment.

 

Voir la catégorie Architecture Micro-Services de notre blog :

 

8

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?

 

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?

 

Un use case UML (cas d'utilisation) est une activité métier comme, par exemple, un acte de gestion exécuté par un acteur externe à l'application.

 

Un use case comporte un ou plusieurs scénarios composés d’une ou plusieurs étapes.

 

Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.

 

Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".

 

Un use case doit avoir en moyenne 10 scénarios, composés chacun d'environ 10 étapes. De plus, il doit être déclenché par un unique acteur (rôle), exécuté dans une limite de temps, être transactionnel, avoir un début et une fin et pour terminer on doit avoir l'unicité de lieu.

 

Voir la catégorie UML de notre blog :

 

7

Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio

 

Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio

 

Le diagramme de contextes de projets modélise tout ce qui est nécessaire à la réalisation d’un projet : acteurs, processus métier, règles métier, services métier, entités métier, composants applicatifs.

 

Ce modèle est réalisé par les architectes applicatifs et experts métier avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.

 

6

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

 

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

 

Les Modsars de « urbanisation-si.com » récompensent les meilleurs logiciels de modélisation de Système d’Information.

 

Nos critères sont sans commune mesure avec les récompenses de références comme, par exemple, celles du Gartner.

 

Nous privilégions l’open source, la communauté et le partage d’informations, l’innovation, la fiabilité en production, la documentation.

 

Les domaines concernés sont ceux des catégories du site de « urbanisation-si.com » :

  • les normes de l’OMG comme UML, BPMN, SysML, DMN, BMM, OCL, MDA, QVT, XMI,
  • ArchiMate
  • les architecture d’entreprise comme Togaf, l'urbanisation du SI, Praxeme,
  • l’Ingénierie Dirigée par les Modèles avec MDE, ATL, Ecore...
  • les processus métiers et le BPM
  • les règles métiers et les BRMS
  • la simulation et la validation de modèles
  • la génération de code à partir de modèles
  • la gestion de projet avec les méthodes agiles, les méthodes d’estimation et de recettes.

 

Voir la catégorie Modélisation de système de notre blog :

 

5

BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

 

BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

 

Voici l'exemple de référence de modélisation BPMN présentant les concepts principaux des processus métiers.

 

L'objectif de cet article est de montrer concrètement comment un processus métier est modélisé avec BPMN.

 

L'accent est mis sur les concepts de « bassins » (pool) modélisant les échanges (associations) inter organisation et de « couloirs » (lane) représentant la communication (flux de messages) explicitant la modélisation des collaborations entre des participants.

 

Cet article montre comment nous pouvons composer des modèles de processus avec des sous-processus et appeler des activités.

 

Cet exemple ne contient pas de modèles de processus exécutables, mais représente un modèle de processus se concentrant sur les aspects organisationnels de processus métiers.

 

Voir la catégorie BPMN de notre blog :

 

4

ArchiMate pour les nuls : les fondamentaux - 1

 

ArchiMate pour les nuls : les fondamentaux - 1

 

L'adoption du standard ArchiMate par le monde de l'architecture d'entreprise a connu une croissance rapide au cours de ces dernières années. 

 

Si d’autres notations sont couramment utilisées par les architectes d'entreprise comme BPMN, DMN et UML, ArchiMate se distingue par son périmètre de modélisation couvrant à la fois les métiers et l’IT, le rendant particulièrement bien adapté pour améliorer l'alignement stratégique, métiers et IT.

 

Le cœur du framework comprend les couches métiers, applicatives et technologiques, avec des couches supplémentaires pour la stratégie, les éléments physiques, l’implémentation et la migration.

 

En intégrant les métiers et l’IT, ArchiMate répond aux principales attentes des parties prenantes de l’entreprise : le standard fournit un ensemble commun de concepts et de vues qui décrit toutes les couches de l'entreprise.

 

D’autre part, de nombreux concepts et relations dans ArchiMate sont basés sur les notations UML et BPMN, offrant une passerelle vers ces langages de modélisation. Mais ArchiMate ne cherche pas à remplacer ces standards.

 

Une grande partie de son succès peut en effet être attribuée au fait qu'ArchiMate inclut uniquement les concepts et les relations qui sont utiles, ce qui résulte en une courbe d’apprentissage très rapide de ce standard.

 

ArchiMate répond également à l'exigence des cadres dirigeants qui est d’avoir une vue d'ensemble de l’entreprise.

 

Le framework utilise des vues centrées sur les besoins spécifiques des différentes parties prenantes de l’entreprise, avec des objets pouvant provenir de différentes couches.

 

Par exemple, il est possible de montrer les applications, les technologies et les processus dans un seul et unique diagramme. 

 

Voir la catégorie ArchiMate de notre blog :

 

Dans l’annexe de cet article se trouvent les 37 articles de l'étude de cas :

 

3

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

 

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

 

La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le Système d'Information et enfin le Système Informatique.

 

En haut, juste en dessous de la stratégie d'entreprise qui ne fait pas partie de l'urbanisation du SI, on trouve la cartographie métier avec les processus métiers et leurs événements déclencheurs, puis en dessous, la cartographie fonctionnelle structurant le système d'information avec des blocs fonctionnels, un niveau encore en dessous, on trouve la cartographie applicative constituée de composants applicatifs du système informatique et enfin tout en bas la cartographie technique représentant l'infrastructure technique du système informatique.

 

Voir la catégorie ArchiMate de notre blog :

 

2

SysML : le diagramme d'exigence (requirement diagram)

 

SysML : le diagramme d'exigence (requirement diagram)

 

Lors de la modélisation de leur système, un grand nombre d’entreprises ont cherché à représenter les exigences afin d'assurer la traçabilité vers les modèles de conception UML.

 

Malheureusement, UML ne proposant pas de diagramme d’exigences, elles ont d’abord créé leurs propres profils UML ou bien utilisé des outils propriétaires. 

 

UML ne prévoit rien pour représenter des éléments non-logiciels, des équations mathématiques, des contraintes, des flux (énergie, fluide...), des allocations structurelles/comportementales... 

 

Et enfin UML utilise la terminologie orientée objet (classe, attribut, méthode...) qui si elle convient bien aux méthodes et langages de programmation objet, n'est pas celle adoptée par l'ingénierie système.

 

En l’absence de langage de modélisation normalisé dans le domaine des systèmes industriels complexes, l’OMG a créé un profil UML (package de stéréotypes, tags/values et contraintes OCL), nommé SysML en n'oubliant pas cette fois le diagramme d’exigences.

 

Voir la catégorie SysML de notre blog :

 

Dans cet article se trouvent les articles traitant : 

 

1

TOGAF pour les nuls

 

And the winner is...

 

TOGAF pour les nuls

 

Au tout début, dans les années 70 à 80, il y avait SOA, je veux parler bien sûr de “Silo Oriented Architecture”, où les architectures propriétaires régnaient en maître (IBM, Bull, DEC…).

Puis, dans les années 90s, toujours SOA, mais cette fois pour “Spaghettis Oriented Architecture” avec l’avènement des serveurs d’application.

 

Avant internet, en France on avait le Minitel, de même avant l’architecture d’entreprise, on avait l’urbanisation du Système d’Information (~1980 dans le domaine bancaire).

L’enjeu principal est de mettre l’IT en adéquation avec le métier. 

A cette époque, l’aspect stratégie est l’apanage de la DG et est négligé dans l'urbanisation du SI. 

 

L’alignement stratégique, la création de référentiels, la définition de scénarios de transformation et l’analyse d’impact ont commencé aux USA avec PRISM framework (1986, IBM), le framework de Zachman (1987) (Architecture d'entreprise : le framework de Zachman pour les nuls), NIST EA model (1989), puis avec DoDAF (~2000, Department of Defense Architecture Framework).

 

A partir de là, on commence à voir apparaître en France des méthodes. 

La Délégation Générale pour l'Armement a élaboré son cadre de référence : Agate (Atelier de gestion de l'architecture des systèmes d'information et de communication, ~2000). 

En 2003, la méthode Praxeme (PRAXEME, la bonne (méthode) à tout faire ?) voit le jour autour d’une nouvelle architecture appelée SOA Service Oriented Architecture. 

 

Voir les catégories de notre blog :

  • Architecture Orientée Services (SOA)

 

Aujourd’hui en France, l’urbanisation du S.I. et Architecture d’Entreprise sont devenues synonymes. 

 

En 1995, la première version de TOGAF (The Open Group Architecture Framework) est publiée. La transformation de l’architecture d’entreprise a sa méthode générique avec des solutions sur étagères.

Évidemment l’objectif suprême est la réalisation d’applications opérationnelles.

 

Pour se faire, il faut une vision globale couvrant les aspects stratégiques, métiers, organisationnels, s’assurer de l’alignement entre le métier et la technique, rechercher constamment l’évolutivité des SI et avoir une culture de l’innovation.

 

Tous les métiers évoluent, le simple développeur disparaît pour devenir fullstack, DevOps voir DevSecOps, l’architecte d’entreprise se métamorphose pour préparer des scénarios d’innovation et anticiper les impacts des tsunamis que sont l’Intelligence Artificielle (Machine Learning, Deep Learning, Big Data), le Cloud [IaaS, PaaS, SaaS, FaaS], IoT, DevOps CI/CD, Microservices Architecture…

 

On peut continuer le parallèle entre le développeur qui n’a plus à mettre en place la chaîne de réalisation d’une application, grâce aux nouveaux outils d’automatisation DevOps CI/CD, et l’architecte d’entreprise qui n’aura plus à assurer la traçabilité métier - IT, qui se fera automatiquement avec les outils d’IA d’analyse des données.

 

Voir la catégorie TOGAF de notre blog :

 

Dans l’annexe de cet article se trouvent les 41 articles de l'étude de cas :

 

 

Rhona Maxwel

@rhona_helena

 

“Celui qui n'appliquera pas de nouveaux remèdes doit s'attendre à de nouveaux maux ; car le temps est le plus grand des innovateurs.”
Francis Bacon

 

Références des principaux articles du blog

 

TOGAF

 

  1. TOGAF pour les nuls.

  2. Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  3. La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  4. Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

  5. Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

  6. Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  7. Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  8. Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  9. Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  10. La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  11. La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  12. Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  13. Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  14. L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  15. L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  16. L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  17. L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  18. L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  19. L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  20. Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

  21. Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

  22. Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?

  23. Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces

  24. Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace

ArchiMate

 

  1. ArchiMate pour les nuls : les fondamentaux - 1

  2. ArchiMate la synthèse : les éléments de motivation - 2

  3. ArchiMate en condensé : les éléments de stratégie - 3

  4. ArchiMate l’essentiel : les éléments de la couche métier - 4

  5. ArchiMate mémento : les éléments de la couche application - 5

  6. ArchiMate aide mémoire : les éléments de la couche technologique - 6

  7. ArchiMate en abrégé : les éléments physiques de modélisation - 7

  8. ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8

  9. ArchiMate : modélisation de l’alignement des couches d'application et de technologie - 9

  10. ArchiMate : les éléments d'implémentation et de migration - 10

  11. ArchiMate : vues et points de vue - 11

  12. ArchiMate : guide complet des éléments de modélisation - 12

 

BPMN

 

  1. BPMN 2 : les concepts de base des processus métiers

  2. BPMN pour les nuls : les collaborations

  3. BPMN pour les nuls : les chorégraphies (Choreographies)

  4. BPMN pour les nuls : les conversations

  5. BPMN : norme OMG - synthèse des éléments graphiques

  6. BPMN : l'antisèche pour rester incollable en modélisation de processus

  7. BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

  8. BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza

  9. BPMN : mais que dit la norme sur les sous-processus et la gestion des événements d'interruption et de remontée d'incidents ?

  10. BPMN : processus exécutables, comment s'y prendre ? (1/3)

  11. BPMN : processus exécutables, comment s'y prendre ? (2/3)

  12. BPMN : processus exécutables, comment s'y prendre ? (3/3)

  13. Comment identifier, simuler, améliorer et modéliser les processus métiers ?

  14. Comment mettre en place un jeu de rôles pour modéliser un processus métier ?

 


19/01/2021
0 Poster un commentaire