urbanisation-si

urbanisation-si

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

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

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

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 TOGAF de contextes de projets utilisant ArchiMate

   

archimate-le-diagramme-de-contextes-de-projets.png

    

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

     

togaf-le-diagramme-de-contextes-de-projets.png

  

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 :   

  

 

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 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 TOGAF de bénéfices utilisant ArchiMate

   

archimate-le-diagramme-de-benefices.png

    

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

     

togaf-le-diagramme-de-benefices.png

  

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 :   

  

 

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 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 TOGAF de matériel informatique en réseau utilisant ArchiMate

   

archimate-le-diagramme-de-materiel-informatique-en-reseau.png

    

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

     

togaf-le-diagramme-de-materiel-informatique-en-reseau.png

   

ArchiMate Opportunities and Solutions Viewpoint

 

archimate-opportunities-and-solutions-viewpoint.png

 

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 :   

  

 

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 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 TOGAF de traitements utilisant ArchiMate

   

archimate-le-diagramme-de-traitements.png
    

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

     

togaf-le-diagramme-de-traitements.png

   

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 :   

  

 

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 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 TOGAF d’environnement et de localisation utilisant ArchiMate

   

archimate-le-diagramme-d-environnement-et-de-localisation.png
 

   

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

     

togaf-le-diagramme-d-environnement-et-de-localisation.png

 

Le ViewPoint Archimate : Technology Architecture ViewPoint

 

archimate-architecture-technology-viewpoint.png

  

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 :   

  

 

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 Poster un commentaire

ArchiMate : le diagramme des données de service, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 32

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme des données de service de la phase C Architecture des Systèmes d'Information 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 des données de service avec TOGAF utilisant le profil UML

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

 

   

Le diagramme TOGAF des données de service utilisant ArchiMate

   

archimate-le-diagramme-des-donnees-de-service.png

   

Pour rappel et à fin de comparaison, le diagramme TOGAF des données de service utilisant le profil UML

     

togaf-le-diagramme-des-donnees-de-service.png

  

Conclusion   

Le diagramme des données de service est un diagramme de classe UML où les classe représentent les types des paramètres des messages (opérations) des services.

 

Tout ou partie des attributs d’une entités métier sera recopié dans les attributs d’un message.

Ce passage des paramètres par recopie entraîne un couplage faible entre les composants applicatifs qui est une des caractéristiques de l’architecture SOA (voir l'annexe 2 avec les articles consacrés à SOA).

       

 

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 :   

  

 

Voir en annexe 1 à 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
 

"Incarnez vous-même le changement auquel vous voulez que les autres aspirent."

Gandhi

   

  

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

 

 

 

Annexe 2 : l’architecture SOA (Service Oriented Architecture)

 


15/10/2018
0 Poster un commentaire

ArchiMate : le diagramme de migration des données, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 31

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de migration des données de la phase C Architecture des Systèmes d'Information 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 migration des données avec TOGAF utilisant le profil UML

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

 

   

Le diagramme TOGAF de migration des données utilisant ArchiMate

   

archimate-le-diagramme-de-migration-des-donnees.png

   

Pour rappel et à fin de comparaison, le diagramme TOGAF de migration des données utilisant le profil UML

     

togaf-le-diagramme-de-migration-des-donnees.png

  

Conclusion   

Le diagramme de migration des données a pour objectif de définir la transformation des données des applications source vers les applications cibles, il fournit  une représentation visuelle de la répartition des sources / cibles et sert d'outil pour l'audit des données et l'établissement de la traçabilité.

 

Le diagramme de migration des données explicite les écarts entre le système avant et après transformation du modèle source en cible.

Il permet la traçabilité et la vérification que toutes les données d’origine se retrouvent bien dans le système migré même si les méta-informations (attributs, classes) de ces données sont différentes.

 

       

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 :   

  

 

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
 

"C’est une belle harmonie quand le faire et le dire vont ensemble."

Michel Eyquem de Montaigne

  

  

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

 


12/10/2018
0 Poster un commentaire