urbanisation-si

urbanisation-si

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

L'extension de services du métamodèle de l’architecture d’entreprise TOGAF est destinée à permettre une modélisation sophistiquée du portefeuille de services en créant un concept de services SI en plus du concept de base des services métier.

 

togaf-metamodel-extension-services-1.PNG

 

Les services SI (ou IS Service = Information System Service) sont directement pris en charge par les applications et la création de la couche d'abstraction assouplit les contraintes sur les services métier tout en permettant aux parties prenantes techniques de gérer un catalogue formel de services SI.

 

Le périmètre de cette extension est la création de services SI en tant qu'extension de services métier.

 

Cas d’utilisation de l’extension « Services »

  • Lorsque l'entreprise a une définition prédéfinie de ses services qui ne correspond pas bien aux besoins techniques et architecturaux
  • Lorsque l'entreprise et l'informatique utilisent un langage différent pour décrire des fonctionnalités similaires
  • Lorsque le service informatique est non aligné par rapport aux besoins de l'entreprise, en particulier dans les domaines de la qualité de service, de la visibilité des performances et de la granularité de la gestion
  • Où le département informatique prend des mesures initiales pour engager les entreprises dans des discussions sur l'architecture informatique

 

Avantages de l'utilisation de l’extension « services »

  • Les services métier peuvent être définis en dehors des contraintes qui existent dans le métamodèle principal.
  • Cela permet un engagement plus naturel avec les parties prenantes de l'entreprise.
  • Les services SI peuvent être définis selon un modèle qui se rapproche de la mise en œuvre, fournissant une abstraction de solution plus réaliste pour soutenir la prise de décision informatique.
  • Les relations entre les services métier et les services SI indiquent si la vue métier est alignée avec la vue SI ou s'il existe des écarts.

 

Références de spécifications concernant les services

  • SoaML (Service Oriented Architecture Modeling Language) la norme de l’OMG (Object Management Group) (http://www.omg.org/spec/SoaML) est une extension du langage de modélisation UML (Unified Modeling Language) pour les architectures orientées services.
    Contrairement aux efforts de standardisation qui ont prévalu jusqu'ici dans l'orientation services, SoaML  s'intéresse bien à l'architecture et non aux composants techniques sous-jacents.
    Le but de SoaML est en effet de fournir aux utilisateurs du langage UML les moyens de modéliser une architecture orientée services - comprenant donc des notions de consommateurs et de fournisseurs de services, ainsi que la notion de contrats.
    Le passage de la notion de composant à celle de service implique des obligations réciproques entre le fournisseur et le consommateur, et il est indispensable de formaliser cela en amont des décisions techniques ».
    SoaML sert ainsi à spécifier un cahier des charges, à l'attention d'un sous-traitant, ou bien à formaliser une approche services dans le cadre d'une démarche MDA (Model Driven Architecture).
    En MDA , on modélise l'architecture d'une application, l'outil générant ensuite le code en fonction de la plateforme visée.
    SoaML est compatible avec tous les outils UML 2.
     
  • Spécification SCA (Service Component Architecture)
    La spécification SCA (Service Component Architecture) développée par la collaboration OSOA (Open Service Oriented Architecture); se référer à www.oasis-opencsa.org/sca
     
  • Spécification SDO (Service Data Objects)
    La spécification SDO (Service Data Objects) développée par la collaboration OSOA (Open Service Oriented Architecture); se référer à www.oasis-opencsa.org/sdo

  

Modifications apportées aux entités et aux relations du métamodèle TOGAF

  • Le service SI est ajouté en tant que nouvelle entité de métamodèle, ce qui étend le service métier.
  • « Service SI » hérite de toutes les relations d'un service métier.
  • Une nouvelle relation est créée reliant un service SI à un service métier.

 

Modifications apportées aux attributs du métamodèle TOGAF

  • « Service SI » est ajouté en tant que nouveau type de service métier.

 

Diagrammes supplémentaires à créer

  • Diagramme de cas d'utilisation professionnelle
  • Diagramme de décomposition de l'organisation

 

Conclusion

Une entreprise peut, avec le concept d’extension du métamodèle TOGAF, personnaliser les descriptions d’architecture, contribuant ainsi au processus d’adaptation du framework TOGAF.

L’entité conceptuelle « Service SI (Information System Service) » appartient bien au domaine « Architecture Applicative (Application Architecture) » structuré comme les autres domaines en 3 parties : conceptuelle, logique et physique.

 

togaf-metamodel-extension-2.PNG

 

Rhona Maxwel

@rhona_helena

 

"Débarrassez-vous d’une mauvaise habitude par an. En agissant ainsi, même le pire des hommes deviendrait un modèle de vertu."

Benjamin Franklin

 

 

Articles conseillés :

 

L’extension « Gouvernance » 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)

 

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

 

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

 

