urbanisation-si

urbanisation-si

TOGAF

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


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

Destiné aux sponsors du cycle d’architecture, à la direction générale, DSI, architectes métier et applicatifs ainsi qu’aux analystes, le diagramme d’objectifs permet de guider les changements à réaliser pour l’entreprise et son Système d’Information, quantifier les objectifs, les allouer et avoir une approche rationnelle pour les prioriser.

 

tutorial-exemple-d-etude-de-cas-togaf-diagramme-d-objectifs-0.PNG

 

Des études marketing préalables, une analyse avec la méthode SWOT (évaluation des forces, faiblesses, opportunités et menaces) et l’identification des objectifs vitaux de l’entreprise, doivent être réalisées.

 

Le stéréotype <<Part>> pour structurer un objectif stratégique

Le diagramme est une structure arborescente dont les liens sont stéréotypés <<Part>> signifiant qu’un objectif se décompose en un autre.

 

Par exemple l’objectif stratégique « Increase turnover and profits » se décompose en objectif opérationnel comme « Increase number of trips reserved per day » qui lui-même se décompose en « Increase sales presence », « Optimize client transformation rate » et « Render products more attractive ».

 

Les stéréotypes <<+ influence>> et <<- influence>> pour tisser des liens d'impacts positifs ou négatifs entre objectifs

L’objectif « Reservation via the internet » décompose l’objectif « Increase sales presence » et influence positivement les objectifs (<<+ influence>> et <<- influence>> dans le cas contraire) « Optimize client transformation rate » et « Reduce file processing times ».

Cette capacité est un objectif stratégique permettant de répondre et de se différencier de la concurrence, qui va modifier les processus métier des domaines marketing, ventes et comptabilité.

 

Voici à titre indicatif l'organisation du sous projet d'analyse avec le conteneur Goals dans lequel sont représentés tous les objectifs et les 2 diagrammes détaillés dans cet article.

 

tutorial-exemple-d-etude-de-cas-togaf-diagramme-d-objectifs-1.PNG

 

N’oublions pas que ces diagrammes font partie d’un profil UML qui offre la possibilité de tisser des dépendances entre les artefacts de modélisation.

 

Les stéréotypes <<assigned>> et <<guarantee>>

Le diagramme ci-dessous, représente l’affectation des objectifs avec des liens stéréotypés pour signifier de quel type il s’agit :

  • <<assigned>> pour allouer un objectif à un acteur, une unité organisationnelle ou un processus métier.
  • <<guarantee>> pour indiquer que la satisfaction d’une exigence contribuera à l’atteinte de l’objectif.

 

exemple-mise-en-pratique-togaf-affectation-d-objectifs-liens-avec-les-exigences-2.PNG

 

Conclusion

Les diagrammes d’objectifs permettent de représenter la décomposition arborescente des objectifs et leurs liens avec les exigences, processus métier et acteurs internes.

Les stéréotypes des dépendances : <<Part>>, <<+ influence>>, <<- influence>>, <<assigned>> et <<guarantee>> apportent les compléments sémantiques nécessaires.

La prochaine étape 3.3 de notre étude de cas a pour but de formaliser le catalogue des objectifs.

 

Rhona Maxwel

@rhona_helena

 

 "Si le seul outil dont vous disposez est un marteau, vous aurez tendance à voir tout problème comme un clou."

Abraham Maslow

 

 

Articles conseillés :

 

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)

 

Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM 

 

Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst


07/05/2018
0 Poster un commentaire

Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst

Le module Togaf Architect fournit les fonctionnalités suivantes :

  • Paysage et modélisation des entreprises et de leurs systèmes d'information au niveau métier, architectural et technologique.

  • Modélisation des données métiers.

 

Modelio BA, organise un projet TOGAF en 2 sous-projets de type « Analyst project » et « UML project ».

Voir l'article consacré à la création du projet TOGAF : 

 

 

01_tutorial-togaf-mode-operatoire-sous-projet-conteneur-01.PNG

    

Organisation du modèle

L'architecture TOGAF est organisée au sein de cette structure :

  • L'architecture métier est définie dans la couche métier.
  • L'architecture des données est divisée entre un niveau métier, où le niveau conceptuel des données est défini (Entités métier sous couche de gestion) et le niveau technique, où le modèle de données persistantes est défini (niveau application / architecture de données).

Au niveau des entités métier, le modélisateur s'intéresse aux concepts et à leurs propriétés, mais pas aux aspects logiques et physiques tels que les référentiels, les modèles relationnels, etc.

 

Il est recommandé de modéliser d'abord les notions importantes de l'entreprise, et ensuite, définissez l'organisation de l'entreprise, les processus métier et les autres éléments de l'architecture métier.

  • L'architecture de l'application est structurée en deux domaines d'application: les données de service pour modéliser les données échangées entre les services métier et les cas d'utilisation système pour modéliser des cas d'utilisation liés aux principaux composants applicatifs du SI.
  • L'architecture technologique .

 

L'explorateur Modelio 

Les règles de modélisation

L'explorateur Modelio centralise et organise chaque élément du modèle créé lors de la modélisation.

 

Chaque élément de modèle peut apparaître dans un ou plusieurs diagrammes.

 

Des éléments de modèle peuvent être créés dans l'explorateur, ou dans des types de diagrammes adaptés, où une palette prend en charge la création de tous les éléments pertinents.

 

Toute modification appliquée à un élément de modèle sera transférée dans chaque diagramme où cet élément apparaît.

 

Dans un modèle d'architecture d'entreprise, un élément de modèle apparaît très fréquemment dans plusieurs diagrammes.

Par exemple, le même acteur peut apparaître dans un diagramme de décomposition d'organisation, un diagramme d'événements, un diagramme de sécurité de données, un diagramme d'emplacement et de nombreux autres types de diagrammes.

Pour afficher un élément de modèle existant dans un diagramme, il suffit de le faire glisser de l'explorateur vers le diagramme ciblé.

 

Ne créez jamais deux fois le même élément.

Une fois créé, faites-le glisser de l'explorateur pour le laisser apparaître dans un autre diagramme.

 

Gérer le déploiement

Le déploiement doit être modélisé principalement pour représenter la distribution géographique d'une entreprise, ou pour représenter la distribution de l'application sur des serveurs dans l'architecture technologique.

 

Comme un même élément de modèle peut être déployé à plusieurs endroits différents, une occurrence (instance) de l'élément déployé doit être créée dans l'élément d'emplacement de déploiement.

 

Vous pouvez créer une instance (ou une partie) dans l'élément d'emplacement de déploiement, puis saisir cette instance à l'aide de l'élément déployé.

 

Une façon plus simple de le faire est simplement de glisser et déposer l'élément déployé (de l'explorateur) dans l'emplacement de déploiement (apparaissant dans un diagramme): une instance est automatiquement créée.

 

Créer des sous-projets

Remarque : pour créer d’autres sous-projets : sélectionner le projet « Discount Travel » -  clic-droit – Sous-projets – sélectionner par exemple « Sous projet ArchiMate »

 

Dans le sous projet « Analyst project » - clic-droit, on peut créer des diagrammes de traçabilité, des matrices de traçabilité et des éléments :

  • Conteneur d’exigences
  • Conteneur de règles métiers
  • Conteneur d’objectifs
  • Conteneur de risques
  • Conteneur de tests
  • Dictionnaire

 

Dans le sous projet « UML project », - clic-droit, on peut créer des diagrammes de traçabilité, des matrices de traçabilité et des éléments de type "Package".

 

Liste des conteneurs du sous projet "Analyst project"

 

01_tutorial-togaf-mode-operatoire-sous-projet-conteneur-01.PNG

 

Exemple de conteneur : le dictionnaire

 

02_tutorial-togaf-dictionnaire-02.PNG

  

Créer un diagramme, par exemple d’objectifs

Sélectionner le conteneur Goals – clic-droit – Créer un diagramme – Diagramme d’objectifs

 

03_tutorial-togaf-mode-operatoire-diagramme-d-objectifs-03.PNG

 

Créer par exemple un objectif ou un autre conteneur

