Articles

Orchestration des micro-services avec BPMN

Pas de monolithe non plus dans la modélisation !

Image by Gerd Altmann from Pixabay

Il n’est pas question de vouloir reproduire en modélisation ce que l’on souhaite désormais éviter en architecture applicative : le monolithe. Pas de modélisation d’un unique processus généralement long. Préférez à la place la modélisation de plusieurs processus courts, avec une règle très simple à appliquer (quand la décomposition en micro-services a déjà était faite préalablement) :

- - 1 micro-service <==> 1 pool BPMN

Vous choisirez alors un diagramme BPMN de collaboration qui représentera les échanges entre les pools (micro-services) par des flux de messages.

Orchestration versus chorégraphie

Des micro-services autonomes et suffisamment intelligents pourraient, en communiquant directement entre eux, composer une chorégraphie d’apparence séduisante (bien que sans vision globale du processus). Ce serait sans compter sur la prise en charge des blocages qui pourraient survenir et des reconfigurations de processus métier, qui compliqueraient inévitablement cette chorégraphie.

Pour éviter les complications de la chorégraphie, il convient de privilégier la mise en place d’une orchestration de micro-services. Un processus principal, celui qui gère les interactions avec le Client (front-office) et nommé l’Orchestrateur, va commander les processus secondaires (micro-services en back-office), via des flux de messages adéquats. On comprend tout de suite que la reconfiguration d’un processus métier sera plus simple : seul l’ordre d’appel aux micro-services par l’Orchestrateur sera alors modifié ; aucun impact sur les micro-services eux-mêmes.

BPMN est souvent utilisé pour modéliser des processus métier relativement longs, mais les durées d’exécutions des tâches automatisées confiées à des micro-services peuvent être extrêmement courtes (mesurées en millisecondes). Cela ne pose pas de problème particulier : seule l’échelle du temps (non formalisée en BPMN) sera différente, plusieurs jours, mois, voire années, à l’échelle du processus métier en entier, contre quelques millisecondes à l’échelle de certaines tâches, celles exécutées par les micro-services.

Communications synchrones versus asynchrones

Les messages figurant sur un diagramme de collaboration peuvent représenter aussi bien des communications synchrones (protocole REST notamment) que des communications asynchrones (MQ par exemple). Ils semblent, par contre, peu adaptés pour représenter le data streaming (Kafka notamment). Mais l’éditeur Confluent notamment propose, sur sa plate-forme, l’API REST Proxy pour accéder au data streaming de Kafka.

Ce n’est pas l’objet principal de cet article, mais rappelons que les communications asynchrones entre les micro-services sont conseillées, afin de limiter le couplage et favoriser la mise à l’échelle d’une architecture micro-services.

La principale caractéristique du protocole de communication synchrone est d’attendre systématiquement un accusé de réception (bonne ou mauvaise). Mais il faut attendre cet accusé avant de continuer : cette attente peut durer longtemps dans certains cas (lors d’un pic de charge notamment) et bloquer la communication ; elle constitue l’exemple parfait d’un couplage fort. Le diagramme de collaboration simple ci-dessus représente des communications synchrones avec les micro-services.

Il existe toutefois des solutions, comme les modèles Circuit Breaker (disjoncteur) et Bulkheads (cloisons), pour limiter l’impact de ce couplage fort (pour aller plus loin, lire cet article de Rhona : https://www.urbanisation-si.com/solutions-sur-etagere-pour-la-gestion-des-defaillances-des-micro-services).

Par contre, avec un protocole de communication asynchrone, cet accusé de réception sera envoyé plus tard (lors d’une prochaine session de communication). L’attente de cet accusé ne sera donc pas bloquante. On imagine ici la difficulté de représentation dans un diagramme BPMN… Cet accusé est toutefois optionnel : on peut considérer par exemple qu’il n’y aura jamais de problème à déposer un objet métier dans une file d’attente, qui absorbera sans difficulté un pic de charge, et se dispenser alors de demander un accusé de réception, toujours bonne. Dans ce cas, le couplage n’en sera qu’encore plus faible. Mais l’accusé de réception n’est pas le résultat de l’appel au micro-service, qu’il faudra bien attendre.

BPMN pas seulement pour la modélisation !

Chaque micro-service n’est pas seulement représenté par un pool dans un diagramme de collaboration. Outre le fait que chaque micro-service doit disposer de son propre magasin de données (Data Store), conformément à l’un des principes fondateurs de l’Architecture Micro-Services, on peut encore améliorer son autonomie en lui donnant son propre moteur d’exécution (un moteur différent par micro-service, donc). C’est désormais possible avec des moteurs poids légers, comme le Camunda Workflow Engine.

Thierry Biard

12/05/2021

1 J'aime 3 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 ?

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

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

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

27/01/2021

0 J'aime 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 ?

(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 :

Modélisation de système

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 :

Architecture Micro-Services

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 :

UML

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 :

Modélisation de système

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 :

BPMN

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 :

ArchiMate

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

ArchiMate : le diagramme de contextes de projets, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 37

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 :

Le processus d'urbanisation du Système d'Information

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 :

SysML

Dans cet article se trouvent les articles traitant :

le contexte d'utilisation et la syntaxe des diagrammes SysML
un exemple complet composé de 12 articles pour illustrer l'utilisation des diagrammes
25 articles expliquant la méthode et les bonnes pratiques accompagnées d'un nouvel exemple complet
- SysML pour les nuls : de la modélisation des exigences à la réalisation du système

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)

- Architecture technique SOA
- Gouvernance 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 :

TOGAF

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

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

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

ArchiMate

BPMN

19/01/2021

0 J'aime 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)

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

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.

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/

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.

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 J'aime 0 Poster un commentaire

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

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

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) = NombreFonctions^3,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) =
NombreFonctions^3,11+ NombreDépendances^3,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