TOGAF pour les nuls.


03/12/2017
0 Poster un commentaire

Experts métiers, passez-vous de développeurs, modélisez vos règles métiers avec DMN puis générez et exécutez automatiquement le code RedHat Drools et inversement

Ou comment Red Hat donna vie au langage DMN (Decision Model and Notation) en le rendant exécutable et en fit une pièce maîtresse du concept des transformations des aspects dans l'architecture d’entreprise.

 

dmn-vers-drools-et-drools-vers-dmn.PNG

 

Les règles métiers font partie de la connaissance stratégique de l’entreprise et doivent être modélisées avec la norme DMN les rendant indépendantes de leur implémentation informatique.

Les dernières innovations des outils de modélisation DMN permettent avec un simple clic de générer le code en langage Drools (DRL Drools Rules Language), le standard open source de l’industrie des moteurs de règles métiers (BRMS Business Rules Management System) et bien sûr de pouvoir l’exécuter.

 

Si vous n’êtes pas familier avec BPMN (Business Process Model and Notation)

dmn-table-decision-3.PNG

 

La plupart des experts métiers ne sont pas concernés par le code, sauf dans les domaines des règles métiers où la logique très détaillée, y compris les quantités, les dates et les formules de calcul, est essentielle.

BPMN a été étendu pour inclure la modélisation des règles métier avec la notation de modélisation de décision (DMN).

Bien que séparé de BPMN, DMN a été conçu pour fonctionner avec BPMN.

Avec la modélisation de décisions, les experts métier peuvent contrôler un processus en déterminant :

  • Que doit-on faire ensuite ?
  • Qui doit le faire ?
  • Quand et où cela est-il fait ?
  • Et surtout, des règles importantes ont-elles été enfreintes ? 

 

Cela fait déjà un certain temps que les processus métiers exécutables au sens de la norme de modélisation BPMN, peuvent l’être réellement dans un moteur BPM (Business Process Management) comme par exemple jBPM.

Les 2 open source jBPM  et Drools de l’éditeur Red Hat (qui édite aussi des versions payantes) sont aujourd'hui intimement associés et supportent entièrement les 2 normes soeurs BPMN et DMN.

 

Les concepts de base :

  1. BPMN 2 : les concepts de base des processus métiers
  2. BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

 

Démonstration de la modélisation d’un processus métier avec BPMN et son exécution complète.

Ce tutorial sur jBPM est destiné aux experts métiers et garantit 100% sans code de programmation :

  1. Tutoriel jBPM : étude de cas avec human task (partie 2/10)
  2. Tutoriel jBPM : connexion à l'IDE KIE Workbench et création des unités organisationnelles (partie 5/10)
  3. Tutoriel jBPM : conception du processus en BPMN 2 (partie 6/10) 
  4. Tutoriel jBPM : vérifiez la conformité à la norme BPMN 2 (partie 7/10)
  5. Tutoriel jBPM : génération de formulaires et mapping des variables (partie 8/10)
  6. Tutoriel jBPM : construction et déploiement du processus de notre étude de cas (partie 9/10)
  7. Tutoriel jBPM : démarrage et test final de l'exécution complète de l'étude de cas (partie 10/10)

  

Si vous n’êtes pas familier avec DMN (Decision Model and Notation)

DMN permet aux utilisateurs métier de modéliser des décisions exécutables en utilisant un langage graphique de haut niveau, normalisé OMG (Object Management Group), qui favorise l'interopérabilité et préserve leur investissement en évitant d’être liés à des fournisseurs.

 

Voici une sélection d’articles que nous avions consacré à DMN :

 

Les concepts de base :

 

dmn-decision-input-data-1.PNG

 

 

dmn-knowledge-source-business-source-knowledge-requirement-authority-requirement-2.PNG

 

 

dmn-table-decision-3.PNG

  

Pour tout comprendre, voici un exemple complet montrant un processus métier modélisé avec BPMN et incluant des règles métiers modélisées avec DMN. 

Cet exemple va 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 ?

 

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]

 

Et Drools donna vie à la norme DMN

L'équipe de Drools, le moteur BRMS open source de RedHat, standard de l’industrie, a activement suivi les spécifications DMN.

L’éditeur Red Hat estime que, conformément à son engagement de longue date envers les normes ouvertes, il est maintenant temps de soutenir la spécification DMN (V 1.1) et de fournir une implémentation conforme aux intérêts des utilisateurs.

Drools a un niveau le niveau conformité maximal (= 3) à la norme, il met en œuvre le langage FEEL (Friendly Enough Expression Language) pour par exemple les formules mathématiques, prend en charge complètement le format d'échange XML permettant de traduire les graphiques DMN en langage interprétable par une machine ainsi qu’une implémentation du métamodèle.

