TOGAF - urbanisation-si, modelisation-metier, processus-metier, expression-des-besoins

urbanisation-si

urbanisation-si

TOGAF

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


Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio

Le diagramme de contextes de projets modélise tout ce qui nécessaire à la réalisation d’un projet : acteurs, processus métier, règles métier, services métier, entités métier, composants applicatifs.  

Ce modèle est réalisé par les architectes applicatifs et experts métier avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.


diagramme-de-contexte-de-projet-phase-e-solutions-et-opportunites-togaf.PNG


Cette phase réutilise les éléments de modélisation des phases précédentes, avec peu de modèles spécifiques.

 

Pour plus de précisions sur les éléments de modélisation avec UML des phases précédentes de TOGAF, voir les articles :

 

 

Pour le projet de réalisation de “TripReservationSite” (stéréotypé composant d’application d’interaction), ce modèle montre que le site internet :

  • est utilisé par les acteurs “Account manager” (interne) et “Client” (externe)
  • satisfait à l'exigence d'accès au SI à internet
  • doit envoyer un flux d’informations à la fédération de systèmes des partenaires “Partners”
  • doit envoyer un flux d’informations à l’application “AccountingERP”
  • doit accéder au référentiel “PortfolioRepository” pour récupérer des données métier
  • réalise le processus métier “Reserve trip”
  • réalise les cas d’utilisation “Reserve trip”, “Consult offer” et “Cancel trip”

 

Conclusion

Le diagramme de contextes de projets modélise le périmètre d’un projet faisant partie de la trajectoire de transformation.

Il montre :

  • les acteurs,
  • les flux d’information avec les autres applications internes et les systèmes externes,
  • l’implémentation : des processus métier, règles métier, entités métier, cas d’utilisation, composants applicatifs et services métier.

  

Les ajouts, modifications et suppressions d’entités au sens large doivent figurer sur le modèle.

 

Le modèle sert à l’initialisation des projets et à la gestion de portefeuilles applicatifs.

 

Rhona Maxwel

@rhona_helena

 

“Souvent, les hommes se haïssent les uns les autres parce qu'ils ont peur les uns des autres ; ils ont peur parce qu'ils ne se connaissent pas ; ils ne se connaissent pas parce qu'ils ne peuvent pas communiquer ; ils ne peuvent pas communiquer parce qu'ils sont séparés.”
Martin Luther King



Annexe : les précédentes étapes de notre étude de cas TOGAF

 


29/08/2018
0 Poster un commentaire

Le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF - étape 40 de l’exemple Modelio

Le diagramme de bénéfices modélise les possibilités d’amélioration avec leurs avantages et leurs inconvénients et participe à l'initialisation d'un nouveau cycle ADM (Architecture Development Method) de TOGAF.

Ce modèle est réalisé par les architectes applicatifs avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.

 

diagramme-de-benefices-phase-e-solutions-et-opportunites-togaf.PNG
 

La phase E Solutions et opportunitésde TOGAF a été abordée dans notre article : 

 

 

Cette phase réutilise les éléments de modélisation des phases précédentes, avec peu de modèles spécifiques.

 

Pour plus de précisions sur les éléments de modélisation avec UML des phases précédentes de TOGAF, voir les articles :

 

 

Le diagramme de bénéfices se base sur le diagramme de communication des applications de la phase C (voir l’article : “ Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel  “).

 

Les améliorations envisagées sont modélisées sous forme de commentaires UML.

Le commentaire détaille la fonctionnalité et sa contribution en terme d'ajout de valeur à l'entreprise.

Pour aider les décideurs à arbitrer, on doit dans le commentaire préciser la complexité de réalisation et l’estimation de la charge de développement.

 

Sur le composant d’application d’interaction modélisant le site internet “TripReservationSite”, il est envisagé d’exploiter et d’analyser finement les précédentes visites des clients et prospects afin de leur présenter éventuellement des remises ou des cadeaux.

Pour cette évolution, la complexité est évaluée à “forte” et l’estimation de la charge de développement à 2000 lignes de codes.

 

Un nouveau stéréotype est défini, le composant d’application intermédiaire (T).

Par exemple “Client history management” est un composant sophistiqué pouvant faire appel à du Big Data ou de l’Intelligence Artificielle.