Sélectionner le conteneur Goals – clic-droit – Objectif (ou Conteneur d’objectifs).

 

Créer un diagramme dans le package TOGAF Model du sous projet UML project

Sélectionner TOGAF Model – clic-droit – Créer un diagramme - choisir un diagramme

 

04_tutorial-togaf-mode-operatoire-diagramme-uml-bpmn-togaf-04.PNG
 

Créer un élément dans le package TOGAF Model du sous projet UML project

Sélectionner TOGAF Model – clic-droit – Créer un élément - choisir un élément

 

10_tutorial-togaf-creer-un-element-uml-10.PNG

 

Créer la structure (Business Layer, Application Layer et Technology Layer) du package TOGAF Model du sous projet UML project

Sélectionner TOGAF Model – clic-droit – Togaf Architect by Modeliosoft – choisissez :

  • Niveau métier
  • Niveau applicatif
  • Architecture technique

 

05_tutorial-togaf-mode-operatoire-niveau-metier-applicatif-technique-05.PNG

 

Transformation de modèles

 

06_tutorial-togaf-transformation-de-modele-06.PNG

 

Génération de documentation

Les matrices

 

07_tutorial-togaf-generation-de-documentation-matrices-07.PNG

 

Les catalogues

 

08_tutorial-togaf-generation-de-documentation-catalogues-08.PNG

 

Les matrices de traçabilité

 

09_tutorial-togaf-generation-de-documentation-matrices-de-tracabilite-09.PNG

    

Structure de « Business Layer »

"Business Entities" et "Business Architecture"

 

11_tutorial-togaf-structure-business-layer-11.PNG

 

Créer les conteneurs de "Business Layer"

 

16_tutorial-togaf-business-layer-togaf-architect-modelio-16.PNG

 

Créer un diagramme de classe dans "Business Entities"

 

17_tutorial-togaf-business-entities-creer-un-diagramme-17.PNG

 

Créer un diagramme d'information/service métier

 

18_tutorial-togaf-business-architecture-creer-un-diagramme-18.PNG

 

Structure de « Application Layer »

"Application Architecture" et "Data Architecture"

 

12_tutorial-togaf-structure-application-layer-12.PNG

13_tutorial-togaf-structure-application-layer-13.PNG

 

Exemple : créer un diagramme de bénéfices dans le conteneur "Application Architecture"

 

19_tutorial-togaf-application-architecture-creer-un-diagramme-19.PNG

 

Exemple : créer un diagramme de migration de données dans le conteneur "Data Architecture"

 

20_tutorial-togaf-data-architecture-creer-un-diagramme-20.PNG

 

Structure de « Technology Architecture »

Les conteneurs de "Technology Architecture"

 

14_tutorial-togaf-structure-technology-architecture-14.PNG

15_tutorial-togaf-structure-technology-architecture-15.PNG

 

Conclusion

L'utilisation hétérogène de l'architecture d'entreprise à travers différentes méthodes, outils et modèles est un obstacle indéniable à sa généralisation.

 

Et pourtant les standards existent, aussi bien pour l'approche elle-même (TOGAF, DODAF, Praxeme, ...) que pour la modélisation (BPMN,  DMN, BMM, UML, SysML, ...), et les pratiques d'architecture d'entreprise sont bien connues (analyse de processus, des règles métiers, analyse des besoins, ...).

 

Cependant, chacune de ces normes est une boîte à outils générique.

 

Toute tentative de les mettre en œuvre de manière coordonnée afin de modéliser l'architecture d'entreprise nécessite beaucoup d'efforts, ce qui dépasse la plupart des utilisateurs.

 

L'architecture d'entreprise est largement utilisée dans les grandes entreprises, mais elle a encore beaucoup de chemin à parcourir.

 

Rhona Maxwel

@rhona_helena

 

"L'amplitude des contradictions à l'intérieur d'une pensée constitue un critère de sa grandeur."

Friedrich Nietzsche

 

 

Articles conseillés :

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles 

 

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

 

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)

 

Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM


01/05/2018
0 Poster un commentaire

Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM

La stratégie d'entreprise est le fait de se fixer des objectifs en fonction de la configuration de l'environnement et des ressources disponibles dans l'organisation puis à allouer ces ressources afin d'obtenir un avantage concurrentiel durable et défendable

 

tutorial-exemple-d-etude-de-cas-togaf-analyser-les-objectifs-0.jpg

 

Dans l’article suivant, je présentais le métamodèle de la vue stratégique de la démarche d’urbanisation du SI :

 

 

J’avais aussi consacré une série d’articles à la stratégie d’entreprise notamment sur les outils de représentation :

 

Rappels sur la "phases préliminaire", "la phase A Vision" et "l’extension  Motivation" de TOGAF

Phase préliminaire 

Cette phase ne fait pas partie du cycle ADM (Architecture Development Method).

La phase préliminaire de TOGAF dont le but est de mettre l’organisation en capacité de maîtriser la gestion et les transformations de son architecture et de préparer le déclenchement d’un cycle ADM avec le procès-verbal de démarrage : « Demande de mise en chantier de l’architecture (Request for Architecture Work) ».

Les questions « où, quoi, pourquoi, qui et comment » trouvent réponses dans ce document spécifiant entre autres les objectifs stratégiques, les sponsors, les moyens financiers, les contraintes, …

 

 

Phase A Vision

Grâce à cette phase préliminaire, les objectifs sont connus en Phase A Vision du cycle ADM (Architecture Development Method).

 

 

Ils vont être retravaillés et finalisés en phase B Métier.

 

 

L’extension « Motivation »

TOGAF possède extension appelée "Motivation" qui a pour but de permettre une modélisation structurée supplémentaire de l’environnement impactant, des buts et des objectifs qui influencent une organisation à fournir des services métier à ses clients.

Ceci permet une définition plus efficace des contrats de service et une meilleure mesure de la performance de l'entreprise.

 

 

Identifier les objectifs selon TOGAF

TOGAF fait la différence entre les objectifs stratégiques (goals) et les objectifs opérationnels (objectives).

 

Si on reprend le diagramme d’Ishikawa, les objectifs stratégiques (le « quoi », c’est-à-dire les résultats souhaités) correspondent à des objectifs de premiers niveaux (axe horizontal), voir l’exemple de notre article cité plus haut (Modélisation métier : méthode des processus métier orientés objectifs), « Etre le numéro 1 du service en informatique », et les objectifs opérationnels (déterminent le « comment ») décomposent un objectif stratégique en sous-objectifs ou étapes pour atteindre les résultats souhaités, pour fixer un jalon déterminé dans le temps, et correspondre à un progrès relativement à l’objectif stratégique.

 

Les objectifs opérationnels définissent donc des cibles intermédiaires pour les objectifs stratégiques de manière à mesurer leur niveau de réalisation.

 

Réciproquement, l’identification d’un objectif de niveau inférieur (opérationnel) amène à la question : « à quel objectif stratégique va-t-il apporter sa contribution ? ».

 

A chaque décomposition d’un objectif de haut niveau, il est utile de poser la question des décompositions alternatives : « quels obstacles y a-t-il à la réalisation des objectifs courants ?

N’y a-t-il pas d’autres moyens pour parvenir à l’objectif stratégiques ? ».

La décomposition se poursuit jusqu’à ce qu’un ensemble d’objectifs élémentaires et faisables ait été identifiés.

 

L’analyse du diagramme d’Ishikawa permet de mettre en évidence des incohérences entre objectifs ou au contraire des renforcements.

 

Toujours par rapport à l’exemple de notre article sur le diagramme d’Ishikawa, les objectifs opérationnels permettant d’atteindre l’objectif stratégique précédent sont : « Réduire les coûts de production » qui a comme sous-objectif « Accroître la réutilisation des composants logiciels ». Par contre l’objectif « Attirer les meilleurs profils par des rémunérations valorisantes » peut rentrer en conflit avec « Réduire les coûts de production ».

 

Comme partout, il s’agira de positionner le curseur à un juste milieu entre ces objectifs.

 