La mise en œuvre DMN exploite toute la plate-forme Drools (y compris, entre autres, le modèle de déploiement, l'infrastructure et l'outillage).

Les modèles DMN sont des citoyens de première classe dans la plate-forme et un atout supplémentaire pour Drools.

Drools DMN est intégré à jBPM BPMN dans la dernière version 7.

 

Partenariat entre l’éditeur Signavio et Red Hat : transformez vos diagramme DMN en code exécutable RedHat Drools

 

 

dmn-en-code-drools-1.PNG

 

Modéliser les processus et les règles métiers avec les standards BPMN et DMN en utilisant les outils Signavio, puis en déployant ces modèles dans les moteurs jBPM et Drools pour l'exécution !

 

C'est un BPM de bout en bout : de la modélisation de processus avec Signavio à l'exécution avec Red Hat !

 

Pendant près d'une décennie, la conception de processus dans BPMN (Business Process Model Notation) a été une bonne pratique pour aligner les objectifs métiers et techniques.

Avec BPMN, l'analyste métier ou l'expert peut définir avec précision les interactions des clients, des systèmes et des partenaires métiers avec les activités et les événements qui les animent.

 

Avec le gestionnaire de processus Signavio, toutes les parties prenantes peuvent collaborer sur les modèles de processus.

 

 

L’outil peut exporter le diagramme dans un format XML que d'autres systèmes peuvent interpréter.

Signavio et Red Hat ont mis à profit cette capacité pour que les processus puissent être échangés.

La logique de décision peut être exportée depuis Signavio Process Manager et intégrée dans l'atelier KIE de RedHat.

 

 

Le travail d'équipe de Signavio et Red Hat est un exemple de la séparation parfaite des préoccupations entre l'entreprise et l'informatique.

 

Parce qu'il est conçu pour être facile à utiliser et collaboratif, le gestionnaire de processus Signavio est l'environnement idéal pour développer la vision d'un processus ou d'une décision.

De même, parce qu'il peut tirer parti de la puissance et de l'évolutivité de l'ensemble de la pile middleware Red Hat, la suite BPM est l'environnement idéal pour transformer ces décisions en une forme exécutable et les héberger.

Signavio vous permet de modéliser la logique de décision avec l'éditeur Signavio facile à utiliser et d'exporter ensuite les diagrammes DMN en fichiers DRL pour les transférer dans la solution de gestion des règles métier open source Drools.

Ainsi, vous pouvez facilement transférer des diagrammes DMN dans une logique métier automatisée.

 

Vous pouvez exporter plusieurs diagrammes, un diagramme ou une seule table de décision et ses sous-décisions.

L'exportation Signavio Drools prend en charge trois types d'exportation différents: Production, Développement et Test.

Contrairement à la production, le développement ajoute des commentaires et un comportement de journalisation supplémentaires.

 

De plus, vous pouvez sélectionner la dernière révision ou la révision publiée qui sera utilisée pour l'exportation.

 

Les autorisations pour l'exportation Drools peuvent être limitées aux utilisateurs de groupes d'utilisateurs spécifiques.

 

Pour exporter la logique de décision vers Drools, ouvrez le Signavio Explorer. sélectionnez un ou plusieurs diagrammes et allez dans Import / Export - Export Drools:

 

 

DMN-exporter-en-code-drools-signavio.PNG

 

Exemple d'un modèle DMN avec son code généré :

dmn-generer-en-drools-et-inversement-drools-en dmn-000.PNG

 

Vous pouvez également exporter une table de décision et ses sous-décisions directement à partir de l'éditeur DMN Signavio.

Dans l'éditeur, ouvrez une table de décision et cliquez sur Importer / Exporter dans le coin supérieur droit de la boîte de dialogue.

Vous pouvez choisir entre générer l'exportation Drools ou les cas de test.

 

Et inversement ...

Pour être conforme à la norme MDA (Model DrivenArchitecture), les transformations doivent être bidirectionnelles.

L'outil Signavio permet à partir du code exécutable RedHat Drools conçu par les développeurs, de générer automatiquement les modèles DMN.

 

dmn-vers-drools-et-drools-vers-dmn.PNG

 

Pour être complet, voici d'autres outils

L’outil DecisionsFirst Modeler Enterprise Edition

Avec DecisionsFirst Modeler Enterprise Edition et l'intégration pour RedHat JBoss BRMS (Drools pour la version opensource), les modèles de décision basés sur la norme DMN peuvent être plus facilement intégrés aux règles métier gérées et déployées à l'aide de RedHat BRMS, améliorant ainsi la traçabilité.

