urbanisation-si

urbanisation-si

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

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

N’abusez pas des Micros-Services et n’oubliez pas : sans DevOps et sans le Cloud, mieux vaut encore un bon vieux monolithe Java dans un serveur d’applications JEE ou COBOL dans un antédiluvien mainframe IBM. Les micro-services font le buzz, alors faut-il suivre cette tendance aveuglément ? N’y a-t-il pas des cas où ça équivaudrait à se tirer une balle dans le pied ?

micro-service-calcul-de-prestation-indemnite-journaliere

(Macro-modèle de la communication entre micro-services)

 

L’utilité des micro-services a été prouvée par un grand nombre d’entreprises de taille colossale (Netflix, Google…) qui les ont mis en œuvre pour résoudre une catégorie de problèmes liés à des cas d’utilisation bien particuliers.

 

Les limites des monolithes, comme celles des antédiluviennes applications COBOL sur mainframe, voire plus récemment Java dans les serveurs d’applications JEE, ont été atteintes en ce qui concerne, par exemple, leur gérabilité, leur évolution dans le Cloud, leur mise à l’échelle et la difficulté rencontrée à intégrer les méthodes agiles.

 

micro-service-et-monolithe

(Exemples de monolithes : les mainframe IBM et les serveurs d’application Java)

 

Certains d’entre vous reconnaîtront peut-être ce contexte d'architecture technique ci-dessus, montrant comment, au fil des années, les architectes techniques ont savamment fait un lifting du monolithe à coup de crème d’interfaces et de gateways. Cette couche cosmétique offre la possibilité à des applications de front office (client lourd ou client léger de type web) d’accéder aux dizaines de milliers de lignes de code COBOL enfouies dans les oubliettes du mainframe.


Les connaisseurs apprécieront le logiciel IBM ECI (External Call Interface) permettant à une application cliente d'appeler un programme CICS de manière synchrone ou asynchrone et le Saint Graal IBM CICS Transaction Gateway (CTG) qui est un connecteur conçu pour la modernisation des monolithes d’entreprise. Tous types d’applications Java JEE (renommer Jakarta depuis son transfert d’Oracle vers la fondation Eclipse), Microsoft .NET… peuvent communiquer avec CICS et des Web Services en COBOL.

 

Le tsunami de micro-services pourrait entraîner certains décideurs à les utiliser dans la conception et la réalisation de produits dans des contextes où ils ne sont pas censés être utilisés, entraînant dans certains cas des échecs.

 

Les microservices sans XOps (DevOps, DevSecOps, MLOps) ? Même pas en rêve !


Les microservices provoquent une explosion d'éléments (entités métiers, DAO/persistance, contrôleurs, sérialisation, annuaire/repository, gateway, load balancing, sécurité, logs, cloud...) à assembler. Ce n'est pas une bonne idée d'essayer de mettre en œuvre des microservices sans déploiement sérieux ni automatisation de la production du produit logiciel et de sa gouvernance. 


Vous devriez être en mesure d'appuyer sur le bouton de votre CI/CD (Intégration et Livraison Continues) et de déployer votre application. En fait, vous devriez même ne rien faire. Le code de validation doit faire déployer votre application via la gestion évènementielle de validation, qui déclenche le pipeline de livraison, au moins en développement.

 

Ne gérez pas votre propre infrastructure


Les microservices intègrent souvent plusieurs bases de données, brokers de messages, gestionnaires de caches de données et autres services qui doivent tous être maintenus en état opérationnel.

 

