urbanisation-si.com

La phase C Architecture des Systèmes d'Information de TOGAF doit mettre en place l’implémentation et l’exécution des constituants métier indépendamment de la phase D technique qui doit établir la correspondance physique et technologique avec les composants des phases précédentes.

La phase C est divisée en 2 : l’architecture des données et l’architecture applicative.

On retrouve les mêmes principes des autres méthodes d’architecture d’entreprise comme l’urbanisation du Système d’Information ou Praxeme qui sont :

• d’avoir une interface entre la couche métier et la couche technique, indépendante de celle ci, ce rôle est joué par la phase C.
• de faire correspondre à chaque bloc de données un bloc applicatif qui en est l’unique propriétaire et qui est le seul à pouvoir les modifier.

Voir l'article sur la phase C Architecture des Systèmes d'Information de TOGAF :

• 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)

Résumé des éléments de la couche application

Conclusion

La couche application est généralement utilisée pour modéliser les architectures des systèmes d'information de l'entreprise, y compris l'architecture de l'application qui, telle que définie par le framework TOGAF, décrit la structure et l'interaction des applications.

Rhona Maxwel
@rhona_helena

“On ne peut ni raisonner ni prévoir au sujet du bonheur : il faut l'avoir maintenant. Quand il paraît être dans l'avenir, songez-y bien, c'est que vous l'avez déjà. Espérer, c'est être heureux.”
Alain

Les mémentos d'Archimate :

• Quels sont les meilleurs langages et notations de modélisation pour TOGAF ?
   
• ArchiMate pour les nuls : les fondamentaux - 1
   
• ArchiMate la synthèse : les éléments de motivation - 2
   
• ArchiMate en condensé : les éléments de stratégie - 3
   
• ArchiMate l’essentiel : les éléments de la couche métier - 4

La couche métier associée avec les éléments de stratégie est définie par le cadre d'architecture d'entreprise TOGAF comme la description de la structure et de l’interaction entre la stratégie, fonctions, processus métier et besoins en informations.

Le métier avec ses exigences, ses processus et ses entités, gouverne l’architecture d’entreprise.
La phase B Métier permet de fixer l’architecture cible et de mesurer les impacts.

Par exemple, une optimisation ou carrément l’apparition d’un nouveau processus métier est décrite dans cette phase et montre les changements dans le travail des acteurs, dans les flux d’informations échangés et dans les services métiers.

La phase B Métier a donc pour objet :

• Les entités métier c’est les concepts cœur du métier et qui sont la base de la phase C Système d’Information
• Les processus métier, rouages centraux de l’efficience de l’entreprise et donc la base de l’architecture d’entreprise
• Les buts stratégiques et opérationnels
• L’organisation
• Les acteurs métier et leurs rôles

Voir l'article consacré à la phase B Métier de TOGAF :

• 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)

Résumé des éléments d'ArchiMate pour la couche métier

Conclusion

La phase B métier est modélisée comme toutes les autres phases suivant les points de vue des acteurs c’est-à-dire en fonction des sujets qui les intéressent et de leur niveau d’affinement

Rhona Maxwel
@rhona_helena

"Ils ne seront conscients qu’après s’être révoltés, mais ils ne se révolteront qu’une fois conscients."  

George Orwell

Les mémentos d'Archimate :

• Quels sont les meilleurs langages et notations de modélisation pour TOGAF ?
   
• ArchiMate pour les nuls : les fondamentaux - 1
   
• ArchiMate la synthèse : les éléments de motivation - 2
   
• ArchiMate en condensé : les éléments de stratégie - 3

ArchiMate  comprend un certain nombre d’éléments de stratégie, notamment la “capacité”, la “ressource” et le “plan d’action”.

Ils sont définis comme des spécialisations du comportement générique et des éléments de structure.

Ressource

La ressources est un concept central dans le domaine de la gestion stratégique, de l'économie, de l'informatique, de la gestion de portefeuille, etc.

Elles sont souvent considérées, avec les capacités, comme des sources d’avantages concurrentiels pour les organisations.

Les ressources sont analysées en termes de forces et de faiblesses (SWOT Strength, Weakness, Opportunity, Threat : Force, Faiblesse, Opportunité, Menace ; méthode fréquemment utilisée pour les évaluations) et sont prises en compte lors de la mise en œuvre des stratégies.

Les ressources étant limitées, elles peuvent souvent constituer un facteur décisif dans le choix de la stratégie, du but et du projet à mettre en œuvre et dans quel ordre.

Capacité

Dans le domaine des affaires, la réflexion et la planification stratégique fournissent des stratégies et des objectifs de haut niveau qui ne sont souvent pas directement applicables à l'architecture d'une organisation.

Ces plans à long terme ou génériques doivent être spécifiés et mis en œuvre de manière à ce que les chefs d’entreprise et les architectes d’entreprise puissent s’impliquer.

Les capacités aident à réduire cet écart en se concentrant sur les résultats métiers.

D'une part, ils fournissent une vue d'ensemble des capacités actuelles et souhaitées d'une organisation, en relation avec sa stratégie et son environnement.

D'autre part, ils sont réalisés par divers éléments (personnes, processus, systèmes, etc.) pouvant être décrits, conçus et mis en œuvre à l'aide d'approches de l'architecture d'entreprise.

Plan d’action

Un plan d'action représente ce qu'une entreprise a décidé de faire.

Les actions peuvent être classées en stratégies et tactiques.

Généralement, les buts sont soutenus par des stratégies et les objectifs sont réalisés par des tactiques.
Dans beaucoup d'entreprises il y a une continuité allant des stratégies majeures qui impactent tout le métier aux tactiques mineure avec des effets limités et locaux.

La ligne de démarcation entre la stratégie mineure et la tactique majeure est floue.

Aussi, au fil du temps, quelques plans d'action peuvent se développer de la tactique à la stratégie et quelques stratégies peuvent se transmettre dans la tactique.

D'autres entreprises utilisent d'autres bases pour distinguer des stratégies et la tactique.

