urbanisation-si.com

urbanisation-si.com

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

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

 

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

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

   

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

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

 

  • Stratégique - Long terme, de l'ordre de 3 à 5 ans,
     
  • Tactique - Moyen terme, de l'ordre de 1 à 2 ans,

  • Solution - Court terme, de l'ordre de 6 à 12 mois.

  

Les architectures Stratégiques

  

togaf-exemple-strategie-tactique-solution-02

  

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

  

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

 

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

  

balanced-scorecard

    

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

    

 

Les architectures Tactiques

  

togaf-exemple-tactique-solution-03

  

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

  

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


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


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

  

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

roadmap-diagramme

  

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

     

Les architectures de Solutions

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


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


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


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


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


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


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


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

 

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

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

  

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

  

bmm-business-motivation-model-exemple

  

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

  

Et l'apport d'ArchiMate ?

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

  

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

  

Strategic-Intent-Goal

  

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

 

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

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

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

  

traceability-relationship-matrix-relationship-view-simple

  

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

    

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

  

traceability-window-usecase-server

  

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

  

Conclusion

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


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

  

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

  

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

Alain

  

Compléments de lecture

BMM (Business Motivation Model)

 

ArchiMate

 

Outils d'Architecture d'Entreprise

 


08/12/2022
0 Poster un commentaire

Comment vérifier un modèle ? Exemple de simulation d’un processus métier BPMN

La simulation de modèle donne vie à vos modèles dynamiques grâce à une exécution instantanée et en temps réel. 
Couplé avec des outils pour gérer les déclencheurs, les événements, les contraintes, les règles, les points d'arrêt et les variables de simulation, ainsi que la possibilité de suivre visuellement l'exécution, le simulateur est un moyen puissant de regarder les roues tourner et de vérifier l'exactitude de vos modèles. 

 

theorie-modelisation-simulation

 

(“Theory of Modeling and Simulation” Bernard P. Zeigler)

 

Objectifs de la simulation de modèle

Le principe fondamental de la simulation de modèle est la séparation du modèle et du simulateur. 

 

Le simulateur est défini comme un moteur de règles qui, en fonction d’un référentiel de règles, exécute un modèle qui sert à l’analyse du comportement. 

La relation de simulation permet de vérifier qu’en obéissant aux règles définies dans le modèle de simulation, le simulateur reproduit le comportement spécifié.

Le cadre expérimental spécifie les conditions d’observations du système et les objectifs de la simulation. 

Le système source (le système à modéliser) est une spécification et il peut être réel ou virtuel : il constitue la source de données observables.

Ces données observables forment la base de données de comportement. 

La relation de modélisation permet ainsi d’établir la validité de l’expérience.

 

La simulation a comme objectifs de :

  • tester une hypothèse du modèle du système de référence, de le vérifier ou d’accréditer la théorie qui a servi à le construire,

  • montrer l'aspect dynamique du système de référence,

  • comprendre le fonctionnement du système de référence, en considérant le modèle comme une réplique miniature, qui pourra être étudiée plus facilement,

  • prévoir les évolutions possibles du système de référence en fonction d’évolutions ou de perturbations spécifiques,

  • reproduire artificiellement le fonctionnement d’un système,

  • valider ou d’invalider des hypothèses, 

  • obtenir des informations quantitatives,

  • valider certaines approximations, 

  • évaluer la sensibilité d’un modèle à certaines hypothèses ou à certains paramètres,

  • explorer le comportement d’un système lorsque celui-ci est mal connu ou incompris.

 

 

BPSim

Le WfMC (Workflow Management Coalition) a réalisé la norme BPSim. 
Il définit une spécification pour le paramétrage et l'échange de données d'analyse de processus permettant l'analyse structurelle d'un modèle de processus, permettant l'optimisation de la pré-exécution et de la post-exécution.

BPSim se compose d'un métamodèle et d'un format d'échange pour faciliter la sauvegarde et le transfert de ces données entre différents outils.
Le métamodèle BPSim est réalisé en UML et le format d’échange en XSD.

 

 

Exemple pratique de simulation d’un processus BPMN avec l’outil Enterprise Architect

Environnement prérequis


JRE/JDK Java 8 (version supérieure non testée).
Enterprise Architect (EA) 15.2 (version d’évaluation Ultimate) Sparx Systems

 

 

Modèle BPMN utilisé dans notre illustration de simulation

Conception du modèle BPMN dans EA

Le but est d’illustrer concrètement une simulation BPSim, le modèle BPMN inclut les éléments les plus utilisés sous forme générique.

Comme nous l’avons vu en théorie, on doit relier le simulateur externe au modèle.

Avec EA, il  suffit que le modèle BPMN et l'artefact "Business Process Simulation" de la toolbox se trouve dans un même package. Ainsi à l'exécution de cet artefact correspondant au simulateur, EA trouvera automatiquement le modèle BPMN. 

 

1) Créer un nouveau projet, par exemple “bpsim-simulation-bpmn.eapx”.

 

2) Puis, dans le “root node Model ”, créer un package (clic droit Add View, Package Only), par exemple “BPSim-Simulation-BPMN”.

 

3) Dans ce package, clic droit, Add Diagram, Type : BPMN, BPMN 2.0, Diagram Types : Collaboration.

Au message, sélectionner “Create this Diagram within a new Collaboration Model”, conserver le nom par défaut.

 

Pour cette démonstration, nous prendrons un modèle BPMN générique, comportant 2 pools (P1 et P2), envoi et réception de messages entre les 2, et à l’intérieur de chacun, des séquences d’activités avec des gateways, ce qui peut déjà correspondre à bons nombres de cas réels :

 

modele-bpmn-utilise-pour-la-simulation-bpsim

 

 

Illustration pratique de la simulation

Objectifs

Pour cette illustration BPSim, nous prendrons un entier n, initialisé à 10 au début et qui sera modifié par les activités en ajoutant des valeurs constantes.

 

Les branches des gateways exclusives seront des conditions selon que n soit supérieur ou égal ou bien strictement inférieur à une valeur donnée.
Pour visualiser le chemin parcouru et les activités traversées, nous initialisons le simulateur avec un contrôle de type TriggerCount.
Le TriggerCount définit le nombre de fois que l'objet ou le connecteur doit être traité pendant une exécution de la simulation, de sorte que le cycle de traitement correspond à la demande type pour une chaîne d'actions particulière.

Il est généralement défini pour les éléments Start Event.
Ce TriggerCount définit le nombre de fois que l'élément ou le connecteur doit être traité dans une simulation normale ou personnalisée.

La matérialisation des artefacts activés par la simulation se fait par l’affichage en rouge de la valeur du TriggerCount sur chaque élément traversé. 

 

Création du simulateur BPSim

On a vu précédemment qu'il faut ajouter l'artefact "Business Process Simulation".

 

Sélectionner le package “BPSim-Simulation-BPMN” > Toolbox > Artifacts > Drag & Drop de "Business Process Simulation" dans le package, laisser le nom par défaut > double cliquer dessus pour ouvrir la fenêtre “Configure BPSim”

 

business-process-simulation-fenetre

 

 

L’onglet “Configure” est sélectionné, laisser les valeurs par défaut. 


Ces valeurs représentent :

  • la date de démarrage,
  • la durée qui doit être supérieure à la durée estimée, ici 999 Days, 
  • l’unité de temps (ici minute),
  • le nombre de réplications (1), 
  • la valeur d’initialisation du générateur aléatoire (n’est pas utilisé ici),
  • le langage d’expression (XPath) pour analyser le XML représentant textuellement le modèle BPMN grâce à la norme XMI,
  • les répertoires d’installation de Java 8 (JRE/JDK),
  • le port de communication du simulateur (1799), attention à que ce port ne soit pas déjà occupé.
  • un timestamp.

 

Paramétrage des éléments de modélisation

Dans le pool P1

1) Sélectionner Debut1 > Configure BPSim > onglet Configure > Category > sélectionner Control > dans la colonne à coté Parameter, sélectionner TriggerCount > et enfin dans la colonne Values, saisir 1

 

configuration-debut1-TriggerCount

 

2) Ajouter une propriété n de type entier (int)

Cliquer sur l'icône "Properties" > New Property, saisir n, puis dans Type, sélectionner int

 

configure-bpsim-configure-propriete

 

3) Sélectionner Debut1 > Configure BPSim > onglet Configure >

Category > en dessous de Control, New Parameter, sélectionner Property > n > pour la valeur, cliquer sur le bouton … à droite,  saisir 10 dans Expression

 

configuration-debut1-property-n

 

 

4) De la même manière, sélectionner Activite1 et compléter les 3 colonnes :
Property > n > Values > …. > Expression {n} + 100

 

5) Sélectionner le sequence flow de Passerelle1 à Fin1 
Control > Condition > Values > …. > Expression {n} >= 50

 

6) Sélectionner le sequence flow de Passerelle1 à Fin2 
Control > Condition > Values > …. > Expression {n} < 50

 

Dans le pool P2

7) Sélectionner Activite2 :
Property > n > Values > …. > Expression {n} + 10

 

8) Sélectionner le séquence flow de Passerelle2 à Activite3 
Control > Condition > Values > …. > Expression {n} >= 15

 

9) Sélectionner le séquence flow de Passerelle2 à Activite4 
Control > Condition > Values > …. > Expression {n} < 15

 

10) Sélectionner Activite3 :
Property > n > Values > …. > Expression {n} + 10

 