La définition des objectifs stratégiques s’appuie en particulier sur l’estimation des capacités de progrès de l’entreprise, et sur la prise en compte des moteur (drivers) du métier, les « moteurs » étant des conditions externes à l’entreprise, liées au secteur d’activité comme des contraintes concurrentielles (baisse des coûts, montée en gamme de la concurrence, …) ou des contraintes légales (par exemple dans le domaine des mutuelles, les directives européennes imposent l'ouverture à la concurrence et à plus de transparence, …).

Les objectifs stratégiques se présentent sous forme informelle et sont toujours le déclencheur d’un cycle ADM.

 

Comme dans tout projet, on commencera en phase A Vision à formaliser, structurer, hiérarchiser et rationaliser les objectifs.

 

L’identification des objectifs doit suivre la méthode SMART :

 

S - Spécifique : Quel est notre objectif SMART ? Qu’est qui doit être fait dans notre métier ?

           

M -  Mesurable : Comment allons-nous mesurer nos progrès ? (Quelles métriques ?)

           

A - Atteignable : Comment allons-nous atteindre notre objectif ? (Segmenter le problème, fournir les bases des solutions)    

           

R - Réaliste : Comment savons-nous qu’il s’agit là d’un objectif réaliste ? (Échéances en tenant compte des limites de délai, des coûts et des capacités de l’entreprise)

           

T – Temporellement borné : Quand comptons-nous avoir atteint cet objectif ?

 

tutorial-exemple-d-etude-de-cas-togaf-analyser-les-objectifs-00.PNG

 

Les objectifs stratégiques sont au niveau corporate (l’entreprise dans sa globalité).

Les objectifs opérationnels sont affectés à des personnes, comme par exemple le responsable d’un domaine métier, d’une unité organisationnelle, …

 

Prioriser les objectifs

Les objectifs opérationnels doivent être mesurables.

La mesure permet la quantification des avantages atteints pour le métier après satisfaction de l’objectif.

Le ratio entre les résultats et l’effort pour les avoir doit être effectué pour déterminer les priorités. 

 

Conclusion

Je vous recommande vivement d’établir un diagramme d’Ishikawa, qui, de manière informelle car il n’est pas normalisé, il ne fait pas partie de toute l’armada de l’OMG, consiste à identifier l’objectif final, stratégique puis les sous-objectifs (opérationnels) permettant de l’atteindre et ainsi de suite de manière récursive.

A partir de ce diagramme, vous pourrez déterminer les alternatives pour satisfaire un objectifs, les éventuels conflits, affecter les objectifs à des responsables et enfin de les prioriser en fonction de métriques.

 

Rhona Maxwel

@rhona_helena

 

"Il suivait son idée. C'était une idée fixe, et il était surpris de ne pas avancer."

Jacques Prévert

 

 

Articles conseillés :

  

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)

 

TOGAF pour les nuls.

 

La méthode top-down dans l'urbanisme du Sytème d'Information


03/04/2018
0 Poster un commentaire

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)

Connaître les préoccupations des participants oriente les choix de création et conception des artefacts. Les rôles des participants et leurs tâches dans le cycle ADM doivent être déterminés. La granularité des modèles seront établies de manière à être compréhensible par les destinataires.

 

Lors de notre précédent article, au paragraphe "Les propriétés des artefacts TOGAF", nous avions abordé les méta-informations des artefacts :

 

 

Méta-informations de l'artefact "Matrice des parties prenantes"

Voici celles pour la "Matrice des parties prenantes" de notre étude de cas "Discount Travel" : 

 

  • Experts : CEO, Marketing director, Marketing officer, Sales director, Account Manager, Finance manager, Financial director, Information systems director, IT Officer
  • Concepteurs : Business analyst
  • Destinataires : toutes les personnes participant à l’architecture d’entreprise
  • Objectifs : identifier les acteurs participant à l’architecture d’entreprise afin de déterminer les artefacts à produire et par qui.
  • Informations en entrée : HR manager

 

Matrice des parties prenantes

  

matrice-des-parties-prenantes-phase-A-vision-etude-de-cas-exemple-togaf.png

 

Conclusion

Cette matrice permet de connaître l’intérêt que porte chaque partie prenante à la réalisation de l’architecture d’entreprise.

L’exemple de l’étude de cas est volontairement très générique, tout le jeux consiste l’adapter au contexte de votre entreprise.

Le prochain article sera consacré à l'analyse, diagramme et catalogue des objectifs.

 

Rhona Maxwel

@rhona_helena

 

"C'est ce que nous pensons déjà connaître qui nous empêche souvent d'apprendre."

Claude Bernard

 

 

Articles conseillés :

 

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

 

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

 

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

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

 

TOGAF pour les nuls.


26/03/2018
0 Poster un commentaire

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation

La phase préliminaire de la méthode ADM (Architecture Development Method) de TOGAF (The Open Group Architecture Framework) identifie les acteurs participant aux travaux d’architecture d’entreprise et par rapport à leurs préoccupations spécifiques, on détermine les points de vue et artefacts importants dans le cadre d’une entreprise.

 

elements-de-modelisation-phase-A-vision-etude-de-cas-exemple-TOGAF.png
 

Pour comprendre ce que sont les points de vues et les vues TOGAF, voir l’article qui leurs sont consacrés  :

 

 

Les propriétés des artefacts TOGAF

Rappelons le, les artefacts TOGAF sont les supports de communication exposant une vue particulière de l'architecture.

Ils se décomposent en :

  • Catalogues,
  • Matrices
  • Modèles (diagrammes)

Un artefact doit avoir :

  • Nom
  • Participants : la phase préliminaire de la méthode ADM (Architecture Development Method) de TOGAF (The Open Group Architecture Framework) identifie les acteurs participant aux travaux d’architecture d’entreprise.
    Parmi ceux-ci, il faut indiquer pour chacun des artefacts lesquels participent à leur élaboration. 
    L’usage veut qu’on considère 3 niveaux : 
    - Experts métiers 
    - Concepteurs des artefacts (analystes étiers, AMOA)
    - Destinataires des artefacts (modèles, matrices).
  • Objectif : chaque artefact comporte sa raison d’être, la justification de sa réalisation, quel est son intérêt, son objectif, bénéfices par rapport à son coût de réalisation.
  • Informations en entrée servant à la conception de l'artefact.

 

L’AGL (Atelier de Génie Logiciel) Modelio propose un profil UML « Analyste » et un profil « TOGAF ».

Par exemple les point de vue sont représentés par des packages UML stéréotypés.

 

Pour l’installation et des informations sur Modelio voir l’article :

 

Création d’un projet TOGAF avec Modelio

Pour créer un projet, menu :

  • Fichier – Créer un projet – sélectionner Enterprise Architect Togaf – nommer le « Discount Travel for TOGAF »

 

creer-un-nouveau-projet-togaf-modelio-00.PNG

 

Modelio crée à l’intérieur du projet, 2 sous-projets.

Le premier est un « Sous-projet Analyste » et le deuxième « Sous-projet UML ».

 

structure-d-un-nouveau-projet-togaf-modelio-01.PNG

structure-d-un-nouveau-projet-togaf-modelio-02.PNG
 

Description de l’étude de cas

Système d'Information existant

L’entreprise « Discount Travel » est un HUB pour les agences de voyages qui veulent écouler leur stock de voyages invendus grâce à des remises ne pouvant pas excéder 50 %.

Le client n’a pas le choix des dates de départ et de retour et doit être prêt à partir dans un maximum de 15 jours.

L’entreprise dispose d’un call center ouvert de 8h à 20h du lundi au vendredi.

Un conseiller de clientèle répond au client qui choisit le voyage qui l’intéresse.

Le marketing envoie quotidiennement aux conseillers des fiches papier sur les produits disponibles en fonction du stock.

Le site web permet aux clients d’enregistrer des commandes qui sont ensuite traitées manuellement par un gestionnaire.

Les commandes sont ensuite gérées par une application accédée par les commerciaux.

 

Système d'Information cible

La décision de refondre le système d’information a été pris en comité de direction.

La direction a décidé :

  • de proposer son service de réservation sur internet,
  • d’améliorer le suivi de clientèle.

 

Ce nouveau SI doit proposer des formules complète, « clé en main » incluant l’avion, l’hôtel, la voiture, une destination et une prestation d’hébergement.

