urbanisation-si.com

urbanisation-si.com

TOGAF

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


Comment consolider un référentiel centralisé TOGAF rassemblant les autres référentiels Stratégie, Métier, Applications, Infrastructure… ? Obeo SmartEA S.1 Ep.2

Si l'on demande à ChatGPT : “A quels défis sont confrontés aujourd'hui les architectes d'entreprise ?”, voici ce qu'il cite en premier : “L’un des principaux défis est de faire face à la complexité croissante des systèmes d’information et des technologies de l’information”. Puis, en deuxième : “Les architectes d’entreprise doivent être en mesure de communiquer efficacement avec les parties prenantes de l’entreprise, y compris les cadres supérieurs, les responsables informatiques et les utilisateurs finaux”.

 

communication-architecte-entreprise-02

  

Une meilleure communication pour une meilleure transformation numérique

 

Commençons par une évidence, que l’on trouve dans toutes les introductions dans cette catégorie d’articles que vous êtes en train de lire : les changements à fréquence effrénée impactent l’entreprise aux niveaux stratégie, processus métier, applications et infrastructure. Vous le savez, il n’y a que des solutions. Une parmi tant d’autres est que les parties prenantes aient accès à des informations qualifiées et de première fraîcheur.


Les problèmes de communication entre les acteurs sont un frein à la compréhension de l'organisation de l'entreprise, son système d'information et son architecture. La diversité des différents métiers ne doit pas empêcher les échanges et l'enrichissement du patrimoine de l’entreprise. Souvent, les outils hétérogènes de chaque métier ne sont pas interopérables.
Le recueil des données pour une transformation par la MOA, les architectes d’entreprise, les urbanistes du SI, les chefs de projets, les architectes logiciels… est une activité chronophage et devient vite obsolète dès que des changements interviennent.

 

Pour avoir un référentiel TOGAF rassemblant les autres référentiels (Stratégies, Finances, Applications, Architectures, Infrastructures…), faciliter la connaissance du SI et rendre plus efficientes les transformations de l’entreprise, la solution est de récupérer et agréger des informations issues de sources hétérogènes dans un référentiel centralisé. Concrètement, un ensemble de connecteurs récupère automatiquement et itérativement les données en fonction de règles préétablies à partir de n’importe quel type de fichiers. Dans le contexte de l’élaboration des trajectoires possibles, cette technique fait gagner beaucoup de temps à l'architecte d’entreprise qui peut se libérer de tâches manuelles fastidieuses et se concentrer sur l’étude des trajectoires les plus pertinentes, réaliser un plan de risques, entreprendre des projets à forte valeur ajoutée et participer à une meilleure gouvernance.


La solution est un outil collaboratif, avec un référentiel maître qui pourrait aller récupérer des données dans d’autres systèmes. C’est ce que propose Obeo SmartEA avec ses connecteurs.

 

La plateforme web sécurisée d’Obeo SmartEA
pour la collaboration


Loin des logiciels très chers (BOC Group ADOIT, MEGA HOPEX, LeanIX, Bizzdesign…) réservés aux grands groupes, nous avons mis à l’épreuve la plupart des outils d’AE open source ou à faible coût, avec comme objectif de cibler les organisations à budget restreint pour ce type d’outils ou encore le monde de l’éducation (voir nos tests en annexe). Nous avons constaté que :

 

-  soit il existe une véritable gestion d’un référentiel d’objets et d’artefacts accessible en local ou nécessitant une installation complexe pour le rendre partageable (Archimatetool),

 

- soit on nous propose une collaboration à la manière de Google (Visual Paradigm Online) pour dessiner des modèles, mais avec une absence totale de référentiel d’entreprise.

 

Déjà évoqué dans plusieurs de nos articles (voir annexe), seul Sparx Systems propose une déclinaison de son produit Enterprise Architect à prix modéré selon les fonctionnalités. Il offre toutes les fonctionnalités des produits bien plus onéreux, y compris la collaboration entre les acteurs de l’AE .


