urbanisation-si.com

urbanisation-si.com

Solutions sur étagère pour la gestion des défaillances des Micro-Services

L'objectif des micro-services est d'accélérer la mise en production des applications, en décomposant l'application en petits services autonomes, qui peuvent être déployés indépendamment les uns des autres. Une architecture de micro-services pose également certains problèmes. Voici une synthèse des patterns les plus utilisés afin d'éviter les pannes.

 

solutions-sur-etagere-defaillances-micro-service

 

 

Le génie logiciel emprunte de nombreuses idées au génie civil, où les ingénieurs s'occupent de la conception, de la construction et de l'entretien des routes, des ponts, des canaux, des barrages et des bâtiments.

Ces ingénieurs prévoient les défaillances des composants individuels et pour pallier cela, ils assurent plusieurs redondances pour des bâtiments plus sûrs et plus stables.

Le même “mindset” peut être appliqué au génie logiciel. Des défaillances isolées sont inévitables, mais l'objectif reste de concevoir des systèmes fonctionnant aussi longtemps que possible. 

Les pratiques d'ingénierie, telles que la modélisation et l’injection de défaillances, devraient être incluses dans le cadre d'un processus d’intégration et de livraison continue, afin de concevoir des systèmes plus fiables. 

 

Circuit Breaker (Disjoncteur)


Le modèle "Circuit Breaker" (disjoncteur) est couramment utilisé pour garantir que, en cas de défaillance d’un micro-service, l'ensemble du système ne soit pas affecté. 

Cela se produit si le volume des appels au service ayant échoué est élevé et, pour chaque appel, on doit attendre qu'un délai se produise avant de continuer.

Faire l'appel au service défaillant et attendre utiliserait des ressources, ce qui finirait par rendre le système global instable.

Le modèle de "Circuit Breaker" se comporte comme un simple disjoncteur, comme celui de votre circuit électrique domestique. Les appels à un micro-service sont enveloppés dans un objet "Circuit Breaker".

Lorsqu'un micro-service défaille, l'objet "Circuit Breaker" autorise les appels ultérieurs au service jusqu'à ce qu'un seuil de tentatives infructueuses soit atteint.

À ce moment-là, le "Circuit Breaker" pour ce micro-service se déclenche, et tout autre appel sera court-circuité et n'entraînera pas d'appels au micro-service en échec.

Ce pattern d'installation économise de précieuses ressources et maintient la stabilité globale du système.

 

 

micro-service-circuit-breaker

 

(Diagramme de séquence UML du "Cicuit Breaker")

 

Lorsque le "Circuit Breaker" se déclenche et que le circuit est ouvert, un traitement de secours peut être démarré à la place. La logique de secours effectue généralement peu ou pas de traitements et renvoie une valeur. Ces actions de secours doivent avoir peu de chances d'échouer, car ils s'exécutent à la suite d'un échec au départ.

 

Bulkheads (Cloisonnement) 


L’informatique a souvent repris à son compte des concepts appartenant à d’autres domaines comme pour la sécurité des navires avec les cloisons étanches des coques. Si l'une des cloisons est endommagée, cette défaillance est limitée à cette seule cloison et les autres cloisons permettent de garder le bateau à flot.

La même approche de partitionnement peut également être utilisée dans les logiciels pour isoler une partie du système. 

Ce pattern peut également être appliqué dans les micro-services eux-mêmes. Par exemple, un pool de threads utilisés pour atteindre deux systèmes existants. Si l'un des systèmes a commencé à connaître un ralentissement et a provoqué l'épuisement du pool de threads, l'accès à l'autre système existant sera également affecté.

Avoir des pools de threads séparés garantit qu'un ralentissement dans un système existant n'épuise que son propre pool de threads.

 

 

micro-service-bulkheads

 

(Exemple de pattern "bulkhead" : utilisation de pools de threads séparés)

 

Gestion décentralisée des données


Dans une application monolithique, il est facile de traiter les transactions, car tous les composants font partie du monolithe.

Lorsque vous passez à une architecture de micro-services distribuée, vous devez désormais potentiellement traiter des transactions réparties sur plusieurs services.

Dans une architecture de micro-services, la préférence va à "BASE" (Basically Available, Soft state, Eventual consistency), plutôt que de type "ACID" (Atomicity, Consistency, Isolation, Durability).

Les transactions distribuées sont à éviter chaque fois que c'est possible.

Idéalement, chaque micro-service gère sa propre base de données. Cela permet d’être agnostique sur les moyens de persistance (SQL, NoSQL…).

Une contrainte de préservation du caractère ACID d’une transaction peut aboutir à ce que plusieurs micro-services utilisent la même base de données. Quelle qu'en soit la raison, une attention particulière doit être accordée au partage de la base de données.

Les avantages et les inconvénients de le faire doivent être pris en considération.

A l’opposé, le partage d'une base de données peut violer le principe de parfaites indépendance et autonomie de chaque micro-service. En effet dans ce cas, les micro-services pourraient dépendre des changements dans la base apportés par un autre micro-service.

Le niveau de partage entre les micro-services doit être limité autant que possible pour rendre les micro-services aussi faiblement couplés que possible.

 

Discoverability (Découverte)


L'architecture des micro-services nécessite de rendre les services fiables et tolérants aux pannes. Cela implique la construction de micro-services de telle manière que, si l'infrastructure sous-jacente est détruite, alors les micro-services peuvent être reconfigurés et communiquer avec d’autres micro-services pour les besoins de l’application globale.

L'utilisation du cloud computing et des conteneurs, pour le déploiement de micro-services, offre la possibilité d’une reconfiguration dynamique. Lorsque la nouvelle instance du micro-service est créée, les autres micro-services peuvent la trouver rapidement et commencer à communiquer avec elle grâce à un système de découverte des micro-services reposant sur un registre (ex. open source : Netflix Eureka), auxquels tous les micro-services doivent s’enregistrer explicitement.

Avec un tel système, l’équilibrage de charge (load balancing ; ex. open source : Netflix Ribbon) devient alors une réalité.

 

Conception de communication inter-services


Lorsque les micro-services sont répartis sur les différents serveurs (Tomcat), conteneurs (Docker) ou machines virtuelles (Oracle Virtual Box), on peut se poser la question : comment communiquent-ils ?

Une première solution est de mettre en place des files d'attente de messages qui suffisent pour les communications unidirectionnelles.

Avec un monolithe applicatif, les clients de l'application (navigateurs ou applications natives) font des requêtes HTTP (Hypertext Transfer Protocol) à un équilibreur de charge, ce qui propage la demande à plusieurs instances identiques de l'application. 
Mais dans l'architecture micro-services, le monolithe a été remplacé par une collection de micro-services. Une deuxième solution consiste à utiliser le protocole REST (REpresentational State Transfer), pour la communication des micro-services entre eux ainsi qu’avec le client.

 

 