11) Sélectionner Activite4 :
Property > n > Values > …. > Expression {n} + 1

 

Sauvegarde de la configuration

Cliquer sur l’icône disquette.

 

Pour vérification, cliquer sur l’icône Property (point bleu), vous devez obtenir toutes les propriétés et les conditions appliquées sur les différents éléments du modèle BPMN :

 

fenetre-proprietes-et-conditions-de-la-simulation-bpsim

 

 

Exécution de la simulation BPSim

Dans la partie “Configure BPSim”, sélectionner l’onglet Execute, puis la première icône en dessous à gauche (Run Simulation)

 

 

execution-de-la-simulation-bpsim-du-modele-bpmn

 

Une fois la simulation terminée, vous pouvez arrêter l'affichage, en cliquant sur l'icône représentant un carré (Stop). L'affichage des "TriggerCount" disparaît.

 

Explication :

 

EA indique les éléments activés, accompagnés d’un "1" rouge (TriggerCount 1) et en sombre les autres.

 

Si l'on vérifie manuellement :

  1. P1
  2. n = 10 on envoie n dans P2
  3. Activite1 n = 10 + 100 = 110
  4. P2 reçoit n = 10
  5. Activite2 n = 10 + 10 = 20
  6. Comme n >= 15, on arrive dans Activite3 : n = 20 + 10 = 30
  7. On envoie n dans P1
  8. P1 reçoit n = 30
  9. Comme n < 50, on termine dans Fin2.

 

Exécution pas à pas de la simulation

 

Pour suivre pas à pas l'exécution de la simulation à des fins par exemple de mise au point, il suffit de sélectionner l'onglet Step, pour trouver les boutons de démarrage, d'avancement, de pause et d'arrêt.

 

On peut aussi (3 ème icône en partant de la droite), générer un diagramme de timing et juste à coté, celle pour générer un fichier CSV.

 

A noter que l'onglet Review permet de générer des rapports.

 

 

execution-pas-a-pas-de-la-simulation-bpsim-du-modele-bpmn

 

Validation du modèle BPMN

A côté de la disquette, on peut cliquer sur l’icône de validation, ce qui ouvre un nouvel onglet “System Output”

 

validation-de-la-simulation-bpsim-et-du-modele-bpmn

 

Conclusion

Le simulateur BPSim d’Enterprise Architect nous a permis de voir concrètement une exécution d’un modèle auquel on a associé aux éléments des propriétés, instructions et conditions.

Bien sûr, le simulateur d’EA possède de nombreuses distributions de probabilités (Binomial, Erlang, Gamma, Normal, Poisson, TruncatedNormal, Uniform…) permettant d’avoir des scénarios proches de la réalité.Les ressources, rôles (acteurs), peuvent être associées à des minis-écrans interactifs. 

Enfin, des calendriers permettent de planifier et gérer les durées et le déclenchement des activités pour plus de réalisme.


Le simulateur supporte aussi la norme DMN (Decision Model and Notation) pour la modélisation des règles métier.

Et pour être complet, on pourrait simuler un processus BPMN avec des tâches de type “Business Rule” qui seraient par exemple un modèle DMN avec des tables de décision et des règles de calculs.

 

N’hésitez pas à partager votre expérience sur le sujet de la simulation BPMN et à nous dire quels outils vous utilisez en postant un commentaire à la fin de cet article.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 


Il dit non avec la tête
mais il dit oui avec le cœur

et malgré les menaces du maître
sous les huées des enfants prodiges
avec les craies de toutes les couleurs
sur le tableau noir du malheur
il dessine le visage du bonheur.

 "Le cancre", Jacques Prévert

 

 

Pour en savoir plus sur 

BPMN

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

 

BPMN pour les nuls : les collaborations

 

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

 

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

 

BPMN

 

 

DMN

DMN - L'antisèche de la notation complète des composants d'un DRD (Decision Requirement Diagram) : notation de la décision

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions

 

DMN

 


01/12/2022
0 Poster un commentaire

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

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

question-mark-gc469bb40d_1280

 

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

 

"The Software Architect Elevator"

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

 

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

 

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

 

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

 

Le modèle en strates du Cigref

 

 

Les strates de l'urbanisation, selon le Cigref

 

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

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

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

 

Questions techniques

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

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

On pourra distinguer deux niveaux :

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

 

processus-urbanisation-du-si 

Macro-processus de l'urbanisation du SI

 

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

bpmn-exemple-01

 

Exemple de diagramme de collaboration BPMN

 

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

 

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

 

Exemple de cartographie fonctionnelle du SI

 

Comment définir et accompagner la trajectoire ?

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

 

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

 

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

Frugalité

 

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

 

Sobriété

 

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

 

Sécurité

 

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

 

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

 

Résilience

 

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

 

Questions organisationnelles

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

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

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

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

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

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

  • Piloter l'urbanisation du SI et communiquer.

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

 

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

 

Questions existentielles

Quels sont les apports ?

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

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

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

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

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

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

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

 

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

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

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

 

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


Qui suis-je ?

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

ia-architecture-entreprise-hal

 

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

 

Architecte de la chaîne de valeur

 

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

 

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

 

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

 
Catalyseur de cohérence

 

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

 

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

 

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

 

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

 

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

 

Architecte d'Entreprise augmentée

 

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

 

La gouvernance doit constamment faire de la prospective, afin de maintenir ses informations sur l’IA, devenue un domaine hautement stratégique. Le rôle de l’architecte d’entreprise peut être renforcé par celui d’un architecte des données (CDO Chief Data Officer) au service de la création de valeur et donc de l’IA.

 

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

 

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

 

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

 

 

urbanisation-si_logo

 

Thierry Biard

& Rhona Maxwel

urbanisation-si.com

 

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

 

 

Compléments de lecture

 


22/11/2022
0 Poster un commentaire

Autonomic Computing ou Informatique Autonome, est-elle une informatique visionnaire ?

L'informatique autonome aide à réduire la complexité en utilisant la technologie pour gérer la technologie. Dans cet environnement, les systèmes sont capables de s’adapter dynamiquement au changement des politiques métier.

 

autonomic-computing-informatique-autonome-00 

Les enjeux de l'Informatique Autonome.

 

Similaire au corps humain ?

Le terme autonome est dérivé de la biologie humaine. Inconsciemment, le système nerveux autonome surveille votre rythme cardiaque, vérifie votre niveau de glycémie et maintient votre température corporelle proche de 37 °C, sans aucun effort de votre part.
De la même manière, l'informatique autonome anticipe les exigences du système informatique et résout les problèmes sans intervention humaine. Les professionnels de l'IT peuvent se concentrer sur des tâches à plus forte valeur ajoutée pour l'entreprise.

 

Cependant, il existe une distinction importante entre l'activité autonome dans le corps humain et les activités autonomes dans les systèmes informatiques : de nombreuses décisions faites par les capacités autonomes du corps humain sont involontaires. En revanche, les capacités autonomes dans les systèmes informatiques effectuent des tâches que les informaticiens choisissent de déléguer à la technologie, conformément à la gouvernance en place.
Un moteur de règles, plutôt qu'une procédure codée en dur, détermine les types des décisions et des actions que les composants autonomes effectuent. 

 

Introspection

Le système autonome se connaît :

  • Il connaît ses composants, leurs spécifications, leurs capacités et leurs états en temps réel.
  • Il a également des connaissances sur ses ressources propres, empruntées et partagées.
  • Il peut se configurer encore et encore et exécuter sa configuration automatiquement
    au fur et à mesure des besoins.
  • Il a la capacité de s'optimiser en ajustant les flux de travail.
  • Il peut se réparer, il peut se remettre des échecs.
  • Il peut se protéger en détectant et en identifiant diverses attaques à son encontre.
  • Il peut s'ouvrir. Cela signifie qu'il ne doit pas s'agir d'une solution propriétaire
    et doit implémenter des standards ouverts.
  • Il est invisible. Cela signifie qu'il a la capacité de permettre l'optimisation des ressources,
    en masquant sa complexité.

 

Un système autonome, selon IBM, doit être capable de savoir ou d'anticiper le type de demande qui va survenir pour ses ressources.

Les capacités d'auto-gestion d'un système accomplissent leurs fonctions, en prenant une action appropriée selon une ou plusieurs situations qu'ils perçoivent dans l'environnement. La fonction de toute capacité autonome est une boucle de contrôle, qui collecte les détails du système et agit en conséquence. 

Ces boucles de contrôle sont organisées en quatre catégories : auto-configuration, auto-réparation, auto-optimisation et auto-protection.

 

Auto-configuration

Les composants auto-configurables s'adaptent dynamiquement aux changements de l'environnement, en utilisant les règles fournies par les informaticiens.

De tels changements pourraient inclure le déploiement de nouveaux composants ou la suppression de ceux existants, ou des changements importants dans les propriétés du système. L'adaptation dynamique assure une productivité constante de l'infrastructure informatique, ce qui entraîne une croissance et une grande flexibilité de l'entreprise.

 

Auto-réparation

Cette propriété permet de découvrir, diagnostiquer et réagir aux perturbations.
Les composants d'auto-réparation peuvent détecter les dysfonctionnements du système et initier des actions correctives basées sur des règles, sans perturber l'environnement informatique. Une action corrective peut impliquer qu'un composant modifie son propre état ou effectue des changements sur les autres.