Après tout, ce ne sont que les enjeux basiques de l’AE, mais pour parvenir à ses fins, encore faut-il un outil qui s’appuie sur un référentiel partagé accessible, en fonction des profils utilisateurs, de manière concurrente et sécurisée et qui doit historiser les changements.


Vous voulez accentuer la collaboration entre tous les acteurs : utilisez une plateforme web sécurisée ! De plus, l’outil doit se conformer au standard en vigueur aujourd’hui, soit ArchiMate de l’Open Group, tout en étant personnalisable avec parcimonie en proposant des APIs ouvertes offrant la possibilité d’utiliser des notations plus spécifiques, comme BPMN pour les processus métier ou vos propres métamodèles.


Obeo, éditeur français, a bien compris les enjeux d’un tel type de logiciel et propose SmartEA, un outil sous licence commerciale intégrant ces fonctionnalités. Comme son concurrent direct Enterprise Architect de Sparx Systems, le référentiel est accessible via un client web permettant le partage des informations et un modeleur basé sur une plateforme Eclipse à installer localement pour peupler et manipuler les différents éléments du référentiel, en vue d'élaborer des scénarios et des trajectoires de transformation.


Ces pages web peuvent être transmises via des URL aux membres de l’organisation dûment habilités. Sinon, on peut les télécharger sous forme d’images haute résolution.

  

obeo-smartea-realisation-des-objectifs-constat-objectif-resultat-principe-exigence

  

Un acteur dûment authentifié peut accéder via une URL au référentiel. Ses actions sont fonction des autorisations que lui a octroyées l’administrateur. Vue basée sur le pattern “Goal Realization Viewpoint” de la spécification ArchiMate. Les buts sont réalisés par un Résultat qui est réalisé par un Principe qui se comporte comme une exigence plus abstraite et plus large. Enfin le Principe est matérialisé par une Exigence indiquant des propriétés spécifiques que le système doit présenter.

 

Une granularité fine du verrouillage des artefacts
pour une résolution de conflits performante

 

Une base de données ou un moniteur de multithreading posent des verrous sur les objets modifiés : Obeo SmartEA va procéder de la même manière. La granularité des parties bloquées est très fine. Une fois les modifications sauvegardées, elles sont propagées automatiquement vers l’ensemble des utilisateurs qui seront libres d’apporter des mises à jour.

 

obeo-smartea-verrouillage-01

  

L'architecte d'entreprise vient de modifier un élément "Principe" de la vue "Motivation".
Un cadenas vert signalant le verrouillage apparaîtra tant que la sauvegarde ne sera pas effectuée.

 

 

obeo-smartea-verrouillage-02

  

Exemple d'un utilisateur voulant modifier un élément "Make" (Logiciel Système),
verrouillé par un autre utilisateur. 

 

Le tableau de bord de l’Architecte d’Entreprise

 

Si un transfert d’objets de modélisation dans le sens top-down était possible, on serait confronté aux problèmes du niveau de maturité et des pratiques des utilisateurs (niveau des macro-exigences, normalisation des noms, approche Domain-Driven Design…).

 

Seul un transfert bottom-up doit être autorisé. Sur demande, l’outil gérant le référentiel maître ira recueillir des informations éparpillées dans des systèmes hétérogènes, utilisés par exemple par les architectes applicatifs. L’architecte d’entreprise décidera de la suite à donner aux artefacts et actions remontées, par exemple doit-il les valider ou les rejeter.


Pour le suivi des états des objets composant la cartographie de l’entreprise, Obeo SmartEA met à la disposition de l’architecte des widgets graphiques personnalisables et regroupés dans un tableau de bord. L’enjeu est de disposer un outil de pilotage du projet avec la démarche TOGAF.

 

obeo-smartea-dashboard-architecte-entreprise

  

Exemple de tableau de bord montrant ce qui est à faire et ce qui est réalisé.
Ici, 4 applicatifs sont déjà validés et le modèle d’architecture ne comporte aucun lien interapplicatif.  

 