3 J'aime 1 Poster un commentaire

ArchiMate : le diagramme de contextes de projets, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 37

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Explications du diagramme de contextes de projets avec TOGAF utilisant le profil UML

Le diagramme de contextes de projets avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant :

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

Le diagramme TOGAF de contextes de projets utilisant ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF de contextes de projets utilisant le profil UML

Conclusion

Le diagramme de contextes de projets modélise tout ce qui nécessaire à la réalisation d’un projet.

Ce diagramme modélise le périmètre d’un projet faisant partie de la trajectoire de transformation.

Il montre :

les acteurs,
les flux d’information avec les autres applications internes et les systèmes externes,
l’implémentation : des processus métier, règles métier, entités métier, cas d’utilisation, composants applicatifs et services métier.

Les ajouts, modifications et suppressions d’entités au sens large doivent figurer sur le modèle.

Le modèle sert à l’initialisation des projets et à la gestion de portefeuilles applicatifs.

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :

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

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate.

Rhona Maxwel
@rhona_helena

"La conscience est la conséquence du renoncement aux pulsions."

Freud

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

06/11/2018

0 J'aime 0 Poster un commentaire

ArchiMate : le diagramme de bénéfices, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 36

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Explications du diagramme de bénéfices avec TOGAF utilisant le profil UML

Le diagramme de bénéfices avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant :

Le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF - étape 40 de l’exemple Modelio

Le diagramme TOGAF de bénéfices utilisant ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF de bénéfices utilisant le profil UML

Conclusion

Le diagramme de bénéfices modélise les possibilités d’amélioration avec leurs avantages et leurs inconvénients et participe à l'initialisation d'un nouveau cycle ADM (Architecture Development Method) de TOGAF.

Ce diagramme modélise les évolutions possibles et se positionne comme une base de travail pour étudier :

les apports en terme de valeur pour l’entreprise
le niveau de complexité
l’estimation de réalisation
les risques

Ce modèle participe à l’initialisation d’une nouvelle itération ADM.

Une analyse d’impacts sur la précédente itération doit être effectuée.

Les changements, les impacts et les objectifs seront répartis en nouveaux projets..

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :

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

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate.

Rhona Maxwel
@rhona_helena

"L'homme devrait mettre autant d'ardeur à simplifier sa vie qu'il en met à la compliquer."
Henri Bergson

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

30/10/2018

0 J'aime 0 Poster un commentaire

ArchiMate : le diagramme de matériel informatique en réseau, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 35

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Explications du diagramme de matériel informatique en réseau avec TOGAF utilisant le profil UML

Le diagramme de matériel informatique en réseau avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant :

Le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF - étape 39 du tutorial Modelio

Le diagramme TOGAF de matériel informatique en réseau utilisant ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF de matériel informatique en réseau utilisant le profil UML

ArchiMate Opportunities and Solutions Viewpoint

Conclusion

Le diagramme de matériel informatique en réseau modélise le déploiement des composants d’application, tous types confondus, dans une architecture technique distribuée.

Ce diagramme constitue une cartographie des infrastructures informatiques hébergeant les composants applicatifs ainsi que les acteurs accédant à ces composants.

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :

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

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate.

Rhona Maxwel
@rhona_helena

"L'homme n'est heureux que de vouloir et d'inventer."
Alain

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

24/10/2018

0 J'aime 0 Poster un commentaire

ArchiMate : le diagramme de traitements, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 34

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de traitements de la phase D Architecture technique de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Explications du diagramme de traitements avec TOGAF utilisant le profil UML

Le diagramme de traitements avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant :

Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio

Le diagramme TOGAF de traitements utilisant ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF de traitements utilisant le profil UML

Conclusion

Le diagramme de traitements modélise les unités déployables de code et configuration ainsi que leur déploiement sur la plate-forme technologique.

Ce diagramme montre comment les composants d’application sont déployés dans les unités de déploiement correspondant aux technologies utilisées (HTTP, BPM, Java/Jakarta EE, ...).

Afin de mettre l'accent sur les unités de déploiement, ce modèle utilise le déploiement de manière plus générique que le diagramme de réseau matériel et informatique dont on parlera dans le prochain article.

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :

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

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate.

Rhona Maxwel
@rhona_helena

"Le contentement apporte le bonheur, même dans la pauvreté. Le mécontentement apporte la pauvreté même dans la richesse."

Confucius

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

19/10/2018

0 J'aime 0 Poster un commentaire

ArchiMate : le diagramme d’environnement et de localisation, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 33

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Explications du diagramme d’environnement et de localisation avec TOGAF utilisant le profil UML

Le diagramme d’environnement et de localisation avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant :

Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio

Le diagramme TOGAF d’environnement et de localisation utilisant ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF d’environnement et de localisation utilisant le profil UML

Le ViewPoint Archimate : Technology Architecture ViewPoint

Conclusion

Le diagramme d’environnement et de localisation modélise les sites où sont installés les matériels dans lesquels sont déployés les applications.

Les technologies et / ou applications utilisées sont représentés ainsi que la manière dont les utilisateurs interagissent avec elles.

Les différents environnements de déploiement, y compris les environnements non liés à la production, tels que le développement et la pré-production doivent aussi être modélisés.

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :

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

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate.

Rhona Maxwel
@rhona_helena

"Le poète se fait voyant par un long, immense et déraisonné dérèglement de tous les sens."

Arthur Rimbaud

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

16/10/2018

0 J'aime 0 Poster un commentaire