Par exemple, quelques entreprises distinguent la stratégie et la tactique en terme de planification.

Dans ce cas, les stratégies sont mises en place pour supporter le long terme.
Les buts sont planifiés sur plusieurs années tandis que la tactique et les plans d'action sont mises en œuvre sur une année ou moins (les plans opérationnels actuels).

Et d'autres entreprises distinguent la stratégie, un plan d'action pour l'obtention d'un avantage spécifique, de la tactique, qui est plan d'action pour le déploiement de ressources spécifiques pour gagner un avantage.

Voir l’article sur BMM Business Motivation Model, la norme OMG, concernant vision, but, objectif, stratégie, tactique, ...

• BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, ...

Voir l'annexe à la fin de cet article sur l'ensemble de la norme BMM.

Résumé des éléments de stratégie

Relations entre les éléments de stratégie et la motivation et les éléments fondamentaux

Le métamodèle suivant montre comment les éléments de stratégie sont liés aux éléments de base et aux éléments de motivation.

Les éléments de comportement internes et externes peuvent réaliser des “capacités”, tandis qu'un élément de structure actif ou passif peut réaliser une “ressource”.

Les “capacités”, les “plans d'action” et les “ressources” peuvent réaliser ou influencer les “exigence”s (et, indirectement, les “principes” ou les “objectifs”) et un “plan d'action” peut également réaliser ou influencer un “résultat” (et aussi indirectement un “objectif”) ).

Voir les articles sur les éléments fondamentaux d'ArchiMate et l'extension Motivation :

• ArchiMate pour les nuls : les fondamentaux - 1
  
  
• ArchiMate la synthèse : les éléments de motivation - 2

Conclusion

Une stratégie représente plan d'action essentiel pour parvenir à ses fins et réaliser ses buts.

Une stratégie est plus que simplement une ressource, ou une compétence à laquelle l'entreprise peut faire appel ; c’est plutôt une approche acceptée par l'entreprise pour atteindre ses buts, étant donné les contraintes environnementales et les risques.

Une tactique est plan d'action qui détaille la stratégie.

Une tactique met en œuvre des stratégies.

La tactique canalise généralement des efforts vers les objectifs.

Rhona Maxwel
@rhona_helena

"Pour pouvoir prendre des paris risqués, il faut multiplier les essais. Et si vous faites des essais, vous ne pouvez pas savoir à l’avance si ça va marcher. De par leur nature même, ils sont rarement couronnés de succès. Cependant, il suffit de quelques réussites notables pour compenser les dizaines de tentatives qui auront échoué."

Jeff Bezos

Les éléments essentiels du langage ArchiMate se concentrent sur la description de l'architecture des systèmes prenant en charge l'entreprise. Il ne couvre pas les éléments qui, de différentes manières, pilotent la conception et l'exploitation de l'entreprise.

Pour pallier à ce manque, on a recours à l'extension Motivation correspondant à la colonne "Pourquoi" du cadre de Zachman.

Métamodèle des éléments de motivation

Plusieurs éléments de motivation sont inclus dans le langage: "partie prenante", "signification", "valeur",  "pilote", "évaluation", "objectif", "résultat", "principe" et "exigence" qui à son tour a une "contrainte" en tant que sous-type.

L'élément de motivation générique est aussi introduit.

Les éléments de motivation servent à modéliser les motivations ou les raisons qui guident la conception ou le changement d’une architecture d’entreprise.

Il est essentiel de comprendre les "facteurs", souvent appelés "pilotes", qui influencent d'autres éléments de motivation.

Ils peuvent provenir de l'intérieur ou de l'extérieur de l'entreprise.

Les facteurs internes, également appelés préoccupations, sont associés aux parties prenantes, qui peuvent être une personne ou un groupe, comme une équipe projet, une entreprise ou une société.

Des exemples de tels facteurs internes sont : 

• la satisfaction du client,
• la conformité à la législation
• la rentabilité.

Il est courant que les entreprises procèdent à une évaluation de ces facteurs. par exemple, en utilisant une analyse SWOT, afin de répondre au mieux.

Résumé des éléments de motivation

Relations entre les éléments de motivation et les éléments principaux

Le but des éléments de motivation est de modéliser la motivation sous-jacente aux éléments fondamentaux d'une architecture d'entreprise.

Par conséquent, il est possible de relier les éléments de motivation aux éléments de base.

Comme le montre le métamodèle suivant, une "exigence" (et indirectement aussi un "principe", un "résultat" et un "objectif") peut être directement liée à une structure ou à un élément de comportement au moyen d’une relation de réalisation.

En outre, la relation d'influence la plus faible est autorisée entre ces éléments.

La "signification" et la "valeur" peuvent être associées à tout élément de structure ou de comportement.

Un "acteur métier" peut être affecté à une "partie prenante", ce qui peut être considéré comme un rôle de motivation (par opposition à un rôle opérationnel) qu'un acteur peut remplir.

Similitude avec BMM Business Motivation Model, la norme OMG

La stratégie et les éléments de motivation d'ArchiMate ont été inspirés en partie par BMM Business Motivation Model, la norme OMG qui est le modèle de motivation des entreprises.

La norme BMM fait la distinction entre les "moyens", les "fins" et les" influenceurs" et les "évaluations".

Elle fournit des concepts assez détaillés pour ces catégories.

L'élément “manières de procéder” ("CourseOfAction") d’ArchiMate correspond directement au même élément de BMM, alors que ses concepts de "directive" peuvent être modélisés avec le "principe", "l'exigence" et les "éléments de contrainte" d'ArchiMate.

Les concepts BMM pour les “fins” sont généralement mappés sur l'élément “objectif” d’ArchiMate.

Les "influenceurs" (ou "facteurs d’impact") BMM correspondent à l'élément ArchiMate “pilote”, alors que les "évaluations" BMM sont directement associées à l'élément d'évaluation ArchiMate.