Pour cela, on a toute la panoplie du Cloud.

 

  1. Infrastructure as a Service (IaaS) dans lequel le fournisseur Cloud gère le matériel serveur, les couches de virtualisation, le stockage, les réseaux.
     
  2. Platform as a Service (PaaS) où le fournisseur maintient la plate-forme d'exécution de ces applications : les serveurs, les systèmes d'exploitation, les systèmes de bases de données et les infrastructures de réseau ainsi que de sauvegarde.
     
  3. Software as a Service (SaaS) est un modèle d'exploitation commerciale des logiciels dans lequel ceux-ci sont installés sur des serveurs distants plutôt que sur la machine de l'utilisateur.
     
  4. Function as a Service (FaaS) est une catégorie de services de Cloud qui fournit une plate-forme permettant aux clients de développer, d'exécuter et de gérer des fonctionnalités d'une application sans la complexité de la création et de la maintenance de l'infrastructure généralement associée au développement et au lancement d'une application. 
    Construire une application suivant ce modèle est un moyen de parvenir à une architecture « sans serveur » et est généralement utilisé lors de la création d'applications de micro-services. 

 

Ne créez pas trop de microservices


Chaque nouveau micro-service utilise des ressources. L'utilisation cumulative des ressources peut dépasser les avantages de l'architecture, si vous dépassez le nombre de micro-services que DevOps, l'organisation, le processus et le système peuvent gérer. Les rendre trop petits transfère la complexité des microservices vers une tâche d'intégration de services. 

 

N'oubliez pas de garder un œil sur le problème de latence potentiel


Rendre les services trop granulaires ou exiger trop de dépendances sur d'autres microservices peut introduire de la latence. Des précautions doivent être prises lors de l'introduction de microservices supplémentaires. Lors de la décomposition d'un système en micro-services autonomes plus petits, vous
augmentez le nombre d'appels passés au-delà des limites supportables par le réseau et par les CPUs, ce qui va dégrader les temps de réponse et le système de multithreading.

 

Ces appels peuvent être soit de service à service, soit de service à composant de persistance. Par conséquent, exécuter des tests de performance pour identifier les sources de toute latence dans l'un de ces appels est fondamental. De nombreux outils sont disponibles dans l’offre commerciale : on peut citer IBM Rational Performance Tester, Oracle Load Testing et dans l’open source très utilisé Apache JMeter. Vous devez identifier les goulots d'étranglement.

 

Conclusion

 

Ces anti-cas d’utilisation permettent d'éviter le battage médiatique des micro-services qui entraînerait des échecs sans certaines précautions. 


Ne donnons pas l’occasion aux détracteurs d'alimenter une polémique qui n’a pas raison d’être sur une technologie saine, aidant à l’agilité, réduisant le time to market et servant la stratégie de l’entreprise.

 

Pour finir, un dernier conseil : si la valeur de partage est une valeur universellement reconnue, ne l'appliquez pas aux micro-services qui ne doivent en aucun cas être liés à plusieurs systèmes différents.

 

 

Rhona Maxwel
@rhona_helena

 

 

"La courbe de tes yeux fait le tour de mon cœur,
Un rond de danse et de douceur,
Auréole du temps, berceau nocturne et sûr,

Le monde entier dépend de tes yeux purs
Et tout mon sang coule dans leurs regards."

Paul Eluard

 

Pour en savoir plus sur les micro-services :

 

  1. L’Architecture Micro-Services expliquée à ma fille
     
  2. Inconvénients de l'Architecture Micro-Services
     
  3. Estimation de la complexité d’une Architecture Micro-Services

 


27/01/2021
0 Poster un commentaire

Les meilleurs articles sur l’architecture d’entreprise, ses méthodes et ses outils, découvrez quels sont les articles les plus lus de notre blog

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

 

meilleurs-articles-architecture-entreprise-methodes-outils

 

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

 

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

 

10

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

 

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

 

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

 

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

 

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

 

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

 

 

9

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

 

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

 

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

 

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

 

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

 

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

 

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

 

8

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie UML de notre blog :

 

7

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

 

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

 

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

 

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

 

6

Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants

 

Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants

 

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

 

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

 

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

 

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

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

 

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

 

5

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie BPMN de notre blog :

 

4

ArchiMate pour les nuls : les fondamentaux - 1

 

ArchiMate pour les nuls : les fondamentaux - 1

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie ArchiMate de notre blog :

 

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

 

3

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

 

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

 

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

 

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

 