Il consiste ici à analyser l’historique des actions du client comme ses anciennes commandes, ses consultations récentes, …

L’objectif est de lui proposer des promotions et orienter ses choix en accord avec ses goûts.

Pour cette évolution, la complexité est évaluée à “moyenne” et l’estimation de la charge de développement à 5000 lignes de codes.

 

Pour le composant d’application entité “Client history” l’évolution consiste ici à stocker l’historique du client ce qui n’avait pas été réalisé dans la précédente itération car non prioritaire face aux autres fonctionnalités.

Pour cette évolution, la complexité est évaluée à “simple” et l’estimation de la charge de développement à 2000 lignes de codes.

 

Pour le composant d’application entité “Client” l’évolution consiste à gérer les prospects et à gérer leur historique. 

La gestion des prospects n'avait été jugée prioritaire lors de la précédente itération.

Pour cette évolution, la complexité est évaluée à “simple” et l’estimation de la charge de développement à 2000 lignes de codes.

 

Conclusion

Le diagramme de bénéfices modélise les évolutions possibles et se positionne comme une base de travail pour étudier :

  • les apports en terme de valeur pour l’entreprise
  • le niveau de complexité
  • l’estimation de réalisation
  • les risques

Ce modèle participe à l’initialisation d’une nouvelle itération ADM.

 

Une analyse d’impacts sur la précédente itération doit être effectuée.

 

Les changements, les impacts et les objectifs seront répartis en nouveaux projets..

 

Rhona Maxwel

@rhona_helena

 

“La règle d'or de la conduite est la tolérance mutuelle, car nous ne penserons jamais tous de la même façon, nous ne verrons qu'une partie de la vérité et sous des angles différents.”
Gandhi



Annexe : les précédentes étapes de notre étude de cas TOGAF

 


29/08/2018
0 Poster un commentaire

Le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF - étape 39 du tutorial Modelio

Le diagramme de matériel informatique en réseau modélise le déploiement des composants d’application, tous types confondus, dans une architecture technique distribuée.

Ce modèle est réalisé par les architectes technique avec comme référents les ingénieurs systèmes/réseau à destination des responsables d’exploitation et des développeurs.

 

diagramme-reseau-materiel-informatique-tutorial-togaf-phase-d-architecture-technique.PNG

 

Pour plus de précisions sur les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF, voir l’article :

 

 

L’outil utilisé est le diagramme de déploiement UML (voir notre article : “   Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio “).

 

Les grandes organisation (corporate) ont souvent pour des raisons historiques un agrégat hétérogène de serveurs de type mainframe IBM fonctionnant sous MVS, des serveurs Microsoft Windows et des serveurs Linux en cluster tendant du reste à remplacer de nos jours les antédiluviens mainframe.

 

Dans cet exemple, une instance de l’application “:TripPortfolioManager-V2” accède à une instance du composant d’application de base de données “:PortfolioRepository” (par exemple DB2).

Ces 2 composants sont déployés dans un mainframe IBM “MVS server” connecté via un LAN au serveur d’application “Linux server”.

 

Une instance de l’application “:AccountingERP” accède à une instance du composant d’application de base de données “:AccountingRepository” (par exemple Microsoft SQL server).

Ces 2 composants sont déployés dans un serveur Microsoft “Windows server” connecté via un LAN au serveur d’application “Linux server”.

 

Le serveur Unix “Linux server” exécute 3 logiciels serveur stéréotypés composant d’application utilitaire.

Il s’agit :

 

  • d’une instance d’un moteur de processus métier BPM (composant d’application utilitaire) “:BPEL server” (voir notre article : “ Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio  “) dans lequel s’exécute le composant d’application de processus “:ReserveTrip”

  • d’une instance de SGBR “:OrderRDB”, le commentaire UML indique qu’il s’agit de la base de données open source MySQL.

  • d’une instance d’un logiciel serveur HTPP (composant d’application utilitaire) “:WEB server” exécutant une instance du composant d’application d’interaction correspondant au site internet  “:TripReservationSite” développé en PHP comme le montre le commentaire UML.

  • d’une instance du conteneur JEE (composant d’application utilitaire) “:Application server”, dans lequel s’exécute des composants d’application d’entité “:Client”, “:Order” et “:Trip” et de processus “:Invoicing”.
    Ces composants d’entité ou de processus sont des services web avec leurs différentes typologies, services d’orchestration, fonctionnels, applicatifs, d’entités métier, ... (voir l’annexe 2 sur l’architecture SOA).

 