DecisionsFirst Modeler est une solution de modélisation décisionnelle collaborative utilisant la norme DMN.

DecisionsFirst Modeler fournit une interface utilisateur conviviale et supporte les diagrammes DMN.

L'intégration de RedHat BRMS lie les modèles de décision graphique aux règles métier implémentées et gérées dans Drools, facilitant ainsi la définition partagée de l'implémentation par l'architecte et l’expert métier propriétaire de la règle.

 

Trisotech, la solution d’intégration de bout en bout

Drools / Red Hat - Trisotech DMN Modeler - Method & Style DT Analysis

Les règles métier sont modélisées par l'outil Trisotech DMN Modeler, puis analysées à l'aide du module Method & Style DT Analysis et exécutées dans le cloud à l'aide de BRMS de Drools / Red Hat.

Les processus métier modélisés en BPMN et les règles métiers en DMN sont nativement exécutées dans RedHat BPM !

 

 

DMN-Drools-Redhat-Trisotech-01.PNG

 

Une belle illustration de l’Ingénierie Dirigées par les Modèles

Voici un brillant exemple de l’Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture la norme de l'OMG Object Management Group), qui repose sur la volonté de décrire précisément les besoins des clients par des CIM (Computational Independent Models) et la connaissance métier d’une organisation dans des modèles abstraits indépendants des plates-formes (PIM - Platform Independent Models).

 

Ayant isolé le savoir-faire métier dans des PIM, on a besoin soit de transformer ces modèles en d’autres PIM (besoin d’interopérabilité, migration vers un nouveau système, fusion de SI en cas d’acquisition d’une autre organisation, …), soit de produire ou de créer des modèles PSM (Platform Specific Models) ciblant une plate-forme d’exécution spécifique (pour améliorer la portabilité et augmenter la productivité) et ceci de manière bidirectionnelle.

 

Vous l’avez compris les modèles BPMN et DMN sont des PIM et jBPM et Drools sont des PSM.

 

 

Dans l'article ci-après on posait la question : « Et pourquoi pas dériver le couple (BPMN, DMN) en modèle de code (PSM Platform Specific Model) d’un moteur de processus métier ou de règles métiers, par exemple le couple open source bien intégré (jBPM, Drools) ? »

 

 

Conclusion

 

praxeme-derivation-des-aspects-semantique-pragmatique-brms-bpm.png

 

Le jour est arrivé où les experts métier peuvent exprimer leurs processus et règles métiers sous forme de diagrammes normalisés en BPMN et DMN et directement les simuler, vérifier, exécuter et gérer leurs cycles de vie dans un référentiel.

 

Avec cette conversion de modèles métier (PIM) BPMN + DMN en code exécutable (PSM) jBPM + Drools, pour une fois une des principales préconisations des cadres d’architecture d’entreprise comme Praxeme ou TOGAF, concernant l’outillage pour les transformations des niveaux selon MDA est bien satisfaite.

 

Drools donne ainsi vie à la norme DMN, puisse d’autres outils de dérivation donner vie à l’automatisation des dérivations des autres aspects de l’architecture d’entreprise.

 

Rhona Maxwel

@rhona_helena

 

"La variété est la véritable épice de la vie, qui lui donne toute sa saveur."

William Cowper

 

 

Articles conseillés :

 

Comment concevoir une règle ? 

 

Les étapes d’un projet avec un moteur de règles

 

A quoi sert un moteur de règles ?


29/11/2017
0 Poster un commentaire

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

L'extension "Gouvernance" a pour but de gérer des données structurées supplémentaires par rapport aux objectifs et aux services métier, comme les mesures, les contrats et la qualité de service, permettant de mettre en place la gouvernance opérationnelle de TOGAF.

 

TOGAF-metamodele-gouvernance-extension-01.PNG
 

Dans les précédents articles, nous avons vu que le métamodèle fournit un modèle de base avec l'ensemble de fonctionnalités minimum et prend en charge un mécanisme d'extensions facultatives permettant d’adapter et de personnaliser la description de l’architecture TOGAF.

Nous allons nous intéresser dans cet article à la première extension, la Gouvernance.

 

 

Le périmètre de l’extension Gouvernance

  • La capacité d'appliquer des mesures aux objectifs, puis de lier ces mesures aux services
     
  • Possibilité d'appliquer des contrats pour gérer les interactions de communication ou de service avec des utilisateurs et des systèmes externes
     
  • La possibilité de définir des qualités de service réutilisables définissant un profil de niveau de service pouvant être utilisé dans les contrats
     
  • Création de diagrammes supplémentaires pour montrer les propriétés et la gestion des systèmes 

 

 