Le système dans son ensemble devient plus résilient, parce que les opérations quotidiennes sont moins susceptibles d'échouer. 

 

Auto-optimisation

Les ressources sont surveillées et réglées automatiquement pour une efficience optimale. 
Les composants d'auto-optimisation peuvent s'adapter pour répondre à l'utilisateur final ou aux besoins de l'entreprise. Les actions de réglage peuvent être la réallocation des ressources - par exemple en réponse à des augmentations des charges de travail - pour améliorer les temps de réponse des processus métier.

 

Auto-protection

Les menaces sont anticipées, détectées, identifiées et les parades sont mises en place.
Les composants auto-protégés peuvent détecter des comportements suspects au fur et à mesure qu'ils se produisent et prendre des contre-mesures, pour se rendre moins vulnérables par exemple aux accès non autorisés, à l'infection et à la prolifération de codes malveillants, ainsi que les attaques par déni de service.

Les capacités d'auto-protection permettent aux entreprises d'appliquer systématiquement des politiques de sécurité et de confidentialité.

 

Intégration dans ITIL

Les entreprises informatiques organisent ces tâches sous la forme d'un ensemble de meilleurs pratiques et processus, tels que ceux définis dans ITIL (Information Technology Infrastructure Library).

 

Traditionnellement, la détection d’un dysfonctionnement nécessite la mise en œuvre d’une procédure fastidieuse : il faut créer la demande de correction, recueillir les détails de l'incident et suivre l’évolution de l’état du ticket d’anomalie sur une plateforme. 
Dans un système auto-géré, les composants peuvent initier ces étapes en fonction des informations provenant directement du système. Cela aide à réduire les tâches manuelles et le temps nécessaire pour répondre aux situations critiques.


Dans un processus de gestion des problèmes, une des étapes est le diagnostic. Dans les systèmes auto-gérés, les ressources sont créées telles que l'expertise requise pour effectuer cette tâche puisse être encodée dans le système et ainsi puisse être automatisée. 

 

La plus-value client

L'efficience des processus informatiques typiques est mesurée à partir du temps écoulé pour terminer un processus, le pourcentage exécuté correctement et le coût d'exécution d'un processus. 
Les systèmes auto-gérés peuvent affecter positivement ces métriques, améliorant la réactivité et la qualité de service, en réduisant le coût total de possession (TCO) et en améliorant le délai de rentabilité. 

 

L'informatique autonome est nécessaire pour surmonter le problème de la complexité accrue :

  • des systèmes distribués, dont les prévisions tablent sur une croissance de 40 % par an,
  • des applications qui doivent s'adapter au travail en distanciel.

 

Architecture de l'Autonomic Computing

 

autonomic-computing-informatique-autonome-architecture-02 

Les couches de l'Architecture de l'Autonomic Computing

 

L'architecture AC (Autonomic Computing) comprend des propriétés qui permettent l'auto-gestion selon divers fournisseurs, en impliquant des boucles de contrôle qu'un fournisseur de ressources intègre dans l'environnement d'exécution.

 

  1. Éléments gérés (Managed Resources) : l'élément géré est un composant du système contrôlé. Il peut s'agir aussi bien d'une ressource matérielle que d'une ressource logicielle. Des capteurs et des effecteurs sont utilisés pour contrôler l'élément géré.
  2. Capteurs (Touchpoint) : fournissent des informations sur l'état et tout changement d'état
    des éléments du système autonome.
  3. Effecteurs (Touchpoint Autonomic Managers) : ce sont des commandes ou interfaces de programmation d'applications (API) qui sont utilisées pour changer les états d'un élément.
  4. Gestionnaire autonome (Orchestrating Autonomic Managers) : utilisé pour s'assurer que les boucles de contrôle sont mises en œuvre. Celui-ci divise la boucle en 4 parties pour son fonctionnement. Ces parties sont : surveiller, analyser, planifier et exécuter -
    MAPE (Monitor, Analyze, Plan, Execute).
  5. Interface Utilisateur (Manual Manager) : l'environnement d'exécution est configuré à l'aide d'une interface de gestion fournie pour chaque ressource, par exemple des moyens de stockage.

 

autonomic-computing-informatique-autonome-architecture-ressources-gerees03 

Architecture MAPE (Monitor, Analyze, Plan, and Execute) : surveiller, analyser, planifier et exécuter

 

Exemples

  • Exécution d'une tâche d'auto-configuration telle que l'installation d'un logiciel
    lorsqu'il détecte que certains logiciels prérequis sont manquants.
  • Exécution d'une tâche d'auto-réparation telle que la correction d'un chemin configuré
    afin que les logiciels installés puissent être correctement localisés
  • Exécution d'une tâche d'auto-optimisation telle que l'adaptation de la CPU
    lorsqu’elle constate une augmentation des transactions.
  • Exécuter une tâche d'auto-protection telle que mettre des ressources hors ligne
    en cas de détection d’une tentative d'intrusion.

 

Conclusion

L'Autonomic Computing nécessite 3 conditions :

  • Automatique : le système doit pouvoir exécuter ses opérations sans intervention humaine.
  • Adaptatif : les ordinateurs autonomes doivent pouvoir apporter des modifications en fonction de leur environnement et d'autres conditions imprévues, telles que les attaques de sécurité et les pannes du système.
  • Conscient : il doit également avoir connaissance des processus et des états internes
    qui permettraient d'exécuter les deux fonctionnalités précédentes.

 

 Avantages

  • Open Source
  • C'est une technologie évolutive qui s'adapte aux nouveaux changements.
  • Donne donc une meilleure efficacité et de meilleures performances.
  • Sécurisé, peut contrer automatiquement des attaques.
  • Dispose de mécanismes de sauvegarde qui permettent la récupération après les pannes
    et le
    plantage du système.
  • Réduit le coût de possession (TCO) d'un tel mécanisme, car il est moins sujet aux pannes
    et peut se maintenir automatiquement.
  • Il peut se configurer lui-même, réduisant ainsi le temps nécessaire
    à la configuration manuelle.

 

Inconvénients

  • Il y aura toujours une possibilité de plantage ou de dysfonctionnement du système.
  • Impact sur l'emploi pour certaines professions.
  • Le système coûte plus cher.
  • Besoin de compétences hautement qualifiées pour gérer ou développer de tels systèmes, augmentant ainsi le coût pour l'entreprise qui les emploie.
  • Dépendant de la bande passante réseau et donc pas forcément disponible partout.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

"Sur tous les sujets, des opinions contradictoires se font face, et la plupart d’entre nous n’ont pas les outils nécessaires pour savoir laquelle est la bonne."

Yuval Noah Harari

 

Compléments de lecture

 


08/11/2022
0 Poster un commentaire

TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?

Un cadre de sécurité pour les entreprises doit permettre de maintenir un état des risques maîtrisé, correspondant à un comportement sécurisé, résilient, fiable et respectueux de la vie privée. Quel est le rôle de l'architecte d'entreprise avec la version 10 de TOGAF et son architecture de sécurité ?

  TOGAF-10-nouveautes-securite-risques-04-2  

Relation entre TOGAF et l'ISM/ERM, source The Open Group

 

TOGAF 10 plus facile à lire ?