A noter le framework open source “Hibernate” qui assure la couche d’ORM (Object Relational Mapping) faisant la traduction d’un modèle de classe UML orienté objet en un modèle relationnel de SGBR.

Le langage HQL (Hibernat Query Language), traduit automatiquement en SQL du SBDR, les requêtes tout en conservant les concept objet et en faisant abstraction du mode physique de stockage (voir l’article consacré à l’ORM : “ A ma gauche Hibernate version 4.3.6 contre MyBatis version 3.2.8, qui va remporter le titre 2014 de champion ORM toute catégorie ?  “).

Remarque : Oracle a confié les développements futurs de JEE à l’organisation open source Eclipse qui l’a renommé Jakarta EE.

 

Les postes de travail sont modélisés sous la forme générique “Workstation” connectés aux serveurs “MVS server” et “Windows server” avec des LAN et accède au serveur d’application “Linux server” via internet (HTTP) avec le navigateur de Microsoft.

 

Afin de bien vérifier que tous les acteurs internes “Marketing officer”, “Account manager”, “Invoicing officer” et externe “Client”, ont bien accès à leurs applications remplissant leurs besoins métier, on les représente en lien à leur poste de travail.

 

Conclusion

Le diagramme de matériel informatique en réseau constitue une cartographie des infrastructures informatiques hébergeant les composants applicatifs ainsi que les acteurs accèdant à ces composants.

 

Rhona Maxwel

@rhona_helena

 

“Une joie partagée est une double joie, un chagrin partagé est un demi-chagrin.”
Jacques Deval



Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 



Annexe 2 : l’architecture SOA (Service Oriented Architecture)

 


28/08/2018
0 Poster un commentaire

Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio

Le diagramme de traitements modélise les unités déployables de code et configuration ainsi que leur déploiement sur la plate-forme technologique.

Ce modèle est réalisé par les architectes technique avec comme référents les ingénieurs systèmes/réseau à destination des responsables d’exploitation et des développeurs.

 

diagramme-de-traitements-etude-de-cas-togaf-phase-d-architecture-technique.PNG

 

Pour plus de précisions sur les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF, voir l’article :

 

 

Une unité de déploiement représente un regroupement de fonctions métier, de services ou de composants d'application.

 

Le diagramme de traitement permet d’identifier

  • les composants d'application qui doivent être regroupés pour former une unité de déploiement
  • les moyens de communication entre les unités de déploiement comme les topologies et types de réseaux (LAN, WAN) ainsi que les protocoles de transport (TCP/IP, …) et les protocoles applicatifs (HTTP + SOAP + WSDL pour SOA, …)
  • la volumétrie, les capacités CPU, le dimensionnement des réseaux, ... à mettre en place pour satisfaire les estimations de charge.