Importation des modèles d’Obeo ISD réalisés
par les architectes applicatifs dans Obeo SmartEA


Dans le cas où les architectes logiciels et techniques utiliseraient l’outil open source d’Obeo ISD (Information System Designer), les artefacts modélisés (voir nos articles en annexe) doivent être importés en vue de la consolidation du référentiel maître d’Obeo SmartEA. 

Concrètement, Obeo SmartEA possède un connecteur Java unidirectionnel et paramétrable qui gère les ajouts, les modifications et les suppressions de ISD vers son référentiel. 

 

obeo-smartea-apres-lancement-connecteur-java-isd-smartea

  

Une fois lancé le connecteur, le référentiel centralisé et partageable d’Obeo SmartEA est mis à jour. L’architecte d’entreprise dispose d’une vue synoptique au travers de son tableau de bord.
ll devra étudier 146 applicatifs et 3 liens interapplicatifs, pour décider s’il les valide ou les rejette.

 

Mais Obeo SmartEA peut aussi récupérer des modèles réalisés par d’autres outils, comme celui de Sparx Systems

 

Obeo SmartEA fournit des APIs ouvertes pour créer des connecteurs vers des ressources externes et notamment vers son concurrent direct Sparx Systems Enterprise Architect.

 

obeo-smartea-connecteur-sparx-system-enterprise-architect-02

    

Notez les connecteurs qui importent des données de fichiers Excel et de Sparx EA (Enterprise Architect)

 

Alimenter automatiquement le référentiel
à partir d’import de données

 

Exemple d’un fichier Excel fourni par l’équipe infrastructure, représentant les échanges entre les applications et les interfaces au travers desquelles elles communiquent. 

 

obeo_smartea-excel-echanges-absents-du-referentiel

  

Pour analyser ce fichier et remonter les informations, Obeo a développé un connecteur que l’on peut lancer depuis la page des traitements (voir paragraphe précédent).

 

obeo-smartea-resultat-import-excel

  

Le composant applicatif "Système suivi de satisfaction client" communique avec le composant "CRM" par l'intermédiaire de l'interface "Web Service CRM" comme spécifié dans le tableau Excel.
De même, un autre lien a été créé avec le composant "Système de fidélité" qui utilise l'interface
"Rapport XLS de suivi de satisfaction" du composant "Système suivi de satisfaction client". 
 

 

Conclusion

 

Voici un outil mettant en œuvre un référentiel centralisé et collaboratif TOGAF. Les éléments de modélisation font partie des standards du marché, à savoir ArchiMate et BPMN. Des APIs ouvertes permettent d’intégrer d’autres notations standards comme UML ou des DSL spécifiques.

 

Toutes les parties prenantes de l’entreprise peuvent accéder aux différentes vues d’architecture via un simple navigateur web. Le concept de prisme permet d’octroyer des authentifications et des autorisations en fonction des rôles des utilisateurs. Le système de gestion de conflits optimisé, pour ne verrouiller que la donnée en cours de modification, permet des accès rapides.

 

Enfin, des connecteurs offrent la possibilité de récupérer des données, en provenance par exemple des architectes logiciels utilisant Obeo ISD ou Sparx Systems Enterprise Architect ou de la MOA à partir de tableaux Excel.

 

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

 

"Qu'est-ce que je serais heureux, si j'étais heureux".

Woody Allen

 

Annexe : nos tests

 

 


19/12/2023
0 Poster un commentaire

TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?

Un cadre de sécurité pour les entreprises doit permettre de maintenir un état des risques maîtrisé, correspondant à un comportement sécurisé, résilient, fiable et respectueux de la vie privée. Quel est le rôle de l'architecte d'entreprise avec la version 10 de TOGAF et son architecture de sécurité ?

  TOGAF-10-nouveautes-securite-risques-04-2  

Relation entre TOGAF et l'ISM/ERM, source The Open Group

 

TOGAF 10 plus facile à lire ?