Conditions d'utilisation de l'extension Gouvernance

  • Lorsqu'une organisation envisage un changement informatique qui aura un impact significatif sur les modèles de gouvernance opérationnelle existants
     
  • Lorsqu'une organisation a des exigences granulaires pour les niveaux de service qui diffèrent d'un service à l'autre
     
  • Quand une organisation cherche à transformer sa pratique de gouvernance opérationnelle
     
  • Quand une organisation se concentre fortement sur les moteurs, les objectifs de l'entreprise et comment ceux-ci se rapportent aux niveaux de service

 

 

Les avantages de l'utilisation de l'extension Gouvernance

Les niveaux de service sont définis de manière plus structurée, avec :

 

  • Ajouts de détails
     
  • Possibilité de réutiliser les profils de service dans les contrats
     
  • Traçabilité des objectifs métiers 

 

 

Les impacts 

Les impacts sur les opérations et les modèles de gouvernance opérationnelle sont considérés de manière plus structurée, avec :

 

  • Diagrammes supplémentaires de la propriété du système et des données
     
  • Diagrammes supplémentaires du fonctionnement du système et des dépendances sur les processus d'exploitation
     
  • Diagrammes supplémentaires de gestion d'entreprise

 

TOGAF est cadre d’architecture d’entreprise ouvert, vous pouvez intégrer par exemple le cadre COBIT pour la gouvernance informatique.

 

 

Les modifications apportées aux entités et aux relations du métamodèle

TOGAF-metamodele-gouvernance-extension-modifications-entites-relations-02.PNG

  

Pour les entités et les relations du métamodèle les modifications sont :

 

  • La mesure est ajoutée en tant que nouvelle entité qui relie le service objectif et le service métier.
     
  • La qualité de service est ajoutée en tant que nouvelle entité fournissant un modèle de profil de service générique à appliquer aux services ou contrats d'entreprise.
     
  • Le contrat est ajouté en tant que nouvelle entité qui formalise les caractéristiques fonctionnelles et non fonctionnelles d'une interaction de service avec d'autres services, des applications externes ou des utilisateurs.

 

Les attributs sont ajoutés pour les nouvelles entités de métamodèle de Mesure, Qualité de service et Contrat.

 

 

Conclusion

Le rôle de TOGAF est de fournir une norme ouverte pour l'architecture applicable dans de nombreux scénarios et situations.

Afin de répondre à cette vision, il est nécessaire de fournir un métamodèle d'architecture d'entreprise complet pour le contenu et de permettre sa personnalisation afin d'éviter de mener des activités inutiles, c’est le rôle des extensions.

Comme toutes les autres extensions, l’extension Gouvernance est facultative et a pour objectif de faciliter l’adaptation du métamodèle en fonction des besoins.

En ce qui concerne, cette extension Gouvernance, mettant en œuvre les indicateurs, les contrats et la qualité de services, elle me paraît être presque obligatoire.

 

Rhona Maxwel

@rhona_helena

 

"Aucune grâce extérieure n’est complète si la beauté intérieure ne la vivifie.

La beauté de l’âme se répand comme une lumière mystérieuse sur la beauté du corps."

Victor Hugo

 

 

Articles conseillés :

 

TOGAF pour les nuls. 

 

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

 

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)

 

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


04/11/2017
0 Poster un commentaire

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

Pour que la conduite du changement d’architecture soit un succès, tous les acteurs, quel que soit leur domaine d’expertise, doivent se comprendre sans ambiguïtés, s’impliquer et coopérer.

Selon le vieil adage, « un schéma vaut mieux qu’un long discours », la vue simplifiée du diagramme de classe UML représentant uniquement les entités et leurs relations, destinée à tous, y compris les experts métiers, permet d’avoir une communication efficace.

 

 

L’alignement entre les objectifs métiers et les artefacts d’architecture est assuré par des liens de traçabilité que l’on peut mettre en place avec des outils (MEGA, Envision TOGAF & ArchiMate CASE,  Modelio, …)  grâce à ce diagramme de classe UML.

 

TOGAF-metamodele-diagramme-de-classe-UML-contenu-principal-01.PNG
 

 

Les entités de base et celles introduites par les extensions

Lorsque toutes les extensions sont appliquées au métamodèle de contenu de base, un certain nombre de nouvelles entités de métamodèle sont introduites.

 

TOGAF-metamodele-contenu-principal-et-extensions-02.PNG
 

 

La carte complète du métamodèle

TOGAF-metamodele-vue-complete-03.PNG
 
 

Conclusion

L’adhésion et l’implication des parties prenantes au projet de transformation de l’architecture d’entreprise implique une bonne compréhension et une communication efficiente.

Pour cela il faut un glossaire accompagné d’une cartographie sous forme de diagramme de classe UML de toutes les entités TOGAF.