Une destination concerne un continent et un pays.

Un voyage concerne un unique pays.

Le marketing est en relation avec les agences de voyage, il décide des voyages prioritaires parmi ceux disponibles afin de constituer les offres les plus attrayantes pour les clients.

 

La modélisation de la phase A Vision s’effectue dans le premier sous-projet « Analyst project ».

 

Les éléments de modélisation mis en œuvre

 

elements-de-modelisation-phase-A-vision-etude-de-cas-exemple-TOGAF.png

 

Conclusion

Ces éléments de modélisation font partie d’un profil UML

Un profil UML contient des :

  • icône
  • stéréotype : sémantique d'un élément, c’est-à-dire que l’on catégorise un élément UML, par exemple une classe, peut être stéréotypée « Goal » (but, objectif stratégique) ou « Requirement » (exigence) ou bien un acteur des use case UML peut être stéréotypé « Acteur interne » ou « Acteur externe», tous les éléments UML peuvent stéréotypés (les relations, ...)
  • tagged value (paire clé/valeur) permettant d’ajouter des méta-informations (priorité, auteur, informations pour l’outil de dérivation de modèle, pour le générateur de code, …) à un élément de modélisation UML

 

Ce profil peut aisément être recréé dans n’importe quel outil de modélisation UML open source comme Eclipse Modeling Tools.

Normalement un profil s'exporte en XMI (XML for Interchange) qui est une norme de l'OMG pour l'interopérabilité des modèles, par exemple entre les différents outils de modélisation.

Un outil de modélisation peut posséder la fonctionnalité de création de profil et son exportation au format XML/XMI puis un autre pourra offrir l'importation à condition de respecter les versions de XMI, mais ça c'est une autre histoire.

 

Le prochain article sur l'étape 2 de "Comment modéliser la phase A Vision de la méthode ADM" sera consacré à la "matrice des parties prenantes (stakeholder)".

 

Rhona Maxwel

@rhona_helena

 

"L'oreille est le chemin du cœur"

Voltaire

 

 

Articles conseillés :

 

TOGAF pour les nuls.

 

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

 

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

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

 

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)

 

Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

 

Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architectur

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles


20/03/2018
0 Poster un commentaire

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

Après la théorie sur le framework d’architecture d’entreprise, standard du marché, TOGAF, voici, des exemples complets et bien concrets illustrant la modélisation des phases du cycle de la méthode ADM (Architecture Development Method).

Les différentes études de cas sont fournies par l’outil de modélisation français, open source, Modelio.

 

exemples-tutorials-etudes-de-cas-architecture-d-entreprise-TOGAF-0.PNG

 

Installation de Modelio

 La version open source est téléchargeable à l’adresse :

 

 

Cette version permet de modéliser en UML, BPMN, supporte les modules TOGAF Architect et Archimate mais ne possède pas la partie « Analyse ».

Pour pouvoir créer des sous-projets d’analyse permettant de modéliser la stratégie, les objectifs et les exigences, il faut télécharger la version d’essai valable 10 jours, Modelio Business Analyst à l’adresse :

 

 

Cette version complète permet en plus des fonctionnalités de la version open source, de modéliser avec SysML, SOAML, de générer des documentation, du code Java, C++, C#, d’utiliser des outils MDA, et bien d’autres encore.

 

Installation des exemples

Une fois Modelio lancer, aller dans le menu Aide – Page d’accueil

 

Il suffit ensuite de sélectionner chacun des 5 projets d’exemples, et cliquer sur « Deploy » pour déployer les projets dans l’outil.

 

exemples-tutorials-etudes-de-cas-architecture-d-entreprise-TOGAF.PNG

 

Les 5 études de cas proposées par Modelio

« ArchiMetal »

Cette étude de cas démontre la valeur du langage de modélisation ArchiMate 2.1 pour planifier et exprimer une transformation commerciale complexe.

L'étude de cas porte sur un fabricant fictif nommé ArchiMetal.

Grâce à la modélisation d'architecture de haut niveau, le langage ArchiMate éclaire la cohérence entre une organisation, ses processus, ses applications et son infrastructure.

Cette étude de cas présente des exemples de modèles ArchiMate qui peuvent être élaborés au besoin pour l'analyse, la communication, l'aide à la décision et la mise en œuvre.

 

« Archisurance »

Un exemple de compagnie d'assurance fictive.

 

« Discount Travel for TOGAF »

Le projet « Discount Travel for TOGAF » est un projet montrant comment modéliser en utilisant les normes UML et BPMN, l'architecture d'entreprise d'une agence de voyage pour gérer un système de réservation.

 

Cette étude de cas utilise un profil UML c’est-à-dire un ensemble d’icônes, de tagged value et de contraintes OCL personnalisant les artefacts UML pour s'appliquer aux concepts TOGAF, sans en changer la sémantique.

 

Exemple d'article sur OCL :

 

Cette possibilité de personnalisation d’UML pour créer son propre langage fait pleinement partie de la norme UML.

 

Cet exemple constituera notre fil conducteur tout au long des prochains articles.

 

L’agence de voyage est à l’architecture d’entreprise ce que la bibliothèque est à UML ou le « Hello world » aux langages de programmation, c’est-à-dire l’exemple par lequel tout débutant se doit de commencer.

 

Ce projet de Modelio reprend l’exemple de la fameuse « agence de voyage », véritable étude de cas open source, maintes fois utilisée, qui est apparu pour la 1ère fois, illustrant le livre bestseller de Christophe Longépé « Le projet d'urbanisation du système d'information : Démarche pratique avec cas concret » (Dunod), qui est encore aujourd’hui considéré comme la bible de la démarche d’urbanisation du SI.

 

« Discount Travel for ArchiMate »

Le projet « Discount Travel for ArchiMate »est identique au projet précédent mais utilise le langage Archimate créé par l’Open Group.

 

« Shopping Cart »

Ce projet contient le modèle pour le système de panier en ligne, y compris tous les modèles utilisés pour spécifier et réaliser le système informatique.

Ce modèle porte sur le développement d'un système de panier en ligne, qui permet aux fournisseurs de vendre leurs produits directement en ligne pour les clients.

Il est fourni à titre d'exemple UML couvrant l'analyse du contexte et des processus métiers, et la conception et le déploiement d'une mise en œuvre possible.

L'objectif est de montrer la puissance qu'UML apporte à l'analyse et la conception d'un système robuste qui correspond aux exigences initiales.

 

Pour modéliser les phases de l’ADM de TOGAF, ma préférence va vers UML et BPMN, voici 2 articles parmi les catégories  UML et  BPMN consacrées à ces normes :

 

Mais pour ne pas être en reste avec Archimate, notez qu’il existe un outil open source nommé Archi (The Free ArchiMate Modelling Tool) de bonne facture que vous pouvez télécharger à l’adresse :

Il n’y a malheureusement aucun exemple livré avec !

 

Le module TOGAF Architect

Il s’agit d’une extension de Modelio dédié à la modélisation basée sur le standard des cadres d’architecture d’entreprise TOGAF.

 

En fournissant un profil dédié à la modélisation TOGAF, le module TOGAF Architect vous permet de réaliser un panorama complet des systèmes d'information d'une entreprise.

 

Il fournit les fonctionnalités suivantes :

  • Paysage et modélisation des entreprises et de leurs systèmes d'information au niveau métier, architectural et technologique.
  • Modélisation des données métiers.

 

Organisation du modèle selon le module TOGAF Architect  

 

organisation-du-modele-d-architecture-d-entreprise-TOGAF-2.PNG

 

