urbanisation-si.com

Comment ChatGPT peut-il aider l’Architecte d’Entreprise ? ChatGPT est un apprenant surdoué : si on lui donne un modèle, il peut ensuite l’adapter à d’autres contextes. Dans cet article très pragmatique, nous allons montrer comment ChatGPT peut créer des vues ArchiMate, mais aussi proposer de nouvelles perspectives auxquelles on ne pense pas forcément. Pour vous prouver que cela fonctionne bien, les résultats générés sont importés dans deux outils Archi et Obeo SmartEA. Voici la méthode que nous avons appliquée. 

 

 

Illustration créée par Copilot gratuit utilisant DALL-E 3 pour cet article

 

Objectif :
Générer les vues ArchiMate "Stakeholders & Concerns" et "Drivers & Business Goals" pour l’Architecture d’Entreprise d’un groupe d’assurances désirant intégrer l’IA

 

Les IA génératives prennent de plus en plus de place dans notre vie professionnelle ou personnelle. Par exemple, les avocats, les juristes, mais aussi les professeurs ou les étudiants ont un tout nouvel assistant pour les aider dans l’analyse de dossiers, pour actualiser leurs cours ou pour faire leurs devoirs, voire carrément les aider à concevoir leur thèse.

 

Qu’en est-il des architectes d’entreprise ? ChatGPT, peut-il aider à la réalisation de modèles ArchiMate qui sont des tâches chronophages et répétitives ? Peut-il donner de nouvelles idées, de nouvelles pistes d’investigation dans le domaine de la transformation numérique ?
Pour cette démonstration, nous allons demander à ChatGPT-4o (omni) en version gratuite de générer la vue des parties prenantes et de leurs préoccupations (Stakeholders & Concerns) dans le cadre de l’Architecture d’Entreprise (AE) d’un groupe d’assurance désirant intégrer l’IA.

 

Nous vérifierons que notre modèle est correct, en lui demandant de générer la suite avec la vue des objectifs pour y contribuer (Drivers & Business Goals).

 

Générer des diagrammes, c’est bien, mais les intégrer dans un référentiel collaboratif, c’est encore mieux

 

Notre article "Texte vers UML et autres outils de "diagrammes en tant que code" - Le moyen le plus rapide de créer vos modèles ?" a remporté un franc succès, car il permet à ChatGPT de générer n’importe quel diagramme dans la quasi-totalité des langages de modélisation. Voir aussi : ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise (AE) et l’Urbanisation du Système d’Information ?.

 

Un des concepts de base de l’AE est de gérer un référentiel partagé regroupant tous les artefacts représentant l’entreprise. Mais si l’on peut demander à ChatGPT de générer des diagrammes, au format PlantUML par exemple, malheureusement ceux-ci ne peuvent être repris dans un véritable référentiel géré par les outils d’AE.

 

On sait maintenant à quoi sert
le format Open Group ArchiMate XML

 

ArchiMate® Model Exchange File Format for the ArchiMate 3.1/3.2 Modeling Language

https://www.opengroup.org/xsd/archimate/

 

L'interopérabilité est rendue possible grâce au format Open Group ArchiMate, particulièrement verbeux et abscons. La technologie retenue est XML, qui permet de créer sa propre langue avec sa grammaire XSD. Les grandes entreprises l'utilisent entre autres pour définir un langage pivot commun à tous leurs domaines métiers. Si ce métalangage présente une infinité de possibilités, son défaut majeur reste sa complexité et sa verbosité. Mais justement, c’est le terrain de prédilection de ChatGPT. En utilisant les informations qu’on lui a fournies, grâce à ses capacités d’auto-amélioration, d’apprentissage autonome et de prises de décisions indépendantes, il peut appliquer des templates et générer des milliers de lignes XML en respectant le standard de l’Open Group.

 

Créer un template XML minimal et réutilisable,
pour que ChatGPT comprenne ce que vous attendez de lui

Template XML obtenu à partir de la vue “Stakeholder & Concerns” d'ArchiSurance, l’étude de cas standard de l’Open Group

ChatGPT ne donne pas immédiatement le code XML exhaustif et sans défaut. Il faut lui fournir un modèle générique (téléchargez notre template XML pour la génération de diagrammes ArchiMate par ChatGPT), qu’il adaptera automatiquement en fonction du contexte que vous lui fournirez.
Dans notre exemple, nous avons choisi d’obtenir le template XML à partir de la vue “Stakeholder & Concerns” d'ArchiSurance, l’étude de cas standard de l’Open Group. Mais n’importe quel autre diagramme correspondant à votre problématique conviendra, à condition qu’il soit dans un outil permettant l’export au format Open Group ArchiMate XML.  

 

ArchiSurance version Open Group

Vous pouvez récupérer le cas d'usage sur le site de l’Open Group : 

 

• https://publications.opengroup.org/y231

 

ArchiSurance version Jean-Baptiste Sarrodie (Archi)

Autre solution, vous pouvez le télécharger sur la plateforme GitHub de Jean-Baptiste Sarrodie, le créateur d'Archi (voir nos articles en compléments de lecture) :

 

• https://github.com/archimate-models/archisurance

 

ArchiSurance version Obeo SmartEA

Comme nous avions testé récemment Obeo SmartEA (voir nos articles en compléments de lecture) , c'est la solution la plus immédiate qui se présentait à nous.

 

Voir en annexe -1- la procédure détaillée pour récupérer ArchiSurance au format XML de l'Open Group.

 

 

L’outil Obeo SmartEA intègre entièrement l’étude de cas ArchiSurance. A lire >

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

 

 

Extraire le diagramme Stakeholder & Concerns avec Archi

Par commodité, nous importons le volumineux fichier XML totalisant la bagatelle de 15 164 lignes dans Archi.

 

Voir en annexe -2- la procédure d'importation d'ArchiSurance dans Archi.

 

Pour extraire uniquement la partie qui nous intéresse, c'est-à-dire le diagramme Stakeholder & Concerns, nous créons un nouveau projet dans Archi, dans lequel nous copions le diagramme.

 

 

Copie de la vue Stakeholder & Concerns dans un nouveau projet Archi, servant juste à générer le XML

 

Pour avoir le XML correspondant, il suffit d'exporter le diagramme à partir d'Archi.

Voir en annexe -2- la procédure d'exportation du diagramme Stakeholders & Concerns à partir d'Archi.

 

Retoucher simplement le template XML
pour ne garder que le strict nécessaire

 

Rassurez-vous, c’est à la portée d’un néophyte et ça ne demande que 5 minutes.
L’objectif est de constituer une ossature générique contenant les principales balises : element, relationship, node et connection.

 

Voir en annexe -2- les détails des modifications apportées à l'export précédent afin d'obtenir le template XML.

 

 

Téléchargez notre modèle XML de génération de diagrammes ArchiMate par chatGPT

 

Télécharger

Template au format Open Group ArchiMate XML, à fournir à ChatGPT pour qu'il sache
dans quel format il doit générer le diagramme correspondant à votre demande

 

Demander à ChatGPT de vous donner
des propositions d’artefacts et leurs relations ArchiMate 

 

En détaillant le plus précisément possible votre contexte, vous pouvez demander à ChatGPT de vous indiquer les artefacts ArchiMate (Stakeholders & Drivers), avec leurs relations et leurs descriptions. Sa réponse constitue une base de travail, qu’il faut analyser, vérifier, modifier en ajoutant vos propres artefacts.

 

Voir en annexe -4- le détail du prompt pour les propositions des stakeholders et leurs préoccupations.

 

Voir en annexe -5- le détail de la liste des stakeholders, drivers et leurs relations générées par ChatGPT.

 

Demander à ChatGPT de générer le code XML
avec vos éléments ArchiMate en suivant votre template

 

Question posée à ChatGPT (prompt)

 

ChatGPT conserve en mémoire tous les échanges d’une conversation. Si vous validez les artefacts qu’il vous a proposés, dans le prompt, il suffit de lui dire de les reprendre, de générer la vue ArchiMate correspondante en appliquant le modèle XML qu'on lui fournit. Il faudra alors copier/coller le contenu du modèle dans le prompt. ChatGPT peut s’arrêter en cours de génération, il suffit alors de lui dire de continuer et ChatGPT reprendra là où il en est resté.

Voir en annexe -6- le prompt pour la génération XML du diagramme ArchiMate.

 

 

La réponse de ChatGPT : télécharger le diagramme ArchiMate Stakeholder & Concerns pour un groupe d'assurance désirant intégrer l'IA

 

Télécharger

Génération par ChatGPT du diagramme ArchiMate Stakeholder & Concerns
pour un groupe d'assurance désirant intégrer l'IA

 

Disponible aussi à l'annexe -7-.

 

Importation du XML généré dans Archi

 

Nous importons dans Archi (voir en annexe -8-) le fichier XML contenant la copie de la réponse de ChatGPT. 

 

 

Vue Stakeholders & Concerns d'un groupe d'assurance intégrant l'IA,
générée par ChatGPT, représentée dans Archi 

 

Importation du XML généré dans Obeo SmartEA

Nous importons dans Obeo SmartEA (voir en annexe -9-) le fichier XML contenant la copie de la réponse de ChatGPT. L’outil propose une réorganisation automatique, on n’aura même pas besoin de redisposer les éléments pour rendre le modèle plus lisible. 

 

 

   

Vue Stakeholders & Concerns d'un groupe d'assurance intégrant l'IA,
générée par ChatGPT, représentée dans Obeo SmartEA

 

Pour vérifier que ChatGPT est capable d’adapter notre template XML, lui demander de générer le point de vue Drivers & Business Goals dans le contexte précédent

 

Vérifier, c’est douter, mais pour vous convaincre que ChatGPT peut vous aider dans l’élaboration de vos vues ArchiMate, nous allons utiliser notre modèle XML pour une tout autre vue.
Nous voulons que ChatGPT génère la vue Drivers & Business Goals en prenant en compte notre contexte et la vue Stakeholders & Concerns qu’il vient de créer.

 

Télécharger le diagramme ArchiMate Drivers & Business Goals généré par ChatGPT grâce à notre modèle XML

 

Télécharger

Résultat de la génération par ChatGPT de la vue Driver & Business Goals, toujours dans le même contexte et sans modifier notre template XML

 

 

Pour l'obtenir, appliquer la même méthode que précédemment

 

• Un premier prompt pour avoir les Assessments (Évaluations), Goals (Objectifs) et Outcomes (Résultats) en relation avec les Drivers précédents, ainsi que leurs relations entre eux.
  Voir en annexe -10- le détail du prompt et la réponse de ChatGPT.
  
  
• Un deuxième prompt pour obtenir le code ArchiMate XML avec les éléments précédents, y compris leurs relations en suivant notre template XML inchangé. Le template XML généré précédemment est conservé et sera toujours réutilisé en l’état sans aucune modification, pour générer n’importe quel autre diagramme ArchiMate.
  Voir en annexe -11- le détail du prompt et la réponse de ChatGPT.
    
• Voir en annexe 12 : Importation dans Archi et en annexe 13 : Importation dans Obeo SmartEA.

 

En contrôlant le résultat, on s’aperçoit que les relations de type “Influence” sont inversées. On demande simplement à ChatGPT d’inverser toutes les valeurs des attributs source et target pour les relations de type “Influence”. 

 

Un prompt ChatGPT doit être contextualisé, explicité et très détaillé. En fait, comme si l’on demandait à un consultant de donner son avis sur un sujet.

 

Conclusion

 

Une bonne pratique de réalisation de diagrammes est de les réaliser sur une seule page, afin qu’il soit lisible et compréhensible pour les destinataires. Pour y arriver, le contexte doit être bien délimité et défini, ce qui facilite la tâche à ChatGPT. Par exemple, nous aurions pu, dans le premier prompt, spécifier que nous sommes limités à 4 ressources. ChatGPT aurait sans doute priorisé et n'aurait pas identifié 7 rôles différents de stakeholders.

A ce stade, il faut considérer ChatGPT comme un outil de traduction automatique par exemple. Il peut nous faire des propositions, nous donner des idées, c’est un super consultant qui connaît une infinité de cas d’usage. Comme un manager contrôlant le travail de son équipe, les résultats fournis par ChatGPT doivent être vérifiés. Dans notre cas, il est facile de voir la représentation graphique du code XML dans un outil d’AE supportant ArchiMate.

Si certains annoncent la disparition de nombreux métiers, celui d’architecte d’entreprise n’est pas près de disparaître, mais ne dit-on pas que nul n’est irremplaçable ?

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

 

 

 

 

 