Les unités de déploiement peuvent être présentées sous la forme (stéréotype UML) d'instances de composant d'application utilitaire (par exemple, un serveur d'application), hébergeant des composants d'application  .


Les associations entre ces unités de déploiement représenteront les connexions (par exemple, un réseau), tandis que les flux d'informations indiqueront la nature des informations échangées.

 

Dans ces diagrammes, des indications sur les besoins en capacité sont fournies.


Les composants de l'application sont déployés dans les unités de configuration déployables, qui sont elles-mêmes des types spécifiques de composants d'application , au niveau de la technologie (serveur web, serveur BPM, serveur d'application, ...).

 

Une instance du composant d’application d’interaction “:TripReservationSite” est déployé dans le “WEB server” qui est une unité de déploiement stéréotypée composant d’application utilitaire (composant standard que l’on achète ou que l’on trouve en open source comme le serveur HTTP Apache).

 

De même les instances des composants d’application processus “:ReserveTrip” et “:Invoicing” sont déployés dans le serveur de BPM (Business Process Management) (par ex. en open source Bonita Soft, RedHat jBPM, …) utilisant le langage BPEL (Business Process Execution Language) qui peut être généré à partir des modèles BPMN (Business Process Model and Notation).
Le langage BPEL permet d’orchestrer les services web.

Ce serveur BPM qui regroupe des composants processus est une unité de déploiement.

 

Enfin les composants d’application d’entité “:Trip”, “:Client” et “:Order” et le composant d’application utilitaire “:CreditCard”, qui sont utilisés par des services web déployés dans un serveur d’application comme par exemple Jakarta EE (nouveau nom de Java Enterprise Edition depuis qu’Oracle l’ait abandonné à l’organisation open source Eclipse) ( ex. de serveurs d’application :  RedHat Wildfly, Oracle GlassFish, …).

 

Ces 3 unités de déploiement sont connectées dans l’exemple par des réseaux locaux (LAN) modélisés par des  association UML sur lesquelles on a attaché des commentaires UML spécifiant les exigences de vitesse en terme de requêtes par seconde.

 

Conclusion

Le diagramme de traitements montre comment les composants d’application sont déployés dans les unités de déploiement correspondant aux technologies utilisées (HTTP, BPM, Jakarta EE, ...).

 

Afin de mettre l'accent sur les unités de déploiement, ce modèle utilise le déploiement de manière plus générique que le diagramme de réseau matériel et informatique dont on parlera dans le prochain article.

 

Rhona Maxwel

@rhona_helena

 

“La science a-t-elle promis le bonheur ? Je ne le crois pas. Elle a promis la vérité, et la question est de savoir si l'on fera jamais du bonheur avec la vérité.”
Emile Zola



Annexe : les précédentes étapes de notre étude de cas TOGAF

 


28/08/2018
0 Poster un commentaire

Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio

Le diagramme d’environnement et de localisation modélise les lieux et sites de déploiement des matériels avec leurs applications installées et les liens d’interconnexion.

Ce modèle est réalisé par les architectes technique avec comme référents les ingénieurs systèmes/réseaux et les experts métiers à destination des responsables d’exploitation et des développeurs.

 

etude-de-cas-togaf-diagramme-d-environnement-et-de-localisation-phase-d-architecture-technique.PNG

 

Pour plus de précisions les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF, voir l’article :

 

 

 

L’outil utilisé est le diagramme de déploiement UML.
Les nœuds représentés par des cubes, sont ici stéréotypés comme “siège” (Paris) ou “site” (Lyon, Nantes, Toulouse).
Ils peuvent contenir des composants :

  • stéréotypés “serveur” comme par exemple “:Linux server”, “:MVS server” et “:Windows server” dans lesquels sont déployés des instances de “composant d’application d’interaction” comme “:TripReservationSite” ou des applications comme “:TripPortfolioManager-V2” et “:AccountingERP”.
  • stéréotypés “poste de travail” avec leur multiplicité 1 ou plusieurs et dans lesquelles s’exécutent des composant d’interaction.

 

 

Le siège et les sites sont connectés par des associations modélisant les liens de communication.

 

En ce qui concerne l'architecture "cloud", on définit un stéréotype <<cloud>> comme on a défini un stéréotype "site".

De même que l'on avait des instances de noeuds stéréotypés "site" (Lyon, ...), on aura des instances stéréotypées <<cloud>> par exemple ":Cloud IBM" avec des serveurs et des applications déployées.

 

Conclusion

Le diagramme d’environnement et de localisation modélise les sites où sont installés les matériels dans lesquels sont déployés les applications.

Les technologies et / ou applications utilisées sont représentés ainsi que la manière dont les utilisateurs interagissent avec elles.

Les différents environnements de déploiement, y compris les environnements non liés à la production, tels que le développement et la pré-production doivent aussi être modélisés.

 

Rhona Maxwel

@rhona_helena

 

“Le savant n'est pas l'homme qui fournit de vraies réponses ; c'est celui qui pose les vraies questions.”
Claude Lévi-Strauss

 

 

Annexe : les précédentes étapes de notre étude de cas TOGAF

 

 


27/08/2018
0 Poster un commentaire

Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

Si la phase C met en place l’implémentation et l’exécution des constituants métier indépendamment des technologies, c’est le rôle de la phase D Architecture technique d’établir la correspondance physique et technologique avec les composants des phases précédentes.

Cette phase est réalisée par les architectes techniques avec comme référents les ingénieurs systèmes/réseaux et les experts métiers à destination des responsables d’exploitation et des développeurs.

 

togaf-elements-modelisation-uml-phase-d-architecture-technique.png

 

 

L’objectif de la phase D Architecture technique est d’avoir une infrastructure et des composants logiciels cohérents qu’ils proviennent de composants sur étagères, de progiciels du commerce, d’ERP ou bien de développements maison.

Ce choix capital se pose à maintes reprises aux architectes des grandes organisations.
Combien se sont lancés dans des développements spécifiques pour s’apercevoir qu’ils réinventent la roue, puis de tout arrêter pendant qu’il est encore temps pour à la fin adopter un progiciel du commerce paramétrable suivant leurs besoins quitte à les implémenter eux mêmes ou par l'éditeur dans le cas où ils n'existent pas.

On retrouve les concepts de l’architecture SOA (Service Oriented Architecture).
La phase C est comparable à l’interface logique de service qui est la structure fondamentale du composant et qui reste inchangée quel que soit son implémentation en C, Java, SOAP, REST, … qui relève bien de la phase D.


L’important est de pouvoir identifier le rôle de chaque composant indépendamment des technologies employées pour leur exécution.

Il n’y a pas d’ordre préconisé, on peut appliquer une méthode top down c’est-à-dire commencer par spécifier l’architecture applicative puis technique ou faire l’inverse avec la méthode bottom-up.
Ce dilemme cornélien se solde par un mixte des 2 méthodes.

 

Voir l'article : 

 

 

Conclusion

Un des intérêts de la phase D Architecture technique de TOGAF est d’analyser les problèmes de performances rencontrés dans les étapes intermédiaires de migration constituant la trajectoire vers le système cible.

 

Les composants physiques qu’ils soient achetés et intégrés ou développés spécifiquement doivent répondre aux exigences non fonctionnelles comme :

  • la conformité réglementaire,
  • l’interopérabilité,
  • la sécurité,
  • confidentialité,
  • protection des données personnelles,
  • fiabilité,
  • tolérances aux pannes/fautes,
  • possibilité de récupération,
  • dimensionnement des réseaux et du stockage,
  • facilité d’exploitation,
  • disponibilité,
  • performances en temps de réponse,
  • maintenabilité,
  • portabilité,

 

Les moyens nécessaires doivent être mis en oeuvre pour procéder à plusieurs “bascules à blanc” du système (environnement de pré-production) pour être certain que l’intégration finale correspond bien aux besoins du métier et est bien aligné sur les objectifs stratégiques de l’entreprise.

 

Rhona Maxwel

@rhona_helena

 

“L'hésitation est le propre de l'intelligence.”
Henri de Montherlant

 

 

Annexe : les précédentes étapes de notre étude de cas TOGAF

 


27/08/2018
0 Poster un commentaire

Le diagramme des données de service de la phase C Architecture des Systèmes d'Information de TOGAF - étape 35 du tutorial Modelio

Le diagramme des données de service représentent les types (classes) de paramètres des opérations (méthodes) des composants applicatifs permettant les envois de messages.

Le diagramme est réalisé par les architectes applicatifs avec comme référents les architectes applicatifs et les architectes techniques à destination des architectes techniques et des développeurs.

 

etude-de-cas-togaf-diagramme-des-donnees-de-service.PNG

 

Pour plus de précisions sur les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF, voir l’article :

  

 

Les services s’échangent des messages contenant de données.

Ces messages sont en fait les paramètres des opérations des services.

Dans l'architecture SOA ou ses dérivées, ces paramètres sont typés sous forme de classe stéréotypée <<message>> comme dans l’exemple.

On trouve aussi le terme de “DTO (Data Transfert Object)” en orienté objet ou “Message Types” dans la norme SoaML de l’OMG.

 

Dans l’exemple, la classe “Order” stréréotypée avec l’icône de “Message” est associée au sous message “IndividualTrip" par une composition UML.

Une instance de “Order” est composée de une ou plusieurs instances de “IndividualTrip” et une instance de “IndividualTrip” est toujours associée à une et une seule instance de “Order”.

La relation sur le cycle de vie composite/composants implique que si on supprime “Order” (composite), toutes les instances (composants) de “IndividualTrip” sont supprimées.

Même remarque pour “IndividualTrip” qui est une composition de “Insurance”.

 

Les données de ces messages, constituant les échanges entre les services, sont extraites de tout ou partie des entités métier.
 

Un compromis doit être réalisé entre les besoins de performance qui impliquent de ne prendre que le strict nécessaire et les besoins d’évolutivité et de réutilisabilité qui impliquent de prendre la totalité des attributs de l’entité métier.
 

Conclusion

Le diagramme des données de service est un diagramme de classe UML où les classe représentent les types des paramètres des messages (opérations) des services.

Tout ou partie des attributs d’une entités métier sera recopié dans les attributs d’un message.

Ce passage des paramètres par recopie entraîne un couplage faible entre les composants applicatifs qui est une des caractéristiques de l’architecture SOA (voir l'annexe 2 avec les articles consacrés à SOA).

 

Rhona Maxwel

@rhona_helena

 

“On mesure l'intelligence d'un individu à la quantité d'incertitudes qu'il est capable de supporter.”

Emmanuel Kant

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 



Annexe 2 : l’architecture SOA (Service Oriented Architecture)

 


25/08/2018
0 Poster un commentaire

Le diagramme de migration des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 34 du tutorial Modelio

Le diagramme de migration des données a pour objectif de définir la transformation des données des applications source vers les applications cibles, il fournit  une représentation visuelle de la répartition des sources / cibles et sert d'outil pour l'audit des données et l'établissement de la traçabilité.

Le diagramme est réalisé par les architectes applicatifs avec comme référents les experts métier et les DBA et à destination des architectes applicatifs, des experts métier et DBA.

 

diagramme-de-migration-des-donnees-togaf-phase-c-architecture-des-systemes-d-information-tutorial.PNG

 

Pour plus de précisions sur les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF, voir l’article :

 

 

Des attributs du modèle d’origine ont été transformés en classes (entités) persistantes dans le modèle final.
Les retours d’expérience montrent que le nouveau modèle de données est plus complet mais aussi plus complexe que le modèle source.
La raison est que la modélisation cible est réalisée suivant les règles de la conception orientée objet : faible couplage, forte cohérence, design pattern, application des formes normales, …

 

La migration des données peut être exprimée au niveau conceptuel, logique ou physique.

Les diagrammes de communication d'application (voir notre article : “ Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel  “) peuvent également être utilisés pour exprimer la migration de données.

La dépendance à la migration est l'élément clé pour formaliser la migration.

Comme nous avons vu que de des attributs du modèle source peuvent devenir des classes, le diagramme risque de devenir illisible à cause du nombre important d’entités et de dépendances <<migrates>> qui vont s’enchevêtrer.
Les spécialistes de la migration utilisent de nombreuses matrices illustrant les différentes étapes de migration, voici un exemple simplifié :

matrice-de-migration-des-donnees-togaf-phase-c-architecture-des-systemes-d-information-tutorial.PNG

Conclusion

Le diagramme de migration des données explicite les écarts entre le système avant et après transformation du modèle source en cible.

Il permet la traçabilité et la vérification que toutes les données d’origine se retrouvent bien dans le système migré même si les méta-informations (attributs, classes) de ces données sont différentes.

 

Rhona Maxwel

@rhona_helena

 

“L'avantage d'être intelligent, c'est qu'on peut toujours faire l'imbécile, alors que l'inverse est totalement impossible.”
Woody Allen



Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 


25/08/2018
0 Poster un commentaire

Le diagramme de sécurité des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 33 du cas pratique

Le diagramme de sécurité des données a pour objet de décrire quel acteur (personne, organisation ou système) peut accéder aux données de l’entreprise et avec quels droits (CRUD).

Le diagramme est réalisé par les architectes applicatifs avec comme référents les experts métier et sécurité et à destination des architectes applicatifs, des experts métier et sécurité.

 

diagramme-de-securite-des-donnees-togaf-etude-de-cas.PNG

 

Pour plus de précisions sur les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF, voir l’article :

 

 

La dépendance stéréotypée <<flow>> représente un flux de données constitué d'un élément actif d'un côté (par exemple, acteur, processus) et d'un élément transportant des données de l'autre côté (entité, événement, produit).

Des habilitations peuvent être exprimées sur ces flux, exprimant l’accès et les droits (Créer, Lire, Mettre à jour, Supprimer) sur les données de l’élément actif.

 

Le diagramme de sécurité des données peut également être utilisé pour démontrer la conformité aux lois sur la confidentialité des données et aux autres réglementations applicables (RGPD Règlement général sur la protection des données ou ou GDPR, pour General data protection regulation, ...).

 

Ce diagramme doit également prendre en compte les implications de confiance pour lesquelles les partenaires d'une entreprise ou d'autres parties peuvent avoir accès aux systèmes de l'entreprise, comme une situation externalisée où les informations peuvent être gérées par d'autres personnes et même hébergées dans un autre pays.


Evitez d’insérer un grand nombre d’entités métier sur le diagrammes qui peut vite devenir difficiles à lire.

Il est vivement recommandé de créer un diagramme de sécurité des données par entité métier et / ou par participant (généralement un acteur).

En particulier, les diagrammes axés sur les acteurs et leurs missions peuvent fournir des liens d’habilitation.

 

Les diagrammes peuvent également se concentrer sur l'accès externe au système, c'est-à-dire sur les données auxquelles les acteurs externes peuvent accéder.

Les droits (C)reate, (R)ead, (U)pdate, (D)elete, des acteurs sur les données métier peuvent être représentés sous forme de matrice :

diagramme-de-securite-des-donnees-togaf-tableau-de-securite-des-donnees.PNG

 

Conclusion

Les données sont considérées comme un atout pour l'entreprise et la sécurité des données signifie simplement que les données de l'entreprise ne sont pas compromises et que leur accès est contrôlé de manière appropriée.

Rhona Maxwel

@rhona_helena

 

“La gaieté est la forme la plus aimable du courage.”
Anatole France

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 


24/08/2018
0 Poster un commentaire

Le diagramme de dissémination de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 32 du cas d’étude

Le diagramme de dissémination de données a pour objet de montrer comment les entités métier doivent être physiquement réalisées par les composants de l'application.

Le diagramme est réalisé par les architectes applicatifs avec comme référents les architectes applicatifs, les DBA et les architectes techniques et à destination des architectes techniques, des DBA et des développeurs.

diagramme-de-dissemination-des-donnees-togaf-phase-c-architecture-des-systemes-d-information-tutorial.PNG

Pour plus de précisions sur les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF, voir l’article :

 

 

La distribution des données consiste, soit à l’encapsulation d’une instance d’une entité métier dans un composant comme la donnée persistante “:Hotel” à l’intérieur du référentiel “PortfolioRepository” (composant d'application base de données), soit en liant l’entité au composant avec une dépendance stéréotypée  <<flow>> comme pour le composant d'application d'entité “Client”.

Le composant d’application d’entité “Trip” est géré (dépendance <<access>>) dans le référentiel “PortfolioRepository” et l’entité “Order” est géré par le composant d’application d’entité “Order” (architecture SOA).

 

Le diagramme permet d'effectuer un dimensionnement efficace de l’architecture informatique à affiner.

En attribuant une valeur métier aux données, il est possible d'obtenir une indication de la criticité métier des composants de l'application.

Le diagramme peut afficher la réplication des données et la référence principale pour les données.
Dans ce cas, il peut afficher deux copies et la relation maître-copie entre elles.

Le diagramme de dissémination de données est une sorte de diagramme d’architecture avec les couches interaction, processus et entité et dans lequel les entités de données sont connectées aux composants de l’application.

 

Conclusion

Le diagramme de dissémination de données spécifie la distribution des entités métier entre les différents composants applicatifs.

Ce diagramme peut être généré par des outils de transformations de modèles à partir des modèles de l’architecture applicative comme le diagramme de communication des applications ( voir notre article : “ Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel “ ) à condition d’appliquer les concepts de SOA ( voir à la fin de cet article l’annexe 2 : l’architecture SOA (Service Oriented Architecture)).

 

Les données métier seront soit dans un référentiel spécifique, soit dans des composants d'application d'entité propres.

 

Rhona Maxwel

@rhona_helena

 

“Toutes les bonnes choses qui existent sont les fruits de l'originalité.”
John Stuart Mill



Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 



Annexe 2 : l’architecture SOA (Service Oriented Architecture)

 


24/08/2018
0 Poster un commentaire