L'architecture TOGAF est organisée au sein de la structure suivante :

  • L'architecture métier est définie dans la couche métier.
    L'architecture des données est divisée entre un niveau métier, où le niveau conceptuel des données est défini (Entités métier sous couche de gestion / entités métiers) et le niveau technique, où le modèle de données persistantes est défini (niveau application / architecture de données).
    Au niveau des entités métiers, le modélisateur s'intéresse aux concepts et à leurs propriétés, mais pas aux aspects logiques et physiques tels que les référentiels, les modèles relationnels, etc.
    Il est recommandé de modéliser d'abord les notions importantes de l'entreprise, et ensuite, de définir l'organisation de l'entreprise, les processus métier et les autres éléments de l'architecture métier.

  • L'architecture de l'application est structurée sous l'architecture de couche application.
    Il a deux domaines d'application :
       - les données de service pour modéliser les données échangées entre les services métiers
       - les cas d'utilisation système pour modéliser les cas d'utilisation liés aux principaux composants applicatifs du SI.

  • L'architecture technologique est structurée dans le domaine technologique de l'architecture technologique.

 

Conclusion

Ce projet classique d’agence de voyage modélisé avec un profil UML et BPMN, nous permettra de mettre en œuvre les phases ADM de TOGAF :

  • la phase A « Vision » avec la modélisation de la stratégie, des objectifs, des exigences
  • la phase B « Métier » avec le diagramme d’entités métier, les diagrammes d’organisation et de localisation, les diagrammes BPMN pour les processus métier
  • la phase C « Architecture des Systèmes d’Information » avec les diagrammes de communication, de cas d’utilisation applicatifs, de réalisation
  • la phase D « Architecture Technique » avec ls diagrammes d’environnement, de traitements, de matériel et réseau
  • la phase E Solutions et Opportunités avec les diagrammes de contexte de projets et les diagrammes de bénéfices.

 

Rhona Maxwel

@rhona_helena

 

"Nos problèmes ne proviennent pas de ce que nous ignorons.

Ils proviennent de ce que nous croyons savoir, et qui en fait est faux."

Mark Twain

 

 

Articles conseillés :

 

TOGAF pour les nuls. 

 

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

 

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

 

Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

 

Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

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


13/03/2018
0 Poster un commentaire

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

TOGAF recommande en phase préliminaire d'identifier les vues architecturales et les points de vue pertinents pour le cycle ADM (Architecture Development Method) afin de satisfaire les préoccupations et les exigences des différentes parties prenantes

 

diagramme-de-classe-uml-concepts-de-base-architecture-entreprise-togaf-01.PNG

 

Les « parties prenantes » (individus, des équipes ou organisations) ont des rôles clés dans le système ou des préoccupations à ce sujet ; par exemple, en tant qu'utilisateurs, développeurs ou gestionnaires.

Les différentes parties prenantes ayant des rôles différents dans le système, ils auront des préoccupations différentes.

 

Les « préoccupations » sont les intérêts clés qui sont d'une importance cruciale pour les parties prenantes du système et déterminent l'acceptabilité du système.

Les préoccupations peuvent concerner tout aspect du fonctionnement, du développement ou de l'exploitation du système, y compris des considérations telles que la performance, la fiabilité, la sécurité, la distribution et l'évolutivité.

 

Définition d’une vue

Une « vue » est une représentation d'un système entier du point de vue d'un ensemble connexe de préoccupations.

 

En capturant ou en représentant la conception d'une architecture de système, l'architecte créera généralement un ou plusieurs modèles d'architecture, en utilisant éventuellement différents outils.

Une vue comprendra des parties sélectionnées d'un ou de plusieurs modèles, choisis de manière à démontrer à un intervenant ou à un groupe de parties prenantes que leurs préoccupations sont prises en compte de manière adéquate dans la conception de l'architecture du système.

 

Définition d’un point de vue

Un "point de vue" définit la perspective à partir de laquelle une vue est prise.

Plus spécifiquement, un point de vue définit : comment construire et utiliser une vue (au moyen d'un schéma ou d'un modèle approprié) ; les informations qui devraient apparaître dans la vue ; les techniques de modélisation pour exprimer et analyser l'information ; et une justification de ces choix (par exemple, en décrivant le but et le public cible de la vue).

 

Une vue est ce que vous voyez.

Un point de vue est l'endroit où vous regardez - le point de vue ou la perspective qui détermine ce que vous voyez.

 

Les points de vue sont génériques et peuvent être stockés dans des bibliothèques pour être réutilisés.

Une vue est toujours spécifique à l'architecture pour laquelle elle est créée.

Chaque vue a un point de vue associé qui la décrit, au moins implicitement.

 

Préoccupations et exigences

Les termes « préoccupation » et « exigence » ne sont pas synonymes.

Une préoccupation est un domaine d'intérêt.

Ainsi, la fiabilité du système pourrait être une préoccupation / un domaine d'intérêt pour certaines parties prenantes.

 

La raison pour laquelle les architectes doivent identifier les préoccupations et les associer aux points de vue, est de s'assurer que ces préoccupations seront traitées d'une manière ou d'une autre par les modèles de l'architecture.

 

Par exemple, si le seul point de vue sélectionné par un architecte est un point de vue structurel, les problèmes de fiabilité ne sont presque certainement pas traités, car ils ne peuvent pas être représentés dans un modèle structurel.

 

Dans ce contexte, les parties prenantes peuvent avoir de nombreuses exigences distinctes : différentes catégories d'utilisateurs peuvent avoir des exigences de fiabilité très différentes pour les différentes capacités du système.

Les préoccupations sont la racine du processus de décomposition en exigences.

Les préoccupations sont représentées dans l'architecture par ces exigences.

Les exigences doivent être SMART (Specific Measurable Achievable Realistic Time-bound).

 

Voir notre article sur la modélisation des exigences,

 

Conclusion

Les vues d'architecture sont donc des représentations de l'architecture globale en termes significatifs pour les parties prenantes.

Ils permettent à l'architecture d'être communiquée et comprise par les parties prenantes, afin qu'ils puissent vérifier que le système répondra à leurs préoccupations.

 

Rhona Maxwel

@rhona_helena

  

"Toutes les choses intelligentes ont déjà été pensées.

Ce qu’il faut à présent, c’est essayer de les repenser."

Johann von Goethe

 

 

Articles conseillés :

 

SysML : tutoriel ( tutorial - didacticiel ) Le diagramme de package (partie 2) 

 

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

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles

 

Le Big-Mac de l'urbanisation SI

 

Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

 

TOGAF pour les nuls.


09/03/2018
0 Poster un commentaire

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles

Un modèle est faux par nature !

Il n’est pas conçu pour être vrai et représenter parfaitement la réalité mais pour répondre à un usage. Un modèle n’est ni bon ni mauvais, un modèle est juste adapté ou pas à un usage.

 

fondamentaux-de-la-modelisation-systeme-d-information-bon-usage-des-modeles.gif

  

Un modèle est comparable aux cartes géographiques, il peuvent être déclinés à différentes échelles qui permettront de zoomer sur une partie du domaine traité pour en connaître les détails les plus subtils.

 

Combien de fois ai-je entendu au cours de mes missions, les DBA me dire : « mais il manque des choses dans ton modèle » et combien leur ai-je répondu « mais regarde, tu n’es pas dans la liste des destinataires. C’est un modèle à forte granularité, spécialement conçu pour le comité d’architecture d’entreprise, ne t’inquiète pas ce modèle subira différentes dérivations qui ajouterons les détails qui te permettons de concevoir la base de données. »

 

Un modèle est une représentation d’une réalité matérielle ou immatérielle, un modèle n’est pas cette réalité.

On pourra affiner les modèles en créant de nouveaux modèles de plus en plus détaillés jusqu'à peut être atteindre de manière asymptotique le monde réel sans jamais l'atteindre.

Modéliser est donc l’acte de représenter nos concepts et les objets de notre réalité.

 

Cette réalité pouvant être immatériel et exister uniquement comme construction mentale, par exemple un remboursement de soins d’une mutuelle n’a pas d’existence physique mais est une réalité pour beaucoup de gens, le relevé papier rend concrète et matérielle la réalité du remboursement.

Un modèle est forcément une description limitée et orientée de la réalité.

 

Il est impossible de décrire de manière absolue la réalité à des fins descriptives ou prédictives, sans même parler de l’intérêt d’une telle démarche.

 

Un modèle va décrire la réalité avec un certain filtre, en utilisant certains concepts permettant de classifier la réalité observée.