Bien qu'un mappage entre de nombreux éléments de motivation d'ArchiMate et les concepts BMM soit possible, BMM fournit une description plus détaillée de la motivation.

Lorsque le langage ArchiMate vise à couvrir un large champ et à interconnecter différents domaines, BMM, plus spécialisé, effectue un zoom avant sur les détails de son domaine spécifique.

Voir en annexe les articles se rapportant à la norme BMM.

Conclusion

Un concept fondamental est qu'une entreprise est pilotée non pas par les changement, mais comment elle décide de réagir à ces changements.

La prise en compte des changements quand on les a prévus et l'évaluation de leur impact sur l'entreprise est cruciale.

L'idée est de développer un modèle métier pour les éléments des plans de développement avant de commencer la conception de système ou le développement technique.

Les plans de développement métiers deviennent alors la base pour une telle activité, connectant des solutions de système à leurs intentions métiers.

Les entreprises ne font pas, ou ne doivent pas faire un acte aléatoirement.

Quand une entreprise exécute un processus métier ou applique une règle de gestion, elle devrait pouvoir le justifier.

Rhona Maxwel

@rhona_helena

"Je ne suis rien, je le sais, mais je compose mon rien avec un petit morceau de tout."
Victor Hugo

Annexe : BMM Business Motivation Model, la norme OMG du modèle de motivation des entreprises

• BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
   
• BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, ...
   
• Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
   
• Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
   
• Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques

Le langage de modélisation ArchiMate fournit une représentation uniforme des diagrammes décrivant les architectures d'entreprise.

Il comprend des concepts permettant de spécifier des architectures interdépendantes, des points de vue spécifiques pour des parties prenantes sélectionnées et des mécanismes de personnalisation de langage.

Il propose une approche architecturale intégrée qui décrit et visualise différents domaines d’architecture et leurs relations et dépendances sous-jacentes.

Son framework fournit un mécanisme de structuration pour les domaines, les couches et les aspects de l'architecture.

Il fait la distinction entre les éléments du modèle et leur notation, pour permettre des représentations variées et orientées vers les préoccupations des parties prenantes sur les informations d’architecture.

Le langage s’appuie sur l’architecture orienté service (SOA) pour distinguer et relier les couches métier, applicative et technologique des architectures d'entreprise et utilise des relations de réalisation pour relier des éléments concrets à des éléments plus abstraits sur ces couches.

Les 3 dimensions du cadre : couches, aspects et composite

Couches

Les trois niveaux auxquels une entreprise peut être modélisée dans ArchiMate :

• Métier,
  
• Application
• Technique

Aspects

• L'aspect de la structure active représente les éléments structurels (les acteurs de l'entreprise, les composants de l'application et les dispositifs qui génèrent un comportement réel, à savoir les "sujets" de l'activité).
  
  
• L'aspect comportemental représente le comportement (processus, fonctions, événements et services) effectué par les acteurs. Les éléments structurels sont affectés à des éléments comportementaux pour montrer qui ou quoi déclenche le comportement.
  
  
• L'aspect de la structure passive représente les objets sur lesquels le comportement est effectué. Ce sont généralement des objets d'information dans la couche de gestion et des objets de données dans la couche application, mais ils peuvent également être utilisés pour représenter des objets physiques.

Les trois types d'éléments, reliés par des relations, peuvent former des phrases de toutes sortes.

Par exemple : un gestionnaire (structure active) crée (comportement) une rente d’invalidité (structure passive)

C'est ce qui fait d’ArchiMate une grammaire, bien qu’on l'appelle généralement un langage.

La structure de la grammaire ArchiMate est en partie basé sur le modèle sujet-verbe-complément de la langue naturelle.

Au travers de vos modèles, vous racontez une histoire : qui agit sur quoi.

Un élément composite

Il s’agit d’un élément qui ne rentre pas nécessairement dans un seul aspect du cadre, mais peut combiner plusieurs aspects.

Utilisation de couleurs et d’icône de notation

Couleurs

Dans les métamodèles de la norme, les nuances de gris permettent de distinguer les éléments appartenant aux différents aspects du cadre ArchiMate :