Voir la catégorie ArchiMate de notre blog :

 

2

SysML : le diagramme d'exigence (requirement diagram)

 

SysML : le diagramme d'exigence (requirement diagram)

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie SysML de notre blog :

 

Dans cet article se trouvent les articles traitant : 

 

1

TOGAF pour les nuls

 

And the winner is...

 

TOGAF pour les nuls

 

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

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

 

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

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

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

 

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

 

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

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

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

 

Voir les catégories de notre blog :

  • Architecture Orientée Services (SOA)

 

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

 

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

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

 

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

 

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

 

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

 

Voir la catégorie TOGAF de notre blog :

 

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

 

 

Rhona Maxwel

@rhona_helena

 

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

 

Références des principaux articles du blog

 

TOGAF

 

  1. TOGAF pour les nuls.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ArchiMate

 

  1. ArchiMate pour les nuls : les fondamentaux - 1

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

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

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

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

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

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

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

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

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

  11. ArchiMate : vues et points de vue - 11

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

 

BPMN

 

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

  2. BPMN pour les nuls : les collaborations

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

  4. BPMN pour les nuls : les conversations

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

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

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

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

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

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

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

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

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

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

 


19/01/2021
0 Poster un commentaire

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

« Les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. » Melvin Conway (Source Wikipédia)

 

conception-microservice-loi-de-conway-adoit-ce-visual-paradigm

 