Par exemple, un processus de liquidation d’une garantie décès d’un contrat de prévoyance sera décrit avec les notions d’événements (dossier client déposé), d’activités (vérifier les pièces, remplir le dossier), de transitions (les conditions sont respectées alors le dossier est transmis au contrôleur).

De manière très simplifié, un modèle décrit toujours une réalité observable ou, encore mieux, mesurable et donc numérique.

La réalité observable peut être décrite en répondant aux questions : « Quoi ? Qui ? Quand ? Où ? Comment ? » ainsi qu’en décrivant les contraintes qui définissent les limites du modèle.

 

La léthargie d’une entreprise dû à la complexité peut être éviter grâce à la modélisation

Les modèles offrent des mécanismes d'abstraction, permettant de raisonner à des niveaux plus macroscopiques, en agrégeant des éléments détaillés, en ne révélant que les parties significatives, ou en généralisant des notions et mécanismes.

 

L'abstraction permet de gérer la complexité, qui est un frein important dans les entreprises.

La complexité cause en effet la léthargie et l’inertie qui empêchent beaucoup d’entreprises d'être réactives.

 

L'abstraction est rendue nécessaire pour des besoins primaires de gestion, de classification, et des besoins plus sophistiqués de mutualisation, de rapprochement, de rationalisation.

Pour des raisons de pédagogie, l'abstraction est également utilisée pour adapter les niveaux de détails présentés selon les interlocuteurs correspondant à points de vue différents, dédiés à des parties prenantes spécifiques.

Le niveau d'abstraction doit être défini en détail selon les objectifs et les parties prenantes ciblés par le modèle.

 

Les modèles comme principal support de communication au sein de l’entreprise

« Nous ne raisonnons que sur des modèles » Paul Valéry

 

En formalisant les connaissances, ils permettent de comprendre et d'éclaircir un problème.

Avec les modèles, les différents constituants d'un domaine d'étude sont représentés, différents types de liaisons permettent de les positionner, et ces constituants sont valorisés en leur affectant des propriétés.

 

Les modèles constituent alors un support à la réflexion, et sont enrichis par les résultats de celle-ci.

En matérialisant la compréhension d'un problème, un modèle décrira à la fois le contexte, le domaine ciblé, et reflétera l'intention, le projet de construction qui est imaginé.

La communication est une nécessité première au sein des entreprises, pour laquelle les modèles offrent un support important.

 

Les entreprises utilisent les modèles pour représenter leur organisation.

Ceux-ci servent d'une part à cartographier les éléments de l'entreprise, comme les rôles dans l'entreprise, les sites, les processus métier, les ressources matérielles, les applications, et d'autre part à détailler ses constituants et son fonctionnement comme le déroulement d'un processus métier. Cartographier consiste à répertorier, classifier et positionner l'existant, pour partager sa connaissance et permettre à chacun de situer les constituants d'une carte.

 

Les modèles facilitent également le dialogue entre des expertises différentes dans l'entreprise, comme typiquement entre MOA et MOE, ou encore entre utilisateurs et analystes métier.

 

Ainsi, les modèles peuvent servir à représenter les besoins métier des utilisateurs, puis ils sont ensuite codifiés de manière précise pour préparer le travail des architectes et concepteurs.

 

Les modèles servent ainsi à partager une connaissance, et à collaborer à sa construction.

Un travail collaboratif peut en effet s'appliquer sur les modèles qui sont enrichis par la contribution de chacun tout en étant partagés.

La modélisation des connaissances sur le métier, sur l'organisation, sur les processus et sur le SI permet de constituer un patrimoine pour l'entreprise pouvant être réutilisé et exploité de multiples façons.

 

Simuler et vérifier qu’un système fonctionne

Voir la série d’articles que j’avais consacrée aux techniques de vérification et simulation des modèles :

 

 

Très utilisés dans toutes sortes de projets d'ingénierie, les modèles sont également exploités pour prévoir et simuler le comportement du système à réaliser, mais aussi les travaux de construction du système.

 

Le modèle, en fournissant une vision d'ensemble, permet plus facilement d'appliquer des changements selon une stratégie particulière.

 

On peut aussi tester des hypothèses, imaginer des variantes : ces activités ne peuvent, en effet, pas être envisageables lors de la réalisation effective du projet, du fait de leur lourde charge en coûts et délais.

 

Par ailleurs, les modèles sont fréquemment utilisés pour identifier des lots de travail au sein d'un projet, afin de déléguer et suivre ces travaux.

 

Dériver les modèles pour générer des productions informatique

L'informatique utilise les modèles aussi pour générer automatiquement des productions informatiques plus détaillées : par exemple du code, des schémas de base de données ou des documents.

 

Lors de leur évolution au cours du temps, depuis la vision vers la réalisation, les modèles deviennent de plus en plus précis, formels, pour guider voire automatiser le travail des architectes, concepteurs puis développeurs.

 

L'inconvénient de cette approche est que dès lors qu'un modèle est suffisamment précis pour être exécutable, il devient beaucoup moins utile pour comprendre et raisonner sur les systèmes complexes.

 

L'architecture d'entreprise est davantage centrée sur la spécification et la conception que sur la construction.

Elle requiert des modèles moins précis et formels.

 

Utiliser les normes UML, BPMN, SysML, BMM, DMN, SOAML, …

L'intérêt des modèles est décuplé par leur standardisation : celle-ci assure une notation unique, connue de tous, partagée entre tous les pays et pour tous les domaines connexes de l'architecture d'entreprise (organisation, processus métier, données, applications) et de l'informatique ; elle fournit une sémantique — c'est-à-dire une définition de l'ensemble de ses termes, mécanismes et constructions — formellement élaborée, limitant ainsi les interprétations que l'on peut avoir d'un modèle ; elle garantit un marché à un grand nombre d'outils associés (modélisation, génération...) ; elle permet une interopérabilité entre ateliers de modélisation évitant ainsi d'être prisonnier d'un atelier particulier.

 

Les modèles réalisés pour l'entreprise ont alors une valeur patrimoniale augmentée par le fait qu'ils sont exploitables par un très grand nombre de personnes et d'outils.

 

Mais attention ces normes formalisent des représentations mais ne précisent pas de méthode d’utilisation.

Je me souviens lors de recrutement, des personnes interrogées sur leur CV, qui me disaient bien connaître la « méthode UML »

 

Cependant, les modèles tels que UML et BPMN sont une boîte à outils très vaste.

Il revient alors à chaque organisation de définir ses conventions, quelles parties de ces modèles sont utilisées et à quelles fins, quelles extensions sont apportées.

 

On peut utiliser dans quelques cas des modèles informels qui n'obéissent pas à un formalisme rigoureux.

Ce sont souvent des graphiques libres, des supports aux idées, des moyens de communication spontanés.

Ils sont naturellement utilisés lors de réunions de travail et sont des facilitateurs de communication spontanée.

Dans les phases initiales d'analyse, lorsque les données du problème ne sont pas clairement établies et qu'il faut bâtir un consensus pour cadrer le domaine d'intervention et les travaux à effectuer, ou lorsqu'il faut communiquer avec des interlocuteurs non avertis des modèles utilisés, les modèles informels peuvent être utilisés.

 

L’outil mindmap en est un bon exemple.

Une Mind Map, encore appelée topogramme, schéma heuristique ou carte mentale, est un diagramme utilisé pour voir, classifier et organiser des concepts, ainsi que pour générer de nouvelles idées.

Elle est utilisée pour connecter des mots, des idées et des concepts à une idée ou un concept central.

Voir les articles consacrés à ce sujet :

 

 

 

 

Ou bien encore le diagramme d’Ishikawa (plus connu sous le nom de diagramme d’arrêtes de poisson ou encore diagramme d’objectifs/sous-objectifs) qui consiste à identifier l’objectif final d’un processus métier puis les sous-objectifs permettant de l’atteindre et ainsi de suite de manière récursive.

 

 

En phase A (vision), ces modèles informels peuvent par exemple être utilisés pour produire des diagrammes de solution conceptuelle ou des diagrammes de chaîne de valeur.

Ils serviront alors de base à la construction de modèles « formels » plus précis et gérés par des ateliers de modélisation.


