urbanisation-si

urbanisation-si

TOGAF

Mise en oeuvre des modèles d'architecture d'entreprise


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

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

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

Quels éléments constituent la formalisation de l’architecture ?

Comme toute architecture digne de ce nom, TOGAF est composé de blocs, d’artefacts et de livrables.

Ces éléments sont regroupés dans le « cadre de contenu TOGAF » permettant aux principaux livrables créés par un architecte d'être définis, structurés et présentés de manière cohérente.

 

TOGAF-structure-architecture-artefacts-building-blocks-referentiel-00.PNG
 

Les architectes exécutant la méthode de développement d'architecture (ADM) produisent un certain nombre de livrables, tels que les flux de processus, les exigences architecturales, les plans de projet, les évaluations de conformité de projet, …

 

Le cadre de contenu fournit un modèle structurel pour le contenu architectural, permettant aux principaux livrables créés par un architecte d'être définis, structurés et présentés de manière cohérente.

 

Le cadre de contenu fourni ici est destiné à permettre à TOGAF d'être utilisé comme un cadre autonome pour l'architecture au sein d'une entreprise.

 

Cependant, d'autres cadres de contenu existent (tels que le cadre de l'urbanisation du Système d'Information, Zachman ou Praxeme) et il est prévu que certaines entreprises puissent choisir d'utiliser un cadre externe conjointement avec TOGAF.

 

Pour les curieux, voici quelques articles consacrés à l'urbanisation du Système d'Information (voir les catégorie de ce blog  Le processus d'urbanisation du Système d'Information et L'urbanisme et la gouvernance du Système d'Information), au framework de Zachman et à Praxeme :

 

 

Dans ces cas, le cadre de contenu fournit une référence utile et un point de départ pour le mapping du contenu TOGAF à d'autres frameworks.

 

Le cadre de contenu d’architecture de TOGAF utilise 3 catégories pour décrire le type d’entité architecturale dans le contexte d'utilisation : livrable, artefact et bloc de construction.

 

 

Livrable

Un livrable est un document de travail qui est contractuellement spécifié et à son tour formellement révisé, approuvé et signé par les parties prenantes.

Les livrables représentent la sortie des projets et les livrables sous forme de documentation sont généralement archivés à la fin d'un projet ou transférés dans un référentiel d'architecture en tant que modèle de référence, standard ou une "photo" à un instant t du paysage architectural.

 

 

Artefact

Un artefact est un composant architectural qui décrit un aspect de l'architecture.

Les artefacts sont classés comme des :

 

  • catalogues (listes d'entités),
     
  • matrices (tableau des relations entre les entités),
     
  • diagrammes (modélisations des différents aspects de l'architecture).

 

 

Bloc de construction 

Un bloc de construction (Buildind Block) représente une composante (potentiellement réutilisable) de la capacité métier, informatique ou architecturale qui peut être combinée avec d'autres blocs de construction pour fournir des architectures et des solutions.

 

Les blocs de construction peuvent être définis à différents niveaux de détail, en fonction du stade de développement de l'architecture atteint.

 

Par exemple, à un stade précoce, un bloc de construction peut simplement consister en un nom ou une description de plan.

Plus tard, un bloc de construction peut être décomposé en plusieurs blocs de construction et peut être accompagné d'une spécification complète.

 

Les blocs de construction peuvent se rapporter à des « architectures » ou à des « solutions ».

 

Les blocs de construction d'architecture (Architecture Building Blocks ABB) décrivent généralement les capacités requises et définissent les spécifications des blocs de construction de solutions (Solutions Building Blocks SBB). Par exemple, une fonction de service client peut être requise au sein d'une entreprise, soutenue par de nombreux SBB, tels que des processus, des données et des logiciels d'application.

Les blocs de construction de solutions (Solutions Building Blocks SBB) représentent les composants qui seront utilisés pour implémenter la capacité requise. Par exemple, un réseau est un bloc de construction qui peut être décrit à l'aide d'artefacts complémentaires, puis mis à profit pour réaliser des solutions pour l'entreprise.

 

 

Exemples de Livrables

Le document "Vision de l'architecture" est un livrable qui documente une description d'architecture.

Ce document contiendra un certain nombre d'artefacts complémentaires qui sont des vues des blocs de construction pertinents pour l'architecture.

 

 

Exemples d'Artefacts

  • Diagramme BPMN (Business Process Model & Notation) de processus métier
     
  • Diagramme DMN (Decision Model and Notation) des règles métier
     
  • Diagramme de classe UML (Unified Modeling Language) ou diagramme de blocs SysML (System Modeling Language)
     
  • Matrice de correspondances objectifs métier/objectifs SI
     
  • Matrice entre les objectifs stratégiques métier et les processus métier
     
  • ... 

 

 

Exemples de Blocs de construction

L'artefact diagramme BPMN modélise un bloc de construction correspondant au processus métier décrit, ce même diagramme représente aussi le bloc de construction correspondant aux acteurs impliqués par le processus comme un gestionnaire dans le processus de déclaration d'un décès en prévoyance. Une application est un bloc de construction, ...

 

 

Schéma récapitulatif

 

TOGAF-structure-architecture-livrable-artefact-building-block-02.PNG

 

Le livrable de "Définition de l'architecture" inclue des artefacts comme une liste des exigences, une matrice de correspondances objectifs métier/objectifs SI et un diagramme de cas d'utilisation. Un livrable architectural peut contenir de nombreux artefacts qui formeront le contenu du référentiel d'architecture.

  

 

Conclusion

Dans TOGAF, un livrables est validé à la fin de chaque phase de la méthode ADM (Architecture Development Method) et est constitué d’artefacts et de blocs de construction.

Les artefacts sont des vues spécifiques de l’architecture comme des modèles, des listes ou des matrices.

Comme dans l’urbanisation des Systèmes d’Information, on retrouve le composant fondamental, le bloc appelé dans TOGAF « bloc de construction ».

Tous ces éléments sont rigoureusement définis dans un métamodèle comme dans tout cadre qui se respecte, c'est ce que nous verrons au cours d'une prochaine aventure.

 

Rhona Maxwel

@rhona_helena

 

"L'enthousiasme est à la base de tout progrès."

Henry  Ford

 

 

Articles conseillés :

 

Vous cherchez désespérement un formalisme pour vos processus métiers mettant en accord MOA et MOE, la solution miracle existe, elle s'appelle BPMN 

 

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

 

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

 

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)

 

SysML : Méthode d'utilisation - 2ème étape Modélisez le domaine opérationnel - Diagramme de bloc et diagramme de bloc interne


01/11/2017
0 Poster un commentaire