• Blanc pour les concepts abstraits (c'est-à-dire non instanciables)
  
  
• Gris clair pour les structures passives
  
  
• Gris moyen pour le comportement
  
  
• Gris foncé pour les structures actives

Dans les modèles ArchiMate, aucune sémantique formelle n’est attribuée aux couleurs et l’utilisation de la couleur est laissée au modélisateur.

Cependant, ils peuvent être utilisés librement pour souligner certains aspects des modèles.

Par exemple, il est d’usage d’utiliser les couleurs suivantes pour distinguer les couches du Framework ArchiMate :

• Jaune pour la couche métier
  
  
• Bleu pour la couche application
  
  
• Vert pour la couche technologique

Les icônes

En plus des couleurs, une lettre «M» (Motivation), «S» (Strategy), «B» (Business), «A» (Application), «T» (Technology), «P» (Physic) ou «I» (Implementation et Migration) dans le coin supérieur gauche d’un élément peut être utilisée.

La notation standard utilise également une convention avec la forme des coins de ses symboles pour différents types d'éléments :

• Les coins carrés sont utilisés pour désigner les éléments de structure.
  
  
• Les coins arrondis sont utilisés pour désigner les éléments de comportement.
  
  
• Les angles diagonaux sont utilisés pour désigner les éléments de motivation.

Synthèse des éléments de structure et de comportement

Synthèse des relations génériques d’ArchiMate

ArchiMate définit un ensemble de relations génériques, chacune pouvant connecter un ensemble prédéfini de concepts source et cible (dans la plupart des cas, mais aussi dans quelques cas, d'autres relations). .

Beaucoup de ces relations sont "surchargées", c'est-à-dire que leur signification exacte diffère selon les concepts source et de destination auxquels elles se connectent.

Les relations sont classées en :

• Relations structurelles qui modélisent la construction statique ou la composition de concepts de types identiques ou différents
  
  
• Relations de dépendance qui modélisent la manière dont les éléments sont utilisés pour prendre en charge d’autres éléments
  
  
• Relations dynamiques utilisées pour modéliser les dépendances comportementales entre les éléments
  
  
• Autres relations qui ne relèvent pas de l’une des catégories ci-dessus.

 

Exemples

Contexte

Description de l'étude de cas "Discount Travel"

Vous la trouverez au paragraphe : "Description de l’étude de cas" de l'article suivant :

Pour les explications, voir l'article qui traitait du diagramme avec le profil UML :

• Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)

Et voici le diagramme ArchiMate correspondant établit dans le point de vue "Vision" de TOGAF :

Diagramme ArchiMate des concepts de la solution de la phase A Vision de TOGAF

Conclusion

Pour chacune des 3 couches d'architecture d'entreprise : Métier, Application, Technique, vous devez spécifier les 3 aspects : structure active, comportemental, passive pour signifier "qui agit sur quoi".

Comme on vient de le voir aux travers des exemples, le langage ArchiMate a tiré un certain nombre de concepts d'UML. 

Pour d'autres concepts, des correspondances simples peuvent être définies.

Rhona Maxwel

@rhona_helena

“Vivre, c'est ne pas se résigner.”
Albert Camus

TOGAF est un cadre méthodologique générique pour l’architecture d’entreprise, il propose une liste d’artefacts facultatifs non exhaustive, mais n’impose aucune technique ni méthode et il est fortement recommandé d’en prendre et de les adapter.

Doit on alors absolument utiliser une multitude de normes et réaliser un travail d’adaptation complexe ou tout simplement prendre la voie du pragmatisme et choisir le langage de TOGAF, ArchiMate, prêt à l’emploi et simple d’utilisation mais non reconnu comme norme ?

Les normes rien que les normes, réservées aux experts en modélisation avec un budget d’adaptation et d’intégration.

L’étude de cas “Discount Travel” de l’open source Modelio a fait l’objet de plus de 40 articles.

Voir le dernier article référençant l'ensemble 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 )

Pour couvrir la modélisation des différentes phase ADM de TOGAF, nous avions utilisé exclusivement des normes de l’OMG :

• UML (Unified Modeling Language),
• SysML (System Modeling Language, qui est un profil UML)
• BPMN (Business Process Model And Notation).

Le métamodèle TOGAF définit les concepts fondamentaux.

Voir l'annexe 1 : Le métamodèle TOGAF

L'implémentation de ces concepts de base, est réalisée dans un profil, seul possibilité d’extension d’UML.

Qu'est ce qu'un profil UML ?

Un profil est un ensemble de stéréotypes, de tagged-value et de contraintes OCL.

Un stéréotype est la possibilité de redéfinir un artefact de modélisation sans en changer la sémantique UML.

Par exemple, sur l’artefact UML “composant”, on peut définir le stéréotype “composant d’application d’entité” en précisant ses caractéristiques et éventuellement une icône le représentant visuellement.

Les tagged-value permettent de définir sur un élément, des méta-information sous forme de paires clé=valeur comme par exemple sur un composant UML :  “complexité=simple”.

Le langage OCL (Object Constraint Language) permet de mettre des règles s’appliquant sur le modèle.

Voir nos articles en annexe 2 : Le langage de contraintes OCL

Par exemple un voyageur ne peut pas être dans 2 hôtels différents à la même date.   

Nous avons vu au cours de l’étude qu’il fallait adapter et filtrer tous ces langages pour correspondre aux concepts et à la structure de TOGAF.

Voir en annexe 3 les articles dans lesquels les stéréotypes utilisés dans les phases ADM ont été définis.

Trois normes OMG pour TOGAF : UML, SysML et BPMN !

Par exemple UML, SysML et BPMN ne possèdent pas de concept de point de vue, notion fondamentale de TOGAF.

En UML, l’artefact le plus approprié pour modéliser un point de vue est le package.

UML est une boite à outil généraliste, on peut tout modéliser à condition de personnaliser les éléments du langage.

Pour TOGAF, la plupart des artefacts UML (classe, attribut, méthode, objet, package, cas d’utilisation, acteur, composant, port, interface, noeud, association, dépendance, …) ont été utilisés.

Pour qu’ils correspondent aux éléments de TOGAF, il a fallu les stéréotyper.

En ce qui concerne SysML, son diagramme d’exigences, unanimement reconnu comme la meilleure pratique, a été choisi pour modéliser cet aspect.

BPMN conçu spécifiquement pour les MOA pour modéliser les processus métier, il est évident de l’utiliser pour pour la partie processus de TOGAF.

Ces choix de langages et notations de modélisation ont été fait sur le critère principal que ce sont des normes acceptées et largement utilisées dans le monde entier aussi bien dans l’ensemble des domaines métier que par les éditeurs d’outils.

On trouve donc aujourd’hui une offre très large d’outils de modélisation supportant ces normes allant des open source aux versions commerciales.

En plus ces outils vont bien plus loin que d’offrir de la simple modélisation.

Ils mettent en place la vérification, la simulation et la transformation des modèles, la génération de code, la gestion d’un référentiel, dictionnaire, planification, traçabilité, estimation, génération de documentation, …

Mais est ce suffisant ?

En plus des 3 normes UML, SysML et BPMN, pour vraiment modéliser dans les règles de l’art et en suivant les recommandations de l’OMG, on pourrait ajouter dans l’étude de cas :

• BMM Business Motivation Model, voir l'annexe 4 
• DMN Decision Model and Notation, voir l'annexe 5 
• SoaML Service Oriented Architecture Modeling Language

Juste pour information, car ça commence à faire beaucoup, je cite d’autres normes complémentaires, peu utilisées mais très intéressantes et définissant bon nombre de concepts et bonne pratiques.

• CMMN Case Management Model and Notation : complète BPMN pour les cas d’utilisation, par exemple certaines activités d’un processus BPMN peuvent demander une séquence d’actions ad hoc à un acteur.
• VDML Value Delivery Modeling Language : langage de modélisation standard pour l'analyse et la conception du fonctionnement d'une entreprise, en mettant l'accent sur la création et l'échange de valeur
• OSM Organization Structure Metamodel : l’objectif principal est de permettre une représentation robuste de la structure d’une organisation, y compris les relations formelles qui vont au-delà de la structure hiérarchique traditionnelle.
• ODM Ontology Definition Metamodel : la spécification définit une famille de méta modèles indépendants, de profils associés et de correspondances entre les métamodèles de plusieurs normes internationales pour l’ontologie et les paradigmes de modélisation conventionnels pour la capture de connaissances conceptuelles, telle que la modélisation entité-relation.

Cela fait beaucoup de normes !

Mais cela ne signifie en aucun cas de toutes les utiliser à tout prix.

Le théoricien et le puriste s’y intéressent, mais les décideurs d’entreprise ont des critères beaucoup plus pragmatiques et orientent leurs choix sur des solutions concrètes répondant juste à leurs besoins avec des retours d’expérience de mise en production réussie par la concurrence.

La logique voudrait qu’on utilise uniquement ces normes de l’OMG car elles constituent un véritable espéranto permettant à l’ensemble des acteurs d’une entreprise de communiquer.

L’intérêt est aussi de pouvoir s’adresser à une large communauté d’utilisateurs connaissant déjà UML et BPMN.

Installer un profil UML, les ennuis commencent !

Le nombre d’outils ayant fait leurs preuves et supportant ces normes est important aussi bien en gratuit/open source qu’en version commerciale.

Mais comme on vient de le voir, il y a beaucoup d’effort à fournir pour personnaliser ces normes afin de les adapter aux concepts de TOGAF.

Par exemple, l’ensemble des stéréotypes utilisé dans l’étude de cas est regroupé dans un profil UML nommé EAP (Enterprise Architecture Profil), en open source mais spécifique à l’outil Modelio.

Pour l’utiliser dans un autre outil, vous devez, télécharger le profil en choisissant le format, puis l’importer. :

• Profil EAP (format XMI OMG UML 2.1.1)
• Profil EAP (format XMI EMF UML 3.0.0)

Mais premier problème, quel profil choisir ?

Si vous n’êtes pas expert en modélisation, passez votre chemin.

XMI (XML Metadata Interchange) est une norme de l’OMG (décidément on ne les compte plus) définissant un format XML permettant d’avoir une représentation textuelle d’un modèle UML.

XMI définit l’aspect syntaxique, et l’aspect sémantique c’est à dire les éléments (classe, association, acteur, état, …) est défini par le métamodéle UML.

L’OMG définit une architecture en 4 couches, nommée MOF (Meta Object Facility).

Le niveau 0 représente le monde réel, les objets, le niveau 1 : le modèle, le niveau 2 : le métamodèle (modèle du modèle) et le 3ème : le métamétamodèle qui s’auto définit et permet de s’arrêter là.

Voir l'annexe 6 : les méta modèles

L’objectif est double, d’abord permettre l’exportation/importation d’un modèle entre différents outils de modélisation ensuite de donner la possibilité à des outils de pouvoir transformer les modèles en parsant ces fichiers XML soit par XSLT soit par des langages spécifiques à MDE (Model Driven Engineering) comme ATL (voir Annexe 7 : Un cours exhaustif en français sur ATL (Atlas Transformation Language) ) ou  QVT (voir Annexe 8 : Exemple complet des possibilités de QVT (Query View Transform) ).

S’il n’y avait qu’un seul métamodèle et qu’un seul choix mais malheureusement ce serait trop simple, il y a un autre standard de l’industrie qui n’est passé pas au stade de norme, nommé “Ecore” faisant partie de la galaxie des opens source de la modélisation EMF (Eclipse Modeling Framework).

Ecore est un métamodèle conçu pour être plus simple que la norme MOF et que l’on peut vraiment utiliser et il est supporté par beaucoup d’outils fonctionnant sous Eclipse, comme ATL, QVT, Sirius, … mais aussi par la majorité des outils commerciaux comme IBM, Oracle, ...

A cause de sa simplicité et de son utilisabilité, Ecore a eu la faveur de l’industrie qui a délaissé la norme MOF trop complexe et trop coûteuse à mettre en oeuvre comme bien souvent pour les normes.  

Il vous faudra donc vérifier que votre outil de modélisation supporte XMI MOF ou EMF Ecore.

Mais pas seulement, car une fois choisi, se pose le problème de la version.

Deuxième problème, qui dit version, dit risque d’incompatibilité !

Concernant XMI OMG, il existe plusieurs versions, la dernière étant la 2.5.1.

Si votre outil de modélisation ne supporte pas une version supérieure ou égale à la version téléchargée, le profil ne pourra pas être importé et vous ne pourrez pas l’utiliser.

Il vous faudra alors soit trouver un outil supportant la version ou bien tout recréer manuellement !

Ecore est stable, la dernière version date de 2014.

A l’inverse de ces normes, on trouve un langage de modélisation spécifique à TOGAF : ArchiMate.

Vous désirez directement modéliser TOGAF de la manière la plus efficiente, alors c'est ArchiMate qu'il vous faut.

Si vous ne connaissez pas UML, si vous ne maîtrisez pas le concept de profil, de métamodèle, si vous ne voulez pas prendre de risques d’importation de profil ou réaliser une adaptation manuelle et si pour vous l’utilisation des normes n’est pas une obligation : alors la solution à tous ces problèmes est  ArchiMate.

ArchiMate publié par l’Open Group, est un langage de modélisation entièrement dédié à l’architecture d’entreprise et dont les concepts correspondent exactement à ceux de TOGAF.

Avantages :

• Par exemple ArchiMate propose des point de vue tels qu’ils sont spécifiés dans TOGAF.
• Si vous connaissez TOGAF, vous n’aurez aucun mal à maîtriser ArchiMate.
• Vous n’avez aucun profil à télécharger, d’adaptation à faire.
• Beaucoup d’outils existent, en open source comme Archi de l’éditeur Archimatetool, ou commerciaux comme Enterprise Architect de Sparx Systems, ModelioSoft, Obeo SmartEA, Bizzdesign, Visual Paradigm, …

Inconvénients :

Si l’avantage d’ArchiMate est simple et peut être rapidement utilisé, il a aussi un principal défaut :

• il n’est pas aussi complet que les normes OMG. notamment ArchiMate ne détaille pas les processus et règles métier. 
  La bonne pratique utilisée par les éditeurs est de combiner ArchiMate avec BPMN pour modéliser les processus, sachant que BPMN est prêt à l’emploi et ne nécessite pas l’importation de profil.

Dans la prochaine version 10 de TOGAF, il est à parier qu’ArchiMate sera complètement intégré dans le framework.

Conclusion

Soit vous êtes dans un environnement où tout est normalisé et l’utilisation des normes vous est imposée, et dans ce cas un profil UML pour TOGAF est la meilleure solution.

Il vous faudra alors choisir un profil existant, mais cela comporte des risques de maintenabilité et d’intégration ou bien vous décidez de créer votre profil UML mais cela va vous demander des compétences en métamodélisation ce qui n’est pas forcément votre métier sans parler du coût et de la charge de travail.

Vous êtes libre d’utiliser les outils que vous voulez, vous ne voulez pas vous embarrasser de détails techniques, vous désirez un formalisme synthétique pour modéliser directement en appliquant les recommandations TOGAF avec le moindre effort et à moindre coût, alors utiliser ArchiMate.

La meilleure pratique est un compromis consistant à utiliser ArchiMate et pour les processus métier BPMN.

Nous reviendrons sur une présentation d’ArchiMate (AchiMate pour les nuls) et nous ferons une correspondance avec les modèles UML de l’étude de cas “Discount Travel” dans les prochains articles.

Rhona Maxwel

@rhona_helena

“Si je recommençais ma vie je tâcherais de faire mes rêves encore plus grands ; parce que la vie est infiniment plus belle et plus grande que je n'avais cru, même en rêve.”
Georges Bernanos

Annexe 1 : Le métamodèle TOGAF

• Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
• Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
• L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
• L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
• L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
• L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

Annexe 2 : Le langage de contraintes OCL

• Modélisation de système : comment utiliser OCL avec Eclipse, c'est bien la question que tout le monde se pose
  
• Modélisation de système : UML n'est rien sans OCL !
  
• Modélisation de système : OCL ça se complique !
  
• Modélisation de système : OCL vous en redemandez ?
  
• Modélisation de système : tutoriel OCL, la gestion des évènements

Annexe 3 : Les stéréotypes utilisés dans les phases ADM

• Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
• Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio
• Le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF - étape 40 de l’exemple Modelio

Annexe 4 : BMM Business Motivation Model

• BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
  
• BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, ...
  
• Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
  
• Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
• Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques

Annexe 5 : DMN Decision Model and Notation

Concepts de base 

• Quels sont les objectifs et les concepts de la notation de modélisation des règles métier, DMN Decision Model and Notation ?
  
• Et voici les concepts de bases pour bien comprendre la modélisation des règles métiers avec DMN ( Decision Model Notation )
  
• Apprenez le niveau logique de décision de la norme de modélisation de règles métiers DMN ( Decision Model Notation )
  
• Introduction au graphique DRG et au diagramme DRD d'exigences de décisions de la norme de modélisation de règles métiers DMN
  
• DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation de la décision
• DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des règles de connexions
• La norme DMN ( Decision Model and Notation ) pour les tables de décision
  

Exemple allant des modèles jusqu’à leur exécution :

1. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
2. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions
3. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision
4. 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
5. DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?
   

Exemple d'utilisation d'un métamodèle : pour aller plus loin avec DMN, nous avions même consacré un tutorial archi complet sur comment concevoir un outil de modélisation DMN :

1. DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
   
2. Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]
   
3. Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
   
4. Améliorations et notions avancées Eclipse Sirius, suite et fin de notre saga : comment concevoir son propre outil de modélisation DMN ? [4/4]

Annexe 6 : Les méta modèles 

• Model-Driven Engineering (MDE) : modèles, métamodèles, métamétamodèles, méta... ?

• Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), concevez les métamodèles avant de passer aux choses sérieuses

• Urbanisation SI : comment marche le méta-modèle ?
• Transformation de modèles et Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture)

• Eclipse Modeling Framework (EMF) : revoyons les fondamentaux

• Ingénierie Dirigée par les Modèles (IDM) : tutoriel Eclipse Ecore, le corps à corps avec les méta modèles

Annexe 7 : Un cours exhaustif en français sur ATL (Atlas Transformation Language)

1. Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), concevez les métamodèles avant de passer aux choses sérieuses
   
2. Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), le "Da Vinci code" de la transformation ATL
   
3. Ingénierie Dirigée par les Modèles (IDM) : documentation ATL (ATLAS Transformation Language), vous saurez tout ou presque sur les modules
   
4. Ingénierie Dirigée par les Modèles (IDM) : cours complet sur ATL (ATLAS Transformation Language)
   
5. Ingénierie Dirigée par les Modèles (IDM) : cours complet sur ATL (ATLAS Transformation Language) : librairie ATL
   