Quel que soit leurs préoccupations et leurs points de vue spécifiques, les différents acteurs y trouveront les informations qu’il recherchent.

 

Rhona Maxwel

@rhona_helena

 

"Sans changer vos schémas de pensée, vous ne résoudrez pas les problèmes créés par votre schéma de pensée actuelle."

Albert  Einstein

 

  

Articles conseillés :

 

Urbanisme SI : la nécessité d'un "espéranto"

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe

 

SysML : éléments de base - le diagramme de bloc (block definition diagram)

 

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

 

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

 

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

 

TOGAF pour les nuls.


03/11/2017
0 Poster un commentaire

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

L’objectif du métamodèle TOGAF est de définir une structure formelle pour les termes utilisés afin d'assurer la cohérence au sein de l'ADM et de fournir des conseils aux organisations qui souhaitent implémenter leur architecture dans un outil.

 

TOGAF-metamodele-vue-d-ensemble-detailleee-05.PNG

 

Une architecture TOGAF est basée sur la définition d'un certain nombre de briques architecturales dans les catalogues d'architecture, spécifiant les relations entre ces blocs dans les matrices d'architecture, puis présentant des diagrammes de communication qui montrent de manière précise et concise ce qu'est l'architecture.

 

 

Le métamodèle de contenu principal de TOGAF et ses extensions

Le rôle de TOGAF est de fournir une norme ouverte pour l'architecture applicable dans de nombreux scénarios et situations.

Afin de répondre à cette vision, il est nécessaire de fournir un métamodèle d'architecture d'entreprise complet pour le contenu et de fournir la possibilité d'éviter de mener des activités inutiles en soutenant la personnalisation.

 

Le métamodèle doit fournir un modèle de base avec l'ensemble de fonctionnalités minimum, puis prendre en charge l'inclusion d'extensions facultatives lors de l'adaptation de TOGAF.

 

Le métamodèle principal fournit un ensemble minimal de contenu architectural pour prendre en charge la traçabilité à travers les artefacts.

 

Des concepts de métamodèle supplémentaires pour prendre en charge une modélisation plus spécifique ou plus approfondie sont contenus dans un groupe d'extensions qui regroupent logiquement des catalogues d'extensions, des matrices et des diagrammes, ce qui permet de se concentrer sur des domaines spécifiques.

 

Tous les modules d'extension sont facultatifs et doivent être sélectionnés pendant la phase préliminaire du développement de l'architecture pour répondre aux besoins de l'organisation.

De plus, les regroupements d'extensions décrits par le métamodèle de contenu ne sont qu'une suggestion et une adaptation ultérieure peut être effectuée pour répondre aux besoins spécifiques à la discrétion des architectes.

 

Ce concept de base et d'extension est destiné à soutenir les approches formelles d'extension de méthodes au sein de TOGAF, telles que le concept de plug-in de méthode trouvé dans le logiciel SPEM (Software Process Engineering Metamodel) développé par OMG (Object Management Group).

 

TOGAF-metamodele-base-et-extensions-01.PNG

 

  

Les Entités du métamodèle de base

Le métamodèle utilise la terminologie discutée dans l'ADM TOGAF comme base pour un métamodèle formel.

 

La terminologie est la suivante :

 

Acteur : Une personne, une organisation ou un système qui est en dehors de la considération du modèle d'architecture, mais qui interagit avec lui.

 

Composant d'application : encapsulation de la fonctionnalité de l'application alignée sur la structure de la mise en œuvre.

 

Business Service : prend en charge les fonctionnalités métier via une interface explicitement définie et est explicitement géré par une organisation.

 

Entité de données : encapsulation de données reconnues par un expert de domaine métier en tant que concept discret.

Les entités de données peuvent être liées à des applications, des référentiels et des services et peuvent être structurées en fonction de considérations d'implémentation.

 

Fonction : fournit des fonctionnalités métier étroitement alignées sur une organisation, mais non explicitement gérées par l'organisation.

 

Service du système d'information : les éléments automatisés d'un service métier.

Un service de système d'information peut fournir ou prendre en charge tout ou partie d'un ou de plusieurs services métier.

 

Unité d'organisation : Une unité autonome de ressources avec des buts, des objectifs et des indicateurs de mesures.

Les unités organisationnelles peuvent inclure des parties externes et des organisations partenaires.

 

Service de plate-forme : Une capacité technique requise pour fournir une infrastructure qui prend en charge la livraison des applications.

 

Rôle: un acteur assume un rôle pour effectuer une tâche.

 

Composante technologique : Encapsulation d'une infrastructure technologique représentant une catégorie de produit technologique ou un produit technologique spécifique.

 

 

Les relation clés liés aux entités de métamodèle