“Mes principales inquiétudes ne sont pas liées à l'immédiat, mais au long terme. De façon presque inévitable, nous nous dirigeons vers des systèmes d'IA qui seront au moins aussi intelligents que nous, humains. Et il est certain que ces systèmes seront utilisés pour de bonnes comme de mauvaises choses. Par ailleurs, si l'IA devient plus intelligente que nous, nous courons le risque d'en perdre le contrôle.”
Yoshua Bengio 

 

 

 

Annexe

Procédure détaillée pour que ChatGPT vous aide à créer vos vues ArchiMate (à adapter selon vos besoins)

- 1 -
Récupérer un exemple de vue ArchiMate
au format Open Group XML

Dans le cadre d’une évolution de votre Architecture d’Entreprise (AE), choisissez dans votre référentiel, parmi les vues existantes, celle correspondant le mieux à vos besoins et exportez-la au format Open Group ArchiMate XML. S’il s’agit de la création d’un nouveau référentiel, alors vous devrez juste créer une première vue, puis l’exporter en XML depuis votre outil.
Pour cet article, notre contexte sera l’étude de cas standard ArchiSurance de l’Open Group, présentant l’avantage d’être déjà intégrée dans les exemples d’Obeo SmartEA

 

Générer simplement dans votre outil le fichier XML de la vue choisie.

Dans Obeo SmartEA, le fichier XML s’obtient en exportant au format d’échange : 

 

• Menu Plus > ArchiMate > Export au format d’échange

 

- 2 -
Créer votre template XML pour la génération
de modèles ArchiMate par ChatGPT 

 

Importation d'ArchiSurance dans Archi

Le fichier exporté faisant plus de 15 000 lignes, il est inexploitable en l’état. Nous allons extraire la vue Stakeholders & Concerns et l’exporter pour obtenir quelques dizaines de lignes.  

 

Pour y parvenir, nous importons le fichier dans Archi, qui est plus simple d’utilisation qu’Obeo SmartEA : 

 

• Menu File > Import > Model From Open Exchange File

 

Une fois importé, nous devons isoler la vue voulue dans un nouveau projet, pour pouvoir l’exporter en XML. Pour accéder à la vue désirée dans Archi : 

 

• Sélectionner Views > Folder > Stakeholders and Concerns > Sélectionner tous les éléments du diagramme et copier

 

Créer un nouveau projet :

 

• File > New > Empty Model > Views Default View > Coller

 

Exportation en XML de la vue Stakeholder & Concerns

Une fois la vue isolée dans un projet, vous pouvez l’exporter au format XML :

Sélectionner le nouveau projet > File > Export > Model to Open Exchange XML File > Désélectionner Include Folder > Save

 

Editer le fichier XML pour supprimer les styles et modifier les identifiants

Rassurez-vous, cette opération ne sera effectuée qu’une fois. Quand vous fournirez votre template XML à ChatGPT, il comprendra ce que vous attendez de lui et il s'adaptera automatiquement au nouveau contexte que vous lui exposerez. 

 

Editer le fichier généré : 

• Supprimer toutes les balises style.
  
  
• Modifier tous les id de manière à ce que ce soit plus lisible. Par ex., pour le stakeholder “Board”, modifier l’id ("id-95f1f282758140f1a795725fdd5c1afa") en ”Board-id”.

 

Le contenu du fichier XML est très simple et logique. Voici les explications des 6 principales balises :

 

• <model> : représente le modèle ArchiMate composé des balises <element> et <relationship>,
  • <element> : les éléments qui sont typés comme par exemple Stakeholder, Driver…, nommés et identifiés,
  • <relationship> : les relations pour lesquelles on doit indiquer un identifiant, leur type comme Association, Aggregation…, les éléments source et cible (target),
     
• <view> : la vue composée des balises <node> et <connection>,
  • <node> : représente un élément présent sur la vue, avec ses coordonnées et l’identifiant référençant l’élément,
    
  • <connection> : affiche dans la vue, la relation référencée, toujours en précisant l’élément source et la cible ce qui permet de montrer le sens de la connexion.

 

Avec cet exemple de syntaxe, ChatGPT est capable de l’adapter à n’importe quel autre point de vue, pourvu qu’on lui précise les types d'artefacts et relations ou qu’on lui demande de nous en proposer, ce que nous faisons dans cet article.

Vous devez ne conserver que les configurations d’occurrence avec leurs relations les plus significatives de votre futur template XML, comme si vous vouliez créer un pattern réutilisable.

 

- 3 -
Télécharger notre template XML pour la génération
de diagrammes ArchiMate par ChatGPT

Vous pouvez télécharger notre template XML qui a servi à cet article : 

 

Télécharger

Pour chacune de nos demandes de génération de diagrammes ArchiMate, nous fournissons
notre template XML à ChatGPT, pour qu'il comprenne ce que nous attendons de lui

 

- 4 -
Prompt ChatGPT pour avoir une proposition des parties prenantes et leurs préoccupations selon votre contexte

 

" Je suis architecte d'entreprise pour un groupe d'assurances. Je dois intégrer l'IA dans la transformation numérique de l'entreprise. Je veux concevoir un diagramme ArchiMate représentant la vue Stakeholders & Concerns. Je veux la liste et la description des nouveaux stakeholders et drivers spécifiques à l'IA. Je veux aussi leur relation de type association et agrégation. "

 

- 5 -
Réponse de ChatGPT :
liste des stakeholders, drivers et relations

Début de la réponse

" Pour intégrer l'IA dans la transformation numérique d'un groupe d'assurances, il est essentiel de bien identifier les nouveaux stakeholders (parties prenantes) et drivers (moteurs) spécifiques à l'IA, ainsi que leurs relations. Voici une proposition pour les stakeholders & drivers, ainsi que leur description et leurs relations.

 

Nouveaux Stakeholders spécifiques à l'IA

Chief AI Officer (CAIO)
Description: Responsable de la stratégie et de la mise en œuvre de l'IA au sein de l'entreprise.

 

Data Scientists
Description: Professionnels responsables de la conception, de la mise en œuvre et de la maintenance des modèles d'IA.

 

AI Ethics Committee
Description: Groupe chargé de veiller à ce que les initiatives d'IA respectent les normes éthiques et les régulations.

 

AI Engineers
Description: Ingénieurs spécialisés dans le développement et le déploiement des solutions d'IA.

 

Business Units
Description: Différentes unités de l'entreprise qui utilisent les solutions d'IA pour améliorer leurs processus et services.

IT Department
Description: Département responsable de l'infrastructure technologique supportant les initiatives d'IA.

 

Compliance Officers
Description: Professionnels chargés de s'assurer que les solutions d'IA respectent les réglementations en vigueur.

 

Nouveaux Drivers spécifiques à l'IA

Innovation et Compétitivité
Description: Utilisation de l'IA pour innover et maintenir un avantage compétitif sur le marché.

 

Amélioration de l'Efficacité
Description: Automatisation des processus pour améliorer l'efficacité opérationnelle.

 

Amélioration de l'Expérience Client
Description: Utilisation de l'IA pour offrir des expériences client plus personnalisées et réactives.

 

Gestion des Risques
Description: Amélioration des capacités de gestion des risques grâce à des modèles prédictifs.

 

Réduction des Fraudes
Description: Détection et prévention des fraudes par des algorithmes d'IA.

 

Conformité et Régulation
Description: S'assurer que les solutions d'IA sont conformes aux lois et régulations.

 

Relations de type association et agrégation

Chief AI Officer (CAIO) est associé à Innovation et Compétitivité, Amélioration de l'Efficacité, Amélioration de l'Expérience Client, Gestion des Risques, Réduction des Fraudes.

 

Data Scientists sont associés à Innovation et Compétitivité, Amélioration de l'Efficacité.

 

AI Ethics Committee est associé à Conformité et Régulation.

 

AI Engineers sont associés à Amélioration de l'Efficacité, Réduction des Fraudes.

 

Business Units sont agrégées sous Amélioration de l'Expérience Client, Gestion des Risques.

 

IT Department est agrégé sous Amélioration de l'Efficacité.

 

Compliance Officers sont associés à Conformité et Régulation.

 

Diagramme ArchiMate

Pour concevoir le diagramme ArchiMate représentant la vue Stakeholders & Concerns, vous pouvez suivre ces étapes :
Créer des éléments de type "Stakeholder" pour chaque partie prenante mentionnée.
Créer des éléments de type "Driver" pour chaque moteur spécifique à l'IA.
Relier les stakeholders aux drivers avec des relations d'association (lien simple) ou d'agrégation (lien avec inclusion).
Utiliser des éléments d'organisation pour montrer les relations hiérarchiques ou fonctionnelles (ex. : le CAIO peut superviser les Data Scientists et les AI Engineers). "

 

Fin de la réponse

 

- 6 -
Prompt pour la génération du diagramme ArchiMate
au format XML par ChatGPT

 

" Avec les éléments précédents, génère le diagramme ArchiMate au format Open Group ArchiMate XML. Je te donne un modèle de code que tu devras respecter : <copier/coller le contenu de votre template XML> "

 

 

- 7 -
Réponse de ChatGPT :
le document XML représentant le diagramme ArchiMate

 

Télécharger

Génération par ChatGPT du diagramme ArchiMate Stakeholder & Concerns
pour un groupe d'assurance désirant intégrer l'IA

 

- 8 -
Importation du modèle ArchiMate généré par ChatGPT dans Archi

 

File > Import > Model from Open Exchange file

 

 

Le diagramme ArchiMate généré par ChatGPT correspondant à notre prompt,
importé dans Archi, après un léger repositionnement

 

 

- 9 -
Importation du modèle ArchiMate généré par ChatGPT dans Obeo SmartEA

 

Sauvegarder et fermer tous les éditeurs en cours > Menu Plus > ArchiMate > Import au format d’échange

 

 

Le diagramme ArchiMate généré par ChatGPT correspondant à notre prompt,
importé dans Obeo SmartEA, dont la fonction "Réorganiser tout" (1ère icône de la vue) est bien utile ici

 

- 10 -
Vérifions que ChatGPT peut générer une autre vue

 

On va utiliser les capacités d’auto-amélioration, d’apprentissage autonome et de prise de décisions indépendantes de ChatGPT pour lui faire générer un nouveau modèle ArchiMate en prenant en compte les étapes précédentes.

L’objectif est de faire générer la vue Driver & Business Goals, toujours dans le même contexte et sans modifier notre template XML. On demande à ChatGPT les Assessments, Goals et Outcomes en relation avec les Drivers précédents ainsi que leur relation entre eux.

 

Prompt 

" Avec les drivers ArchiMate précédents, je veux les assessments et leur relation de type association, les goals avec leur relation de type influence et les outcomes liés aux goals avec des relations de type influence ou realization. Je veux les descriptions de tous ces éléments ArchiMate. "

 

Remarque : non seulement ChatGPT nous donne la description des éléments ArchiMate, mais dans la même réponse, il a compris que nous voulons aussi le code XML correspondant. 
On peut apporter quelques modifications en promptant : 

“ Parfait. Je veux le même code, mais sans les stakeholders. “

“ Traduis en français les assessments, les goals, les outcomes et leur description. Je veux le même code, mais avec tous les éléments en français. “

 

Début de la réponse de chatGPT

" Le code XML est fourni (voir le fichier joint) avec la description des éléments : 
Descriptions

 

Drivers:

Innovation et Compétitivité : Améliorer l'innovation et la compétitivité grâce à l'intégration de l'IA.

 

Amélioration de l'Efficacité : Optimiser l'efficacité des opérations et des processus internes.

 

Amélioration de l'Expérience Client : Améliorer la satisfaction et la fidélité des clients grâce à des services personnalisés et efficaces.

 

Gestion des Risques : Renforcer la gestion des risques en identifiant et en atténuant les risques de manière proactive.

 

Réduction des Fraudes : Utiliser l'IA pour détecter et réduire les fraudes de manière efficace.

 

Conformité et Régulation : Assurer la conformité avec les régulations et les exigences légales en vigueur.

 

Assessments:

Faisabilité de l'Adoption de l'IA : Évaluer la faisabilité de l'adoption de l'IA au sein de l'organisation.

 

Impact de l'IA sur la Main-d'Œuvre : Analyser l'impact de l'IA sur la main-d'œuvre, notamment en termes d'emplois et de compétences.

 

