urbanisation-si

urbanisation-si

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

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 132 autres membres