Un processus est un flux d'interactions entre des fonctions et des services et ne peut pas être déployé physiquement.

Tous les processus doivent décrire le flux d'exécution d'une fonction et, par conséquent, le déploiement d'un processus passe par la fonction qu'il prend en charge ; c'est-à-dire qu'une application implémente une fonction qui a un processus, et non une application qui implémente un processus.

 

La fonction décrit les unités de capacité métier à tous les niveaux de granularité.

Le terme « fonction » est utilisé pour décrire une unité d'activité à tous les niveaux de granularité, en encapsulant des termes tels que chaîne de valeur, zone de processus, capacité, fonction métier, etc. Toute fonction d'unité d'activité délimitée doit être décrite comme une fonction.

 

Les services métier prennent en charge les objectifs organisationnels et sont définis à un niveau de granularité cohérent avec le niveau de gouvernance requis

Un service métier fonctionne comme une limite pour une ou plusieurs fonctions.

La granularité des services aux entreprises dépend de l'orientation et de l'importance de l'entreprise (comme en témoignent les facteurs, les buts et les objectifs).

Un service dans la terminologie SOA (Service Oriented Architecture) (c'est-à-dire une unité d'application déployable) est en fait beaucoup plus proche d'un service d'application, composant d'application ou composant technologique pouvant implémenter ou supporter un service métier.

 

Les services métier sont déployés sur les composants de l'application

Les services métier peuvent être réalisés par une activité métierne se rapportant pas à l'informatique ou pouvant être supportée par l'informatique.

Les services métier pris en charge par le service informatique sont déployés sur des composants d'application.

Les composants d'application peuvent être décomposés hiérarchiquement et peuvent prendre en charge un ou plusieurs services métier.

Il est possible qu'un service d'entreprise soit pris en charge par plusieurs composants d'application, mais cela est problématique du point de vue de la gouvernance et est symptomatique des services métier à trop forte granularité ou des composants d'application qui sont trop fins.

 

Les composants d'application sont déployés sur des composants technologiques

Un composant d'application est implémenté par une suite de composants technologiques.

Par exemple, une application, telle que « Système RH », serait généralement implémentée sur plusieurs composants technologiques, y compris le matériel, le logiciel du serveur d'application et les services d'application.

 

TOGAF-metamodele-base-entites-relations-02.PNG

 

  

Catalogue, matrice et concept de diagramme

Le métamodèle de contenu est utilisé comme une technique pour structurer l'information architecturale d'une manière ordonnée afin qu'elle puisse être traitée pour répondre aux besoins des parties prenantes.

La majorité des acteurs de l'architecture n'ont pas vraiment besoin de savoir ce qu'est le métamodèle d'architecture et ne sont concernés que par des problèmes spécifiques, tels que "quelles fonctionnalités supporte cette application?", "Quels processus seront impactés par ce projet?"

Afin de répondre aux besoins de ces parties prenantes, les concepts TOGAF de blocs de construction, de catalogues, de matrices et de diagrammes sont utilisés.

 

Les blocs de construction sont des entités d'un type particulier dans le métamodèle (par exemple, un service métier appelé «Commande d'achat»).

Les blocs de construction portent des métadonnées selon le métamodèle, qui prend en charge la requête et l'analyse.

Par exemple, les services métier ont un attribut de métadonnées pour le propriétaire, ce qui permet à un acteur d'interroger tous les services métier appartenant à une organisation particulière.

Les blocs de construction peuvent également inclure des entités dépendantes ou contenues selon le contexte de l'architecture (par exemple, un service métier appelé «Commande» peut implicitement inclure un certain nombre de processus, d'entités de données, de composants d'application, etc.).

 

Les catalogues sont des listes de blocs de construction d'un type spécifique, ou de types apparentés, utilisés à des fins de gouvernance ou de référence (par exemple, un organigramme, montrant les emplacements et les acteurs).

Comme pour les blocs de construction, les catalogues contiennent des métadonnées selon le métamodèle, qui prend en charge la requête et l'analyse.

 

Les matrices sont des grilles qui montrent les relations entre deux ou plusieurs entités modèles.

Les matrices sont utilisées pour représenter les relations basées sur des listes plutôt que sur leur utilisation graphique (par exemple, une matrice CRUD montrant quelles applications Créer, Lire, Mettre à jour et Supprimer un type particulier de données est difficile à représenter visuellement).

 

Les diagrammes sont des rendus de contenu architectural dans un format graphique permettant aux parties prenantes de récupérer les informations requises.

Les diagrammes peuvent également être utilisés comme technique pour remplir graphiquement le contenu de l'architecture ou pour vérifier l'exhaustivité des informations collectées.

TOGAF définit un ensemble de diagrammes d'architecture à créer (par exemple, organigramme).