micro-service-communication-rest

 

(Appels entre les clients et les micro-services en utilisant des API REST)


À première vue, cela peut sembler souhaitable. Cependant, certains clients peuvent être « bavards » ; d'autres peuvent nécessiter de nombreux appels pour obtenir les données. Étant donné que les services peuvent évoluer différemment, il y a d'autres défis à relever, comme le traitement des défaillances partielles.

Une meilleure approche pour le client est de faire peu de requêtes, peut-être juste une, en utilisant le pattern du GoF (Gang of Four) "façade", de type API Gateway (passerelle).

 

micro-service-api-gateway

 

(Intégration du pattern "façade" comme l'API Gateway)


L'API Gateway se situe entre les clients et les micro-services et fournit des API qui sont sur mesure pour les clients. Elle consiste principalement à masquer la complexité technologique (par exemple, la connectivité à un ordinateur central), par rapport à la complexité de l'interface.

Une API Gateway est donc une façade. Cependant, une façade offre une vue uniforme des éléments internes complexes aux clients externes, alors qu'une API Gateway fournit une vue uniforme des ressources externes aux composants internes d'une application.

Tout comme le modèle de conception de façade, l'API Gateway fournit une interface simplifiée aux clients, ce qui rend les services plus faciles à utiliser, à comprendre et à tester.

En effet, il peut fournir différents niveaux de granularité aux clients. L'API Gateway peut fournir des API à grosses granularités aux appareils mobiles et des API à fines granularités aux ordinateurs de bureau, qui pourraient utiliser un réseau haut débit. Dans ce scénario, l'API Gateway réduit la conversation en permettant aux clients d'agréger plusieurs demandes en une seule, optimisée pour un client donné (tel que le client mobile).

 

HTTP synchrone versus messagerie asynchrone

Il existe deux approches principales pour la communication interprocessus :

  • Les mécanismes synchrones basés sur HTTP, tels que REST, SOAP ou WebSocket, qui permettent de conserver un canal de communication entre les navigateurs et serveurs, pour les requêtes / réponses pilotées par les événements,
     
  • La communication asynchrone utilisant un "message broker" (négociateur de messages ; ActiveMQ, Kafka, RabbitMQ, Redis...).

 

La communication synchrone est un mécanisme simple, compatible avec le pare-feu. L'inconvénient est qu'elle ne prend pas en charge d'autres modèles, comme le modèle de publication / abonnement. Elle ne permet pas non plus la mise en file d'attente des demandes, ce qui peut ralentir les performances.

Avec les applications synchrones, le client et le serveur doivent être disponibles simultanément et les clients doivent toujours connaître l'hôte et le port du serveur, ce qui n'est pas toujours simple lorsque les services évoluent automatiquement lors d'un déploiement cloud.

 

La communication asynchrone dissocie les services les uns des autres dans le temps, permettant d’envoyer des messages au fil de l'eau, stockés dans une file d'attente, tandis que le système de messagerie prend la responsabilité du message, en le gardant en sécurité jusqu'à ce qu'il puisse être livré au destinataire.

 

Le style de messagerie de publication / abonnement est plus flexible que la mise en file d'attente point à point, car il permet à plusieurs destinataires de s'abonner au flux de messages. Cela permet d'ajouter plus facilement plusieurs micro-services à l'application. 

 

Alternativement, un mécanisme asynchrone utilise un "message broker", cet intermédiaire permet  de diminuer le couplage entre les producteurs et les consommateurs. Le "message broker" met les messages en mémoire tampon jusqu'à ce que le consommateur soit en mesure de les traiter. Ce type de scénario de répartition de la charge permet aux développeurs de créer des applications évolutives et réactives. L'application peut être découpée en threads s'exécutant en arrière-plan, ce qui lui permet de continuer sans attendre la fin d'exécution des threads.

 

Les deux approches présentent des avantages et des inconvénients. La plupart des applications utilisent une combinaison de ces deux approches, adaptée à leurs besoins.

 

Faire face à la complexité


Une architecture de micro-services crée une utilisation supplémentaire des ressources pour de nombreuses opérations. Le nombre de composants augmente et en même temps la complexité. Rationaliser le comportement de chaque composant individuel pourrait être plus simple, mais comprendre le comportement de l'ensemble du système est beaucoup plus difficile.

Le réglage d'un système basé sur des micro-services, qui peut consister en des dizaines de processus, en comptant les "load balancers" et les "messages brokers", nécessite une surveillance et une expertise accrues.

Tests 

Le test d'un système complexe nécessite des suites de tests unitaires et d'intégration, et un cadre de tests qui simule les composants défaillants, la dégradation des performances du service, la résistance et le comportement global du système au cours d'une journée classique.

Ces cadres de tests assurent l'exactitude et la résilience globale du système.

En raison de l'accent mis sur le bon fonctionnement du système lorsqu'un composant tombe en panne, dans une architecture de micro-services, il n'est pas rare de tester un échec en production.

Des tests automatisés, qui forcent un composant à échouer, permettent de tester la capacité du système à reprendre en cas d'erreurs, ainsi que les capacités de surveillance.

 

Surveillance 

En plus des systèmes de surveillance conventionnels, des services bien conçus peuvent fournir des informations supplémentaires sur l'état de santé d'une architecture en utilisant le modèle publication / abonnement.

De cette façon, les informations peuvent être collectées par le service de surveillance, offrant des indicateurs de configuration.

Ces indicateurs peuvent à leur tour être utilisés pour garantir que les services ont la capacité suffisante pour traiter le volume demandé et comparer les performances actuelles par rapport à celles attendues.

Les contrôles personnalisés peuvent être enregistrés pour recueillir des données supplémentaires.

Toutes les informations de collecte peuvent être agrégées et affichées dans le tableau de bord de surveillance.

 

DevOps 

Le défi de maintenir les micro-services opérationnels signifie que vous avez besoin d'expertise en DevOps dans votre équipe de développement.

 

Programmation polyglotte

Très souvent, une architecture micro-services utilise plusieurs langages, Java pour la partie back-end, Python pour l'IA… ce qui présente un défi pour maintenir un tel système hyper-polyglotte.

Des développeurs peuvent déployer, exécuter et optimiser les produits noSQL (MongoDB) et remplacer l'administrateur de base de données (DBA).

Maintenir un pipeline de développeurs et d'architectes techniques qualifiés est aussi critique que la maintenance du pipeline DevOps.

On doit garantir qu’il y a suffisamment de développeurs qualifiés pour maintenir la plate-forme et améliorer la conception du système à mesure que de nouvelles évolutions sont réalisées.

La plupart des organisations ont une liste restreinte de langages de programmation qu'ils utilisent. Cela présente des avantages du point de vue de la réutilisation du code et des compétences.

 

Conception évolutive

L'architecture des micro-services permet une approche de conception évolutive. L'idée centrale est que vous pouvez introduire de nouvelles fonctionnalités dans votre application en changeant un seul micro-service. Il vous suffit de déployer les micro-services que vous avez modifiés. Le changement n'affecte que les consommateurs de ce micro-service et, si l'interface n'a pas changé, tous les consommateurs continuent de fonctionner.

Étant donné que les micro-services sont faiblement couplés, petits et ciblés, et ont un contexte borné, des modifications peuvent y être apportées rapidement et fréquemment avec un risque minimal.

Cette facilité de l'évolutivité d'un micro-service permet d'évoluer rapidement.

Parce qu'un micro-service est petit et généralement conçu, développé et entretenu par une petite équipe « deux pizzas », il est typique de trouver des micro-services entièrement réécrits, par opposition à être mis à niveau ou maintenus. Un compromis courant réside dans la petite taille de votre micro-service.

Cependant, plus chaque micro-service est petit, plus il est probable qu'une mise à jour d'une application classique nécessite plus de micro-services à déployer, augmentant ainsi le risque de dysfonctionnement.

Les principes des micro-services, tels que la déployabilité indépendante et le couplage lâche, doivent être pris en compte pour déterminer quelle fonctionnalité métier devient un micro-service.

 

Conclusion

 

Les micro-services peuvent avoir un impact positif sur votre entreprise.

Ce nouveau paradigme qu'est l'architecture micro-service (MSA) nécessite l'utilisation de modèles de conception pour la fiabilité, exactement comme pour le paradigme objet, où il existe des design patterns pour l'évolutivité, la maintenabilité et la réutilisabilité.

 

 

Rhona Maxwel
@rhona_helena

 

 

"Au calme clair de lune triste et beau,
Qui fait rêver les oiseaux dans les arbres
Et sangloter d'extase les jets d'eau,
Les grands jets d'eau sveltes parmi les marbres."

 

Clair de lune, Paul Verlaine

 

 

En complément :

 

Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?

 

Estimation de la complexité d’une Architecture Micro-Services

 

Conseils pour réussir vos micro-services et éviter qu’ils ne se transforment en véritable pensum

 

Inconvénients de l'Architecture Micro-Services

 

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

 


11/02/2021
0 Poster un commentaire

BPSim, la théorie et la pratique de la simulation de processus 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.

 

 

Rhona Maxwel
@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

 


02/02/2021
0 Poster un commentaire

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

Much ado about something

adult-1822449_1920_lite.jpg

 

Architecture d’Entreprise et outillage

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

 

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

 

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

 

ADOIT:CE (Community Edition) du groupe BOC

Le groupe autrichien BOC, spin-off de l’université de Vienne, propose des solutions pour la gestion de processus métier (ADONIS), la gestion de l’Architecture d’Entreprise (ADOIT) et la gestion des risques (GRC-Suite). Nous nous intéressons aujourd’hui à la solution de gestion de l’Architecture d’Entreprise ADOIT:CE. Il s’agit ici d’une première prise en main, en utilisant le contenu fourni comme exemple.

 

Depuis plusieurs années, l’édition communautaire ADOIT:CE Classic était disponible gratuitement au téléchargement pour une installation locale, mais celle-ci commençait à dater (2013) et s’appuyait sur une version encore plus ancienne du SGBD SQL Server (Microsoft). En outre, la cohabitation avec d’autres applications utilisant également ce SGBD s’avérait délicate.

 

Après quelques années de patience, la nouvelle édition communautaire ADOIT:CE est enfin disponible depuis le mois de septembre 2020, pour une utilisation en ligne uniquement. Seuls un accès à l’internet et un navigateur web sont nécessaires. Mais nous vous recommandons également d’utiliser un grand écran, afin de pouvoir afficher des modèles en entier et lire les noms des objets.

 

Le SGBD SQL Server est, cette fois-ci, chez BOC (ou son prestataire cloud). La Community Edition est une édition gratuite, mais allégée, de l’édition payante Enterprise, qui, elle, peut être utilisée en ligne ou bien installée sur un serveur local (on-premise). Ces deux éditions gratuite et payante semblent alignées sur la même version, la version 11.0.4 la date de publication de cet article. Utiliser une application en ligne (SaaS), c’est l’assurance de disposer automatiquement de la dernière version, sans aucun effort de mise à jour.

 

Pour information, il existe également une application mobile optionnelle nommée « Ask ADOIT », disponible sur Apple Store et Google Play, qui permet de consulter son référentiel d’architecture ou son smartphone ou mieux, sur sa tablette.

 

Initialisation et présentation de l’environnement

Un navigateur web et une adresse électronique valide, pour recevoir le mot de passe, suffisent pour s’inscrire sur https://www.adoit-community.com/account-registration/ avant d’utiliser ADOIT:CE. Lors de la première connexion, quelques minutes de patience sont nécessaires pendant la création de l’environnement, qui est dédié à chaque utilisateur. Car l’édition communautaire d’ADOIT est mono-utilisateur, c’est là sa principale restriction. Après leur mise en mémoire cache initiale, l’affichage des pages est rapide. Il faut indiquer que l’interface utilisateur est sobre, voire dépouillée, en noir et blanc essentiellement. Quelques touches de couleur verte viennent l’égayer légèrement.

 

L’utilisateur n’est pas « agressé » par une multitude de menus et de fonctions, comme il pourrait l’être par d’autres outils concurrents, aux abords beaucoup plus dissuasifs. Mais derrière cette apparente simplicité, se cachent des menus contextuels à deux niveaux, accessibles en cliquant sur le bouton droit de la souris, sur un modèle, un objet, voire un groupe d’objets sélectionnés, et permettent d’accéder à de nombreuses fonctions, qu’il conviendra d’apprivoiser.

 

Des objets et des modèles

Cet environnement est créé avec des objets et des modèles à des fins de démonstration. Le nombre d’objets est limité à 2.000 et 568 objets et artefacts de démonstration sont déjà fournis. Cette limite peut sembler un peu juste à long terme. Le nombre de modèles est, quant à lui, limité à 1.000 et 25 modèles de démonstration sont déjà fournis. Cette fois-ci, cette limite semble très élevée (qui, parmi nos fidèles lecteurs, ont plus de 1.000 modèles pour représenter l’architecture de leur entreprise ?).

 

Deux toutes petites jauges, de couleur verte également, rappellent les ratios d’utilisation des objets et des modèles, par rapport à leurs limites. Sans doute passeront-elles au rouge à l’approche des limites ? Un accès direct et rapide aux objets et modèles récemment ouverts est possible par un menu dédié.

 

Pour créer un nouvel objet, il faut sélectionner son type (61 types différents) et son groupe d’appartenance, c.-à-d. avoir déjà une idée précise de son utilisation ultérieure. L’outil de recherche permet de retrouver facilement un objet ou un modèle. Il est possible d’indiquer un type d’objets uniquement, afin d’obtenir la liste de tous les composants, par exemple, et générer ensuite un diagramme de dépendances.

 

Image2.png 

 

La sauvegarde des objets et des modèles, sur le cloud donc, est automatique, toutes les 20 modifications par défaut. Si vos données d’architecture sont hautement confidentielles ou si vous devez respecter la souveraineté numérique, il faudra donc préférer l’édition Enterprise payante, que vous pourrez alors installer on-premise.

 

Traduction partielle en français

Il est possible de choisir le français comme langue d’utilisation. La traduction est de qualité. Certaines listes sont toutefois restées en anglais (propriétés des objets et des modèles). La documentation, un manuel utilisateur de 213 pages au format Acrobat PDF, à télécharger à la première consultation ainsi que les vidéos, disponibles au centre de connaissances en ligne, sont, elles, en anglais uniquement. Ce n’est pas très grave, car il s’agit d’une documentation de référence, à ne consulter qu’en cas de besoin, et de vidéos peu instructives. En effet, ces vidéos trop courtes, réparties en deux catégories Débutant et Expert, répondent essentiellement aux questions Comment, mais pas aux questions Pourquoi.

 

La documentation, en anglais donc, concerne l’édition complète Enterprise et décrit quelques fonctionnalités qui ne sont pas disponibles dans l’édition communautaire allégée. En effet, l’édition CE d’ADOIT permet essentiellement de Cartographier et Documenter (ce qui constitue la base du travail de l’architecte d’entreprise, bien sûr), tandis que l’édition Enterprise propose en plus de :

 

- Contrôler et Publier, ce qui a du sens avec cette édition multi-utilisateurs,
pour passer en revue les objets créés par ses collègues, avant de les publier,

 

- Gouverner et gérer, pour obtenir la big picture de l’entreprise (statistiques,
évaluation des capacités, roadmap).

 

Forte orientation ArchiMate

Parmi les modèles fournis, figure le métamodèle d’ArchiMate, reproduit ci-dessous. D’autres standards internationaux sont simplement cités dans la documentation : ITIL, COBIT, TOGAF et RiskIT. N.B. ArchiMate est le langage de modélisation recommandé par le cadre d’architecture TOGAF.

 

Image3.png 

 

Restitutions

35 vues différentes sont proposées par ADOIT:CE. Par défaut, ces vues sont listées par type et dans l’ordre alphabétique :

 

- Diagrammes de composition et de dépendances,

- Graphiques à barres et à bulles,

- Listes et matrices,

- Rapports bureautiques.

 

A l’usage, il faudra préférer la liste de ces vues regroupées par couche (Reports by Layer), dans l’ordre top-down. Un type de vue peut être utilisé dans plusieurs couches, ce qui permet à ADOIT:CE de proposer une soixantaine de restitutions :

 

- Motivation,

- Stratégie,

- Métier*,

- Application*,

- Technologie*,

- Physique

- Implémentation & Migration.

 

*On retrouve donc, parmi ces 7 couches, 3 couches du POS (Plan d’Occupation des Sols) pour l’Urbanisation du Système d’Information (CIGREF) : seule la couche fonctionnelle entre la couche Métier et la couche Application n’y figure pas.

 

 Image4.png

 

Cycle de vie des objets

La date de début de validité (facile) et la date de fin de validité (beaucoup plus difficile à estimer) du cycle de vie de chaque objet peuvent être renseignées. Par défaut, tous les objets s’affichent, mais il est possible d’indiquer une date dans le filtre temporel optionnel. Ainsi, en indiquant la date du jour, c’est l’architecture As-Is qui s’affichera, tandis qu’en indiquant une date dans le futur, ce sera l’architecture To-Be. Cette approche, qui ne nécessite qu’un seul référentiel pour stocker les objets du passé, du présent et du futur, est habile. On peut également comparer le modèle To-Be avec le modèle As-Is, mais pour que cette fonctionnalité soit pratique, il faudrait disposer d’un écran encore plus grand.

 

Contenu de démonstration

Le contenu de démonstration fourni en exemple concerne l’architecture d’une banque fictive « ADOmoney Bank ». 24 modèles répartis dans 4 catégories (Gouvernance, Architecture d’Entreprise, Service Management et Gestion des Risques) sont fournis. Les modèles de la catégorie Architecture d’Entreprise sont répartis en 4 sous-catégories d’architecture : Transformation, Métier, Système d’information et Technologie.

 

 Image5.png

La complexité de cet exemple est similaire à celle d’une architecture réelle. Voici un extrait de l’architecture des composants constituant une application et notamment leurs interfaces. Une vue miniature, mais panoramique (en bas à droite), permet d’ajuster automatiquement l’affichage d’un modèle à la taille de la fenêtre ou de zoomer en avant et en arrière. L’écran de 13 pouces d’un notebook est clairement trop petit pour avoir une vue globale du diagramme.

 

 Image6.png

 

Vous noterez qu’ADOIT:CE dessine automatiquement des petits ponts sur les connecteurs, lorsque ceux-ci se croisent : cela peut sembler être un détail, mais cette simple fonctionnalité contribue grandement à la clarté des diagrammes.

 

Evaluation du portefeuille d’applications

Il est possible d’évaluer chaque application du portefeuille, selon trois critères, dans l’exemple ci-dessous, de satisfaction du métier du métier (axe horizontal), de coût (axe vertical) et d’importance stratégique (taille des points).

 

 Image7.png

Gestion des données de référence

Il est possible de faire du Master Data Management : une matrice entre les composants et des objets métiers peut ainsi révéler que plusieurs composants écrivent dans un même objet métier, ce qui peut révéler des conflits, surlignés en orange dans l’exemple ci-dessous.

 Image8.png

 

Importation et exportation

Les objets uniquement peuvent être importés au format Excel, ce qui est, en théorie, utile pour récupérer l’existant. Un classeur « ADOIT 11 ArchiMate Excel Import Template (FR).xlsx » est téléchargeable avec 61 feuilles différentes, une pour chaque type d’objet. Rien n’indique si chaque champ est obligatoire ou facultatif… Plusieurs types d’objets possèdent plus de 500 champs ! En pratique, cela ne sera pas très facile à utiliser.

 

Chaque modèle est exportable dans un document autonome, au format Acrobat PDF, ou comme un graphique, au format bitmap PNG ou au format vectoriel SVG, pour être inséré dans un document bureautique, au format Word ou PowerPoint par exemple.

 

La portabilité des données d’un outil vers un autre est un point important également. Il est possible d’importer et d’exporter modèles et objets via des fichiers au format (The Open Group). L’application Archi (www.archimatetool.com) au moins supporte également ce format.

 

Avantages                                     

ü Rien à installer, toujours la dernière version en ligne

ü Interface utilisateur relativement simple

ü Support complet d’ArchiMate

ü Gratuit pour toujours

ü Nombreuses fonctionnalités, pour une version gratuite

 

Inconvénients

û Différences entre modèles, rapports, vues et restitutions peu claires

û Rien pour supporter les diagrammes UML

û Pas d’aide méthodologique, lorsque l’on part de rien

û Les connaissances (ressources) ne sont pas en français

 

N.B. Les diagrammes BPMN sont supportés par l’autre outil ADONIS.

 

Conclusion

En guise de conclusion, si vous utilisez déjà le langage de modélisation ArchiMate ou si vous envisagez de l’utiliser, n’hésitez pas à essayer cet outil lors d’un vrai projet d’Architecture d’Entreprise, puis à partager vos impressions sous la forme de commentaires à la fin de cet article.

 

Thierry BIARD

 

« La rumeur est la fumée du bruit. »
Victor Hugo

10/11/2020
2 Poster un commentaire

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

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

microservices-architecture-principes.jpg

 

C’est le premier article d’une nouvelle série qui vise à expliquer l’Architecture Micro-Services.

Evolution de l’architecture logicielle

Tentons de résumer l’évolution de l’architecture logicielle en trois grandes étapes, forcément réductrices, qui ont mené à l’Architecture Micro-Services :

1-      Architecture monolithique

A la fin du 20e siècle, les applications informatiques développées étaient monolithiques, c.-à-d. constituées d’un seul bloc, parfois très gros. Ce qui n’empêchait pas la programmation modulaire. Seul le stockage des données, centralisé, était confié à un Système de Gestion de Base de Données (SGBD).

 

De nombreuses applications monolithiques sont encore en production aujourd’hui (souvent une application monolithique par domaine métier), tellement cloisonnées entre elles que l’on parle alors d’architecture en silos.

2-      Architecture Orientée Services

Au début du 21e siècle, disons vers 2005, un premier effort de partitionnement a été effectué avec l’Architecture Orientée Services (SOA), pour supporter l’avènement des processus métier et leur orchestration. Les données étaient toujours centralisées dans un SGBD.

 

Les solutions techniques mises en œuvre, peut-être trop lourdes (protocole SOAP et autres Web Services sur un ESB - Enterprise Service Bus), n’ont pas permis à la SOA de rencontrer le succès escompté : son usage s’est souvent limité aux gros projets dans les grandes entreprises.

3-      Architecture Micro-Services

Le terme micro-service fut utilisé pour la première fois en 2011, lors d’une conférence pour les architectes. Un des objectifs était de proposer un mécanisme de mise à l’échelle (scaling) plus performant et surtout plus flexible pour faire face à l’accroissement du nombre de visites des sites web les plus populaires (Amazon, eBay, Google, Netflix).

 

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

 

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

 

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

Principes de l’Architecture Micro-Services

C’est un style d’architecture dont l’approche est de :

- concevoir une application en une suite de petits services, appelés micro-services,
  découplés le plus possible les uns des autres,

- chaque micro-service :

  • répond à une fonctionnalité métier unique,
  • est simple ou moins complexe,
  • est indépendant, voire autonome,
  • s’exécute dans son propre processus,
  • dispose de sa propre base de données,
  • peut être développé dans un langage de programmation quelconque,
  • communique avec un protocole léger,
  • est déployable indépendamment des autres,
  • est déployable de façon continue et automatisée,

- la gestion centralisée des micro-services doit être réduite au strict minimum
(service discovery, par exemple ; il s’agit d’un dispositif pour découvrir les services).

 

Le fait que chaque micro-service doit disposer de sa propre base de données est sans aucun doute la différence principale avec l’Architecture SOA et provoque un fort impact sur la conception.

Partitionnement et granularité

L’Architecture Micro-Service se doit de répondre à une question primordiale : Comment partitionner une application volumineuse ou le Système d’Information de l’entreprise en micro-services ? Et ce partitionnement a son pendant : quelle granularité pour ces micro-services ?

 

Si vous comptez sur The Open Group (l’auteur de TOGAF) pour connaitre la bonne granularité d’un micro-service, vous serez fort déçu : « les bons micro-services sont situés entre les monolithes et les nanoservices ». Nous n’osons pas reproduire ici le diagramme lapalicien associé à cette affirmation, visible à cette adresse https://www.opengroup.org/soa/source-book/msawp/p6.htm.

 

Le partitionnement en tant que tel ne doit pas être un objectif, mais la conséquence de l’application des principes de l’Architecture Micro-Services. La démarche à suivre sera sans doute différente selon qu’il s’agisse de refondre une application monolithique existante (et même tout le Système d’Information de l’entreprise) ou de concevoir une nouvelle application en partant d’une feuille blanche.

 

L’approche de type top-down, orientée décomposition, est la plus courante, mais une approche alternative de type bottom-up, orientée agrégation, n’est pas exclue. Nous reviendrons sur ce sujet crucial du partitionnement d’une application et de la granularité des micro-services.

Prochains articles

Après les principes-avantages de l’Architecture Micro-Services, que nous venons de présenter dans ce premier article, nous nous intéresserons dans le deuxième article aux :

 

- Considérations techniques, inconvénients et impact sur l’organisation de l’Architecture Micro-Services,

 

Puis nous développerons le sujet de l’Architecture Micro-Services, souvent associé à d’autres sujets plus conceptuels, déjà abordés sur ce blog (liste non exhaustive) :

 

- Le partitionnement d’une application et la granularité des micro-services,

- L’Architecture Micro-Services dans les cadres d’Architecture d’Enterprise (Praxeme, TOGAF),

- Les méthodes de conception de l’Architecture Micro-Services,

- La modélisation de l’Architecture Micro-Services avec UML, ArchiMate ou autres,

- L’Architecture Micro-Services et les bases de données,

- L’Architecture Micro-Services et les processus métier,

- L’Architecture Micro-Services et les règles métier,

- La gestion des API et la gouvernance des micro-services.

 

N’hésitez pas à poster un commentaire en cliquant sur le lien ci-dessous.

 

Thierry BIARD

Architecte d’Entreprise, Spécialiste EDI, BPMN et DMN, je propose mes compétences aux leaders du Transport et de la Logistique, pour mettre en place des échanges B2B efficients. J’ai fait mienne cette citation de Nelson Mandela : « Je ne perds jamais. Soit je gagne, soit j’apprends ». En fait, j’apprends plus souvent que je gagne !

 

« La vie ce n’est pas d’attendre que l’orage passe, c’est d’apprendre à danser sous la pluie ».


18/04/2020
4 Poster un commentaire

ADOIT:CE (compléments d’information)

Voici quelques compléments d’information intéressants qui ont été donnés par l’éditeur BOC Group.

 

La version payante de l’application ADOIT peut être complétée par des modules optionnels UML et BPMN. Le module UML propose les 4 diagrammes les plus courants : cas d’utilisation, classes, paquetages et activités, tandis que la module BPMN propose l’emblématique diagramme de collaboration (une alternative plus qu’intéressante au diagramme d’activités UML). Ces deux modules partagent le même référentiel d’objets, unique par définition.

 

L’article principal ci-dessus concernait la prise en main de la version 11 d’ADOIT:CE. La prochaine version 12, disponible en décembre 2020, promet encore plus de ressources en français, notamment le métamodèle d’ArchiMate. Cette traduction s’appuiera sur le glossaire officiel anglais-français de The Open Group, qui publie ce langage de notation standard.

 

Enfin, légèrement effrayé par le nombre conséquent de champs importables pour chaque objet (souvent plus de 500), il convient de signaler que ces champs ne concernent pas uniquement les propriétés des objets, mais permettent également de décrire les relations entre eux.

 

Thierry BIARD


19/11/2020
0 Poster un commentaire

Inconvénients de l'Architecture Micro-Services

Intéressons-nous à quelques considérations techniques importantes, puis aux inconvénients de l’Architecture Micro-Services et enfin à son impact sur l’organisation.

mciroservices-archictecture-inconvenients.jpg

 

Dans notre premier article L’Architecture Micro-Services expliquée à ma fille, nous avons résumé l’évolution de l’architecture logicielle, présenté les principes de ce style d’architecture et posé les questions du partitionnement d’une application monolithique et de la granularité des micro-services.

Considérations techniques

L’architecture idéale est sans doute celle qui dépend le moins de toutes considérations techniques, mais au moment où il faut la réaliser, il est nécessaire de disposer des outils adéquats. La panoplie des outils dont on dispose pour mettre en place les micro-services, selon l’architecture préalablement établie, est très large.

 

Pour être précis, il vaudrait mieux parler de composants logiciels qui proposent des micro-services. Les composants favorisent la réutilisation du code déjà développé et limitent automatiquement la redondance (du code, mais aussi des données), que l’on trouve bien souvent dans une architecture en silos. Attention toutefois à ce que cette lutte contre la redondance n’augmente pas le couplage entre les micro-services.

 

Ces composants sont encapsulés et accessibles uniquement via leurs API (Application Programming Interface), soit selon le style RESTful (REpresentational State Transfer), qui s’appuie sur le protocole synchrone HTTP, soit via un système de messagerie au protocole asynchrone (de type message broker). Ce principe de composants encapsulés et échangeant entre eux via leurs interfaces n’est pas sans rappeler le paradigme de la Programmation Orientée Objet (OOP).

 

Tandis que les micro-services peuvent échanger entre eux directement via leurs API, les Clients externes peuvent éventuellement accéder à toutes les API de façon unifiée, grâce à une passerelle (API Gateway). Le couplage entre les micro-services peut être réduit en utilisant le mécanisme d’Inversion des Dépendances : les micro-services doivent dépendre de leurs abstractions (couches de haut niveau), mais pas de leurs implémentations (couches de bas niveau).

 

Autre considération, les micro-services sont exécutés par des serveurs qui n’ont pas besoin de connaitre leurs contextes d’utilisation (stateless servers), ce qui permet de les distribuer et de les dupliquer plus facilement.

 

La dernière considération technique importante est la conteneurisation (containerization), qui facile grandement le déploiement des micro-services, avec une règle simple à appliquer : un seul micro-service, ou plutôt un seul composant logiciel donc, par conteneur.

 

Ces considérations techniques seront approfondies dans nos prochains articles.

Inconvénients de l’Architecture Micro-Services

Tandis que les principes de l’Architecture Micro-Services sont généralement partagés par tous, car ils constituent autant d’avantages, les inconvénients sont plus rarement évoqués. Ces inconvénients sont bien souvent les conséquences de ces principes et constituent parfois des contradictions. Il est toutefois possible d’atténuer ces inconvénients : c’est en fait là que réside le talent de l’architecte.

 

1- Terme « micro » très relatif : la difficulté est de bien définir la granularité des micro-services. Cette granularité est variable d’un micro-service à l’autre. Ce n’est pas une bonne idée d’essayer d’obtenir une granularité uniforme pour tous les micro-services.

 

2- Problème de mise à jour des bases de données cloisonnées (chaque micro-service ayant sa propre base et pouvant être instancié plusieurs fois par le mécanisme de mise à l’échelle). Le mécanisme usuel de transaction de type « commit » n’est plus suffisant ; un mécanisme plus complexe appelé « saga » est nécessaire.

 

3- Défi en matière de débogage, test, déploiement des applications constituées de micro-services. Chaque micro-service aura été testé individuellement au préalable, mais ensuite, il faudra bien les tester tous ensemble, de façon automatisée de préférence.

 

4- Changements compliqués à cause des éventuelles dépendances entre les micro-services. Les micro-services supportent toutefois le versioning et plusieurs versions d’un même micro-service peuvent coexister, permettant une migration progressive vers la dernière version.

 

5- Application globale moins performante (latence), car dépendante du réseau (éventuellement moins fiable). Un protocole de communication asynchrone sera souvent préféré à un protocole synchrone, afin d’éviter d’attendre trop longtemps une réponse « immédiate » à chaque requête. De plus, l’usage d’un mécanisme de lecture via une mémoire cache est recommandé, afin d’optimiser la performance.

 

6- Besoin d’authentification, voire de chiffrage, pour diminuer les failles de sécurité du réseau.

 

(Liste non exhaustive, sans doute)

Impact sur l’organisation

Ce serait très réducteur de résumer l’Architecture Micro-Services à son aspect purement technique, car elle a également un impact fort sur l’organisation de la direction informatique de l’entreprise et l’exploitation d’une infrastructure distribuée et automatisée va induire de nouvelles pratiques, et même un changement de culture.

 

Ainsi, la frontière entre le build et le run (selon ITIL) disparaît. Cette approche est alignée avec la tendance DevOps (Development & Operations) avec Intégration et Livraison Continues (CI/CD). A noter que l’imbrication de la conception avec le déploiement en production des micro-services nécessite un champ très large de compétences.

 

Exemple concret de l’impact sur l’organisation : La taille de l’équipe responsable d’un micro-service est plus ou moins proportionnelle à la taille de ce micro-service. Chaque équipe, malgré sa taille réduite, doit pouvoir travailler de manière autonome. Amazon conseille de limiter la taille de l’équipe à une douzaine de personnes (two-pizza team !).

 

Les responsabilités nouvelles sont distribuées par micro-service, et sont étendues d’un bout à l’autre du cycle de vie du micro-service, c.-à-d. depuis la conception jusqu’à la production et même le support. Aussi faut-il raisonner en termes de Produit (alors qu’il s’agit d’un Service…), comme dans une méthode Agile, et non en termes de Projet, avec une fin planifiée.

 

Thierry BIARD

 

In theory, there is no difference between theory and practice, while in practice, there is.
Benjamin Brewster


28/04/2020
2 Poster un commentaire

Cas concret d’un Système d’Information urbanisé : Mango

 

Dans cette vidéo sous forme de présentation silencieuse de slides, vous découvrirez un exemple pédagogique illustrant les fondamentaux de l’urbanisation du Système d’Information allant même parfois jusqu’à montrer des rapports et des structures de données. 

Cette vidéo très détaillée convient bien à ceux qui recherchent des exemples de la vraie vie.

urbanisation-du-si-cas-mango

(extrait de la vidéo de Fatima-Zahra Yamani)

 

Les systèmes d'information dans l'entreprise - Cas Mango par Fatima-Zahra Yamani :

 

 

 

 

urbanisation-si_logo

 

 

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

“Maintenant que nous avons abouti à un paradoxe, nous avons des chances de progresser.”

Niels Bohr

 


14/09/2021
1 Poster un commentaire

La sélection d’urbanisation-si.com d’articles du web - 09 septembre 2021

 

 

Architecture et agilité : deux concepts incompatibles ?

 

Les architectes d’entreprise sont-ils en droit de se demander si un projet d'architecture peut se réaliser en mode agile avec des sprints soutenus ?

Après avoir rappelé les fondamentaux de l’architecture d’entreprise et de l’agilité, cet article répond par l’affirmative en montrant, avec des exemples à l’appui, que les deux se fortifient mutuellement.

 

Architecture et agilité : deux concepts incompatibles ?

 

 

5 conseils pour ré-architecturer vos applications pour le cloud

 

La migration d’une application vers le cloud peut comporter des pièges et le retour sur investissement ne sera pas garanti.

L’auteur de l’article décrit les bonnes pratiques pour faire un reengineering d’une application afin de profiter au maximum des avantages du cloud.

 

5 conseils pour ré-architecturer vos applications pour le cloud

 

 

RGPD : Un guide pratique pour les développeurs

 

La réglementation européenne RGPD (Réglementation Générale sur la Protection des Données - General Data Protection Regulation - GDPR en anglais) s'applique à tout le monde. Dans le cadre d’une entreprise importante, il est fort probable qu'un processus de mise en conformité soit en cours.

Cet article montre comment concevoir les modèles de données, leurs stockages, les flux associés, et les appels d'API tout en gardant à l'esprit la protection des données.

 

RGPD : Un guide pratique pour les développeurs

 

 

Quel framework d’architecture d’entreprise choisir ?

 

Quel est l'état de popularité des différents frameworks ?

Les architectes d’entreprise sont souvent interrogés sur le choix d'un framework d'Architecture d'Entreprise.

Le framework est à l’Architecture d’Entreprise ce que la boussole est au marin, il constitue une trame, un espace de langage commun, de coordination et de collaboration pour les acteurs, à partir duquel chaque entreprise bâtit sa démarche de façon itérative afin d’atteindre sa cible, c’est-à-dire une entreprise agile et résiliente.

 

Quel framework d’architecture d’entreprise choisir ?

 

 

Architecture d’Entreprise : vision métier ou technologique ?

 

Un des des objectifs de l’Architecture d’Entreprise est d’aligner la stratégie IT sur la stratégie Métier, de faire en sorte que la couche technologique supporte l’architecture métier. 

Cet article montre que l’Architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, si l’on prend le framework TOGAF, en comporte quatre (Business, Data, Application, Technology). 

 

L’architecture d’entreprise : vision métier ou technologique ?

 

 

Comment promouvoir une démarche d’architecture d’entreprise ?

 

Cet article, daté de 2015, de Dominique Vauquier, créateur et auteur principal de Praxeme, méthodologie de transformation d’entreprise, très en vogue en France, dans les années 2000, notamment avec les débuts de SOA (Service Oriented Architecture), n’a pas pris une ride. On se délecte du style adopté pour présenter d’une manière très pédagogique la théorie et la pratique de sa vision, parfois même philosophico-technique, de l’architecture d’entreprise.

L’article se conclut sur la définition, due à Thierry Biard (auteur de nombreux articles que vous pouvez découvrir sur ce site urbanisation-si.com : https://www.urbanisation-si.com/ )

« L’Architecture d’Entreprise permet de concevoir, du métier à la technique, l’Entreprise dans tous ses aspects. »

 

Comment promouvoir une démarche d’architecture d’entreprise ?

 

Bonne lecture.

 

 

urbanisation-si_logo

 

 

Rhona Maxwel

urbanisation-si

@rhona_helena

 

"Si vous voulez tuer une idée à coup sûr, créez un Comité pour l'évaluer."

Charles Kettering

 


09/09/2021
0 Poster un commentaire

CMMN (Case Management Model and Notation) : vie et mort d’une norme de l’OMG (Object Management Group)

La spécification date de fin 2016 et est, ou devrais-je plutôt dire “était”, destinée à venir en complément au BPMN (Business Process Model Notation). 

Seulement voilà, les compléments, demandant des efforts d’assimilation supplémentaires, les utilisateurs ont souvent tendance à s’en passer en les contournant, et au fil du temps, ils tombent dans les oubliettes.

Comme nombreux avant nous, nous allons donc démontrer que l’on peut se passer de CMMN en utilisant BPMN et les “sub-process ad hoc”.

cmmn-exemple-suspicion-de-fraude-a-la-mutuelle

(exemple pédagogique d'un dossier de suspicion de fraude à la mutuelle modélisé avec CMMN)

 

 

Objectifs de CMMN 

BPMN a été adoptée comme norme de modélisation des processus métier, qui sont décrits comme des séquences prédéfinies d'activités avec décisions (passerelles) pour diriger la séquence le long de chemins alternatifs ou pour des itérations. 

Ces modèles sont efficaces pour des processus métier prédéfinis, entièrement spécifiés et reproductibles. (Voir nos articles dans la catégorie BPMN)

 

Qu’en est-il de la modélisation d’activités qui ne sont pas prédéfinies et reproductibles, mais qui dépendent plutôt de l'évolution des circonstances et des décisions ad hoc des experts métier concernant une situation particulière ?

C’est en partant de ce manque dans les normes de modélisations que l’OMG a créé CMMN.

Les applications sont nombreuses, on peut citer par exemple : les traitements antifraude, la gestion des réclamations dans les assurances, les diagnostics médicaux…

 

Le kit de survie CMMN

Il fut un temps où nous aurions pu utiliser l’outil open source bpmn.io, qui proposait le tiercé gagnant de la modélisation : BPMN pour les processus métier, DMN (Decision Model Notation) (voir nos articles dans la catégorie DMN) pour les règles métier et CMMN pour les processus ad hoc et non reproductibles, mais aujourd’hui CMMN est absent de la plateforme.

 

Heureusement pour notre démonstration, l’outil Enterprise Architect de Sparx Systems supporte toujours CMMN, en plus de BPMN, DMN et bien d’autres choses encore pour notre plus grand bonheur. 

 

Comme cet article n’a pas pour vocation d’être exhaustif concernant la norme, voici donc les principaux artefacts de modélisation avec leur description :

 

cmmn-elements-de-modelisation-1

 

cmmn-elements-de-modelisation-2

 

Exemples de patterns CMMN

Enterprise Architect propose même un “Model Wizard” avec 3 patterns.

 

“Three Choice Tasks”

Ce pattern crée des éléments et un diagramme qui modélisent un choix simple où une tâche particulière doit être effectuée avant que d'autres tâches puissent être sélectionnées. La tâche sélectionnée dépend généralement de ce qui est déterminé dans la tâche précédente.

 

cmmn-omg-pattern-three-choice-tasks

(pattern CMMN “Three Choice Tasks”)

 

“Two Phase Expanded Case Plan”

Ce pattern crée des éléments et un diagramme qui contient un modèle de plan de cas composé de deux étapes dont chacune contient cinq tâches dont deux sont discrétionnaires. Les deux étapes sont déclenchées par deux événements différents et pourraient potentiellement s'exécuter simultanément.

 

cmmn-omg-pattern-two-phase-expanded-case-plan

(pattern CMMN “Two Phase Expanded Case Plan”)

 

“Basic Five Task Plan”

Ce pattern crée des éléments et un diagramme où un événement utilisateur déclenche une tâche humaine qui est terminée, puis un certain nombre d'autres tâches peuvent être terminées. Pour atteindre un jalon, une tâche humaine doit être terminée. À tout moment, un événement de minuterie pourrait être déclenché mettant fin à l'exécution du cas.

 

cmmn-omg-pattern-basic-five-task-plan

(pattern CMMN “Basic Five Task Plan”)

 

Modélisation CMMN d’un cas de suspicion de fraude à la mutuelle

L’exemple pour notre démonstration sera volontairement simplifié, pour être avant tout pédagogique et se concentrer sur les sous-processus ad hoc.

La nature des fraudes reste assez classique : ordonnances fausses ou trafiquées, déclarations mensongères, fausses identités...

A l'origine du soupçon, souvent un signalement par les gestionnaires, qui émane de leur intuition face à un dossier, car les algorithmes d'IA n’éprouvent pas (encore) de sentiments.

D’autres niveaux reposent sur des moteurs de machine learning.

 

La tâche humaine bloquante “Analyser les arguments et les pièces justificatives fournis” est une tâche ad hoc. En effet, le gestionnaire doit adapter les vérifications en fonction de la spécificité des affirmations et des pièces fournies par l’assuré.

A noter aussi la tâche humaine non bloquante “Lancer le moteur d'IA”, qui est facultative, en fonction par exemple du type de fraude.

 

cmmn-exemple-suspicion-de-fraude-a-la-mutuelle

(exemple pédagogique d'un dossier de suspicion de fraude à la mutuelle modélisé avec CMMN)

 

Modélisation BPMN du même cas de suspicion de fraude à la mutuelle

Pour arriver à la même sémantique, nous avons utilisé l’artefact BPMN “sub-process ad hoc” nommé “Sous-processus ad hoc pour analyser les dires de l'assuré” avec le sigle ~ (tilde) en bas de l'activité et l'événement intermédiaire interruptible (en pointillé) typé message : “L'entretien entraîne des vérifications spécifiques”.

 

 

bpmn-remplace-cmmn-exemple-suspicion-de-fraude-a-la-mutuelle

(le même exemple que précédemment, mais en utilisant BPMN en remplacement de CMMN)

 

Conclusion

La réticence aux changements, aux nouveautés, est présente partout.

Convaincre des experts métier de faire l’effort d’apprentissage d’une nouvelle notation comme CMMN, alors qu’on vient de leur infliger BPMN et qu’ensuite on leur a rajouté une couche avec DMN, en leur vendant que c’était complémentaire, est totalement une mission impossible. 

Les utilisateurs chercheront à s’en passer par tous les moyens.

Les solutions de contournement existent, comme nous l’avons démontré en utilisant les subprocess ad hoc de BPMN. 

D'autres défauts viennent s'ajouter, comme sa valeur limitée, la connaissance métier enfouie dans des règles invisibles, les artefacts de modélisation mal interprétés et rien n'est prévu pour montrer l'alignement de l'informatique avec le métier. 

CMMN rejoint donc le club des normes (CWM, KDM, VDML, MDMI, SBVR, SPEM...) qui n’ont pratiquement jamais été utilisées, car souvent trop complexes à mettre en œuvre et, en tous les cas, toujours boudées par les utilisateurs. 

 

urbanisation-si_logo

 

 

Rhona Maxwel

urbanisation-si

@rhona_helena

“On mesure l’intelligence d’un individu à la quantité d’incertitudes qu’il est capable de supporter”

Emmanuel Kant

 

Compléments de lecture


07/09/2021
2 Poster un commentaire

TOGAF : Retour d'expérience sur les phases Migration Planning F, Implementation Governance G et Architecture Change Management H

Parmi les critiques de TOGAF, une qui revient souvent concerne le manque d'exemples détaillés et de cas d'usage démontrant la praticité de ses recommandations. Cette vidéo devrait adoucir ce reproche.

 

SAFe-DevSecOps-approach

(extrait de la vidéo de Laurent Jordi)

 

De nombreux retours d'expérience sur les premières phases (A à E) de TOGAF sont présents sur internet, ceux concernant les 3 dernières : Migration Planning F, Implementation Governance G et Architecture Change Management H, sont nettement plus rares.

 

Vous trouverez donc dans cette vidéo, une mise en œuvre des phases "Migration Planning", une intéressante personnalisation de la phase "Implementation Governance" en intégrant le processus "DevSecOps" et pour finir la phase "Architecture Change Management".

 

Voici la vidéo de Laurent Jordi :

Cas d'usage : Modernisation d'une partie du SI d'un leader de la sécurité

 

La généricité de TOGAF ressort bien à travers cette vidéo. 

TOGAF n'impose rien, ce n'est qu'une boîte à outils de bonnes pratiques, et la méthode ADM (Architecture Development Method) doit être adaptée sans plus de précision.

Si vous recherchez un retour d'expérience de mise en œuvre, vous le trouverez dans cette vidéo.

Bien évidemment, les métiers et la DSI doivent conjointement définir l'architecture, puis c'est la vision de l'architecte d'entreprise qui permettra à chacun, grâce aux modèles et cartographies, d'avoir des vues correspondant à leurs enjeux

 

Rhona Maxwel

@rhona_helena

 

"Notre taux de réussite est actuellement trop élevé, nous devons prendre plus de risques, ..., essayer plus de choses folles, ..., et nous devrions déprogrammer plus de séries, globalement."

 

Reed Hastings (PDG de Netflix)

 

Articles conseillés :

 

 


31/08/2021
0 Poster un commentaire