Par contre, lorsque l'on progresse vers la solution technique, les modèles doivent être plus précis, et fournir un grand niveau de détail sur le fonctionnement de la solution.

On aboutit ainsi à des modèles plus formels, décrivant en détail la structure des données, ou la logique d'enchaînement des activités dans un processus.

On s'adresse ici à des interlocuteurs plus avertis, ce qui autorise l'usage de modèles plus techniques.

Les phases d'élaboration de l'ADM exploiteront ainsi davantage les modèles formels.

 

La gouvernance des modèles

Le modèle n'est qu'un constituant au sein de TOGAF, le point majeur étant le cycle ADM.

L'ADM fournit les processus et activités qui produisent et consomment les modèles, et qui motivent leurs évolutions dans le temps pour des objectifs déterminés.

Le modèle est un outil qui doit être ciblé sur les usages pertinents dans le contexte de l'entreprise.

Les limitations des modèles (incomplétude, difficulté de mise à jour ) nécessitent un calibrage et une gouvernance adaptée.

 

Par ailleurs, les modèles ne fournissent pas les informations de contexte nécessaires à leur bonne compréhension :

 

  • Pourquoi ce modèle est-il élaboré ?
  • Quel problème veut-on traiter ?
  • Comment sera-t-il exploité ?

 

La gouvernance doit intégrer des politiques et des règles concernant la modélisation comme la gestion du cycle de vie d’un modèle,  mettre en place des conventions sur les méta informations d’un modèle (son propriétaire, les droits d’un utilisateur, le but recherché, les destinataires, le versionning, …).

 

Leurs spécialisations à travers les différents artefacts TOGAF de nature « diagramme », et leur structuration en point de vue permettront de résoudre ce dernier point : pour chaque utilisation de modèle dans un artefact, TOGAF et le point de vue affecté nous indiquent quelles grandes préoccupations sont ciblées, et à quels participants s'adressent les modèles.

 

TOGAF et la modélisation

Selon TOGAF, un modèle est une représentation d'un sujet particulier.

Le modèle fournit cette représentation sur une échelle réduite, d'une manière simplifiée ou plus abstraite, relative au sujet concerné.

Dans le contexte de l'architecture d'entreprise, le sujet est l'entreprise ou certaines de ses parties.

La finalité du modèle est l'élaboration de vues qui adressent les préoccupations des parties prenantes : leurs points de vue sur l'entreprise.

 

Conclusion

Les normes UML, BPMN, SysML, BMM, DMN, SOAML, … sont des boites à outils, des notations, mais pas des méthodes.

TOGAF recommande l'usage de UML et BPMN.

Cependant, TOGAF a son propre métamodèle.

L’architecte qui doit modéliser doit au préalable définir la manière d'utiliser ces normes pour TOGAF, et comment mettre en correspondance les concepts de ces normes et les concepts TOGAF.

 

L'abstraction permet de gérer la complexité, qui est un frein important dans les entreprises.

La complexité cause en effet la léthargie et l’inertie qui empêchent beaucoup d’entreprises d'être réactives.

Pour mettre en œuvre la réutilisabilité, l’évolutivité, la flexibilité, la maintenabilité, la capacité d’innovation, une entreprise est obligée de pratiquer la modélisation de son fonctionnement.

  

Rhona Maxwel

@rhona_helena

 

"Tous les modèles sont faux, certains sont utiles."

G. Box

 

 

Articles conseillés :

 

UML

 

SysML

 

BPMN

 

DMN

 

 

BMM

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 2ème partie - Processus métiers - Profil UML Eriksson Penker


27/02/2018
0 Poster un commentaire

Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace

Cet article fournit des directives pratiques pour la mise en œuvre efficace de la gouvernance de l'architecture. Une architecture d'entreprise imposée sans soutien politique approprié est vouée à l'échec. Pour réussir, l'architecture d'entreprise doit refléter les besoins de l'organisation.

 

cadre-de-gouvernance-de-l-architecture-TOGAF-structure-organisationnelle-2.PNG

Gouvernance de l'architecture - Principaux facteurs de succès

Il est important de prendre en compte les éléments suivants pour assurer une approche réussie de la gouvernance de l'architecture et une gestion efficace du contrat d'architecture :

 

  • Meilleures pratiques pour la soumission, l'adoption, la réutilisation, la création de rapports et le retrait des politiques, procédures, rôles, compétences, structures organisationnelles et services de support de l'architecture
  • Responsabilités organisationnelles et structures pour soutenir les processus de gouvernance de l'architecture et les exigences de rapport
  • Intégration d'outils et de processus pour faciliter l'adoption des processus, tant sur le plan procédural que culturel
  • Critères pour le contrôle des processus de gouvernance de l'architecture, des dispenses, des évaluations de conformité, des SLA (Service Level Agreement) et des OLA (Operational Level Agreement).
  • Exigences internes et externes pour l'efficacité, la confidentialité, l'intégrité, la disponibilité, la conformité et la fiabilité de toutes les informations, services et processus liés à la gouvernance de l'architecture

 

Éléments d'une stratégie efficace de gouvernance de l'architecture

Gouvernance de l'architecture et politique corporative

Une architecture d'entreprise imposée sans soutien politique approprié est vouée à l'échec.

Pour réussir, l'architecture d'entreprise doit refléter les besoins de l'organisation.

Les architectes d'entreprise, s'ils ne sont pas impliqués dans le développement de la stratégie métier, doivent au moins en avoir une compréhension fondamentale ainsi que des problèmes métiers qui se posent à l'organisation.

Il peut même être nécessaire de les impliquer dans le processus de déploiement du système et de prendre en fin de compte les décisions d'investissement et de sélection des produits découlant de la mise en œuvre de l'architecture technologique.

 

Conclusion

Il y a trois éléments importants de la stratégie de gouvernance de l'architecture qui concernent particulièrement l'acceptation et le succès de l'architecture au sein de l'entreprise.

 

  • Un conseil d'architecture inter organisationnel doit être créé avec le soutien de la direction pour superviser la mise en œuvre de la stratégie de gouvernance informatique.
  • Un ensemble complet de principes d'architecture devrait être établi, afin de guider, d'informer et de soutenir la manière dont une organisation entreprend de remplir sa mission grâce à l'utilisation de l'informatique.
  • Une stratégie de conformité de l'architecture devrait être adoptée - des mesures spécifiques (plus qu'une simple déclaration de politique) pour assurer la conformité avec l'architecture, y compris les évaluations d'impact des projets de l'équipe d'architecture.

 

Rhona Maxwel

@rhona_helena

 

"Si la matière grise était plus rose, le monde aurait moins les idées noires."

Pierre Dac

 

 

Articles conseillés

 

TOGAF pour les nuls.

 

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)

 

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

 

Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?

 

Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces


24/02/2018
0 Poster un commentaire

Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces

Cet article décrit un cadre conceptuel et organisationnel pour la gouvernance de l'architecture.

Le cadre de gouvernance est ici, un cadre générique qui peut être adapté à l'environnement de gouvernance existant d'une entreprise.

Il est destiné à aider à identifier les processus et les structures organisationnelles efficaces, de sorte que les responsabilités métiers associées à la gouvernance de l'architecture puissent être élucidées, communiquées et gérées efficacement.

  

La Phase G de TOGAF est dédiée à la gouvernance de la mise en œuvre, qui concerne la réalisation de l'architecture à travers des projets de changement.

 

Voir les articles : 

  

La gouvernance de la mise en œuvre n'est qu'un aspect de la gouvernance de l'architecture, qui couvre la gestion et le contrôle de tous les aspects du développement et de l'évolution des architectures d'entreprise et autres architectures au sein de l'entreprise.

 

Cadre de gouvernance de l'architecture - Structure conceptuelle

Les fondamentaux

Conceptuellement, la gouvernance de l'architecture est une approche, une série de processus, une orientation culturelle et un ensemble de responsabilités qui garantissent l'intégrité et l'efficacité des architectures de l'organisation.

 

cadre-de-gouvernance-de-l-architecture-TOGAF-structure-conceptuelle-1.PNG

 