Avec la version 10 de TOGAF, The Open Group (https://www.opengroup.org/) a restructuré le contenu de l'architecture d'entreprise pour améliorer la lisibilité, l’utilisabilité et la maintenabilité. La solution retenue a été de développer la modularité du contenu.

Bonne nouvelle, la taille de la partie standard de TOGAF est passée de 692 (version 9.1) à 532 pages et ne contient que du contenu pérenne.

La structure de TOGAF 10 ressemble à des poupées russes.

 

TOGAF-10-nouveautes-resume-structure-oignon-01 

TOGAF Fundamental est la partie stable, tandis que les guides évolueront, source The Open Group

 

Le socle de TOGAF 10, très stable, se trouve dans la partie fondamentale, les guides et la bibliothèque rassemblent des aspects plus pratiques et peuvent évoluer au cours du temps.

 

TOGAF-10-nouveautes-resume-documentation-structure-02 

Détails de l'organisation de TOGAF 10, source The Open Group

 

Bonnes pratiques

Pour une véritable intégration de la sécurité dans l'architecture, une approche d'ingénierie système doit être utilisée. Cela signifie que la sécurité et les risques sont pris en compte le plus tôt possible dans le cycle de vie du développement de l'ingénierie système du sujet en question. À chaque phase du cycle de vie du développement, des activités appropriées, liées à la sécurité et aux risques, sont menées. Ces activités peuvent aller de conseils et d'orientation de haut niveau dans les premières phases, à des contrôles de sécurité détaillés dans la phase finale. De cette manière, un système opérationnel sécurisé peut être réalisé, en étant fiable, sûr, résilient et respectueux des préoccupations de confidentialité. 

 

L'architecture de sécurité d'entreprise cherche à aligner les mesures de sécurité sur les objectifs métier. Pour ce faire, il définit les relations entre les composants sur les différentes couches d'architecture, assurant ainsi la traçabilité et la justification. L'architecte de sécurité d'entreprise utilise généralement les processus ISM (Information Security Management) et ERM (Enterprise Risk Management) pour développer les livrables et interagir avec les parties prenantes.

 

Qu’est-ce qu’un risque ?

D’après la norme ISO 31000:2009, un risque est l'effet que l'incertitude a sur la réalisation des objectifs de l'entreprise. L'incertitude concerne la prédiction des résultats futurs, compte tenu de la quantité limitée disponible d'informations imparfaites lors de la prise de décision métier. 

  TOGAF-10-architecture-securite-iso-31000-2009-06-3   

Gestion des risques, norme ISO-31000:2009

 

La norme ISO 31000:2009 indique clairement que la gestion des risques doit être profondément et fermement ancrée dans toutes les activités métier. Elle indique également qu'il s'agit d'un cycle de vie continu plutôt que d'une activité isolée.

Chaque décision est basée sur :

  • l'évaluation de l'équilibre entre les opportunités et les menaces potentielles,
  • la probabilité de résultats bénéfiques par rapport aux résultats préjudiciables,
  • l'ampleur de ces évènements potentiels, positifs ou négatifs,
  • la probabilité associée à chaque résultat identifié. 

 

L'identification et l'évaluation de ces facteurs sont appelées “évaluation des risques” ou “analyse des risques”. La gestion des risques est l'art et la science d'appliquer ces concepts dans le processus de prise de décision. Le risque peut être vu au niveau stratégique à long terme (direction générale de l'entreprise), au niveau tactique à moyen terme (projets et programmes de transformation) et au niveau opérationnel (décisions, processus métier). L'objectif de la gestion des risques est d'optimiser les résultats métier, afin de maximiser la valeur métier et de minimiser les pertes. Le risque peut être vu à n'importe quel niveau de l’architecture métier, mais est toujours guidé de haut en bas, par l'évaluation de la valeur métier et son optimisation.

 TOGAF-10-architecture-securite-architecture-metier-05 

Risques métier et cyber-risques source The Open Group

 

La triade CIA

Pour de nombreux experts, la sécurité repose sur trois piliers fondamentaux :

  • la confidentialité,
  • l'intégrité,
  • la disponibilité.

 

Ces 3 notions sont également connues sous le nom de triade CIA avec une classification (élevé-moyen-faible), surtout omniprésente dans le domaine de la finance. A part pour James Bond 007, ces termes complexes englobant trop de significations sont peu utilisés par les dirigeants d’entreprise, préférant parler par exemple d’autorisations d’accès à des fonctionnalités.

 

Pour se recentrer sur les entreprises, TOGAF 10 a intégré le modèle SABSA (Sherwood Applied Business Security Architecture)

 

Quel outil pour les architectes sécurité ?

 

TOGAF-10-et-sabsa-couches-architecture-07 

Le modèle en couches SABSA (Sherwood Applied Business Security Architecture),
source https://sabsa.org/

 

Dans un contexte TOGAF 10, en collaboration avec l’architecte d’entreprise, l’architecte sécurité pourra s’appuyer sur l’architecture SABSA. Son modèle en couches, centré sur les risques, est aisément modulable. 


La méthodologie donne plusieurs visions : 

  • contextuelle - métier (le décisionnaire), 
  • conceptuelle (les objectifs et les risques), 
  • logique (informations, processus, applications, interactions), 
  • physique (données, mécanismes de transfert, infrastructure), 
  • composants (outils, produits, technologies, standards),
  • une vision transverse avec les services de sécurité. 

 

SABSA comprend une vue pour les processus d’audits et de contrôles indépendants. 

 

Pour chaque couche, on doit répondre aux questions Quoi ? Pourquoi ? Comment ? Qui ? Où ? Quand ? A noter que ce questionnement de Quintilien est aussi utilisé par un autre framework d'Architecture d'Entreprise, celui de Zachman (voir notre article Architecture d'entreprise : le framework de Zachman).

 

TOGAF-10-et-sabsa-perspectives-architecture-08 

Les perspectives de l'architecture de sécurité SABSA

 

Par exemple, on pourra déterminer les points liés à la classification de l’information, la méthode d’analyse et de traitement des risques, la cartographie des flux applicatifs et des échanges de données, les aspects IAM (Identity and Access Management), les domaines de confiance et leurs localisations.

 

Exemples de l'architecture SABSA :

  • les services d'authentification (par exemple, cas d’approbations entre les annuaires, les types d'authentification en fonction des risques ou de la sensibilité des informations)
  • la gestion de la cryptographie (l’organisation, les possibilités de gestion centralisée des clés, les types de chiffrement possibles selon les risques, les cas de pseudo-anonymisation…)
  • les cas d’évaluation de la sécurité par des audits techniques
  • l’intégration de la sécurité dans les méthodes agiles comme Scrum (répartition des rôles entre le "Product Owner", le "Scrum Master", l’équipe de développement et les experts sécurité, comment et quand intégrer la sécurité dans les réunions "Sprint Planning" et les "Daily Scrum", les standards applicables…)
  • les niveaux d’audits internes

Conclusion

Toutes les organisations, des réseaux électriques aux systèmes de combat, les entreprises privées ou publiques, les organismes de santé, tout est vulnérable face à l’arme numérique. Quelques attaques informatiques concernant des villes et des hôpitaux ont été rendues publiques, mais ce n’est que la partie émergée de l’iceberg,

Face à ces attaques, il est bon de trouver des alliés, et pour une fois il n’y a pas à choisir entre TOGAF vs SABSA, mais un seul framework TOGAF intégrant SABSA.

 

Le rôle de l'architecte d'entreprise sera alors de créer un environnement opérationnel dans lequel le risque opérationnel pourra être optimisé, pour un bénéfice métier maximal et une perte potentielle minimale.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“La chose la plus difficile est de n'attribuer aucune importance
aux choses qui n'ont aucune importance.”

Charles de Gaulle

 

Compléments de lecture

 

 

 

 


27/10/2022
0 Poster un commentaire

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