urbanisation-si

urbanisation-si

TOGAF

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


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

La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

Avec TOGAF, les exigences peuvent changer tout au long des phases ADM.

Un nombre important de facteurs externes ou internes peuvent impacter les exigences durant le projet : les lois changent, la concurrence est de plus en plus agressive, les utilisateurs ne savent pas ce qu’ils veulent, des nouvelles technologies apparaissent à des fréquences de plus en plus réduites …

La solution est d’itérer le processus et d’intégrer à chaque nouvelle itération, la gestion des exigences et étudier s’il y des changements.

 

TOGAF-methode-ADM-Architecture-Development-Method-gestion-des-exigences-01.PNG

 

Pour en savoir plus sur système itératif ADM de TOGAF :

 

Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  

 et l’article sur la phase H concernant la gestion des changements dans TOGAF

 

Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

 

TOGAF avec la méthode ADM reprend toutes les bonnes pratiques bien connues.

Une exigence spécifie un besoin ou une règle qui doit être satisfaite.
Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.
 
La modélisation des exigences est destinée à fournir une passerelle entre des outils de gestion d'exigences traditionnels et les autres modèles.
On pourra ainsi réutiliser des exigences dans d'autres produits ou projets.
Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.
On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modifications aux exigence réutilisées.

 

Si TOGAF n’impose aucune technique ni méthode de gestion d’exigences, il est fortement recommandé d’en prendre et de les adapter.

 

Vous trouverez dans la suite, des articles, qui vous aideront dans vos choix, sachant qu’ils sont le fruit de mes retours d’expérience.

 

 

Comment identifier les besoins ?

Expression des besoins : mais à quoi bon les modéliser ? 

 

Expression des besoins : Techniques pour recueillir les besoins

 

Expression des besoins : Posez des questions efficacement

 

Expression des besoins : Soyez efficient dans l'organisation de vos groupes de travail !

 

Modéliser l'expression des besoins pour vous éviter de vous retrouver avec un lave-vaisselle alors que vous vouliez un lave-linge !

 

 

Apprendre à modéliser les exigences avec SysML

SysML : le diagramme d'exigence (requirement diagram)

 

SysML : exemples de diagramme d'exigence tout droit sortie de la norme de l'OMG

 

SysML : le diagramme de cas d'utilisation (use case diagram)

 

SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)

 

SysML pour les nuls : de la modélisation des exigences à la réalisation du système

 

 

Mettre en pratique une méthode efficace pour modéliser les exigences

SysML : la méthode, les exemples et l'étude de cas dont vous rêviez

 

SysML : les bonnes pratiques - les étapes pour une modélisation efficace

 

SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.0 Organisation en packages

 

SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.1 Le package de spécifications - cahier des charges

 

SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.2 Le package des cas d'utilisation (use case)

 

SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.3 Le package d'interactions (diagramme séquence) 

 

SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.4 Le package diagrammes d'état (state machine)

 

SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.5 Le package contrainte de bloc (diagramme paramétrique)

 

 

Comment modéliser vos processus métier avec BPMN (Business Process Model & Notation) ?

Comment mettre en place un jeu de rôles pour modéliser un processus métier ? 

 

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

 

BPMN : l'antisèche pour rester incollable en modélisation de processus

 

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

 

BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza.

 

 

N’oublier pas de modéliser vos règles métier avec la norme DMN (Decision Model Notation)  et les relier à vos processus métier

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier 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

 

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des exigences de connaissances

 

 

Vous pouvez aussi choisir UML (Unified Modeling Language)

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ? 

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 10ème partie - Liste des exigences – UML – Diag. Package

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 11ème partie - Exigences – UML – Profil spécifique

 

 

Notre palmarès des outils

Les meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont ...

 

Le gratuit :

Tutoriel Papyrus : vos diagrammes UML 2 comme à l'époque des manuscrits de l'antiquité !

 

Le payant (très cher !) :

Expression des besoins : modélisation des exigences avec le "mega extra super" AGL MEGA

 

Modélisation métier : Mindmap, ne vous perdez plus dans votre cheminement de pensée, mettez de l'ordre dans vos idées !

 

Et une petite méthode exotique pour ceux qui aiment :

Ingénierie Dirigée par les Modèles : l'orienté but avec KAOS

 

 

Conclusion

Les exigences doivent être rédigées sous la forme « sujet, verbe, complément ».

 

L’exigence classique du type : « l’adhérent à la mutuelle peut consulter ses remboursements de soins en ligne à tout moment », cache en réalité une exigence fonctionnelle : « l’adhérent à la mutuelle peut consulter ses remboursements de soins en ligne » et une exigence non fonctionnelle « une consultation de remboursement peut être faite à tout moment ».

 

Les exigences sont rédigées bien sûr par le métier et c’est la responsabilité de l’architecte de faire préciser la formulation des exigences en fonction des impacts potentiels.

 

Dans le cycle ADM de TOGAF, tout en restant indépendante du domaine considéré, la gestion des exigences s’applique à toutes les phases qui peuvent les analyser et déterminer leurs impacts sur l’architecture.

Avec ces allers-retours, les redondances sont évitées et la cohérence est maintenue.

 

Les exigences sont rationalisées, hiérarchisées, suivies, possèdent un cycle de vie, des méta informations, …, le tout stocké dans un référentiel spécifique géré par un outil.

 

À vous de choisir ce que vous voulez utiliser, cela peut être le « Modèle de spécification des exigences de Volere », le langage normalisé SysML, …

 

Un bon conseil, identifiez les scénarios métiers les plus stratégiques et les plus complexes, simulez grâce à la modélisation ou bien faites réaliser un prototype (POC Proof Of Concept) qui montrera aux sponsors et aux utilisateurs que les projets avancent et qu’ils sont bien alignés avec les objectifs et exigences métiers.

Sinon gare aux dérives.  

  

Rhona Maxwel

@rhona_helena

 

"Celui qui pose une question est bête cinq minutes, celui qui n’en pose pas l’est toute sa vie."

Proverbe chinois

 

 

Articles conseillés :

 

TOGAF pour les nuls. 

 

Pour trouver les services logiques, les modèles sémantiques et pragmatiques tu dériveras. (« Praxeme 4ème commandement extrait de la bible de l’aspect logique »).

 

BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise


31/10/2017
0 Poster un commentaire