Conformité Réglementaire : Vérifier que les solutions d'IA respectent les régulations et les normes en vigueur.

 

Goals:

Mise en Œuvre Réussie de l'IA : Assurer une mise en œuvre réussie des technologies d'IA dans l'organisation.

 

Satisfaction Client Améliorée : Augmenter la satisfaction des clients grâce à des solutions innovantes et efficaces.

 

Efficacité Opérationnelle : Améliorer l'efficacité opérationnelle grâce à l'optimisation des processus par l'IA.

 

Atténuation des Risques : Réduire les risques grâce à des analyses prédictives et des actions proactives.

 

Réduction de la Fraude : Réduire significativement les fraudes grâce à des technologies d'IA avancées.

 

Outcomes:

Augmentation des Revenus : Générer des revenus supplémentaires grâce à l'amélioration des processus et à l'innovation.

 

Fidélité des Clients : Renforcer la fidélité des clients en améliorant leur expérience et leur satisfaction.

 

Réalisation de la Conformité : Atteindre une conformité totale avec les régulations et les normes en vigueur. "

 

Fin de la réponse

 

- 11 -
ChatGPT a inversé des relations

 

Une fois importé, on s’aperçoit que les relations "influence et realization" sont inversées : on va donc demander à ChatGPT d’inverser ces types de relations.

 

Remarque : on a épuisé pour l’heure notre quota de ChatGPT-4o, on est repassé en ChatGPT-3.5

 

Prompt

“ Inverse toutes les valeurs des éléments source et target sauf la relationship rel25 et la connection connection25. “

 

Réponse de chatGPT

Télécharger

Génération par ChatGPT de la vue Driver & Business Goals, toujours dans le même contexte
et sans modifier notre template XML

 

- 12 -
Importation dans Archi

 

 

 

Résultat de l'importation dans Archi de la vue Driver & Business Goals
au format XML générée par ChatGPT

 

 

- 13 -
Importation dans Obeo SmartEA

 

 

Résultat de l'importation dans Obeo SmartEA de la vue Driver & Business Goals
au format XML générée par ChatGPT

 

 

 

Compléments de lecture

• Architecture d'Entreprise augmentée, quelle influence de l’Intelligence Artificielle sur la gouvernance et la stratégie ?
   
• Le rôle de la prospective pour une entreprise innovante et résiliente
   
  
• ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?
   
• 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
   
• Comment consolider un référentiel centralisé TOGAF rassemblant les autres référentiels Stratégie, Métier, Applications, Infrastructure… ? Obeo SmartEA S.1 Ep.2
   
• Archi (archimatetool) : essai et analyse de cet outil ArchiMate français gratuit sous Windows, Linux et Mac OS

 

• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information

 

 

La rédaction tient à souligner que la plateforme urbanisation-si.com est indépendante de toute organisation et son fonctionnement repose entièrement sur des bénévoles passionnés de pédagogie et désirant partager leur expérience. Vous ne verrez jamais de publicités sur notre plateforme.

Bien que nous encourageons l’open source, il peut nous arriver d’utiliser des logiciels commerciaux qui nous sont gracieusement prêtés sous aucune condition et nous ne touchons aucune rémunération de qui que ce soit. 

 

Des ontologies modulaires
pour gérer la complexité et la pluridisciplinarité

Un Knowledge Graph, c’est une base de connaissance sous forme de graphe. Pour sa conception, il est crucial de clarifier les questions auxquelles elle devrait pouvoir répondre, ainsi que celles portant sur sa maintenance et son évolution.

 

Une approche clé pour assurer la flexibilité et la maintenabilité d’un Knowledge Graph consiste à le baser sur plusieurs ontologies modulaires inter-reliées, avec un noyau central. Chaque module peut alors être conçu pour traiter des concepts, des relations et des règles spécifiques à un sous-domaine d’expertise, ce qui en facilite la gestion et l’évolution avec les experts du domaine.

 

En reliant ces ontologies modulaires entre elles, on crée un réseau de connaissances. Cela permet de représenter des relations complexes entre les concepts qui transcendent les frontières des différents sous-domaines, offrant ainsi une vue globale et intégrée du domaine métier dans son ensemble. Or c’est typiquement un besoin des descriptions d’architecture de pouvoir représenter des couches d’architecture et leurs correspondances. Ou de présenter des perspectives spécifiques. Par exemple, la gestion des risques, l’architecture applicative, l’architecture des données, l’infrastructure technologique, l’évaluation de la performance…

 

Un noyau central définissant les fondamentaux de l’EA, via les concepts et relations réutilisables pour tous les modules, permettra l’interopérabilité. La référence à une ontologie de haut niveau (top-level) ou des « patrons » de conception servira à ne pas réinventer la poudre pour des problèmes généraux de conception déjà bien connus.

 

Bien entendu, la conception d’un Knowledge Graph d’Architecture d’Entreprise doit suivre les bonnes pratiques. En particulier, réutiliser autant que possible des ontologies existantes et des vocabulaires standards pour éviter la duplication d’efforts et promouvoir la cohérence avec les pratiques établies dans le domaine.

 

Des ontologies pour des Knowledge Graphs agnostiques des cadres de référence

Les concepts décrits dans une ontologie d’Architecture d’Entreprise (ou module), existent indépendamment des cadres de référence ou langages de description. Car si ces derniers sont réutilisables pour les identifier et les définir, ni un glossaire, ni des textes descriptifs, ni des objets graphiques ne spécifient formellement des concepts et des relations. « Things, not strings » : une ontologie définit des choses et les labels donnés aux choses ne suffisent pas pour les définir. Si deux terminologies différentes désignent le même concept, on trouvera un concept et deux labels dans l’ontologie. Quand elles désignent l’une une spécialisation, l’autre une généralisation, on définira les relations de subsomption et les caractéristiques propres des deux concepts. Et si au contraire elles désignent deux choses différentes et disjointes, on doit le définir également.

 

Une ontologie, c’est une représentation sémantique riche des entités et de leurs relations en mesure de suivre l’évolution des connaissances. En utilisant les standards du Web sémantique (RDF, RDFS, OWL), contrairement à certains langages de modélisation plus rigides, les Knowledge Graphs sont flexibles et extensibles. Ils permettent d’ajouter de nouveaux concepts, relations et attributs au fur et à mesure que l’Architecture d’Entreprise évolue, assurant ainsi une représentation toujours à jour et adaptable.

 

Pour prendre l’exemple du langage graphique de description d’architecture ArchiMate, les liens sont limités et certains concepts spécifiques à la stratégie d’offre, au marché, aux situations, aux aspects financiers, ne sont pas dans l’ensemble de ceux prédéfinis.

 

A contrario, un réseau d’ontologies modulaires peut spécifier des concepts dans tous les sous-domaines de gouvernance et de pilotage de l’entreprise et les relier aux capacités de l’entreprise et les composants qui les supportent. Tout Knowledge Graph exploitant ce réseau peut dès lors procurer une représentation plus riche, flexible et contextuelle des éléments clés éclairant les décisions qui engagent l’entreprise.

 

Architecture d’Entreprise et continuum d’ontologies

La démarche de description d’Architecture d’Entreprise est continue, itérative et incrémentale. On peut difficilement arriver à une architecture unifiée unique qui satisferait à toutes les exigences de toutes les parties prenantes à tout moment et l’idéal d’avoir des documentations et des modèles à jour suivant toutes les perspectives est une utopie dont la mise en œuvre est dystopique.

 

Des plateformes pour réutiliser des ontologies consistantes et cohérentes, ou accéder à des patrons de conception et des outils de développement et de curation pour modéliser et implémenter de nouvelles spécifications, ont été mises en place dans différents secteurs d’industrie. Elles concrétisent une approche réellement FAIR des métadonnées.

 