6. Ingénierie Dirigée par les Modèles (IDM) : cours complet sur ATL (ATLAS Transformation Language) : les types ATL
   
7. Cours complet sur ATL (ATLAS Transformation Language) : les types primitifs
   
8. Cours complet sur ATL (ATLAS Transformation Language) : les collections
   
9. Cours complet sur ATL (ATLAS Transformation Language) : les énumérations
   
10. Cours complet sur ATL (ATLAS Transformation Language) : les tuples
    
11. Cours complet sur ATL (ATLAS Transformation Language) : les éléments de modèles des métamodèles
    
12. Cours complet sur ATL (ATLAS Transformation Language) : Les expressions déclaratives dans OCL / ATL
    
13. Cours complet sur ATL (ATLAS Transformation Language) : quelques trucs et astuces sur les expressions
    
14. Cours complet sur ATL (ATLAS Transformation Language) : les helpers
    
15. Cours complet sur ATL (ATLAS Transformation Language) : introduction aux règles ATL
    
16. Cours complet sur ATL (ATLAS Transformation Language) : le code impératif ATL, l’instruction d’affectation
    
17. Cours complet sur ATL (ATLAS Transformation Language) : le code impératif ATL, l’instruction de test : if
    
18. Cours complet sur ATL (ATLAS Transformation Language) : le code impératif ATL, l’instruction de boucle : for
    
19. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules” (les règles de correspondance), présentation (1/5)
    
20. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, la section “from” (pattern source) (2/5)
    
21. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, la section des variables locales (3/5)
    
22. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, le pattern élément cible (4/5)
    
23. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, la section bloc impératif (5/5)
    
24. Cours complet sur ATL (ATLAS Transformation Language) : les règles paresseuses (Lazy Rules)
    
25. Cours complet sur ATL (ATLAS Transformation Language) : les règles appelées (Called Rules)
    
26. Cours complet sur ATL (ATLAS Transformation Language) : l’héritage des règles
    
27. Cours complet sur ATL (ATLAS Transformation Language) : De la bonne utilisation des règles dans le langage ATL
    
28. Cours complet sur ATL (ATLAS Transformation Language) : le mode “affiné” ATL
    
29. Cours complet sur ATL (ATLAS Transformation Language) : les requêtes ATL
    
30. Cours complet sur ATL (ATLAS Transformation Language) : les mots clés ATL
    
31. Cours complet sur ATL (ATLAS Transformation Language) : pour terminer, une dernière chose à laquelle il faut prendre garde !
    
32. Le plugin ATL (ATLAS Transformation Language) pour Eclipse : les étapes pour réaliser une transformation (1/2)
    
33. Le plugin ATL (ATLAS Transformation Language) pour Eclipse : les étapes pour réaliser une transformation (2/2)

Annexe 8 : Exemple complet des possibilités de QVT (Query View Transform)

• Query View Transform (QVT) Operational : tutoriel, plus simple tu meurs !

Le diagramme de contextes de projets modélise tout ce qui 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.

Cette phase réutilise les éléments de modélisation des phases précédentes, avec peu de modèles spécifiques.

Pour plus de précisions sur les éléments de modélisation avec UML des phases précédentes de TOGAF, voir les articles :

• Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
• Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

Pour le projet de réalisation de “TripReservationSite” (stéréotypé composant d’application d’interaction), ce modèle montre que le site internet :

• est utilisé par les acteurs “Account manager” (interne) et “Client” (externe)
• satisfait à l'exigence d'accès au SI à internet
• doit envoyer un flux d’informations à la fédération de systèmes des partenaires “Partners”
• doit envoyer un flux d’informations à l’application “AccountingERP”
• doit accéder au référentiel “PortfolioRepository” pour récupérer des données métier
• réalise le processus métier “Reserve trip”
• réalise les cas d’utilisation “Reserve trip”, “Consult offer” et “Cancel trip”

Conclusion

Le diagramme de contextes de projets 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.

Rhona Maxwel

@rhona_helena

“Souvent, les hommes se haïssent les uns les autres parce qu'ils ont peur les uns des autres ; ils ont peur parce qu'ils ne se connaissent pas ; ils ne se connaissent pas parce qu'ils ne peuvent pas communiquer ; ils ne peuvent pas communiquer parce qu'ils sont séparés.”
Martin Luther King

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 modèle est réalisé par les architectes applicatifs avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.

La phase E Solutions et opportunitésde TOGAF a été abordée dans notre article : 

• 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)

Cette phase réutilise les éléments de modélisation des phases précédentes, avec peu de modèles spécifiques.

Pour plus de précisions sur les éléments de modélisation avec UML des phases précédentes de TOGAF, voir les articles :

• Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
• Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

Le diagramme de bénéfices se base sur le diagramme de communication des applications de la phase C (voir l’article : “ Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel  “).

Les améliorations envisagées sont modélisées sous forme de commentaires UML.

Le commentaire détaille la fonctionnalité et sa contribution en terme d'ajout de valeur à l'entreprise.

Pour aider les décideurs à arbitrer, on doit dans le commentaire préciser la complexité de réalisation et l’estimation de la charge de développement.

Sur le composant d’application d’interaction modélisant le site internet “TripReservationSite”, il est envisagé d’exploiter et d’analyser finement les précédentes visites des clients et prospects afin de leur présenter éventuellement des remises ou des cadeaux.

Pour cette évolution, la complexité est évaluée à “forte” et l’estimation de la charge de développement à 2000 lignes de codes.

Un nouveau stéréotype est défini, le composant d’application intermédiaire (T).

Par exemple “Client history management” est un composant sophistiqué pouvant faire appel à du Big Data ou de l’Intelligence Artificielle.

Il consiste ici à analyser l’historique des actions du client comme ses anciennes commandes, ses consultations récentes, …

L’objectif est de lui proposer des promotions et orienter ses choix en accord avec ses goûts.

Pour cette évolution, la complexité est évaluée à “moyenne” et l’estimation de la charge de développement à 5000 lignes de codes.

Pour le composant d’application entité “Client history” l’évolution consiste ici à stocker l’historique du client ce qui n’avait pas été réalisé dans la précédente itération car non prioritaire face aux autres fonctionnalités.

Pour cette évolution, la complexité est évaluée à “simple” et l’estimation de la charge de développement à 2000 lignes de codes.

Pour le composant d’application entité “Client” l’évolution consiste à gérer les prospects et à gérer leur historique. 

La gestion des prospects n'avait été jugée prioritaire lors de la précédente itération.

Pour cette évolution, la complexité est évaluée à “simple” et l’estimation de la charge de développement à 2000 lignes de codes.

Conclusion