La division du processus, du contenu et du contexte est essentielle au soutien de l'initiative de gouvernance de l'architecture, en permettant l'introduction de nouveaux documents de gouvernance (juridiques, réglementaires, normatifs ou législatifs) sans impacter indûment les processus. Cette approche agnostique du contenu garantit la flexibilité du cadre.

Les processus sont généralement indépendants du contenu et mettent en œuvre une approche éprouvée des meilleures pratiques en matière de gouvernance active.

 

Le cadre de gouvernance de l'architecture fait partie intégrante du continuum des entreprises et gère tout le contenu pertinent à la fois pour l'architecture elle-même et pour les processus de gouvernance de l'architecture.

 

Principaux processus de gouvernance de l'architecture

Des processus de gouvernance sont nécessaires pour identifier, gérer, auditer et diffuser toutes les informations relatives à la gestion de l'architecture, aux contrats et à la mise en œuvre.

Ces processus de gouvernance seront utilisés pour s'assurer que tous les artefacts et les contrats d'architecture, les principes et les accords de niveau opérationnel font l'objet d'un suivi continu avec une vérifiabilité claire de toutes les décisions prises.

 

Gestion des stratégies et prise en charge

Toutes les modifications d'architecture, tous les contrats et toutes les informations de support doivent être soumis à un processus formel afin de pouvoir enregistrer, valider, ratifier, gérer et publier du contenu nouveau ou mis à jour.

Ces processus assureront l'intégration ordonnée avec le contenu de gouvernance existant de sorte que toutes les parties concernées, les documents, les contrats et les informations de support soient gérés et audités.

 

Conformité

Les évaluations de conformité par rapport aux accords de niveau de service (SLA Service Level Agreement), aux accords de niveau opérationnel (OLA Operational Level Agreement), aux normes et aux exigences réglementaires seront mises en œuvre de manière continue pour assurer la stabilité, la conformité et le suivi des performances.

Ces évaluations seront examinées et acceptées ou rejetées selon les critères définis dans le cadre de gouvernance.

 

Dispense

Une évaluation de la conformité peut être rejetée lorsque le domaine (conception, exploitation, niveau de service ou technologie) n'est pas conforme.

Dans ce cas, le sujet peut :

 

  1. Être ajusté ou réaligné afin de répondre aux exigences de conformité
  2. Demander une dérogation

 

Lorsqu'une évaluation de conformité est rejetée, un itinéraire alternatif pour se conformer à la conformité provisoire est fourni au moyen de dérogations.

Ceux-ci sont accordés pour une période de temps donnée et un ensemble de critères de service et opérationnels identifiés qui doivent être appliqués pendant la durée de la dispense.

Les dispenses ne sont pas accordées indéfiniment, mais sont utilisées comme un mécanisme pour assurer que les niveaux de service et les niveaux opérationnels sont atteints tout en offrant un niveau de flexibilité dans leur mise en œuvre et leur calendrier.

La nature temporelle des dispenses garantit qu'elles constituent un déclencheur majeur dans le cycle de conformité.

 

Surveillance et rapports

La gestion des performances est nécessaire pour garantir que les éléments opérationnels et de service sont gérés selon un ensemble de critères convenus.

Cela inclura la surveillance des accords de niveau de service et opérationnel, des commentaires pour ajustement et des rapports.

Les informations de gestion interne seront prises en compte dans la gestion de l'environnement.

 

Contrôle de gestion

Le Contrôle de gestion concerne les processus invoqués pour garantir la conformité aux stratégies de l'entreprise.

 

Gestion de l'environnement

Ceci identifie tous les services requis pour s'assurer que l'environnement basé sur le référentiel qui sous-tend le cadre de gouvernance est efficace et efficient.

Cela inclut la gestion du référentiel physique et logique, l'accès, la communication, la formation et l'accréditation de tous les utilisateurs.

 

Tous les artefacts d'architecture, les contrats de service, les contrats et les informations de support doivent être soumis à un processus formel d'enregistrement, de validation, de ratification, de gestion et de publication de contenu nouveau ou mis à jour.

Ces processus assureront l'intégration ordonnée avec le contenu de gouvernance existant de sorte que toutes les parties concernées, les documents, les contrats et les informations de support soient gérés et audités.

 

L'environnement de gouvernance aura un certain nombre de processus administratifs définis afin de créer un environnement de service et de processus géré.

Ces processus incluront la gestion des utilisateurs, les SLA internes (définis afin de contrôler ses propres processus) et les rapports d'informations de gestion.

 

Cadre de gouvernance de l'architecture - Structure organisationnelle

Nécessité de mettre en place les structures organisationnelles appropriées

La gouvernance de l'architecture est la pratique et l'orientation par lesquelles les architectures d'entreprise et autres architectures sont gérées et contrôlées.

Afin de s'assurer que ce contrôle est efficace au sein de l'organisation, il est nécessaire de mettre en place les structures organisationnelles appropriées pour soutenir toutes les activités de gouvernance.

 

Une structure de gouvernance d'architecture peut impliquer en pratique une combinaison de processus de gouvernance informatique, de structures organisationnelles et de capacités existants. Ils comprennent généralement les éléments suivants :

 

  • Conseil de gouvernance mondiale
  • Conseil de gouvernance locale
  • Autorités de conception
  • Groupes de travail

 

cadre-de-gouvernance-de-l-architecture-TOGAF-structure-organisationnelle-2.PNG

 

L'organisation de l'architecture met en évidence les principaux éléments structurels requis pour une initiative de gouvernance de l'architecture.

Bien que chaque entreprise ait des exigences différentes, on s'attend à ce que les principes de base de la conception organisationnelle soient applicables dans une grande variété de types organisationnels.

 

Les trois domaines clés de la gestion de l'architecture : Développer, Mettre en œuvre et Déployer.

Chacun d'entre eux est la responsabilité d'un ou plusieurs groupes au sein de l'organisation, tandis que le continuum des entreprises est montré pour soutenir toutes les activités et les artefacts associés à la gouvernance des architectures tout au long de leur cycle de vie.

 

Les responsabilités, les processus et les structures de développement sont généralement liés à ADM (Architecture Development Method) de TOGAF et à son utilisation, tandis que les responsabilités, les processus et structures d'exécution sont généralement liés à la phase G.

 

Avantages opérationnels

La gouvernance des architectures de l'organisation fournit non seulement un contrôle et une orientation directs de leur développement et de leur mise en œuvre, mais s'étend également aux opérations des architectures mises en œuvre.

 

Les avantages suivants découlent de la gouvernance continue des architectures :

 

  • Relie les processus, ressources et informations informatiques aux stratégies et objectifs organisationnels
  • Intégrer et institutionnaliser les meilleures pratiques informatiques
  • S'aligne sur les cadres de l'industrie tels que COBIT (planification et organisation, acquisition et mise en œuvre, livraison et support, suivi de la performance informatique)
  • Permet à l'organisation de tirer pleinement parti de ses informations, de son infrastructure et de ses ressources matérielles et logicielles
  • Protège les actifs numériques sous-jacents de l'organisation
  • Soutient les exigences réglementaires et les meilleures pratiques telles que la vérifiabilité, la sécurité, la responsabilité et la responsabilité
  • Favorise la gestion du risque visible

Ces avantages positionnent le cadre de gouvernance de l'architecture de TOGAF comme une approche, une série de processus, une orientation culturelle et un ensemble de responsabilités qui, ensemble, garantissent l'intégrité et l'efficacité des architectures de l'organisation.

 

Conclusion

Conceptuellement, la gouvernance de l'architecture est une approche, une série de processus, une orientation culturelle et un ensemble de responsabilités qui doivent garantir l'intégrité et l'efficacité des architectures de l'organisation.

Afin de s'assurer que ce contrôle est efficace au sein de l'organisation, il est nécessaire de mettre en place les structures organisationnelles appropriées pour soutenir toutes les activités de gouvernance.

 

Rhona Maxwel

@rhona_helena

 

"Créer, c'est vivre deux fois"

Albert Camus

 

 

Articles conseillés :

 

Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

 

Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

 

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

 

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

 

TOGAF pour les nuls.


23/02/2018
0 Poster un commentaire