Avec la version 10 de TOGAF, The Open Group (https://www.opengroup.org/) a restructuré le contenu de l'architecture d'entreprise pour améliorer la lisibilité, l’utilisabilité et la maintenabilité. La solution retenue a été de développer la modularité du contenu.

Bonne nouvelle, la taille de la partie standard de TOGAF est passée de 692 (version 9.1) à 532 pages et ne contient que du contenu pérenne.

La structure de TOGAF 10 ressemble à des poupées russes.

 

TOGAF-10-nouveautes-resume-structure-oignon-01 

TOGAF Fundamental est la partie stable, tandis que les guides évolueront, source The Open Group

 

Le socle de TOGAF 10, très stable, se trouve dans la partie fondamentale, les guides et la bibliothèque rassemblent des aspects plus pratiques et peuvent évoluer au cours du temps.

 

TOGAF-10-nouveautes-resume-documentation-structure-02 

Détails de l'organisation de TOGAF 10, source The Open Group

 

Bonnes pratiques

Pour une véritable intégration de la sécurité dans l'architecture, une approche d'ingénierie système doit être utilisée. Cela signifie que la sécurité et les risques sont pris en compte le plus tôt possible dans le cycle de vie du développement de l'ingénierie système du sujet en question. À chaque phase du cycle de vie du développement, des activités appropriées, liées à la sécurité et aux risques, sont menées. Ces activités peuvent aller de conseils et d'orientation de haut niveau dans les premières phases, à des contrôles de sécurité détaillés dans la phase finale. De cette manière, un système opérationnel sécurisé peut être réalisé, en étant fiable, sûr, résilient et respectueux des préoccupations de confidentialité. 

 

L'architecture de sécurité d'entreprise cherche à aligner les mesures de sécurité sur les objectifs métier. Pour ce faire, il définit les relations entre les composants sur les différentes couches d'architecture, assurant ainsi la traçabilité et la justification. L'architecte de sécurité d'entreprise utilise généralement les processus ISM (Information Security Management) et ERM (Enterprise Risk Management) pour développer les livrables et interagir avec les parties prenantes.

 

Qu’est-ce qu’un risque ?

D’après la norme ISO 31000:2009, un risque est l'effet que l'incertitude a sur la réalisation des objectifs de l'entreprise. L'incertitude concerne la prédiction des résultats futurs, compte tenu de la quantité limitée disponible d'informations imparfaites lors de la prise de décision métier. 

  TOGAF-10-architecture-securite-iso-31000-2009-06-3   

Gestion des risques, norme ISO-31000:2009

 

La norme ISO 31000:2009 indique clairement que la gestion des risques doit être profondément et fermement ancrée dans toutes les activités métier. Elle indique également qu'il s'agit d'un cycle de vie continu plutôt que d'une activité isolée.

Chaque décision est basée sur :

  • l'évaluation de l'équilibre entre les opportunités et les menaces potentielles,
  • la probabilité de résultats bénéfiques par rapport aux résultats préjudiciables,
  • l'ampleur de ces évènements potentiels, positifs ou négatifs,
  • la probabilité associée à chaque résultat identifié. 

 

L'identification et l'évaluation de ces facteurs sont appelées “évaluation des risques” ou “analyse des risques”. La gestion des risques est l'art et la science d'appliquer ces concepts dans le processus de prise de décision. Le risque peut être vu au niveau stratégique à long terme (direction générale de l'entreprise), au niveau tactique à moyen terme (projets et programmes de transformation) et au niveau opérationnel (décisions, processus métier). L'objectif de la gestion des risques est d'optimiser les résultats métier, afin de maximiser la valeur métier et de minimiser les pertes. Le risque peut être vu à n'importe quel niveau de l’architecture métier, mais est toujours guidé de haut en bas, par l'évaluation de la valeur métier et son optimisation.

 TOGAF-10-architecture-securite-architecture-metier-05 

Risques métier et cyber-risques source The Open Group

 

La triade CIA

Pour de nombreux experts, la sécurité repose sur trois piliers fondamentaux :

  • la confidentialité,
  • l'intégrité,
  • la disponibilité.

 

Ces 3 notions sont également connues sous le nom de triade CIA avec une classification (élevé-moyen-faible), surtout omniprésente dans le domaine de la finance. A part pour James Bond 007, ces termes complexes englobant trop de significations sont peu utilisés par les dirigeants d’entreprise, préférant parler par exemple d’autorisations d’accès à des fonctionnalités.

 

Pour se recentrer sur les entreprises, TOGAF 10 a intégré le modèle SABSA (Sherwood Applied Business Security Architecture)

 

Quel outil pour les architectes sécurité ?

 

TOGAF-10-et-sabsa-couches-architecture-07 

Le modèle en couches SABSA (Sherwood Applied Business Security Architecture),
source https://sabsa.org/

 

Dans un contexte TOGAF 10, en collaboration avec l’architecte d’entreprise, l’architecte sécurité pourra s’appuyer sur l’architecture SABSA. Son modèle en couches, centré sur les risques, est aisément modulable. 


La méthodologie donne plusieurs visions : 

  • contextuelle - métier (le décisionnaire), 
  • conceptuelle (les objectifs et les risques), 
  • logique (informations, processus, applications, interactions), 
  • physique (données, mécanismes de transfert, infrastructure), 
  • composants (outils, produits, technologies, standards),
  • une vision transverse avec les services de sécurité. 

 

SABSA comprend une vue pour les processus d’audits et de contrôles indépendants. 

 

Pour chaque couche, on doit répondre aux questions Quoi ? Pourquoi ? Comment ? Qui ? Où ? Quand ? A noter que ce questionnement de Quintilien est aussi utilisé par un autre framework d'Architecture d'Entreprise, celui de Zachman (voir notre article Architecture d'entreprise : le framework de Zachman).

 

TOGAF-10-et-sabsa-perspectives-architecture-08 

Les perspectives de l'architecture de sécurité SABSA

 

Par exemple, on pourra déterminer les points liés à la classification de l’information, la méthode d’analyse et de traitement des risques, la cartographie des flux applicatifs et des échanges de données, les aspects IAM (Identity and Access Management), les domaines de confiance et leurs localisations.

 

Exemples de l'architecture SABSA :

  • les services d'authentification (par exemple, cas d’approbations entre les annuaires, les types d'authentification en fonction des risques ou de la sensibilité des informations)
  • la gestion de la cryptographie (l’organisation, les possibilités de gestion centralisée des clés, les types de chiffrement possibles selon les risques, les cas de pseudo-anonymisation…)
  • les cas d’évaluation de la sécurité par des audits techniques
  • l’intégration de la sécurité dans les méthodes agiles comme Scrum (répartition des rôles entre le "Product Owner", le "Scrum Master", l’équipe de développement et les experts sécurité, comment et quand intégrer la sécurité dans les réunions "Sprint Planning" et les "Daily Scrum", les standards applicables…)
  • les niveaux d’audits internes

Conclusion

Toutes les organisations, des réseaux électriques aux systèmes de combat, les entreprises privées ou publiques, les organismes de santé, tout est vulnérable face à l’arme numérique. Quelques attaques informatiques concernant des villes et des hôpitaux ont été rendues publiques, mais ce n’est que la partie émergée de l’iceberg,

Face à ces attaques, il est bon de trouver des alliés, et pour une fois il n’y a pas à choisir entre TOGAF vs SABSA, mais un seul framework TOGAF intégrant SABSA.

 

Le rôle de l'architecte d'entreprise sera alors de créer un environnement opérationnel dans lequel le risque opérationnel pourra être optimisé, pour un bénéfice métier maximal et une perte potentielle minimale.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“La chose la plus difficile est de n'attribuer aucune importance
aux choses qui n'ont aucune importance.”

Charles de Gaulle

 

Compléments de lecture

 

 

 

 


27/10/2022
0 Poster un commentaire

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.

diagrams.net ne demande rien, aucune inscription, mail ou carte de crédit. Dès que l’on clique sur “Créer un nouveau diagramme”, on découvre une liste impressionnante de types de diagrammes : Entreprise, Graphiques, Cloud, Ingénierie, Organigramme, Cartes, Réseau, UML, etc. Que demander de plus ?

diagrams-net-outil-gratuit-francais-diagramme-entreprise-02  

https://www.diagrams.net/

 

Demandons-nous d'abord ce qu’est un bon outil
pour l'architecte d’entreprise ?

Prenons l’outil numéro 1 Gartner dans la catégorie “Choix des clients Gartner® Peer Insights™” de cette année, pour les outils d'architecture d'entreprise (avec une note globale de 4,7 étoiles sur 5) : la plate-forme HOPEX de MEGA International.

 

Cette plate-forme web dispose d’un socle d’architecture d’entreprise exhaustif et ouvert supportant les standards du marché (TOGAF, ArchiMate, NAF, DoDAF, UML…). Le support de TOGAF (voir nos articles dans la catégorie TOGAF) comprend une bibliothèque de méthode décrivant l’ensemble de l’ADM (Architecture Development Method) avec les différentes phases, les entrées, les sorties, les livrables, les rôles…

 

L’architecte d’entreprise gagne un temps précieux, car il lui suffit de partir d’un modèle standard qu’il adapte au contexte. Une gestion des droits facilite la collaboration, chaque partie prenante accédant à ses vues en fonction de ses missions.

 

Des outils de demande de changement et de suivi de validation assurent la conduite opérationnelle des projets d’architecture en mode collaboratif.

 

D’autre part, MEGA propose des fonctions d’analyse et de reporting nécessaire à l’optimisation du patrimoine applicatif de l’entreprise, en lien avec la cartographie applicative et les méthodes d’urbanisation du SI. 

 

MEGA intègre les derniers paradigmes de l’architecture d’entreprise comme les approches capacitaires, les dernières méthodes d’architecture logicielle, le cloud, la modélisation systémique, la modélisation complexes comme les systèmes de systèmes.

 

Les référentiels sont interopérables, par exemple les informations gérées dans une démarche d’optimisation de processus de type Lean Six Sigma peuvent être réintégrées dans une démarche d’architecture.

 

Pour la mise en œuvre d’une transformation numérique, l'architecte d’entreprise dispose d'un ensemble d’outils comme la gestion de portefeuille applicatif, de ressources et de projets, mais aussi de gouvernance, de gestion de risques et de mise en conformité des opérations.

 

Et en ce qui concerne diagrams.net ?

Absolument rien de tout cela : juste un très bon outil de dessin, couvrant la plupart des normes et standards du spectre de la schématisation de systèmes.

 

Voici une liste à la Prévert des rendus de la plupart des types de diagrammes :

 

Pour les architectes d'entreprises : ArchiMate diagrams-net-outil-gratuit-francais-diagramme-archimate-03 

Exemple de diagramme ArchiMate

 

Pour les experts métier : BPMNdiagrams-net-outil-gratuit-francais-diagramme-bpmn-04  

Rendu des évènements BPMN

 

Pour les concepteurs et les développeurs : UML   diagrams-net-outil-gratuit-francais-diagramme-uml-sequence-06

UML, exemple de diagramme de séquence

 

diagrams-net-outil-gratuit-francais-diagramme-uml-activite-07  

UML, exemple de diagramme d’activité

 

Pour les spécifications des systèmes industriels complexes : SysMLdiagrams-net-outil-gratuit-francais-diagramme-sysml-exigence-08 

SysML, exemple de diagramme d'exigence

 

Pour les directions opérationnelles : Ishikawa

diagrams-net-outil-gratuit-francais-ishikawa11 

Exemple de cartographie de dépendances d'objectifs

 

Pour la prise de notes rapide : Mind Mappingdiagrams-net-outil-gratuit-francais-mind-mapping12 

Exemple de cartes mentales

 

Pour les infographistes et les développeurs frontend : Maquette d'écran

diagrams-net-outil-gratuit-francais-maquette-ecran13 

Template montrant les possibilités de maquettage d'écran

 

Pour les chefs de projets : Gantt et PERT

diagrams-net-outil-gratuit-francais-gantt-10 

Exemple de diagramme de Gantt

 

diagrams-net-outil-gratuit-francais-pert-10-bis 

Exemple de diagramme PERT

 

Pour les concepteurs et les développeurs : Git

diagrams-net-outil-gratuit-francais-git-09 

Exemple de représentation des différentes versions d'une application
suivi par le SCM (Source Control Management) Git

 

Pour le DevOps : Cloud AWS

diagrams-net-outil-gratuit-francais-diagramme-aws-05 

Les fonctionnalités d'un système dans le cloud Amazon Web services

 

Pour les architectes logiciel : Architecture Micro-Services

diagrams-net-outil-gratuit-francais-ibm-microservices-14 

Architecture Micro-Services vue par IBM

 

Conclusion

Son mode cloud, sa version française, son entière gratuité et l’accès instantané aux diagrammes ne demandant aucune authentification en font un excellent outil pédagogique pour illustrer les types de diagrammes utilisés par les architectes d’entreprise, les chefs de projet, les architectes logiciels, les concepteurs/développeurs, les MOA…

 

Vraiment dommage que diagrams.net ne possède pas un mode collaboratif comme Visual Paradigm ou une exhaustivité et une expertise dans les normes de modélisation de système comme GenMyModel.

 

diagrams.net, comme tous les outils de dessin, ne possède pas de référentiel d'objets d'architecture, pour réutiliser les mêmes objets dans plusieurs diagrammes. Avec la version locale appelée draw.io, il sera toutefois possible de copier-coller des objets d'un diagramme vers un autre. Malgré tout, diagrams.net reste une bonne alternative gratuite à d’autres standards payant comme Visio.

 

Cet outil conviendra donc parfaitement aux étudiants, voire aux consultants pressés. 

 

Note : 2,5/5

Nous regrettons :

- pas de mode collaboratif

- l’ergonomie moindre que celle de la concurrence

- pas de mise à jour semi-automatique des diagrammes

- bibliothèque de symboles limitée

- pas de traçabilité pour les mesures d’impact

- pas de validation des diagrammes

- pas d’audit

- pas de métamodèle

 

Nous aimons :

+ pas besoin d’authentification

+ la simplicité d’utilisation

+ le nombre de points d'ancrage de connecteurs sur une forme

+ la sauvegarde automatique des diagrammes

+ le mode Cloud

+ les exemples ArchiMate, BPMN, UML...

+ les exemples de cartographies d’architecture, comme celle des micro-services

+ connecteur draw.io gratuit pour Word, Powerpoint et Excel

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“Chrétien, on aime un Dieu capable de réduire le monde à lui­-même au point de le créer ; (...) astronome, on quête l’origine de l’Univers au point de déduire son évolution du Big Bang ; mathématicien, on cherche les axiomes qui contiendraient tout le reste comme corolaires et conséquences ; philosophe, on espère trouver le fondement radical à partir duquel tout le reste n’est que phénomènes ; intellectuel, on ramène à la vie de la pensée la simple pratique et les simples opinions du vulgaire”. 

Bruno Latour

 

Compléments de lecture

 


20/10/2022
0 Poster un commentaire

Texte vers UML et autres outils de "diagrammes en tant que code" - Le moyen le plus rapide de créer vos modèles ?

Que valent les outils de modélisation "diagrams as code" ?
Écrire textuellement un modèle, puis générer les diagrammes correspondant en UML, BPMN, ArchiMate, etc. : rêve ou réalité ?

diagram-as-code-yuml-uml-diagramme-classe 

Et hop, un diagramme de classe UML dont le texte peut être mis sur GitHub (réalisé avec yuml).

 

 

 

De quoi parlons-nous ?

Au lieu de dessiner des diagrammes dans un environnement graphique, on écrit quelques lignes (en utilisant par exemple un langage de balisage) dans un fichier texte brut. Un générateur le convertit en un fichier image.
Un outil de modélisation textuelle prend donc en charge l'utilisation d’un langage à base d’une syntaxe comportant des mots clés, pour décrire des modèles logiciels et restitue automatiquement le diagramme graphique correspondant, à partir de cette description écrite. 
Ce mode de fonctionnement se fait en round-trip, c’est à dire qu’une fois le diagramme généré, le modélisateur a la possibilité d’apporter des modifications par l’intermédiaire d’un éditeur WYSIWYG, qui sont retraduites automatiquement en texte.
Ces outils de modélisation textuelle ne se concentrent pas uniquement sur UML, mais aussi sur BPMN, ArchiMate, etc.
D’autres appellations leur sont attribuées, comme diagrams as code ou outils low-code.

 

Quelle est leur place sur le marché des outils de modélisation ?

Cette catégorie d'outils textuels serait l'un des segments à la croissance la plus rapide du marché des modeleurs UML, les éditeurs ne s’y trompent pas : il suffit de regarder l’offre pléthorique ; nous en avons recensé plusieurs dizaines et en avons retenu 5, répertoriés en annexe de cet article.
Dans ses nombreux essais d’outils de modélisation, urbanisation-si.com a toujours systématisé l’UX/UI, l’efficience de l’ergonomie et les fonctionnalités proposées.
Avoir tous les artefacts de notations sous les yeux à portée de souris, des templates sur étagère, des conseils en temps réel permettant en quelques clics de cartographier un système, apportent un réel avantage sur les plans de l’utilisabilité et la rapidité d’appropriation des procédures de fonctionnement.
Alors, quelles sont les raisons qui pousseraient à décrire textuellement, puis à générer graphiquement, les modèles ?

 

Les défauts inhérents aux éditeurs WYSIWYG

Un premier problème concerne l'incohérence des éléments dont les détails divergent selon les vues.
Soit le diagramme 1, par exemple un diagramme de classes, et soit le diagramme 2, par exemple un diagramme de séquence. Que se passe-t-il si l'on copie/colle certains éléments du diagramme 1 dans le diagramme 2 et si par la suite on modifie un élément (par exemple, le nom d'une classe) présent dans les deux diagrammes uniquement dans l'un des diagrammes ? Avec de nombreux outils graphiques, on risque de se retrouver avec des vues incohérentes.

D’autre part, les modeleurs visuels UML (et autres styles) peuvent sérialiser les diagrammes en XMI (XML Metadata Interchange) conformément à la norme de l’OMG. 
A moins d’être expert en XSD (XML Schema Definition), d’avoir lu les presque 1000 pages de la technical reference UML et lire couramment XMI, le traitement manuel de ce code généré est absolument rédhibitoire et à proscrire, compte tenu de sa complexité et de son énormité et ne peut être réservé qu’à des parsers spécialisés.

 

Pourquoi s’embêter à écrire, plutôt qu’à schématiser ?

Mais pourquoi les outils de conversion de texte en UML sont-ils si populaires ? 

Qui n’a pas rêvé de pouvoir différencier toutes les versions d’un modèle ?
Le fait que les modèles UML soient stockés sous forme de texte simplifie leur intégration avec une variété d'outils comme les SCM (Source Control Management, les systèmes de gestion de versions).
Un des usages fréquents est de pouvoir comparer des modèles, de pouvoir gérer leur cycle de vie. Depuis que l'informatique existe, on sait comparer des fichiers texte bruts de manière extrêmement rapide et efficiente.
Tous les acteurs intéressés par la modélisation peuvent ainsi mieux comprendre les différences entre deux révisions de diagramme beaucoup plus rapidement que si l’on n'avait que des fichiers image, où il faudrait basculer sans arrêt entre deux versions. Cet avantage est particulièrement important pour les différentes cartographies des grandes organisations.

 

Outils de prédilection pour les ingénieurs d’études

Si cela est valable pour les architectes d’entreprise, il l’est aussi pour les concepteurs/développeurs qui utilisent des SCM dans leurs tâches quotidiennes : pour eux nulle nécessité d’acheter/installer des outils supplémentaires. 
Ces profils sont souvent plus à l’aise avec des langages textuels qu’avec des notations visuelles. Par exemple, ils utilisent le format Markdown et les outils associés pour concevoir la documentation technique, plutôt que MS Word.
Ces aspects représentent un énorme coup de pouce pour l'adoption de ces outils.

 

Solution légère et efficiente

Avec les outils de modélisation en ligne, ils constituent l'option incontournable pour toutes les personnes à la recherche d'une solution légère pour dessiner des modèles. En effet, comme la plupart des outils graphiques, ils disposent d'un éditeur en ligne, ils constituent un jackpot pour les modélisateurs occasionnels.

 

Finies les heures perdues à la mise en forme

Les mises à jour ne doivent pas être un exercice frustrant de déplacement et de redimensionnement pour faire de la place à un nouvel artefact de modélisation. Qui n’a pas passé des heures à rendre son modèle lisible, à se casser la tête pour éviter les croisements entre les relations, à centrer les entités saillantes, à regrouper par domaine métier, à modifier l’échelle, à choisir les couleurs les plus parlantes…

Avec un peu de pratique, la création de diagrammes devient beaucoup plus efficace que l'utilisation d'éditeurs WYSIWYG. 
La disposition des éléments du diagramme se fait automatiquement par l’application par le générateur de sa propre politique de mise en forme. De même, plus besoin de passer du temps sur le style manuel des nœuds, car cela peut maintenant être fait en utilisant un mécanisme semblable à une feuille de style, à un endroit central.

 

Mise en œuvre de l’architecture pilotée par les modèles grandement facilitée

La plupart du temps, les modèles sont cantonnés à un rôle documentaire, au lieu d'un rôle prépondérant dans le processus d'ingénierie logicielle, comme le postule l'architecture pilotée par les modèles MDE Model-Driven Engineering (IDM Ingénierie Dirigée par les Modèles) ou encore dans le monde des normes de l’OMG, MDA Model Driven Architecture. Dans ces cadres de pensée, tout peut être représenté sous forme de modèles, aussi bien les outils que les référentiels, les entités métier, la conception, le développement.
La transformation de modèle a pour objectif majeur la possibilité de spécifier les manières de produire plusieurs modèles cibles à partir d'un ensemble de modèles sources.
Techniquement, le moteur de transformation est grandement simplifié, car il est bien plus facile d’avoir en intrant un texte syntaxiquement simple et des règles qui seront appliquées pour générer le texte cible, que d'avoir un transformateur XSLT (eXtensible Stylesheet Language Transformations) qui doit traiter du XMI extrêmement verbeux.

 

Et l’envers du décor ?

Le problème central des outils les plus connus, tels que PlantUML ou Mermaid, est qu'ils peuvent toujours se retrouver avec des vues incohérentes. Pour contourner un peu le problème, il existe des mécanismes tels qu'une commande include <file>. Cela permet à un diagramme d'en inclure un autre, en réutilisant tous ou un sous-ensemble sélectionné de ses éléments. 
Pourtant, lorsqu’on regarde de plus près la plupart des outils listés en annexe ci-dessous, les fonctionnalités, l'expressivité et la robustesse de ces outils sont plutôt limitées. 

L’apprentissage d’un langage de balisage est nécessaire et implique un effort supplémentaire par rapport aux éditeurs graphiques. 
La disposition automatique choisie par le générateur d'images n'est parfois pas optimale. Dans ce cas, on va passer plus de temps à apprendre les astuces de mise en page offertes par le langage de balisage, telles que les constructions de contraintes spéciales.

 

Conclusion

Toute documentation complète doit inclure des diagrammes, car les images aident souvent à transmettre des idées et des concepts, plus efficacement que le texte. 
Cet article plaide en faveur de l'utilisation de diagrammes en texte pour faire de la création de diagrammes une expérience agréable pour les ingénieurs utilisant des SCM. Ces outils seront donc plus volontiers réservés comme outils de développement et à l'architecture logicielle.
Cependant, leur limite sera atteinte dès qu’il s’agira, en architecture d’entreprise, de concevoir des référentiels d’objets et d’assurer la traçabilité entre les cartographies.
 
Nous terminerons par une formule classique : comme toujours, le meilleur outil n’existe pas, il dépendra du contexte et de votre objectif.

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

“Tout ce qu’il faut pour faire un film, c’est une fille et un revolver.” 
Jean-Luc Godard
 

Annexe : nos préférés

PlantUML

Caractéristiques

https://plantuml.com/fr/

 

https://plantuml.com/fr/guide


PlantUML est un outil open source permettant aux utilisateurs de créer des diagrammes à partir d'une description textuelle. PlantUML vous permet de dessiner à peu près n'importe quel diagramme architectural dont vous avez besoin lors de la conception d'un système. Outre les diagrammes UML, il prend en charge plusieurs autres formats liés au développement de logiciels (ArchiMate, BPMN, Gantt chart, etc.), ainsi que la visualisation de fichiers JSON et YAML. 


PlantUML permet de dessiner rapidement des :

  • diagrammes de séquence
  • diagrammes de cas d'utilisation
  • diagrammes de classes
  • diagrammes d'objet
  • diagrammes d'activité
  • diagrammes de composant
  • diagrammes de déploiement
  • diagrammes d'états
  • diagrammes de temps

Certains autres diagrammes (hors UML) sont aussi possibles:

  • données au format JSON
  • données au format YAML
  • diagrammes ArchiMate
  • diagrammes de Gantt
  • diagrammes d'idées (mindmap)
  • organigramme ou Work Breakdown Structure (WBS)
  • notation mathématique avec AsciiMath ou JLaTeXMath
  • diagrammes entité relation (ER/IE)

 

Exemple de code

@startuml
skinparam rectangle<<behavior>> {
roundCorner 25
}
sprite $bProcess jar:archimate/business-process
sprite $aService jar:archimate/application-service
sprite $aComponent jar:archimate/application-component
rectangle "Handle claim" as HC <<$bProcess>><<behavior>> #Business
rectangle "Capture Information" as CI <<$bProcess>><<behavior>> #Business
rectangle "Notify\nAdditional Stakeholders" as NAS <<$bProcess>><<behavior>> #Business
rectangle "Validate" as V <<$bProcess>><<behavior>> #Business
rectangle "Investigate" as I <<$bProcess>><<behavior>> #Business
rectangle "Pay" as P <<$bProcess>><<behavior>> #Business
HC *-down- CI
HC *-down- NAS
HC *-down- V
HC *-down- I
HC *-down- P
CI -right->> NAS
NAS -right->> V
V -right->> I
I -right->> P
rectangle "Scanning" as scanning <<$aService>><<behavior>> #Application
rectangle "Customer admnistration" as customerAdministration <<$aService>><<behavior>> #Application
rectangle "Claims admnistration" as claimsAdministration <<$aService>><<behavior>> #Application
rectangle Printing <<$aService>><<behavior>> #Application
rectangle Payment <<$aService>><<behavior>> #Application
scanning -up-> CI
customerAdministration -up-> CI
claimsAdministration -up-> NAS
claimsAdministration -up-> V
claimsAdministration -up-> I
Payment -up-> P
Printing -up-> V
Printing -up-> P
rectangle "Document\nManagement\nSystem" as DMS <<$aComponent>> #Application
rectangle "General\nCRM\nSystem" as CRM <<$aComponent>> #Application
rectangle "Home & Away\nPolicy\nAdministration" as HAPA <<$aComponent>> #Application
rectangle "Home & Away\nFinancial\nAdministration" as HFPA <<$aComponent>> #Application
DMS .up.|> scanning
DMS .up.|> Printing
CRM .up.|> customerAdministration
HAPA .up.|> claimsAdministration
HFPA .up.|> Payment
legend left
Example from the "Archisurance case study" (OpenGroup).
See
====
<$bProcess> :business process
====
<$aService> : application service
====
<$aComponent> : application component
endlegend
@enduml

 

Diagramme ArchiMate généré

diagram-as-code-plantuml-archimate

 

PlantUML est un des outils "diagram as code" les plus connus et utilisés

 

Mermaid

https://mermaid-js.github.io/mermaid/#/


Mermaid est un outil de création de diagrammes et de graphiques basé sur JavaScript, qui utilise des définitions de texte inspirées de Markdown et un moteur de rendu pour créer et modifier des diagrammes complexes. L'objectif principal de Mermaid est d'aider la documentation à rattraper le développement. Mermaid permet aux utilisateurs de créer des diagrammes facilement modifiables, qui peuvent également être intégrés aux scripts de production (et autres morceaux de code). Mermaid est un outil open source.

 

diagram-as-code-mermaid-uml-sequence

Mermaid est un autre standard du marché

 

 

D2 (Declarative Diagramming)

https://terrastruct.com/


D2 vous permet d'éditer des diagrammes avec du texte ou une interface graphique, avec des changements synchronisés entre les deux.

D2 n'a pas de types de diagrammes. Dans d'autres outils, vous spécifiez "ceci est un diagramme de classe", ou "ceci est un diagramme d'état". L'un des objectifs de la conception de D2 est d'avoir une syntaxe minimale avec laquelle vous composez. Terrastruct explique qu'elle évite la mode "DSL dans un DSL" qui consiste à déclarer des diagrammes spéciaux et à avoir une syntaxe spéciale pour chacun.
Pour créer des diagrammes de classes dans D2, vous créez des objets comme n'importe quels autres et leur donnez une forme : classe.

 

  • D2 supporte les extraits de code et le texte Markdown
  • D2 supporte entièrement les diagrammes de classe UML
  • relations entre tables SQL
  • fractionnement d'un seul diagramme D2 en plusieurs fichiers qui peuvent être importés et réutilisés
  • transpilation à partir des standards du marché PlantUML et Mermaid
  • code source disponible
  • prise en charge des connexions courbes
  • personnalisation et création de thèmes
  • D2 supporte les icônes personnalisées

 

diagram-as-code-declarative-diagram-d2-terrastruct

 

 

Aperçu de l'IDE de D2

 

Structurizr

https://structurizr.com/

 

Un outil populaire, Structurizr DSL, vous permet de créer des modèles d'architecture logicielle basés sur le modèle C4 (https://c4model.com/), en utilisant un langage textuel spécifique au domaine (DSL). Le DSL vous permet de créer plusieurs diagrammes dans plusieurs formats de sortie, à partir d'un seul fichier source DSL.

 

diagram-as-code-structurizr

Structurizr est basé sur le modèle C4 technique de notation graphique allégée
pour modéliser l'architecture des systèmes logiciels.

 

Umple

https://cruise.umple.org/umpleonline/

 

https://yuml.me/

 

https://yuml.me/diagram/scruffy/class/draw

 

diagram-as-code-yuml-uml-diagramme-classe 

Si vous êtes pressé !

 

Compléments de lecture

 


11/10/2022
0 Poster un commentaire

GenMyModel est un outil de modélisation en ligne, supportant ArchiMate, BPMN, UML, DMN et gratuit, mais convient-il à l’architecte d’entreprise ?

GenMyModel est une plate-forme française de conception logicielle basée sur les normes UML pour la modélisation de systèmes, BPMN pour les processus d'entreprise, DMN pour les règles métier et AchiMate pour l’Architecture d’Entreprise. Complètement accessible dans le cloud en mode SaaS, il fournit des générateurs de code intégrés pour Java, SQL, Spring… Idéal ou produit d'appel à des formules payantes ?

genmymodel-uml-bpmn-dmn-archimate  

L'offre des catégories de projets est pléthorique

 

Mise en œuvre

Simplissime, le site https://www.genmymodel.com/ propose de créer un compte afin d’accéder à la plate-forme. Vous pouvez aussi utiliser un compte Google ou GitHub existant.

 

Axellience, les jumeaux numériques et les heatmaps

Basé à Lille, Axellience a été le premier éditeur français de logiciel à créer une plate-forme de modélisation collaborative en ligne, GenMyModel, permettant une co-création à la « Google Drive », basée sur un référentiel commun.

 

A partir de la plate-forme technologique GenMyModel, Axellience a élaboré “Agile Architecture Factory”, une solution collaborative payante en ligne pour l’architecture agile du SI dans les projets de transformation, ainsi qu’une offre de services associés.

 

Axellience étend les possibilités de personnalisation de sa méthode en généralisant aux normes ArchiMate et BPMN la notion de profil UML. Ces profils permettent de créer de nouveaux objets avec leurs icônes, et d'en disposer immédiatement pour la modélisation, le reporting et la documentation, en mode no-code. Un projet peut être “multi-modèles”, c'est-à-dire combiner autant de notations que nécessaire, par exemple un modèle de stratégie ArchiMate, des modèles de processus BPMN, des modèles de données en diagramme entité-relation ou UML...

 

Partant du constat que personne n’a le temps de réaliser la documentation, Axellience a conçu LiveView, un outil bâti sur le principe suivant : “modéliser = documenter”, qui génère automatiquement tous types de rapports.

 

L’éditeur propose un service basé sur les jumeaux numériques (réplique numérique d'un objet, d'un processus ou d'un système), qui, combiné avec sa méthode, permet de réaliser des indicateurs visuels comme des heatmaps, graphique de données statistiques faisant correspondre à la grandeur d’une variable une gamme de couleurs, pour illustrer les résultats des décisions prises. 

 

Une ombre au tableau,
le service de collaboration à la Google est payant

genmymodel-service-collaboration-payant-03 

Pour pouvoir travailler à distance à plusieurs, dans le cloud en mode SaaS ("Software as a Service"), il faut tout d’abord créer une organisation ; ce service est payant ; voir la copie d’écran ci-dessus. Une fois créée, on peut ajouter des membres avec leurs courriels. Les membres devront se connecter, aller dans leur tableau de bord où apparaîtra l’invitation et cliquer sur le bouton pour joindre l’organisation.

 

Les changements effectués par chacun des membres seront relayés en temps réel, comme pour un document Google Drive ou comme avec Visual Paradigm (voir notre article dans les compléments de lecture).

 

L’utilisateur possédant un compte FREE ou SOLO devra modifier sa souscription moyennant finance en EQUIPE ou ENTREPRISE.

 

Dépôt public

genmymodel-import-depot-public-02 

Les modèles dans le dépôt public ne sont malheureusement pas vérifiés
quant à leur conformité aux normes.

 

GenMyModel possède un dépôt public avec quelque 200 000 exemples permettant de ne pas partir from scratch.

 

Les modèles UML : la grande classe

GenMyModel propose les diagrammes UML ("Unified Modeling Language") suivants : classes, composants, activités, état-transitions, objets, séquence, cas d’utilisation, déploiement. Dommage que les diagrammes UML composite, package, communication, temps et global d'interaction soient absents. Les choix par défaut sont judicieux ; les noms des rôles sont automatiquement définis positionnés ainsi que les multiplicités.

 

On pressent que GenMyModel est destiné à la génération automatique de code, ce qui le positionne dans le camp des évangélistes du low-code/no-code.

GenMyModel est très certainement à ranger parmi les outils de modélisation classieux.

 

genmymodel-uml-generation-jpa 

Pour UML, GenMyModel ravira les architectes logiciels, ainsi que les concepteurs-développeurs

 

BPMN et la notation souvent oubliée DMN

Si la norme BPMN ("Business Process Model and Notation") est incontournable pour la modélisation des processus métier et si la grande majorité des outils de modélisation l’implémentent, il en est différemment pour la norme DMN (Decision Model and Notation) pour la modélisation des règles métier et des tables de décision. Rares sont les outils supportant cette norme pourtant associée à BPMN.

 

En effet, à une “Business Rule Task” BPMN, il est d’usage de lui faire correspondre le modèle DMN détaillant les règles métier. A noter que cette tâche est nommée “Business Task” dans l’outil. Si GenMyModel supporte DMN, il est malheureusement impossible de faire correspondre les 2 modèles BPMN et DMN sur le même diagramme.

 

genmymodel-bpmn-rule-task 

Il aurait été judicieux de pouvoir insérer le diagramme DMN ci-dessous
à côté de la Business Rule Task "Etudier l'adhésion"

 

 

genmymodel-dmn-generation-code-java-spring-boot 

GenMyModel supporte la norme DMN
pour la modélisation des règles métier et des tables de décision

 

ArchiMate

Nous avons utilisé le pattern ArchiMate (langage de modélisation du framework TOGAF The Open Group Architecture Framework) “Point de vue de réalisation de service" qui permet de montrer comment un ou plusieurs services métier sont réalisés par les processus sous-jacents (et parfois par les composants d'application).

 

GenMymodel est moins abouti dans ce domaine qu'Archi par exemple (voir notre article dans les compléments de lecture).

 

genmymodel-archimate-service-realization-viewpoint 

Pour ArchiMate, GenMyModel se situe un cran en dessous d'un outil comme Archi,
mais, contrairement à lui, il s'exécute à distance en environnement Cloud.

 

Import/Export

Pour accélérer la transition Cloud, GenMyModel est interopérable avec Confluence et Jira d’Atlassian. Les utilisateurs profitent de la solution pour se libérer des outils concurrents à base de clients lourds. Ainsi, l’import de l’outil Enterprise Architect de Sparx Systems (https://sparxsystems.com/) se rajoute aux imports XMI et BPMN, pour faciliter la reprise des référentiels d’architecture existants.

 

GenMyModel propose d’exporter la documentation dans les formats standards Word, PDF…

L’outil offre la possibilité d’exporter les diagrammes en XMI (XML Metadata Interchange) qui est le format textuel normalisé par l’OMG d’import/export de diagrammes UML. Pour les processus métier, le format d’import/export BPMN2 est entièrement supporté.

 

Outil low-code/no-code ?

Comme son nom l’indique, la spécialité de GenMyModel est la génération de code. Nous avons été agréablement surpris par l’étendue et la puissance du générateur de code utilisant des modules open source en provenance de l’organisation Eclipse.

 

En effet, la plupart des langages sont supportés. De plus, il est possible de générer des microservices en Java Spring Boot, qui est une des solutions d’implémentation les plus tendance pour une Architecture Microservice (voir notre article dans les compléments de lecture).

 

genmymodel-generation-code-spring-boot 

Extrait du code Java produit par le générateur UML2SpringBoot de GenMyModel

 

Conclusion

La formule gratuite n’offre pas la possibilité de gérer un référentiel d’objets transverses à l’ensemble de l’entreprise.

 

GenMyModel est sans conteste un excellent outil de modélisation, plutôt réservé à la conception d’application qu’à l’Architecture d’Entreprise. Les concepteurs-développeurs trouveront leur bonheur en modélisant, puis en générant des squelettes de code dans leur langage favori.

 

GenMyModel comporte très peu d’aide, pas d’exemple complet comme dans ADOIT:CE, Modelio ou WinDesign (voir nos articles dans les compléments de lecture). 

 

Comme beaucoup d’autres sociétés de consulting, Axellience propose gratuitement un outil de modélisation offrant les fonctionnalités de base, afin de montrer ses compétences et d’attirer de potentiels clients qui, pour leurs référentiels d’entreprises, auront nécessairement besoin d’extensions payantes et des services, autour de leur méthode maison “Agile Architecture Factory”.

 

Note : 3/5

Nous regrettons :

- L'impossibilité de lier n’importe quels objets du référentiel pour assurer la traçabilité,

 

- Peu de documentation,

 

- Pas d’exemple concret et complet, mais anonymisé, montrant les possibilités de l’outil

 

- L’absence de validation des diagrammes, avec la description détaillée des erreurs
et des propositions de solutions pédagogiques.

 

Nous aimons :

+ L’ergonomie et le design sont au niveau de ce qui se fait de mieux aujourd’hui,

 

+ Un outil de modélisation open source supportant ArchiMate, BPMN, DMN et UML,

 

+ Outil en mode Cloud se dispensant de toute installation en local et disponible sur tous les OS.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“Always choose people that are better than you, that challenge you and are smarter than you. Always be the student” Sandra Bullock.

(Choisissez toujours des personnes qui sont meilleures que vous, qui vous challengent et qui sont plus intelligentes que vous. Soyez toujours l'étudiant) 

 

Compléments de lecture

 


30/06/2022
0 Poster un commentaire

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

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

 

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

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

 

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

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


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

 

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

 

Du Machine Learning dans la gestion de projet

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

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

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

 

Le comité de direction augmenté, une utopie ?

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

Voir nos articles :

 

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

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


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


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

 

Conclusion

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

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

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

 

Compléments de lecture

 


09/06/2022
0 Poster un commentaire

Méta-physique ? Non, méta-modélisation !

La sortie récente de la version 5 du Camunda Modeler, permettant de modéliser les processus métier avec la notation BPMN, nous donne l’occasion de faire un rappel sur la notion de méta-modèle, qui se cache souvent derrière le modèle.

 

four-russian-dolls

 

Un méta-modèle pour quoi faire ?

 

3U

 

Les 3U pour la Modélisation, l’Exécution et le Pilotage d’un processus métier

 

  • Un modèle est Utile.
    Si vous n’en êtes pas convaincu, alors vous ne butinez pas sur le bon site ! Car la mise en œuvre de l’Urbanisation du Système d’Information et de l’Architecture d’Entreprise avec méthode, pour une entreprise agile et résiliente, prônée par urbanisation-si.com, est basée sur la modélisation.

 

  • Un modèle doit être Utilisable.
    C’est cet aspect d’un modèle qui est détaillé plus bas dans cet article et qui s’appuie, selon nous, sur la normalisation grâce à un méta-modèle. Et cela permet de passer éventuellement de la modélisation statique à la modélisation dynamique.

 

  • Un modèle est-il Utilisé ?
    Un modèle de processus métier peut être directement utilisé avec la plate-forme adéquate. Souvent, il est toutefois nécessaire d’ajouter quelques artefacts, comme des formulaires de saisie.
    Utiliser un modèle reste la manière la plus efficace de s’assurer que la pratique du processus métier correspond à la théorie. Le modèle de processus est alors indissociable de la réalité. Le processus métier va pouvoir être piloté.
    Un dispositif optionnel comme le BAM – Business Activity Monitoring – permet de compter le nombre d’instances d’un processus métier (combien sont terminés, combien sont en cours, combien sont en erreur, etc.) et de mesurer leurs durées.

 

 

Utilisabilité d’un modèle

 

Intéressons nous plus particulièrement ici à l’utilisabilité d’un modèle. L’utilisation d’un langage ou une notation de modélisation normalisée facilite la réalisation, le partage, la compréhension d’un modèle. Ceci est particulièrement vrai avec la notation BPMN, qui permet notamment aux analystes métier et aux informaticiens de partager des modèles de processus métier et permet même directement leur exécution grâce à un BPMS.

 

Pyramide de modélisation

 

Concernant les langages et les notations de modélisation, la normalisation ne s’appuie pas seulement sur la publication de spécifications détaillées, pour diffuser et partager les éléments de représentation : elle repose également sur un système pyramidal complexe, mais cohérent, de (méta) modélisation.

 

PyramideModélisation

 

La pyramide de modélisation de l’OMG

 

La largeur de chaque niveau est proportionnelle à son nombre d’occurrences. En fait, le nombre d’occurrences se réduit de façon drastique quand le niveau augmente.

 

Niveau M0 : C’est le monde réel (ou imaginé), constitué d’instances qui doivent être représentées par le modèle de niveau 1. Si l’on veut représenter les êtres humains, cela fera plus de 7 milliards d’instances.

 

Niveau M1 : C’est le modèle que nous connaissons tous. Ce modèle représente généralement une partie du monde réel, par exemple, un diagramme de collaboration BPMN qui représente un processus métier. Ce modèle peut également représenter un système qui n’existe pas encore). Il existe sans doute dans le monde entier des centaines de milliers de modèles.

 

Niveau M2 : Le méta-modèle est beaucoup moins connu. Les modèles utilisant un langage ou une notation normalisée respectent généralement un méta-modèle. Tous les langages et notations de l’OMG – Object Management Group – notamment sont fournis avec un méta-modèle. Par exemple, celui de la notation BPMN. Ce méta-modèle est surtout utilisé par les éditeurs de logiciel. Il existe plusieurs dizaines de méta-modèles.

 

Niveau M3 : Le méta-méta-modèle est encore moins connu. Il fixe les règles de représentation des méta-modèles. Il existe très peu de méta-méta-modèles : je n’en connais que deux Ecore et MOF.

 

Pas de niveau M4 : A nos lecteurs qui seraient taraudés par l’idée qu’un méta-méta-méta-modèle (oui, je compte le nombre de « méta » sur mes doigts) serait sans doute nécessaire pour fixer les règles de représentation des méta-méta-modèles, soyez rassurés ! En effet, les méta-méta-modèles possèdent une caractéristique appelée méta-circularité, qui leur permet de se définir eux-mêmes. « Seulement » 4 niveaux numérotés de 0 à 3, donc.

 

Pas de méta-modèles dans les applications de dessin

 

Vous pouvez réaliser un diagramme de collaboration BPMN avec l’application Microsoft PowerPoint (vous trouverez quelques formes simples dans la section Organigrammes), mais vous serez rarement certain que votre modèle BPMN est conforme au méta-modèle. En effet, PowerPoint est, pour la partie graphique, une simple application de dessin qui vous permet d’agencer puis de relier les symboles BPMN n’importe comment. Parmi les applications Microsoft, il vaudra mieux utiliser Visio Professionnel pour réaliser des diagrammes BPMN sérieux, car validés par le méta-modèle BPMN.

 

Utilisation du méta-modèle

 

Les vraies applications de modélisation utilisent le méta-modèle de deux façons différentes :

 

  • En temps réel, pour déduire automatiquement la nature de certains éléments de modélisation. Ainsi, avec un outil de modélisation BPMN, quand on relie deux tâches, la connexion se fera automatiquement avec un flux de séquence (trait plein) si ces deux tâches sont dans le même pool ou bien avec un flux de message (trait pointillé), si ces deux tâches sont dans deux pools différents,

 

  • A postériori, pour valider le modèle avec le méta-modèle. La plupart des outils de modélisation BPMN disposent d’une fonction de validation du modèle et il est fortement conseillé de l’utiliser, afin de ne partager que des modèles valides, ce qui contribue grandement à la compréhension et à la diffusion d’un langage ou d’une notation normalisée.

 

Bonnes pratiques

 

Certains outils vont plus loin que la validation avec le méta-modèle. Signavio Process Manager par exemple peut vérifier également si les bonnes pratiques sont bien appliquées, en l’occurrence celles définies dans le livre de référence de Bruce Silver : BPMN method and style: with BPMN implementer’s guide (2. edition), Cody-Cassidy Press (2011).

 

Le sens critique des utilisateurs humains est toutefois toujours nécessaire pour peaufiner la modélisation. Par exemple, il est recommandé que chaque tâche soit renseignée avec un verbe d’action, suivi d’un complément d’objet direct (Exemple : Préparer commande). Le validateur contrôle que chaque tâche est renseignée (c.-à-d. non vide), mais n’effectue pas une analyse syntaxique du contenu.

 

Validation BPMN avec Camunda Modeler

 

Camunda Modeler, outil gratuit et largement utilisé, dont nous apprécions la facilité d’installation, même quand on ne dispose pas des droits Administrateur sur son PC, ne dispose pourtant pas d’une fonction de validation. Les utilisateurs motivés pourront remédier à cette lacune en installant le module d’extension Linter.

 

Il convient, en plus du Camunda Modeler, d’installer git et node.js, puis à partir du sous-répertoire ..\camunda-modeler\resources\plugins\, de lancer la commande suivante pour installer ce module :

npx degit github:camunda/camunda-modeler-linter-plugin camunda-modeler-linter-plugin

 

Dans le menu Plugins de Camunda Modeler, il suffit d’activer BPMN Linter qui effectue la validation en temps réel. Les erreurs les plus courantes sont alors aussitôt signalées et affichées directement sur l’élément concerné. Mais il est parfois préférable d’attendre la fin de la modélisation (on peut désactiver provisoirement BPMN Linter).

 

BPMN_KO

 

BPMN_OK

Diagramme de collaboration BPMN réalisé avec Camunda Modeler et le plugin Linter

 

Conclusion

 

Ce principe général de méta-modélisation, illustré dans cet article avec la notation BPMN, s’applique à d’autres notations et langages, notamment UML. Pour passer facilement de la théorie à la pratique, il suffit d’avoir un outil de modélisation adapté, qui va masquer la complexité du méta-modèle, grâce à sa fonction de validation des diagrammes notamment.

 

Thierry BIARD

 

“Il importe en peinture, que le portrait ressemble au modèle, mais non pas le modèle au portrait.” (Paul-Jean Toulet)
(Note de Thierry Biard : Il est amusant de noter qu’en peinture, sculpture et photographie, le modèle est le personnage du monde réel lui-même et non sa représentation – le portrait)

 

Compléments de lecture

MOF - ECORE - MDA

Métamodèle TOGAF - ArchiMate

Application des métamodèles

Les critères d'un bon modèle

   


01/06/2022
0 Poster un commentaire