Le diagramme de bénéfices 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..

Rhona Maxwel

@rhona_helena

“La règle d'or de la conduite est la tolérance mutuelle, car nous ne penserons jamais tous de la même façon, nous ne verrons qu'une partie de la vérité et sous des angles différents.”
Gandhi

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 modèle est réalisé par les architectes technique avec comme référents les ingénieurs systèmes/réseau à destination des responsables d’exploitation et des développeurs.

Pour plus de précisions sur les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF, voir l’article :

• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

L’outil utilisé est le diagramme de déploiement UML (voir notre article : “   Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio “).

Les grandes organisation (corporate) ont souvent pour des raisons historiques un agrégat hétérogène de serveurs de type mainframe IBM fonctionnant sous MVS, des serveurs Microsoft Windows et des serveurs Linux en cluster tendant du reste à remplacer de nos jours les antédiluviens mainframe.

Dans cet exemple, une instance de l’application “:TripPortfolioManager-V2” accède à une instance du composant d’application de base de données “:PortfolioRepository” (par exemple DB2).

Ces 2 composants sont déployés dans un mainframe IBM “MVS server” connecté via un LAN au serveur d’application “Linux server”.

Une instance de l’application “:AccountingERP” accède à une instance du composant d’application de base de données “:AccountingRepository” (par exemple Microsoft SQL server).

Ces 2 composants sont déployés dans un serveur Microsoft “Windows server” connecté via un LAN au serveur d’application “Linux server”.

Le serveur Unix “Linux server” exécute 3 logiciels serveur stéréotypés composant d’application utilitaire.

Il s’agit :

• d’une instance d’un moteur de processus métier BPM (composant d’application utilitaire) “:BPEL server” (voir notre article : “ Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio  “) dans lequel s’exécute le composant d’application de processus “:ReserveTrip”
  
  
• d’une instance de SGBR “:OrderRDB”, le commentaire UML indique qu’il s’agit de la base de données open source MySQL.
  
  
• d’une instance d’un logiciel serveur HTPP (composant d’application utilitaire) “:WEB server” exécutant une instance du composant d’application d’interaction correspondant au site internet  “:TripReservationSite” développé en PHP comme le montre le commentaire UML.
  
  
• d’une instance du conteneur JEE (composant d’application utilitaire) “:Application server”, dans lequel s’exécute des composants d’application d’entité “:Client”, “:Order” et “:Trip” et de processus “:Invoicing”.
  Ces composants d’entité ou de processus sont des services web avec leurs différentes typologies, services d’orchestration, fonctionnels, applicatifs, d’entités métier, ... (voir l’annexe 2 sur l’architecture SOA).

A noter le framework open source “Hibernate” qui assure la couche d’ORM (Object Relational Mapping) faisant la traduction d’un modèle de classe UML orienté objet en un modèle relationnel de SGBR.

Le langage HQL (Hibernat Query Language), traduit automatiquement en SQL du SBDR, les requêtes tout en conservant les concept objet et en faisant abstraction du mode physique de stockage (voir l’article consacré à l’ORM : “ A ma gauche Hibernate version 4.3.6 contre MyBatis version 3.2.8, qui va remporter le titre 2014 de champion ORM toute catégorie ?  “).

Remarque : Oracle a confié les développements futurs de JEE à l’organisation open source Eclipse qui l’a renommé Jakarta EE.

Les postes de travail sont modélisés sous la forme générique “Workstation” connectés aux serveurs “MVS server” et “Windows server” avec des LAN et accède au serveur d’application “Linux server” via internet (HTTP) avec le navigateur de Microsoft.

Afin de bien vérifier que tous les acteurs internes “Marketing officer”, “Account manager”, “Invoicing officer” et externe “Client”, ont bien accès à leurs applications remplissant leurs besoins métier, on les représente en lien à leur poste de travail.

Conclusion

Le diagramme de matériel informatique en réseau constitue une cartographie des infrastructures informatiques hébergeant les composants applicatifs ainsi que les acteurs accèdant à ces composants.

Rhona Maxwel

@rhona_helena

“Une joie partagée est une double joie, un chagrin partagé est un demi-chagrin.”
Jacques Deval

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 modèle est réalisé par les architectes technique avec comme référents les ingénieurs systèmes/réseau à destination des responsables d’exploitation et des développeurs.

Pour plus de précisions sur les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF, voir l’article :

• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

Une unité de déploiement représente un regroupement de fonctions métier, de services ou de composants d'application.

Le diagramme de traitement permet d’identifier

• les composants d'application qui doivent être regroupés pour former une unité de déploiement
• les moyens de communication entre les unités de déploiement comme les topologies et types de réseaux (LAN, WAN) ainsi que les protocoles de transport (TCP/IP, …) et les protocoles applicatifs (HTTP + SOAP + WSDL pour SOA, …)
• la volumétrie, les capacités CPU, le dimensionnement des réseaux, ... à mettre en place pour satisfaire les estimations de charge.

Les unités de déploiement peuvent être présentées sous la forme (stéréotype UML) d'instances de composant d'application utilitaire (par exemple, un serveur d'application), hébergeant des composants d'application  .

Les associations entre ces unités de déploiement représenteront les connexions (par exemple, un réseau), tandis que les flux d'informations indiqueront la nature des informations échangées.

Dans ces diagrammes, des indications sur les besoins en capacité sont fournies.

Les composants de l'application sont déployés dans les unités de configuration déployables, qui sont elles-mêmes des types spécifiques de composants d'application , au niveau de la technologie (serveur web, serveur BPM, serveur d'application, ...).

Conclusion

Le diagramme de traitements montre comment les composants d’application sont déployés dans les unités de déploiement correspondant aux technologies utilisées (HTTP, BPM, 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.

Rhona Maxwel

@rhona_helena

“La science a-t-elle promis le bonheur ? Je ne le crois pas. Elle a promis la vérité, et la question est de savoir si l'on fera jamais du bonheur avec la vérité.”
Emile Zola