Chacun de ces diagrammes peut être créé plusieurs fois pour une architecture avec un style ou une couverture de contenu différent pour répondre aux préoccupations des parties prenantes.

 

Les blocs de construction, les catalogues, les matrices et les diagrammes sont tous des concepts bien supportés par les principaux outils d'architecture d'entreprise.

Dans les environnements où les outils sont utilisés pour modéliser l'architecture, ces outils prennent généralement en charge des mécanismes pour rechercher, filtrer et interroger le référentiel d'architecture.

 

L'interrogation à la demande du référentiel d'architecture (tel que l'exemple de propriété de service d'entreprise mentionné ci-dessus) peut être utilisé pour générer des catalogues ad hoc, des matrices et des diagrammes de l'architecture.

Comme ce type de requête est par nature requis pour être flexible, il n'est donc pas restreint ou défini dans le métamodèle de contenu.

 

 

Les interactions entre le métamodèle, les blocs de construction, les diagrammes et les parties prenantes

 

TOGAF-metamodele-interactions-03.PNG

 

 

Vue d'ensemble du métamodèle de contenu

Le métamodèle de contenu définit un ensemble d'entités qui permettent de capturer, stocker, filtrer, interroger et représenter les concepts architecturaux de manière à assurer la cohérence, l'exhaustivité et la traçabilité.

 

Au niveau le plus élevé, le cadre de contenu est divisé en fonction des phases ADM TOGAF

 

 

TOGAF-metamodele-vue-d-ensemble-par-phase-04.PNG
 

Les artefacts des principes d'architecture, de la vision et des exigences visent à capturer le contexte environnant des modèles d'architecture formelle, y compris les principes généraux d'architecture, le contexte stratégique entrant dans la modélisation de l'architecture et les exigences générées par l'architecture.

 

Le contexte de l'architecture est généralement recueilli dans les phases « Préliminaire » et « Vision » d’ADM.

 

Les artefacts de l'architecture métier capturent les modèles architecturaux de l'activité métier, en examinant spécifiquement les facteurs qui motivent l'entreprise, la structure organisationnelle de l'entreprise et les capacités fonctionnelles de l'entreprise.

 

Les artefacts de l'architecture des systèmes d'information capturent les modèles d'architecture des systèmes informatiques en examinant les applications et les données en phase avec les phases ADM de TOGAF.

 

Les artefacts d'architecture technologique capturent les actifs technologiques acquis qui sont utilisés pour implémenter et réaliser des solutions de système d'information.

 

Les artefacts de réalisation capturent des feuilles de route de changement montrant la transition entre les états d'architecture et les instructions de liaison qui sont utilisées pour piloter et gouverner une implémentation de l'architecture.

 

 

Représentation détaillée du métamodèle

TOGAF-metamodele-vue-d-ensemble-detailleee-05.PNG

 

Conclusion

Le métamodèle TOGAF décrit les éléments de base pour concevoir une architecture d’entreprise.

L’objectif est d’avoir un diagramme de classe des entités et leurs relations.

Cette cartographie des composants de TOGAF servira de moyen pou assurer la traçabilité à travers les artefacts.

Le métamodèle est un élément essentiel de communication entre tous les acteurs, il évite les mauvaises compréhension, les ambiguités. 

Les nombreux désaccord et les longues discussions qui en découlent lors de réunions interminables, sont épargnées lorsqu'on montre le métamodèle et les définitions rigoureuses, presque mathématiques qui y sont détaillées. 

 

Rhona Maxwel

@rhona_helena

 

"Il devient indispensable que l'humanité formule un nouveau mode de pensée si elle veut survivre et atteindre un plan plus élevé."

Albert  Einstein

 

 

Articles conseillés :

 

TOGAF pour les nuls. 

 

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

 

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

 

Ingénierie Dirigée par les Modèles (IDM) : le tour de passe-passe des transformations de modèles

 

Ingénierie Dirigée par les Modèles (IDM) : un exemple vaut mieux qu'un long discours

 

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

 

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

 

Eclipse Modeling Framework (EMF) : revoyons les fondamentaux

 

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]

 

Urbanisation SI : comment marche le méta-modèle ?

 

Libérez-vous, laissez votre stratégie prendre le leadership"

 

En cas d'évènements imprévus, votre SI doit savoir jouer les "Transformers" !

 

Avec un peu de métier, métamodéliser la vue métier pour assurer la traçabilité avec la stratégie

 

En urbanisation SI, comment définit-on la vue fonctionnelle et quels sont les liens avec la vue métier et applicative ?

 

En urbanisation SI, comment met on en oeuvre la traçabilité entre la vue applicative et les vues fonctionnelle et infrastructure ?


02/11/2017
0 Poster un commentaire