(Mars Climate Orbiter est une sonde spatiale de la NASA lancée en 1998 pour étudier la planète. A la suite d'une confusion d'unités, la sonde se place en orbite trop basse et est détruite.

Un logiciel développé par les ingénieurs de Lockheed, concepteurs de la sonde, communiquait la poussée des micro-propulseurs en unités de mesure anglo-saxonnes (livre-force · seconde), tandis que le logiciel de l'équipe de navigation du JPL qui recevait ces données pour les calculs des corrections de trajectoire attendait des données en unités du système métrique (newton · seconde)).

 

 

Lorsqu'un système cible est décomposé en services, il existe un risque réel que sa décomposition s'aligne sur les silos ou les strates (cela dépend comment on voit les choses) existants au sein de l'organisation.

 
L’organisation des équipes a un effet direct sur le système que l’on conçoit. Les applications peuvent alors refléter les intérêts de l’organisation au détriment des réels besoins utilisateurs.
Ça signifie qu'il existe un risque pour que le système soit plus fragile, car il y a plus de modules indépendants à gérer et ne s’intégrant pas bien, même si le service résultant peut communiquer avec chacun d’entre eux.

 
De plus, si les services qui composent le système ne sont pas conçus pour le bon objectif, ils ne peuvent pas être réutilisés. Les coûts de développement et de maintenance peuvent également augmenter si les services sont conçus selon des périmètres organisationnels ou technologiques.

 
Une conception en ayant à l’esprit le métier comme unique objectif peut devenir critique. 

 
Les équipes, au-delà des frontières organisationnelles, doivent se réunir et concevoir les services conjointement, plutôt que d'utiliser des micro-services pour acheminer les appels entre les équipes.

 
Voici un extrait du contexte d’une de nos études de cas, qui nous sert comme POC pour tester des outils, illustrer des patterns ou des architectures comme les micro-services.

 
Pour avoir de la matière, nous avons choisi le monde assurantiel. Nous appellerons ClairPrev notre assureur fictif, résultant de nombreuses fusions/acquisitions et reflétant ce qui s'est passé ces derniers temps.

 

architecture-micro-services-loi-de-conway-visual-paradigm-free

 

Dans ce scénario, la conception du système a été calquée sur la structure de communication de l'organisation. Des défauts évidents apparaissent à cause de services isolés. 

 
Le système de prestation ne peut pas évoluer, car chaque domaine métier a son propre processus, chacun a sa propre vision de l’entité métier “Personne”. Chacun utilise des termes différents ou, pour une même entité métier, leur prête des sémantiques différentes.

 
Les services conçus dans ce scénario vont également être impactés par des changements qui affectent généralement une organisation, comme les aspects légaux, les fusions et acquisitions. 

 
Aujourd’hui, les exigences d’agilité dans les organisations et les systèmes sont devenues stratégiques. Tout change tout le temps, mais pas toujours au même moment. Un système n’est donc agile que s’il est possible de le faire évoluer par morceau. Il est d’autant plus agile que les morceaux sont plus petits et qu’ils sont faiblement couplés entre eux.

 
Les services ne doivent pas être évalués par chaque domaine, avec leurs propres paramètres de configuration, tests, performance, qualité, sécurité, time to market... 

 
L'architecture micro-services fonctionne bien si les architectes métier et techniques de chaque domaine communiquent entre eux pour concevoir les services conjointement, afin de servir les objectifs stratégiques de l’entreprise. 

 

architecture-micro-services-redesign-loi-de-conway-adoit-ce

 

Le diagramme ArchiMate ci-dessus montre un refactoring avec une approche architecture micro-services (AMS). A ce niveau d’échelle, on ne peut la différencier d’une architecture SOA (Service Oriented Architecture), qui de toute manière n’est que l’ancêtre de l’AMS.

 
En appliquant la loi de Conway, les équipes appartenant au domaine “Processus Transverses” se sont réunies pour concevoir un service amont de prestation. Lorsqu'une telle demande est reçue, elle est stockée, fournissant une vue unifiée de la personne (déclarant). Suivant les principes de la SOA, on ajoute un service d'orchestration (Service Orchestration de Prestation), qui reçoit la demande, puis selon les cas, appelle les services Santé, Prévoyance ou Services à la Personne. 

 
Ces appels activent ensuite chaque module de gestion de paiement.

 
Comme la conception des services ne suit plus les frontières organisationnelles, technologiques ou de communication, ils peuvent alors résister à des changements dans l'organisation, comme des fusions, des nouvelles réglementations nationales ou européennes, ainsi que le reengineering de processus. 

 
Les services sont indépendants et supportent des fonctions métier bien spécifiques.

 

Notes sur les outils utilisés

Visual Paradigm Free Edition

Pour ceux qui seraient intéressés par les outils utilisés pour des 2 diagrammes ArchiMate montrant les flux échangés entre blocs fonctionnels, le premier a été réalisé avec Visual Paradigm :

 

https://online.visual-paradigm.com/fr/diagrams/

 

Visual-Paradigm-Free-Edition

 

 

C’est la mallette “James Bond” du parfait consultant powerpointer qui doit dégainer des présentations avec des schémas sexy. Mais attention, ici point de référentiel d'artefacts d’architecture, d’outils de traçabilité, d’analyseur d’impact…, non non, juste du coloriage !

 

ADOIT:CE Community Edition

Le 2ème diagramme a été réalisé avec ADOIT:CE. Voir nos articles :

 

 

Là, par contre, c’est du lourd (bien qu’il s’agisse d'un client léger), avec, bien sûr, un référentiel d’objets, le support complet d’ArchiMate 3, des outils de traçabilité, bref la mallette du parfait cartographe.

 

ADOIT-CE

 

Conclusion

Nos systèmes, nos produits, nos outils reflètent nos rôles, nos processus et nos méthodes.

Pour enfoncer le clou, on peut citer, par exemple, Eric S. Raymond qui écrivait : "si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes".

 

Rhona Maxwel

@rhona_helena

 

" Sauriez-vous compléter la suite de Conway, John de son prénom :

1

11

21

1211

? "

 

A découvrir aussi

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.

 

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.

 

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

pour la comparer avec la complexité d’une architecture monolithique.

 

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

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 (compléments d’information)

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

 


12/01/2021
0 Poster un commentaire

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

pour la comparer avec la complexité d’une architecture monolithique.

20200703115506_01_recadrée

Dans notre premier article sur l’Architecture Micro-Services, nous avons indiqué parmi les principes que :

 

  • une application composée de micro-services serait plus simple et donc moins complexe qu’une application monolithique équivalente (c.-à-d. ayant les mêmes fonctionnalités).

 

Il s’agit là d’une sorte d’intuition, présentée comme un postulat. Pourrions-nous le démontrer ?

Postulats et formule magique

La programmation modulaire est apparue peu après les prémices de l’informatique, dès les années 1970, et quelques connaisseurs se sont intéressés à l’impact de la modularité sur la complexité d’un système. Cette complexité est liée au nombre de fonctions dans un système. Une constatation généralement faite par tous permet de formuler un second postulat :

 

  • la complexité d’un système croît exponentiellement avec le nombre de ses fonctions.

 

Comment quantifier cette croissance exponentielle ? Selon l’étude de Scott N. Woodfield en 1979 :

 

  • accroitre de 25 % le nombre de fonctions d’une solution logicielle double sa complexité.

 

Cette constatation est connue comme la loi de Robert L. Glass, qui porte le nom de celui qui l’a exprimée en 2003. Puis Roger Sessions l’a formulée ainsi en 2011, après une simplification mathématique justifiée : Complexité(NombreFonctions) = NombreFonctions3,11.

 

Dans le cadre d’une Architecture Orientée Services (SOA), il convient d’appliquer cette formule pour estimer la complexité de chaque partition, une partition étant un module contenant une ou plusieurs fonctions. Roger Sessions a constaté que la complexité dépendait également du nombre de dépendances entre les partitions-modules. La complexité totale est donc formulée ainsi :

 

ComplexitéTotale(NombreFonctions,NombreDépendances) =
NombreFonctions3,11 + NombreDépendances3,11

 

N.B. Afin de ne pas compter les dépendances deux fois, on les comptera au niveau de chaque module qui dépend d’autres modules (les pointes de flèches sur un diagramme de dépendances).

 

Vous noterez qu’une dépendance a la même pondération d’une fonction. L’unité de mesure est la SCU (Standard Complexity Unit). Il ne s’agit pas vraiment d’une mesure absolue, mais d’une mesure relative, qui va permettre de comparer la complexité des différentes solutions d’architecture d’un système.

Vers la simplexité ?

Appliquons cette formule d’estimation de la complexité à un exemple relativement simple. Soit une application de vente de livres en ligne, avec 5 fonctions principales :

 

  • Gestion des utilisateurs (les clients, mais aussi les libraires),
  • Catalogue des livres,
  • Avis des lecteurs,
  • Gestion des achats (paniers, commandes),
  • Vitrine (interface utilisateur).

 

Les dépendances entre ces 5 fonctions principales peuvent être représentées comme cela :

 

 

Comparons la complexité d’une application monolithique, qui contient ces 5 fonctions, avec une application où chaque fonction a été partitionnée en un micro-service :

 

 

On constate que l’estimation de la complexité de l’application micro-services avec ce partitionnement maximum est presque deux fois moins élevée que celle de l’application monolithique.

 

Considérons maintenant qu’il serait logique de regrouper l’avis des lecteurs avec le catalogue des livres, soit deux fonctions dans le même module-micro-service :

 

 

Ce regroupement divise encore par deux l’estimation de la complexité ! En effet, on obtient un module-micro-service un peu plus complexe, car contenant deux fonctions au lieu d’une seule, mais on supprime une dépendance, ce qui a un impact plus fort.

Compromis, chose due

Bien sûr, nous pourrions débattre sur le postulat de départ et notamment sur la valeur 3,11 de la puissance, qui traduit l’augmentation exponentielle de la complexité selon le nombre de fonctions. Mais une chose est sûre :

 

  • la complexité du système conçu ne sera maitrisée que si l’architecte trouve un compromis entre son partitionnement en modules et la dépendance entre ces modules.

 

Thierry BIARD

 

« En mettant au premier plan l'expérience vécue et le corps en action, la simplexité est également utile pour penser un environnement mieux adapté à l'homme. »
Petit traité de cyber-psychologie de Serge Tisseron


03/07/2020
1 Poster un commentaire