L’alliance OntoPortal autour de l’outil éponyme (https://ontoportal.org) est significative du besoin de promotion de telles plateformes pour « le développement de référentiels d’ontologie – en science et dans d’autres disciplines ».

 

Le parallèle peut être fait avec la notion de Continuum d’Entreprise qu’on trouve dans TOGAF. L’idée est d’organiser des artefacts d’architecture et des actifs de solutions réutilisables afin de maximiser les opportunités d’investissement dans l’Architecture d’Entreprise. Dans cette optique, la construction de plateformes communes aux architectes d’entreprises pour recevoir, héberger, servir, aligner et permettre la réutilisation d’ontologies pour l’EA a tout son intérêt. On devrait y trouver différentes ontologies d’entreprise et des métamodèles génériques à spécialiser ou étendre.

 

Un métamodèle d’entreprise générique
et un langage graphique : EDGY

Si toute entreprise a sa propre dynamique, toutes les entreprises partagent le fait d’avoir des produits et/ou services, des offres portant sur ces produits, des processus supportant les opérations, des rôles, des acteurs, des applications des SI avec des composants, etc. On peut très bien s’entendre sur un vocabulaire et des axiomes logiques pour exprimer ce genre de choses et leurs liens.

 

Dans ce domaine, l’initiative de la communauté Intersection Group est à souligner. Car elle introduit, avec l’approche « Enterprise Design with EDGY », un langage graphique simple et expressif pour un métamodèle d’entreprise transverse à tous les métiers. En effet, EDGY propose une vue unifiée et consolidée de l’entreprise à des fins de décision collaborative grâce à l’intersection entre trois perspectives : identité, Expérience et Architecture.

 

La première traite de la raison d’être de l’entreprise aussi bien que de sa culture. A ce sujet, le mantra
« culture eats strategy at breakfast » illustre bien l’importance de ces concepts. La seconde se focalise sur l’expérience procurée aux clients et aux autres acteurs. Une manière également pertinente de traiter dynamiquement de la valeur créée pour les parties prenantes. La dernière s’interroge sur comment orchestrer tout cela, en déclinant modèle d’affaires, modèle opératoire et composants d’architecture.

 

Le credo d’EDGY est d’avancer que les connecteurs nécessaires à créer entre des disciplines traitées aujourd’hui de façon trop isolée se trouvent à l’intersection desdites perspectives, où l’on trouvera les concepts de produit, organisation, marque.

 

L’approche EDGY propose les outils pour élaborer une représentation graphique commune, utile et transverse, des éléments clés de l’entreprise à des fins de décision. Cependant, il lui manque encore la dimension formelle des ontologies, pour disposer également d’une base de connaissances sémantiquement riche.

 

Un outil d’EA basé sur des ontologies :
The Essential Project

Fournir pour la description des composants d’architecture, un métamodèle à base d’ontologies, flexible et extensible, cela existe déjà. Dès 2009, «The Essential Project » a été lancé par l’équipe des consultants d’EAS (Enterprise Architecture Solutions) sur cette base, en modélisant des ontologies sous Protégé. La première version open source d’Essential (visant les capacités essentielles à une pratique d’EA) date de mars 2009. La mise en relation avec les concepts TOGAF n’est arrivée qu’en 2015.

 

Certes, ce sont des demandes des utilisateurs qui ont conduit à la publication d’un mappage TOGAF vers Essential. Reste que, selon EAS, « le métamodèle Essential est, en fait, plus riche en contenu et prend en charge tous les principaux frameworks EA, tout en restant indépendant du framework ».

 

L’outil Essential a été placé « visionnaire » dans le Gartner Magic Quadrant 2023 des outils d’Architecture d’Entreprise. Si l’on consulte Gartner Peer Reviews, il est globalement bien noté. Avec des commentaires tels que ce dernier : « EAS has a powerful metadata repository that can cover multiple dimensions of the architecture. Also, the look and feel is very appealing, with easy to navigate reports ». Certes, à d’autres égards, notamment les représentations graphiques, il offre moins de richesse que d’autres alternatives.

 

Mais si l’essentiel recherché est d’avoir effectivement les bons liens entre composants, pour une bonne analyse d’impact, il correspond. Grâce à son métamodèle à base d’ontologies. Tandis que ceci est rarement capturé sans la moindre ambiguïté par un diagramme, au contraire d’un Knowledge Graph. De plus, si l’on part sur l’usage des technologies RDF et OWl, l’interopérabilité du référentiel d’architecture avec d’autres outils utilisés comme bases de modèles, de documentation ou d’exigence sera de facto facilitée, éventuellement avec un VKG et des outils de conversion conformes à RML.

 

A quand un EAO comme OBO ?

Il manque toutefois un véritable consensus sur des spécifications formelles de conceptions partagées des domaines de connaissance en Architecture d’Entreprise. I.E les ontologies du réseau modulaire évoquées précédemment, avec un moyen de généraliser ou spécialiser certaines. Tout autant qu’un moyen pour les partager (en mode FAIR) ainsi que disposer de services utiles sur tout le cycle de vie du (ou des) Knowledge Graph d’architecture qu’on peut construire à partir de ces spécifications.

 

On sait que dans certains domaines, cela existe, le plus connu étant l’OBO foundry pour la biologie et la biomédecine. Une communauté autour d’OBO a développé de bonnes pratiques autant pour l’évaluation, la curation, la réutilisation des ontologies que pour la constitution d’outils utiles à leur développement. On peut évoquer des outils comme ODK, ROBOT, ou OntoPortal.

 

Comme on peut évoquer de nombreux outils, conformes à RML, qui faciliteront le mapping en RDF de sources de données existantes pour la construction des Knowledge Graphs d’EA en entreprise.

 

Si les bénéfices et les outils existent, une question demeure. Pourquoi nulle communauté d’architecte, éventuellement avec le financement d’une association de standardisation, n’a construit d’EA Ontology foundry ? Est-ce parce que financer une telle démarche serait contre-productif pour certains modèles d’affaires associés aux cadres de références d’EA existants ?

 

Sabine BOHNKÉ

"Le vrai signe d'intelligence n'est pas la connaissance, c'est l'imagination."
Albert Einstein

 

Compléments de lecture

• Knowledge Graph et Architecture d’Entreprise (1/2)
    
• Comment vérifier un modèle ? Exemple de simulation d’un processus métier BPMN
   
• 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
   
• Comment consolider un référentiel centralisé TOGAF rassemblant les autres référentiels Stratégie, Métier, Applications, Infrastructure… ? Obeo SmartEA S.1 Ep.2

  

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

 

Un potentiel mal exploité

L’Architecture d’Entreprise (AE) est une discipline destinée à favoriser, face à des situations en constante évolution, le développement d‘une stratégie d’entreprise conforme à ses finalités ainsi que son exécution ad hoc.

 

Cette discipline est profondément liée aux approches de représentation des connaissances. Il est donc curieux que le potentiel des Knowledge Graphs y soit encore insuffisamment exploité. En effet, ces derniers sont pertinents pour représenter de manière expressive la sémantique d’un système. Ils offrent également des moyens de naviguer entre les concepts de connaissance et leurs interrelations. Cela en suivant des standards du Web sémantique et des modèles et ensembles de données FAIR (Findable, Accessible, Inter-operable, Re-usable).

 

Il est toutefois décevant, au niveau de la couche sémantique, de constater que les essais d’approche des Knowledge Graphs pour l’Architecture d’Entreprise – à quelques exceptions près – se soient cantonnés à des traductions littérales en langage OWL de modèles ou de cadre de référence existants. Or exprimer en OWL les règles et objets de langages tels ArchiMate ou la terminologie de TOGAF, a peu d’intérêt. On restreint ainsi une richesse d’expression sémantique aux contraintes voire incohérences de sources existantes. Les réutiliser à un sens, mais il ne faut pas confondre sources terminologiques et spécification formelle d’une conceptualisation.

 

Pour que l’approche des graphes de connaissances appliquée à l’Architecture d’Entreprise fonctionne, il ne faut pas se tromper de cible. Aussi suivre les bonnes pratiques de construction, tant pour la conception que l’implémentation. Cet article développe aussi bien les enjeux en la matière que les moyens d’y arriver.

 

Architecture d’Entreprise
et représentation des connaissances

 

Les descriptions d’architecture servent à acquérir une connaissance utile pour comprendre, choisir et planifier les actions de transformation en continu. L’entreprise est, par ailleurs, un système dynamique complexe. Dès lors, l’approche systémique est de mise. Elle conduit à se concentrer sur les interactions internes entre éléments du système ainsi que leurs relations externes avec l’environnement. Sans oublier, bien sûr, de définir clairement les finalités du système pour identifier des pistes d’évolution conformes aux enjeux stratégiques.

 

Tout cela nécessite de décrire explicitement ce qui est su des éléments et leurs interactions. Donc de collaborer avec des « SME » (Subject Matter Expert) pour éliciter leurs connaissances. Il faut ensuite la formaliser tout en intégrant la nécessité permanente de mise à jour. Dès lors, des outils et procédés de représentation et partage des connaissances sont nécessaires à plusieurs niveaux d’abstraction.

Things, not strings

Deux erreurs communes depuis des années sont prégnantes dans les systèmes d’information. Modéliser des données pour stockage avant d’expliciter les concepts manipulés et penser plus au couple problème/solution qu’aux enjeux globaux. D’où le fameux « integration spaghetti » du Gartner. C’est à dire un SI constitué d’une mosaïque de systèmes peu évolutifs, peu interopérables, avec de nombreux silos de données.

 

Quand on parle de concepts manipulés, ce sont les objets métiers, concrets ou abstraits de l’univers du discours de l’entreprise. Un constructeur automobile manipulera des concepts liés aux voitures, un assureur, des contrats d’assurance. Les acteurs métiers aujourd’hui évoquent des « données métiers ». En réalité, les données ne sont déjà plus des objets métiers. Ce sont des traductions en formats numériques, de parties de choses utiles au métier. Et souvent, sous la seule perspective à court terme d’un fonctionnement applicatif recherché.

 

Dans le champ de l’Architecture d’Entreprise, il y a nécessairement la description des objets métiers manipulés par les acteurs. Cette description sert autant à définir les capacités à développer qu’à fluidifier les échanges entre systèmes d’information.

 

En 2012, un article de Amit Singhal « Introducing the Knowledge Graph: things, not strings » saluait l’arrivée du Google Knowledge Graph. Things, not strings : tel devrait être également le slogan des échanges entre systèmes d’information.

 

Les choses sur lesquelles on a besoin d’information ne sont pas les chaines de caractères qui les désignent. Pas plus qu’elles ne sont la façon dont on les stocke ou on les transfère. On a besoin d’un niveau de représentation indépendant des plateformes ou des syntaxes des formats d‘échange pour dire que les données qu’on manipule sont bien liées à telle ou telle chose. Des métadonnées connectées dans un « Knowledge Graph » sont typiquement une réponse à ce besoin.

 

Architecture d’Entreprise,
Virtual Knowledge Graph et Data Fabric

Un Knowledge Graph consiste en une ou plusieurs ontologies formelles liées et des ensembles de données cohérents avec celles-ci. En créant les ontologies spécifiant les concepts de l’entreprise, on peut ensuite créer un « Virtual Knowledge Graph » (VKG). Il s’agit du concept autrefois nommé OBDA (Ontology-Based Data Access).

 

En utilisant des ontologies, de la fédération de requêtes SPARQL et du mapping (R2ML), cette approche offre un moyen d’interroger les différentes sources de données distribuées au sein de plusieurs systèmes en fonction des concepts métiers sur lesquels elles ont des informations. Elle permet en outre aux données de rester dans leurs bases d’origine pour une gestion plus agile et plus efficace.

 

Ici, la description, via une spécification formelle, de composants de l’Architecture d’Entreprise, permet d’optimiser la construction d’autres composants d’architecture. Il existe par ailleurs des outils commerciaux et open source pour créer des VKG. Au-delà de la notion de VKG, c’est le concept de Data Fabric qui profite au mieux des Knowledge Graphs. En utilisant la couche sémantique du graphe de connaissance pour établir la provenance, la qualité et le sens des données gérées dans les systèmes d’information de l’entreprise, on s’oriente vers une meilleure vue intégrée et unifiée de ces derniers. Ce que soulignait l’article publié en 2021 sur le site du Gartner « Data Fabric Architecture is Key to Modernizing Data Management and Integration » : « Data fabric must create and curate knowledge graphs ».

 

Architecture d’Entreprise :
cas d’usage des Knowledge Graphs

Certes, la construction et la curation desdits Knowledge Graphs nécessitent des efforts. Cependant, il existe de meilleures pratiques et des outils pour des résultats relativement rapides avec des solutions robustes et évolutives.

 

Deux orientations d’usages des Knowledge Graphs dans le domaine de l’Architecture d’Entreprise sont particulièrement intéressantes. L’une, déjà évoquée, porte sur l’interopérabilité sémantique via la spécification des concepts métiers pour cas d’usage analytique ou transactionnel. L’autre porte sur l’activation dynamique d’un métamodèle des composants d’une entreprise pour guider des changements stratégiques. En spécifiant formellement les composants à connaître, ainsi que leurs interrelations, pour décider et suivre au mieux l’évolution des transformations, on peut construire un graphe de connaissance qui permettrait de réduire les incertitudes liées aux options de changement.

 

Les Knowledge Graphs aident à contextualiser les décisions liées à l’évolution du système d’information en reliant les éléments architecturaux aux facteurs d’influence externes, aux objectifs métier, aux contraintes opérationnelles et aux tendances technologiques. Cette vision holistique guide les décideurs vers des choix plus éclairés et alignés sur les objectifs stratégiques de l’entreprise. Par ailleurs, en spécifiant avec des métadonnées les relations entre les composants, les Knowledge Graphs facilitent l’analyse d’impact des changements. Cela permet de comprendre rapidement comment une modification dans une partie spécifique de l’architecture peut affecter d’autres composants, aidant ainsi à anticiper les conséquences potentielles et à simuler des scénarios pour prise de décision.

 

Mais si l’on veut un Knowledge Graph d’Architecture d’Entreprise, contenant tous les composants de l’entreprise ainsi que leurs liens, comment procéder ? N’est-ce pas un travail trop complexe ?

Vous trouverez des éléments de réponses dans le prochain article
" Knowledge Graph et Architecture d’Entreprise (2/2) ".

 

 

Sabine BOHNKÉ

 

 

 

 

« La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information. »

Albert Einstein

 

Compléments de lecture

Métamodèle TOGAF - ArchiMate

• Méta-physique ? Non, méta-modélisation !
    
• Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
• L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
• ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8

  

Les critères d'un bon modèle

• Le PILI était-il un bon modèle ?

   

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

 

 

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

 

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

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

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

 

Pourquoi la rationalisation est-elle importante pour la transformation ?

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

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

 

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

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

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

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

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

 

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

 

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

 

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

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

 

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

 

Transformation sans rationalisation

 

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

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

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

Sans rationalisation des applications, plusieurs conséquences : 

 

1 Des applications qui ne fonctionnent plus

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

 

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

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

 

3 Certains coûts sont inattendus

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

 

4 Réticence potentielle des employés

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

 

5 Problèmes réglementaires

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

 

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

 

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

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

 

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

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

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

 

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

 

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

 

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

Par exemple, elles vont utiliser : 

 

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

 

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

 

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

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

 

Alors que faut-il faire ?

  

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

 

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

 

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

 

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

 

C4 model

 

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

 

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

 

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

 

Contexte, Conteneurs, Composants, Code

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Avec Uncia, vous pouvez :

 

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

 

Comment fonctionne Uncia ?

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Conclusion

 

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

 

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

 

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

Si l'on demande à ChatGPT : “A quels défis sont confrontés aujourd'hui les architectes d'entreprise ?”, voici ce qu'il cite en premier : “L’un des principaux défis est de faire face à la complexité croissante des systèmes d’information et des technologies de l’information”. Puis, en deuxième : “Les architectes d’entreprise doivent être en mesure de communiquer efficacement avec les parties prenantes de l’entreprise, y compris les cadres supérieurs, les responsables informatiques et les utilisateurs finaux”.

 

  

Une meilleure communication pour une meilleure transformation numérique

 

Commençons par une évidence, que l’on trouve dans toutes les introductions dans cette catégorie d’articles que vous êtes en train de lire : les changements à fréquence effrénée impactent l’entreprise aux niveaux stratégie, processus métier, applications et infrastructure. Vous le savez, il n’y a que des solutions. Une parmi tant d’autres est que les parties prenantes aient accès à des informations qualifiées et de première fraîcheur.

Les problèmes de communication entre les acteurs sont un frein à la compréhension de l'organisation de l'entreprise, son système d'information et son architecture. La diversité des différents métiers ne doit pas empêcher les échanges et l'enrichissement du patrimoine de l’entreprise. Souvent, les outils hétérogènes de chaque métier ne sont pas interopérables.
Le recueil des données pour une transformation par la MOA, les architectes d’entreprise, les urbanistes du SI, les chefs de projets, les architectes logiciels… est une activité chronophage et devient vite obsolète dès que des changements interviennent.

 

Pour avoir un référentiel TOGAF rassemblant les autres référentiels (Stratégies, Finances, Applications, Architectures, Infrastructures…), faciliter la connaissance du SI et rendre plus efficientes les transformations de l’entreprise, la solution est de récupérer et agréger des informations issues de sources hétérogènes dans un référentiel centralisé. Concrètement, un ensemble de connecteurs récupère automatiquement et itérativement les données en fonction de règles préétablies à partir de n’importe quel type de fichiers. Dans le contexte de l’élaboration des trajectoires possibles, cette technique fait gagner beaucoup de temps à l'architecte d’entreprise qui peut se libérer de tâches manuelles fastidieuses et se concentrer sur l’étude des trajectoires les plus pertinentes, réaliser un plan de risques, entreprendre des projets à forte valeur ajoutée et participer à une meilleure gouvernance.

La solution est un outil collaboratif, avec un référentiel maître qui pourrait aller récupérer des données dans d’autres systèmes. C’est ce que propose Obeo SmartEA avec ses connecteurs.

 

La plateforme web sécurisée d’Obeo SmartEA
pour la collaboration

Loin des logiciels très chers (BOC Group ADOIT, MEGA HOPEX, LeanIX, Bizzdesign…) réservés aux grands groupes, nous avons mis à l’épreuve la plupart des outils d’AE open source ou à faible coût, avec comme objectif de cibler les organisations à budget restreint pour ce type d’outils ou encore le monde de l’éducation (voir nos tests en annexe). Nous avons constaté que :

 

-  soit il existe une véritable gestion d’un référentiel d’objets et d’artefacts accessible en local ou nécessitant une installation complexe pour le rendre partageable (Archimatetool),

 

- soit on nous propose une collaboration à la manière de Google (Visual Paradigm Online) pour dessiner des modèles, mais avec une absence totale de référentiel d’entreprise.

 

Déjà évoqué dans plusieurs de nos articles (voir annexe), seul Sparx Systems propose une déclinaison de son produit Enterprise Architect à prix modéré selon les fonctionnalités. Il offre toutes les fonctionnalités des produits bien plus onéreux, y compris la collaboration entre les acteurs de l’AE .

Après tout, ce ne sont que les enjeux basiques de l’AE, mais pour parvenir à ses fins, encore faut-il un outil qui s’appuie sur un référentiel partagé accessible, en fonction des profils utilisateurs, de manière concurrente et sécurisée et qui doit historiser les changements.

Vous voulez accentuer la collaboration entre tous les acteurs : utilisez une plateforme web sécurisée ! De plus, l’outil doit se conformer au standard en vigueur aujourd’hui, soit ArchiMate de l’Open Group, tout en étant personnalisable avec parcimonie en proposant des APIs ouvertes offrant la possibilité d’utiliser des notations plus spécifiques, comme BPMN pour les processus métier ou vos propres métamodèles.

Obeo, éditeur français, a bien compris les enjeux d’un tel type de logiciel et propose SmartEA, un outil sous licence commerciale intégrant ces fonctionnalités. Comme son concurrent direct Enterprise Architect de Sparx Systems, le référentiel est accessible via un client web permettant le partage des informations et un modeleur basé sur une plateforme Eclipse à installer localement pour peupler et manipuler les différents éléments du référentiel, en vue d'élaborer des scénarios et des trajectoires de transformation.

Ces pages web peuvent être transmises via des URL aux membres de l’organisation dûment habilités. Sinon, on peut les télécharger sous forme d’images haute résolution.

  

  

Un acteur dûment authentifié peut accéder via une URL au référentiel. Ses actions sont fonction des autorisations que lui a octroyées l’administrateur. Vue basée sur le pattern “Goal Realization Viewpoint” de la spécification ArchiMate. Les buts sont réalisés par un Résultat qui est réalisé par un Principe qui se comporte comme une exigence plus abstraite et plus large. Enfin le Principe est matérialisé par une Exigence indiquant des propriétés spécifiques que le système doit présenter.

 

Une granularité fine du verrouillage des artefacts
pour une résolution de conflits performante

 

Une base de données ou un moniteur de multithreading posent des verrous sur les objets modifiés : Obeo SmartEA va procéder de la même manière. La granularité des parties bloquées est très fine. Une fois les modifications sauvegardées, elles sont propagées automatiquement vers l’ensemble des utilisateurs qui seront libres d’apporter des mises à jour.

 

  

L'architecte d'entreprise vient de modifier un élément "Principe" de la vue "Motivation".
Un cadenas vert signalant le verrouillage apparaîtra tant que la sauvegarde ne sera pas effectuée.

 

 

  

Exemple d'un utilisateur voulant modifier un élément "Make" (Logiciel Système),
verrouillé par un autre utilisateur. 

 

Le tableau de bord de l’Architecte d’Entreprise

 

Si un transfert d’objets de modélisation dans le sens top-down était possible, on serait confronté aux problèmes du niveau de maturité et des pratiques des utilisateurs (niveau des macro-exigences, normalisation des noms, approche Domain-Driven Design…).

 

Seul un transfert bottom-up doit être autorisé. Sur demande, l’outil gérant le référentiel maître ira recueillir des informations éparpillées dans des systèmes hétérogènes, utilisés par exemple par les architectes applicatifs. L’architecte d’entreprise décidera de la suite à donner aux artefacts et actions remontées, par exemple doit-il les valider ou les rejeter.

Pour le suivi des états des objets composant la cartographie de l’entreprise, Obeo SmartEA met à la disposition de l’architecte des widgets graphiques personnalisables et regroupés dans un tableau de bord. L’enjeu est de disposer un outil de pilotage du projet avec la démarche TOGAF.

 

  

Exemple de tableau de bord montrant ce qui est à faire et ce qui est réalisé.
Ici, 4 applicatifs sont déjà validés et le modèle d’architecture ne comporte aucun lien interapplicatif.  

 

Importation des modèles d’Obeo ISD réalisés
par les architectes applicatifs dans Obeo SmartEA

Dans le cas où les architectes logiciels et techniques utiliseraient l’outil open source d’Obeo ISD (Information System Designer), les artefacts modélisés (voir nos articles en annexe) doivent être importés en vue de la consolidation du référentiel maître d’Obeo SmartEA. 

Concrètement, Obeo SmartEA possède un connecteur Java unidirectionnel et paramétrable qui gère les ajouts, les modifications et les suppressions de ISD vers son référentiel. 

 

  

Une fois lancé le connecteur, le référentiel centralisé et partageable d’Obeo SmartEA est mis à jour. L’architecte d’entreprise dispose d’une vue synoptique au travers de son tableau de bord.
ll devra étudier 146 applicatifs et 3 liens interapplicatifs, pour décider s’il les valide ou les rejette.

 

Mais Obeo SmartEA peut aussi récupérer des modèles réalisés par d’autres outils, comme celui de Sparx Systems

 

Obeo SmartEA fournit des APIs ouvertes pour créer des connecteurs vers des ressources externes et notamment vers son concurrent direct Sparx Systems Enterprise Architect.

 

    

Notez les connecteurs qui importent des données de fichiers Excel et de Sparx EA (Enterprise Architect)

 

Alimenter automatiquement le référentiel
à partir d’import de données

 

Exemple d’un fichier Excel fourni par l’équipe infrastructure, représentant les échanges entre les applications et les interfaces au travers desquelles elles communiquent. 

 

  

Pour analyser ce fichier et remonter les informations, Obeo a développé un connecteur que l’on peut lancer depuis la page des traitements (voir paragraphe précédent).

 

  

Le composant applicatif "Système suivi de satisfaction client" communique avec le composant "CRM" par l'intermédiaire de l'interface "Web Service CRM" comme spécifié dans le tableau Excel.
De même, un autre lien a été créé avec le composant "Système de fidélité" qui utilise l'interface
"Rapport XLS de suivi de satisfaction" du composant "Système suivi de satisfaction client".   

 

Conclusion

 

Voici un outil mettant en œuvre un référentiel centralisé et collaboratif TOGAF. Les éléments de modélisation font partie des standards du marché, à savoir ArchiMate et BPMN. Des APIs ouvertes permettent d’intégrer d’autres notations standards comme UML ou des DSL spécifiques.

 

Toutes les parties prenantes de l’entreprise peuvent accéder aux différentes vues d’architecture via un simple navigateur web. Le concept de prisme permet d’octroyer des authentifications et des autorisations en fonction des rôles des utilisateurs. Le système de gestion de conflits optimisé, pour ne verrouiller que la donnée en cours de modification, permet des accès rapides.

 

Enfin, des connecteurs offrent la possibilité de récupérer des données, en provenance par exemple des architectes logiciels utilisant Obeo ISD ou Sparx Systems Enterprise Architect ou de la MOA à partir de tableaux Excel.

 

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.

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

 

 

 

 

 

 

"Qu'est-ce que je serais heureux, si j'étais heureux".

Woody Allen

 

Annexe : nos tests

 

• 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
    
• Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
    
• Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
    
• Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3
    
• Quelle solution pour concevoir la modélisation d’une architecture micro-services, l’intégrer dans une architecture d’entreprise et permettre une collaboration avec l’ensemble des acteurs projet ? Obeo ISD S.1 Ep.4
    
• Vous cherchez un outil pour gérer le mapping entre les objets métier et une base de données relationnelle, générer les scripts SQL et produire du code à partir de vos modèles ? Obeo ISD S.1 Ep.5
    
• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information
    
• Modelio
    
• Visual Paradigm (online)
    
• ADOIT : CE (BOC Group) et ADOIT : CE (compléments d’information)
    
• Archi (archimatetool)
    
• GenMyModel
    
• Camunda 
    
• Papyrus
    
• Eclipse Modeling Tools
    
• diagrams.net ou draw.io
    
• Texte vers UML et autres outils de "diagrammes en tant que code"
    
• Enterprise Architect
    
• WinDesign
    
• 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 meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont…

 

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. 

 

   

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.

 

 

   

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

 

    

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.

 

 

  

 

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.

 

     

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.

 

   

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

 

 

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. 

 

   

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 HubSpot

    

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 

 

 

 

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.

 

  

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

 

 

 

 

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.

 

  

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

  

  

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.

 

 

   

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.

 

  

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.

 

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

L’atelier Entity d’Obeo Information System Designer (ISD) va vous permettre de modéliser vos entités métier. Avec l’autre atelier Database, vous pourrez modéliser votre base de données relationnelle, générer des scripts SQL, rétromodéliser des bases existantes, gérer des Modèles Logiques de Données (MLD) et des Modèles Physiques de Données (MPD).

Et grâce aux deux, vous serez assuré de la synchronisation efficiente entre vos objets métier et votre base SQL. ISD a plus d’un tour dans son sac avec ses nombreux frameworks qui vous permettront de générer une partie du code de votre application, à partir de vos modèles de conception et d'analyse.

 

   

Vous créez votre modèle d'entités persistantes, puis, à partir de ce modèle, ISD va générer le MLD ;
vous lui indiquez votre moteur SQL, ISD génère le MPD, puis les scripts correspondants
et enfin vous les exécutez directement dans ISD.

 

Résumé des épisodes précédents

     

Nos 4 précédents articles détaillent toutes les étapes, depuis l'analyse du besoin
jusqu'à la conception d'une architecture micro-services.

 

Les différents modeleurs et leurs fonctions

• Épisode 1 : présentation des fonctionnalités et installation d’ISD. 
   
  A lire > Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
   
• Épisode 2 : l’atelier Graal de modélisation des acteurs, des use cases, des tâches, des enchaînements d’actions, des diagrammes de séquence et de machine à états.
   
  A lire > Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
   
• Épisode 3 : l'atelier Graal de gestion des User Stories, l’atelier Requirement pour gérer le référentiel des exigences et leur traçabilité, l’atelier Cinematic pour la modélisation des maquettes et la cinématique des écrans 
   
  A lire > Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3
   
• Épisode 4 : l’atelier SOA pour modéliser des API (REST ou SOAP) avec leurs composants applicatifs micro-services ou Web Services, leurs interfaces de communications, leurs relations, leurs opérations avec les données échangées (DTO), pour générer des documents OpenAPI et pour rétromodéliser des interfaces REST.
   
  A lire > Quelle solution pour concevoir la modélisation d’une architecture micro-services, l’intégrer dans une architecture d’entreprise et permettre une collaboration avec l’ensemble des acteurs projet ? Obeo ISD S.1 Ep.4

 

Créez des entités persistantes

Jouez la partition

En préambule, quelques mises au point sur la terminologie d’ISD :

 

• les Domain classes représentent les entités métier définies par les experts métier et modélisées par les business analysts avec la méthode Graal,
   
• les Entities correspondent aux classes persistantes gérées par un ORM (Object Relational Mapping) offrant la dualité objet/relationnel SQL.
   
• les DTO, créés à partir des attributs des Entities, représentent les données échangées entre les services dans une SOA.

 

Un diagramme Entities Namespaces Hierarchy est créé dans le conteneur de l'Entity Model.
Le NoUML de modélisation d’Obeo ISD est en fait un DSL (Domain-Specific Language), dans lequel le package UML est renommé namespace, avec un nombre restreint de relations.

 

De manière similaire à la vue Domain Classes Namespaces Hierarchy du modèle Graal ou celle DTO Namespaces Hierarchy, il faut créer au préalable au moins un namespace : 

 

• File ou clic droit sur votre Modeling Project > New > Other > IS Designer > Entity Model

 

  

Les pictos en bas à droite des namespaces indiquent qu’en double-cliquant,
on peut accéder au diagramme d’entités.

 

Ce diagramme permet de modéliser les classes, qu'elles soient internes ou externes au namespace. S’il existe des relations entre des classes appartenant à des namespaces différents, alors ISD génère automatiquement les relations dans le diagramme des namespaces.

 

• Une fois le namespace créé, le sélectionner via le menu contextuel > New Representation > Entities Diagram

 

 

On retrouve exactement le même type de diagramme que les Domain Classes ou les DTO,
sauf que cette fois-ci les classes sont stéréotypées Entity.

 

ISD supporte les visions entités persistantes vers DTO ou bien l’inverse. Dans le diagramme d’entités, on a Entity from DTO et dans celui des DTO on a DTO from Entity.

Ce choix est judicieux, car il permet une souplesse de conception bidirectionnelle qui se présente souvent dans un contexte agile, où l’on doit ajouter des données, soit dans les entités persistantes et les répercuter dans les DTO, soit l’inverse.

 

Un bémol à la clé

Par contre, il est impossible de récupérer les classes métier (Domain Classes) modélisées dans le modèle Graal de l’analyse. Dommage, car en pratique la plupart des entités persistantes proviennent des classes participantes ou métier !
 
Il nous a été impossible de créer une relation entre une entité et une énumération, on a donc créé à la place un attribut du type énumération.

En choisissant de générer toutes les entités à partir de nos DTO, nous avons constaté que : 
Les liens d’héritage ne sont pas repris, bien que l’on ait sélectionné toutes les relations à importer, mais les attributs sont dupliqués dans l’entité héritière.
Les énumérations n'apparaissent pas, bien qu’un attribut d’une entité soit de type énumération.

 

Ajoutez à vos entités persistantes
les informations spécifiques à la base SQL 

 

 

Préparez la correspondance de vos entités persistantes
avec les noms des colonnes, type, taille, unicité, index...

 

La vue Entities Physical Names est un tableau qui reprend en lignes toutes les entités définies précédemment et permet dans les colonnes d’ajouter les informations spécifiques à la base de données, comme le nom physique d'une colonne, la taille, les contraintes de vérification, les contraintes d’unicité, la valeur par défaut, le choix des schémas pour les tables intermédiaires.

Par exemple, sur un attribut indexé, on peut mettre dans la colonne Unique ASC pour ascendant ou DESC pour descendant.
Pour une contrainte d’unicité portant sur plusieurs champs, on doit adopter un langage spécial (sur l’entité et non plus sur l’attribut, dans la colonne Unique, on doit saisir champ1:ASC,champ2,champ3,etc. avec éventuellement un | pour séparer des index différents).

Il est impossible de saisir dans les colonnes Name, etc. les attributs des entités créées à partir des DTO. Par contre, si nous ajoutons une nouvelle entité avec des attributs, elle se retrouve bien dans le tableau et nous pouvons bien saisir dans les colonnes des attributs.

 

Générez automatiquement le modèle logique
de données (MLD) à partir du modèle Entités

Construisez l'échafaudage de votre architecture :
le système de génération Scaffolding d'ISD

• Menu File ou clic droit sur votre Modeling Project > New > Other > IS Designer > Database Model > Laissez toutes les valeurs par défaut (Data Base, Logical Types et UTF-8)

 

Un diagramme de schéma logique de base de données, encore appelé MLD (Modèle Logique de Données) pour les nostalgiques de la méthode Merise, est créé, dans lequel on peut modéliser des tables, vues, colonnes, clés primaires et étrangères, des séquences, des index… 

 

Le système Scaffolding d’ISD permet de transformer des modèles, suivant les concepts MDA (Model Driven Architecture) de l’OMG. 

 

A lire > nos articles dans la catégorie : Ingénierie Dirigée par les Modèles (IDM)

 

Après avoir modélisé vos entités persistantes et défini les propriétés physiques (nom de table, taille…) avec l’atelier Entities, vous pouvez générer vos tables dans le diagramme de schéma pour une base de données relationnelle (MLD), pour l’instant vide, grâce au système Scaffolding Entity to Logical database d’ISD.

 

• Sélectionnez à la fois, en maintenant la touche Ctrl enfoncée, le conteneur (Entities) sous la vue (.entity) et le conteneur Data Base sous la vue (.database) > clic droit > IS Designer > Scaffolding > Entity to Logical database (remarque : on dispose aussi de l’option inverse) > les schémas générés à partir des namespaces du modèle Entities apparaissent : 

 

 

Dans le schéma logique de base PrevIT, 3 sous-namespaces sont créés correspondant
aux 3 contextes métier (Domain Driven Design) Prestation, Personne et Contrat.

 

Pour avoir le détail, double-cliquez sur un schéma : 

 

  

On retrouve les concepts des bases de données relationnelles, avec les clés primaires, étrangères,
les contraintes de check (triangle sur les tables), etc. Vous pouvez réorganiser les colonnes.

 

Le MLD est bien créé à partir du modèle entities. Des colonnes de pistes d'audit ont été ajoutées par le générateur d'ISD comme PRESTATION_XTOPSUP (Indicateur pour savoir si l'enregistrement est valide) et PRESTATION_XDMAJ (Date de mise à jour de la ligne). La table SURVENANCE est en relation avec la table PERSONNE dans le schéma PERSONNE et avec la table CONTRAT dans le schéma CONTRAT.

 

Pour la génération de l'héritage, l'échafaudage est bancal

Les bases de données relationnelles n'ont pas de moyen simple de mapper les hiérarchies de classes sur les tables de base de données. Pour résoudre ce problème, plusieurs stratégies existent :

 

• MappedSuperclass - les classes parentes ne peuvent pas être des entités,
   
• Table unique – Les entités de différentes classes ayant un ancêtre commun sont placées dans une seule table,
   
• Table jointe - Chaque classe a sa table, et interroger une entité de sous-classe nécessite de joindre les tables,
   
• Table par classe - Toutes les propriétés d'une classe sont dans sa table, donc aucune jointure n'est requise.

 

La stratégie d’héritage choisie est celle d’une table par classe. Cette stratégie mappe donc chaque entité à sa table, qui contient toutes les propriétés de l'entité, y compris celles héritées.

 

 

3 tables ont bien été générées. Seule la table PERSONNE_MORALE est correcte compte tenu des relations d'héritage modélisées dans le diagramme Entities. En effet, les colonnes NUMERO et COORDONNES héritées sont bien présentes, en plus du SIRET spécifique à la table.

 

Dans le modèle des entités persistantes (partie supérieure de l'illustration), PersonnePhysique et PersonneMorale héritent des attributs numero et coodonnees de Personne. Dans le schéma généré (partie inférieure de l'illustration), on constate que coordonnees n’apparaît pas dans la table PERSONNE, ni dans la table PERSONNE_PHYSIQUE, alors que bizarrement elle est bien présente dans la table PERSONNE_MORALE. Auparavant, nous avons bien pris soin de spécifier la colonne coordonnees dans le tableau Entities Physical Names du modèle Entities, avec une taille de 100.

Autre bizarrerie, la colonne NUMERO de la table PERSONNE et PERSONNE_MORALE apparait bien, conformément à la stratégie d’implémentation de l’héritage, mais pas dans la table PERSONNE_PHYSIQUE !

 

 

Dans le tableau Entities Physical Names du modèle Entities, permettant de configurer le MLD qui va être généré, à l'attribut coordonnees de la classe Personne, on a fait correspondre la colonne du même nom avec une taille 100, qui pourtant n'apparaît pas dans la table PERSONNE.

 

Gestion des modifications

Si l’on fait d’autres modifications, et que l’on refait l’opération de scaffolding, ISD propose de créer une nouvelle version ou d’écraser l’ancienne.

 

• Par exemple, on modifie le nom du schéma, il suffit de sélectionner le conteneur .scaffold sous le répertoire scaffold > IS Designer > Scaffold > Entity to Logical database. Un nouveau schéma EB apparaît, on crée un nouveau diagramme (New representation > nouveau nom Schema) et l’on retrouve un nouveau MLD avec en préfixe le nom du nouveau schéma.

 

Générez automatiquement
le Modèle Physique de Données (MPD)

 

Prenons MySQL comme RDBMS de test.

 

Créez tout d’abord un schéma (database) vide dans MySQL, par exemple previtDB_testISD, puis dans ISD, menu File > Import > Database > Import Database > saisissez les informations de connexion à votre database MySQL :

 

   

Remarque importante : dans le champ New model file, vous devez saisir
un modèle de database inexistant, par exemple Previt_MPD_MySQL8.database

 

Générez le MPD avec le système de scaffolding d’ISD, en procédant de la même manière que pour générer le MLD à partir des entités :

 

• Sélectionnez simultanément votre MLD (Data Base My) et votre MPD vide, que vous venez de créer (Data Base previtDB_testISD)

 

   

A partir de votre MLD généré précédemment, le système Scaffolding d'ISD va générer
votre MPD nouvellement créé et qui pointe sur votre database vide MySQL.

 

• Menu contextuel sur le MPD > IS Designer > Scaffolding > Logical database to Physical database (on dispose aussi du reverse engineering Physical database to Logical database).

 

Le MPD est créé avec les 4 schémas MySQL correspondants aux 4 namespaces : le namespace previtDB_testISD correspondant au namespace de base et PRESTATION, PERSONNE et CONTRAT correspondant aux 3 sous-namespaces.

 

Générez les scripts SQL

 

Sur le conteneur Previt_MPD_MySQL8.database, on peut générer les scripts SQL :  

 

• Menu contextuel > IS designer > Generate SQL Scripts, un répertoire sql est créé, comportant 4 scripts pour les créations de contraintes, de clés étrangères, d'index et de tables et un script complet rassemblant les 4 précédents.
  

 

  

On trouve les scripts SQL correspondant au MPD. Ces scripts SQL devront être exécutés manuellement.

 

Exécutez les scripts SQL directement dans la base

 

Le générateur Liquibase permet d’exécuter directement des scripts dans la base.

 

• Sur le conteneur MySQLtest2.database, on peut générer les scripts SQL :  
  Menu contextuel > IS designer > Generate Liquibase changelog

 

Un répertoire liquibase est créé, contenant un fichier de propriété, permettant de configurer les accès à la base de données, et un fichier XML contenant les propriétés sous forme de balises avec les instructions SQL qui seront envoyées à la base par liquibase.

 

 

Vous devez valoriser les variables du fichier liquidbase.properties (<hostname>…).

 

Au lieu de configurer le fichier de propriétés liquibase, il existe une manière plus facile en utilisant le fichier run.changelog.xml : 

 

• menu contextuel sur le fichier run.changelog.xml > Liquibase > Apply changing > saisir l’URL (jdbc:mysql://localhost:3306/previtDB_testISD), le user et le password 

 

A ce moment, liquibase va se connecter directement et exécuter le fichier XML.

 

Nous avons rencontré 2 types d’exceptions : 

 

• la 1re concernait l’impossibilité dans le fichier run.changelog.xml, de prendre en charge la propriété : column autoIncrement="true". Nous avons remplacé partout true par false,
   
• la 2e disait que les schémas (database) CONTRAT, PERSONNE et PRESTATION n’existaient pas. Effectivement, comme nous avions créé 3 sous-namespaces dans le namespace de base, 3 schémas ont été créés dans ISD, il faut donc naturellement les créer dans MySQL (dans notre cas MariaDB, compatible MySQL).

 

 

Extrait de la vérification de l'exécution des scripts SQL dans la console de la base de données.

 

Vous pouvez analyser les changements apportés grâce à l’historique : 

 

• Menu contextuel sur le conteneur MLD .database > Compare With > Local History 

 

       

Exemple d'utilisation de l'historique.

 

Rétromodélisation et intégration de l’existant

 

   

Capacité à se connecter au format OpenAPI, en import, mais aussi en export.
Liquibase permet de piloter les schémas d’une base de données
à partir d’un diagramme de classes de conception.

 

On peut exporter et générer des previews avec SwaggerUI. Voir les copies d’écran dans la documentation github.

 

Génération documentaire

 

       

M2Doc généré à partir d’un template variabilisé.
La valorisation se fait à partir des modèles créés dans ISD.

 

Le Graal de l’agilité : générer une application directement à partir des modèles et de manière bidirectionnelle

 

  

La génération de code est basée sur des templates. Voir un exemple de template Acceleo en annexe 1.

 

Avec ISD, le processus est simple : vous modélisez la conception, puis vous générez le code. Vous pouvez modifier le code que vous avez généré. Si vous modifiez la conception, votre code est conservé. Le concept de génération se fait en round-trip, c’est-à-dire que l’on peut intégrer les parties de codes réalisées par les concepteurs/développeurs. 

 

Plus on remonte dans les couches de l'architecture, moins on pourra générer de code. 

Ainsi, 80 % du code backend peuvent être générés. Par exemple, 100 % des entités seront générés et plus de 50 % pour le métier. La couche de persistance est entièrement créée par le générateur d’ISD, auquel Obeo a ajouté les tests unitaires, ce qui n’est pas le cas des ORM classiques.

 

Les 20 % restants concernent les écrans laissés aux spécialistes frontend et certaines parties métier, comme des règles métier ou les machines à états, car les développeurs séniors produiront un code plus efficient.

 

Toute la partie architecture est sécurisée, car elle est mise en place par le générateur.

ISD utilise plusieurs générateurs de code open source, comme Acceleo de la fondation Eclipse et PACMAN du Ministère des Armées de la France.

 

A lire > Les générateurs de codes Acceleo et PACMAN

 

La mise en œuvre de ces outils passera souvent par les services payants d'Obeo. 

       

Ne vous enthousiasmez pas trop vite, à moins d'avoir une connaissance approfondie des techniques de génération de code, l'utilisation efficiente de ces générateurs demandera l'aide d'experts.

 

Obeo vous propose toute une série de modeleurs gratuits pour la partie analyse et modélisation de votre application. Si la fourniture des générateurs de code l’est aussi, leur utilisation reste extrêmement complexe. Obeo peut alors vous proposer, moyennant finance, un accompagnement. Il en va de même pour la maintenance et le support d’ISD. 

 

Travail collaboratif avec l’extension payante
Obeo Designer Team

 

Pour le travail collaboratif, là encore il faudra mettre la main au porte-monnaie. En effet Obeo Designer Team est une extension commerciale, non-open source, permettant de partager des modèles, à la manière Google Doc.

 

Conclusion

 

 

Le couple de frameworks Sirius & Acceleo permet à ISD de produire
le code correspondant aux modèles de conception.

 

Les éloges

ISD d’Obeo est indubitablement un outil basé sur la collaboration de toutes les parties prenantes d’un projet de réalisation d’une application. 
Avec ses différents ateliers, ISD vous aidera dans l’élaboration de la phase d’analyse (atelier Graal). Le cadre apporté par la méthode Graal vous facilitera la formalisation des use cases, avec les enchaînements d’actions, l’intégration des user stories, le modèle métier de vos données et la mise en place du référentiel d’exigences. L’atelier Cinematic vous permettra de concrétiser les scénarios des use cases, en maquettant les écrans et en planifiant la navigation. L’atelier SOA vous permettra d’élaborer votre architecture distribuée à base de micro-services ou de services web. Avec l’atelier Entity, vous définirez, parmi vos classes métier et DTO, lesquels doivent être persistants.

 

Les déceptions

Après avoir fait du NoUML, il est étrange qu’ISD ne supporte pas le NoSQL, comme (MongoDB, Cassandra…). 

Nous regrettons aussi que le modeleur SOA Designer ne couvre que le type d’exposition REST. SOAP n’est disponible dans le studio qu’à titre indicatif, aucun outillage spécifique n’ayant été développé pour l’exploiter. Que vous utilisiez l'approche top-down, concevoir le contrat WSDL (Web Services Description Language), puis, à partir de celui-ci, faire générer le code ou l'approche inverse bottom-up, il vous faudra vous tourner vers les frameworks open source conventionnels du marché en fonction de votre langage de programmation. Autre solution, demander à Obeo, d'implémenter cette fonctionnalité, qui sera alors payante.

Open source oui, closed pour le reste.

 

A notre avis, l’atelier Database, qui génère les schémas logiques de base SQL, les scripts SQL et qui les exécute, ne présente que peu d'intérêt, car la plupart des technologies, Java, Python… possédant déjà des frameworks de synchronisation bidirectionnels entre les objets et le moyen de persistance, quelque soit son paradigme : SQL, NoSQL, voire XML.

 

Y a-t-il encore un intérêt pour les outils de génération de code
face à l'IA générative comme ChatGPT ?

La génération de code utilise des paradigmes comme MDA et des frameworks comme Acceleo, qui sont déjà anciens et qui semblent quelque peu désuets face à la puissance, la facilité et l’expansion phénoménale des nouvelles IA génératives (OpenAI ChatGPT, Microsoft Bing Chat, Google Bard ou encore Meta Llama, Anthropic Claude pour les plus connues). 

Quelles sont leurs places dans le domaine de l’Architecture d’Entreprise, de l’Architecture Logicielle et la modélisation de système ? C’est l’étude que nous allons effectuer et que nous vous livrerons dans nos articles à venir.

 

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.

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

 

 

 

 

 

« Je me suis un peu amusée à tester ces nouveaux outils et ce que je trouve très intéressant, c’est que pour utiliser l’IA dans la phase de recherche et de documentation, il faut entrer des mots. Ça nous force quelque part à mettre des mots dès le départ sur une intention créative. C’est très utile pour formaliser et conceptualiser des idées. » 
Adèle Hennion

Obeo Information System Designer (ISD) offre aux architectes logiciel la possibilité de maîtriser leur architecture micro-services (composants, services, interfaces, flux, infrastructure, interdépendances...). Cet outil, interopérable avec SmartEA du même éditeur, permettra de s'assurer que les spécifications techniques sont correctement comprises et que les développements sont conformes à l'architecture d'entreprise. 

 

 

Le diagramme SOA (Service Oriented Architecture) montre une chorégraphie de composants,
par exemple les micro-services (DossierSinistre, Assure et Contrat), les services fournis (Provided interface en vert) et ceux qui les utilisent (Required interface en violet). Les liens orientés du consommateur vers le fournisseur illustrent les appels des services entre les micro-services.

 

A lire > Orchestration des micro-services avec BPMN

 

Que dit la bible TOGAF de l’Open Group
à propos de l’architecture micro-services ?

 

 

Extrait du TOGAF® Series Guide Microservices Architecture (MSA) montrant les interfaces où les entrées et les sorties du micro-service sont échangées avec d'autres couches architecturales qui doivent être identifiées. La gouvernance et la conduite du changement sont héritées de l'Architecture d'Entreprise globale.

 

Le guide TOGAF Series sur l’architecture des micro-services (MSA) publié par The Open Group fournit une définition complète de la MSA et présente la portée de l’architecture d’entreprise comme englobant toutes les activités et capacités commerciales de l’entreprise, les informations et la technologie qui composent l’ensemble de l’infrastructure et de la gouvernance de l’entreprise.

 

L’architecture des micro-services (MSA) est un style d’architecture dans lequel les systèmes ou applications logicielles sont composés d’un ou plusieurs services indépendants et autonomes. Ce n’est pas un produit, un cadre ou une plateforme. C’est une stratégie pour construire de grands systèmes distribués. Les micro-services sont faiblement couplés et déployés indépendamment les uns des autres.

 

A lire >

 

• Notre dossier complet : Architecture Micro-Services et Micro-Services études de cas
   
• Une définition pédagogique et les avantages des micro-services : L’Architecture Micro-Services expliquée à ma fille
   
• Leurs inconvénients : Inconvénients de l'Architecture Micro-Services
   
• La démonstration qu’une architecture micro-services est beaucoup plus simple qu’une architecture monolithique : Estimation de la complexité d’une Architecture Micro-Services

 

Résumé des épisodes précédents

 

Ça y est, l’analyse de votre application est bien avancée dans ISD, il est temps pour les architectes logiciel de passer à la modélisation de l’architecture micro-services (MSA).

ISD est un environnement open source, low code et NoUML pour l’analyse, la conception et la génération de code d’applications s’interfaçant avec l’outil d’Architecture d’Entreprise SmartEA du même éditeur. Jusqu’ici, nous avons vu des équivalents des cartographies métier, fonctionnelle, applicative avec la cinématique et les représentations des écrans.

Avec ISD, les acteurs, qu’ils soient business analyst, product owner, concepteur, développeur, testeur... embarquent dans un train et se laissent conduire. Chacun apporte sa pierre à l’édifice : le product owner conçoit les user stories, le testeur crée les exigences et les cas de tests à partir des cas d'utilisation, le concepteur modélise les interactions utilisateur et le business analyst les cas d'utilisation, le modèle conceptuel de données et les transitions d’état des entités métier.

 

Pour l'aspect dynamique du système, la démarche permet de modéliser les rôles des acteurs, puis les cas d'utilisation. Leur granularité étant toujours problématique, l'utilisateur sera aidé en ayant la possibilité de les décomposer suivant 2 niveaux de détails :

 

1. les scénarios (Tasks Graph),
    
2. les étapes (Actions Plan) d’un scénario.
    

Pour ceux qui le désirent, il est possible d'ajouter des diagrammes de séquence et d'états.

 

L'aspect statique se compose de diagrammes semblables à UML, mais expurgés des éléments rarement utilisés :

 

1. les domaines métier (Namespaces), équivalent du diagramme de package UML avec la complexité des relations en moins,
    
2. les entités métier et leurs relations (Domain Classes), correspondant à un diagramme de classes UML pragmatique.

 

Comme le montre notre étude de cas avec les matrices de traçabilité des exigences avec les use case, les tâches, les cinématiques et les maquettes des écrans, les liens sont bien tissés entre les besoins utilisateurs et les spécifications de l’application. Lors de changements, le contrôle de cohérence entre tous ces éléments et les études d’impact en seront grandement facilitées, principe cher aux méthodes agiles.

 

En couplant ISD avec l’outil SmartEA, vous obtiendrez des cartographies allant jusqu’à une granularité très fine et augmenterez le degré d’agilité de votre architecture d’entreprise.

 

A lire >

 

1. Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
    
2. Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
    
3. Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

 

Comment réaliser la modélisation
d'une architecture micro-services

 

Orientée NoOMG

ISD permet, par l’intermédiaire de son SOA Designer, de modéliser la communication entre les composants d’une application. Cet outil cartographie leurs liens réalisés par des interfaces de services fournies ou requises. Tout y est : la définition des opérations que vos services peuvent effectuer avec leurs entrées/sorties et la gestion des exceptions.

 

Les protocoles standards SOAP (qui n'est plus un acronyme depuis la version 1.2) et REST (REpresentational State Transfer) sont supportés. La documentation technique ne fait pas état de GraphQL (Graph Query Language). Dommage, car ce langage offre de nombreux avantages par rapport à REST.

 

L’importation de services REST existants en format OpenAPI (Swagger) est supportée, ce qui rend possible la rétromodélisation. L’export au même format permet de générer la documentation.

 

Enfin, les données échangées DTO (Data Transfer Object) peuvent être modélisées en NoUML, à partir des entités persistantes (Entities). Dommage qu'ils ne peuvent l'être à partir des classes du domaine (classes métier) définies dans le modèle utilisant la méthode Graal, vue dans nos précédents articles.

Ici, pas de norme ésotérique ou rarement utilisée comme SoaML de l’OMG (Object Management Group), que du pragmatique, on pourrait dire du NoOMG.

 

Créer un SOA Model

 

File > New > Other > IS Designer > SOA Model

 

 

Après avoir vu Graal Model, Interaction Model, State Machine Model,
Requirement Model, Cinematic Model, examinons le SOA Model.

 

Les vues DTO Namespaces Hierarchy et SOA Diagram sont ouvertes afin de commencer la modélisation.

 

Commencer par les DTO (Data Transfert Object)

DTO, JSON, XML/XSD, REST, SOAP

Le pattern DTO d’architecture distribuée consiste à ne considérer que les données échangées et utiles pour le consommateur du service. L’architecte applicatif doit les sélectionner parmi les attributs des classes persistantes (Entities). En effet, transmettre des données non pertinentes pour l’utilisateur encombrerait la bande passante réseau pour rien et présenterait un risque potentiel de sécurité.

 

Une structure commune entre le fournisseur et le consommateur du service devra être choisie comme JSON (JavaScript Object Notation) pour les micro-services ou XML/XSD (eXtended Markup Language/Xml Schema Definition) pour les Web Services.

 

Un socle technologique implémentant un protocole commun de transport entre les 2 protagonistes devra être mis en œuvre comme REST (REpresentational State Transfer) pour les micro-services ou SOAP (qui n’est plus un acronyme dans sa nouvelle version) pour les Web Services.

Pour les opérations des interfaces du SOA Diagram, on aura besoin des structures des données échangées. Vous devez donc modéliser vos DTO.

 

Créer des namespaces pour organiser vos DTO

• Sélectionnez le SOA Model > cliquez sur la vue DTO Namespaces Hierarchy > créer un nouveau namespace de base à partir de la palette et éventuellement des sous-namespaces 

  

Création du namespace représentant le système de prévoyance contenant 3 sous-systèmes :
prestation, personne et contrat.

 

Modéliser vos données échangées en entrée/sortie en créant un diagramme DTO

Un diagramme DTO est un diagramme de classes UML simplifié où les classes seraient stéréotypées DTO. Certaines subtilités sont supprimées, comme les agrégations, les implémentations d’interface, les dépendances et évidemment les méthodes. Les DTO ne contiennent que des données, les opérations seront décrites dans les services des composants.

 

• Sélectionnez le namespace > double-cliquez pour ouvrir un diagramme ou clic droit > New > New DTO Diagram

 

 

Vu d'avion, ce diagramme a tout d'un diagramme de classe UML. À y regarder de plus près, pas d'affectation de méthodes dans les classes, pas de relation d'agrégation, de réalisation, de dépendance, pas d'interface, pas de classe abstraite, pas de classe paramétrée... :
on dirait bien du NoUML.

 

Certains choix peuvent dérouter quelque peu les experts UML, comme le fait qu’une relation de composition soit identifiée par un losange blanc du côté du composite, alors qu’en UML il est noir. Le losange blanc signifie un agrégat dans une relation d’agrégation UML.

Toujours quelques regrets sur l’ergonomie. Par exemple, pour les valeurs d’une énumération, on aurait aimé une saisie globale, plutôt que de ressortir chaque fois, de sélectionner le +, puis de saisir la nouvelle valeur.

 

La palette vous propose une fonctionnalité alléchante, qui est de créer des DTO à partir d'entités “DTO from Entity”. A noter qu’à l’inverse, il est possible de créer des entités à partir des DTO.

Dans ISD, les Entities correspondent aux classes persistantes gérées par un ORM (Object Relational Mapping) offrant la dualité objet/relationnel SQL. Notre prochain article sur ISD abordera la génération de code et plus particulièrement les Entities, les MLD (Modèle Logique de Données), les MPD (Modèle Physique de Données), la génération et l’exécution de script SQL.

 

S’il est possible de créer des DTO à partir des entités persistantes (Entities), il est par contre impossible de le faire à partir des classes participantes (Domain Classes), identifiées lors de l’étape d’analyse de la méthode Graal. L’outil SOA Designer semble complètement ignorer les éléments identifiés dans le module Graal. Dommage, car on pourrait aussi concevoir les DTO à partir des classes du domaine métier et pas seulement des classes persistantes.

 

Un autre inconvénient est que la traçabilité des classes du domaine n’est pas assurée vers les classes persistantes. Pourquoi ce choix ? Ce ne peut être une limitation technique, car par exemple, le SOA Designer accède bien au modèle d’exigences (Requirement Model) pour la traçabilité avec les composants, services et opérations.

 

Doit-on en conclure qu’il n’y a pas véritablement de référentiel transverse à tous les modules ? 

 

Cartographier les services (SOA Diagram)

 

L’objectif est de représenter les composants, leurs liens de communication par l’intermédiaire des interfaces fournies et requises, composées d’opérations avec leurs données en entrée/sorties et leurs traitements exceptionnels (fault).
 
On commence par une vue globale : il s’agit d’un diagramme de composants UML simplifié, où Obeo a gardé les concepts d’interfaces fournies et requises, ainsi que leurs liens, en modifiant leur représentation.

 

• Dans SOA Model > Components > double-cliquez sur SOA Diagram

 

 

Le composant applicatif DossierSinistre doit utiliser (Required interface) les services
du composant Assure et Contrat pour fournir les services qui gèrent la survenance et le dossier.
Notez le niveau de sécurité, ici OAuth 2.0 (Open Authorization).

 

Le picto clé jaune indique que le composant DossierSinistre est lié à des exigences à visualiser dans l’onglet Linked Requirements et l’autre à droite signifie qu’en double-cliquant sur le composant, on accède au diagramme Component Contract détaillant les opérations.

 

Contractualiser les opérations d’un service
et les traitements exceptionnels 

 

Une fois un composant créé avec les interfaces qu’il fournit (Provided) et celles qu’il utilise (Required), on va détailler leurs opérations avec leurs paramètres d'entrée/sorties et les exceptions (Fault) dans un nouveau diagramme.

 

• Double-cliquez sur le composant, ISD crée automatiquement un nouveau diagramme. On peut aussi passer par le menu contextuel sur le composant : clic droit > New Representation > Component Contract

 

 

Le service (Provided Interface) SurvenanceService possède 2 opérations : listerHistoriqueSurvenances avec le picto vert S pour SOAP et le picto paginé. Les paramètres en entrée sont indiqués par une icône bleue, en sortie par une icône verte et les messages d'erreurs en rouge.
L'autre opération possède un picto R pour REST.

 

Les interfaces apparaissent et, dans la palette, il suffit de faire des drag and drop pour les opérations avec leurs entrées/sorties et les exceptions.

 

Configurer une opération

 

Si le nombre d’occurrences retourné par une opération est trop important, vous pouvez décider de paginer le résultat :

 

• Sélectionnez une opération > onglet Properties > onglet Operation > cochez Paged
  Si ce nombre dépasse la limite métier maximale stipulée dans une exigence, alors vous pouvez renvoyer un message d’erreur (Fault). 

 

Pour choisir le protocole d'échange :

 

• Sélectionnez une opération > onglet Properties > onglet Operation > Exposition > choisir entre REST (picto roue verte R), SOAP (picto roue verte S) et NONE (roue grise pour les services internes).

 

Vous pouvez tout configurer. Par exemple, si vous avez sélectionné REST, l’onglet “Exposition” des propriétés permet de choisir l’URI (Uniform Resource Identifier) et les méthodes HTTP disponibles qui sont GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH et TRACE.

 

Pour configurer les données en entrée et en sortie :

 

• En cliquant sur un paramètre d’une opération, on a le détail et notamment le type, comme ContratDTO, en cliquant sur les 3 points horizontaux,
   
  
• Dans Exposition, on trouve aussi le détail des paramètres entrants, qui peuvent être transmis en : BODY, PATH, QUERY, COOKIE et HEADER et leurs noms Swagger pour la documentation et les tests unitaires,
   
• Pour les paramètres en sortie, on peut choisir un code HTML normalisé (200 : OK, 201 : Created…).

 

La sécurité n’est pas en reste avec l’API REST 

 

Les schémas de sécurité peuvent être mis au niveau du service ou d’une opération.

 

Sécurité d'un composant

Il faut d’abord définir les schémas de sécurité.

 

• Cliquez dans le diagramme Component Contract > Properties > Security Schemes > clic sur le picto + > vous pouvez alors sélectionner le type de sécurité : API_KEY ; HTTP ; OAUTH2 ; OPEN_ID_CONNECT. Il est possible d’en cumuler.

 

 

Création d'un système d'authentification et d'autorisation OAUTH2 (Open AUTHorization)
et par token JWT (JSON Web Token) pour le micro-service DossierSinistre.

 

Sécurité d’une opération ou d’un service

• Dans le diagramme Component Contract sélectionner une opération ou un service (toutes ses opérations seront sécurisées) > Properties > Security > + > sélectionner parmi les schémas de sécurité > Add

 

 

Ici, la sécurité est configurée sur l'opération creerSurvenance.

Une clé rouge indiquera que l’opération est sécurisée.

 

Traçabilité des exigences
avec les composants et leurs opérations

 

Contrairement aux DTO qu’on ne peut pas lier aux entités métier définies à l’extérieur du modèle SOA, vous avez la possibilité de lier vos services à des exigences définies dans le modèle Requirement Model. Les générateurs de code en tiendront compte.

 

• Sélectionner le composant (micro-service), un service (interface du composant) ou une opération de l’interface dans le diagramme Component Contract > onglet Linked Requirements > picto jaune Link Requirements with Selection > sélectionner des exigences dans la fenêtre Link Requirements.

 

Une clé jaune apparaîtra alors sur l’opération.

 

 

La clé jaune en bas du service SurvenanceService indique qu'il est lié à des exigences du Requirement Model. Pour les visualiser, il suffit de sélectionner le service et l'onglet Linked Requirements. 

 

 

 

Sur le conteneur, une clé grise apparaît lorsque toutes les opérations ne sont pas liées à des exigences, sinon une clé jaune sera visible. Ici, seule l'opération creerSurvenance est liée à des exigences.

 

A lire >

 

• Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

 

Conclusion

Que ce soit une architecture micro-services ou Web Services, vous pourrez la modéliser simplement avec ISD qui, une fois de plus, a laissé de côté la complexité des normes comme UML pour laisser la place à l’efficience et au pragmatisme. 

En tant qu’architecte logiciel, vous y trouverez votre compte en créant des cartographies représentant les composants applicatifs, avec leurs échanges basés sur un système d’interfaces fournies et requises, indépendamment de leur implémentation technique. Vous pourrez documenter toutes les spécifications, comme le protocole de transfert, REST ou SOAP, le format d’échanges de données, JSON ou XML, les DTO, les opérations avec leurs paramètres d’entrée/sortie, les traitements exceptionnels, les politiques de sécurité, sans oublier la traçabilité avec les exigences.

 

Réaliser la modélisation détaillée des composants de votre architecture micro-services permet d’étudier précisément les impacts que des changements auraient sur le reste du système. Ensuite, il vous faudra prendre de la hauteur et la décrire de manière globale, afin de l'intégrer dans le SI et alimenter votre patrimoine existant. En effet, une fois cette modélisation finalisée avec ISD, vous pourrez l'importer dans SmartEA, l’outil d’architecture d’entreprise d’Obeo. La notation utilisée est ArchiMate, le standard de l’Open Group. Ce langage de modélisation est spécialisé dans la cartographie des applications d’un SI, mais également de l’infrastructure technique sur laquelle elles sont déployées (logiciels, serveurs, etc.). Il fournit aussi le moyen de modéliser plus largement l’entreprise (son organisation, sa stratégie, ses processus), de manière à décrire à quels besoins répond le SI et ainsi vérifier son alignement métier.

 

Cette interopérabilité offre une totale collaboration entre l’ensemble des acteurs d’un projet de réalisation d’une application, des experts métier jusqu’aux concepteurs/développeurs, en passant par les business analysts et les architectes logiciel.

Après avoir présenté Obeo ISD (S.1 Ep.1), abordé la méthode d’analyse Graal (S.1 Ep.2), la traçabilité des exigences avec les user stories, la cinématique et les maquettes d'écrans (S.1 Ep.3) et modélisé une architecture SOA micro-services ou Web Services (S.1 Ep.4), il nous restera, pour atteindre le Graal, à voir comment ISD peut générer le code de l’application. Nous verrons entre autres la modélisation des entités persistantes, les MLD (Modèle Logique de Données), les MPD (Modèle Physique de données), la génération et l’exécution de scripts SQL.

 

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.

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

 

 

 

 

 

“ Ce n'est pas sa beauté, sa force et son esprit que j'aime chez une personne,
mais l'intelligence du lien qu'elle a su nouer avec la vie. “
Christian Bobin