urbanisation-si.com

“AE, ma sœur AE, ne vois-tu point l’IA venir ? Non, je ne vois que des éléments classiques et des aménagements cosmétiques…” Bien que certains éditeurs nous disent que l’intégration de l'IA est à l’étude, il semble que ce n'est pas pour tout de suite. En attendant, nous vous proposons d’examiner quelques fonctionnalités, du côté de l'Australie, de l’outil Enterprise Architect (EA) de Sparx Systems, comme nous l’avions fait avec son concurrent français Obeo SmartEA.

Image générée par ChatGPT.

Forces et faiblesses d’Enterprise Architect

EA rassemble tout ce qu'on peut imager comme outils pour gérer les composants d’une architecture d'entreprise. Rien n'y manque. Voici une liste à la Prévert : TOGAF, ArchiMate, BPMN, DMN. CMMN, UML, SysML, SOAML… la simulation de modèles, la mise en œuvre de méthodes agiles, Scrum, Kanban, la gestion de projet, Gantt, les exigences, les tests, XML, WSDL, API, REST, scripts SQL, la génération de code dans de nombreux langages, le maquettage d’écran, la conception et l’exécution des tests, la production de documentation, on pourrait continuer l'énumération des fonctionnalités proposées. À tel point qu’une fois dans l’outil, il est facile de se perdre, comme un Parisien au milieu du souk de Marrakech.

La collaboration a toujours été le talon d’Achille d’EA. Une plateforme de versioning était nécessaire pour centraliser les artefacts d’architecture. Chaque utilisateur devait avoir EA installé et être connecté à la plateforme.

Dans notre article "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", nous demandions à ChatGPT :

“A quels défis sont confrontés aujourd'hui les architectes d'entreprise ?”,

voici ce qu'il répondait 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”.

Le cloud au secours d’EA

EA reste l’outil d’administration du référentiel d’Architecture d’Entreprise (AE). Grâce à lui, l’architecte d’entreprise met en œuvre le framework TOGAF, cartographie les différentes strates d’architecture, structure le référentiel et doit s’assurer de la participation de tous les acteurs, les actionnaires, la DG, les responsables de domaines métiers, les architectes techniques… Pour ce faire, il doit être possible de communiquer tout ou partie du référentiel d’AE, de gérer des revues de cartographies, de solliciter les différents points de vue, de gérer des discussions, des anomalies, des simulations, d’effectuer des campagnes de tests.

Pour s’aligner sur les standards du marché, Sparx Systems a intégré le cloud dans son écosystème. La plateforme Pro Cloud Server permet à l'administrateur de stocker le référentiel d’AE dans le cloud. Les modèles d’entreprise sont accessibles grâce à l’application WebEA, développée en PHP et déployée dans un serveur Apache, ce qui permet aux parties prenantes de : 

• les réviser, 
• discuter de leur pertinence et de leur validité, 
• les commenter, 
• les illustrer avec des cas d’utilisation, 
• les tester, 
• gérer les exigences, 
• identifier les problèmes, 
• les tester
• suivre les modifications du modèle via une liste de surveillance

Un cas d’utilisation :
Automatiser le ranking des mails pour la Relation Client

Partant du constat que la Relation Client (RC) est mal notée dans les avis, la DG pose comme objectif d’améliorer la RC, avec comme indicateur d’être en tête dans le classement de RC.

Enterprise Architect propose sur étagères les patterns d’AE :

L’architecte d’entreprise crée la vue ArchiMate en adaptant le pattern Réalisation des objectifs : 

Partant du fait que la RC est aujourd'hui un domaine stratégique pour l'entreprise,
il a été décidé d'intégrer de l'IA dans son fonctionnement.

L’architecte d’entreprise connecte le modèle dans le cloud (plateforme Pro Cloud Server) : 

Une fois les modèles connectés à la plateforme Pro Cloud Server,
les parties prenantes dument autorisées pourront les consulter et collaborer.

WebEA

L’architecte technique se connecte, via la plateforme Pro Cloud Server, au projet créé par l’architecte d’entreprise. Il visualise le modèle : 

Création d’une revue à propos du modèle précédent

L’architecte technique peut alors créer une revue :

Enterprise Architect et son application WebEA permettant aux acteurs de l'Architecture d'Entreprise de collaborer à la validation des modèles. Ici, on va ajouter un élément de type "Revue".

Identification et priorisation des risques

L'architecte technique identifie et priorise des risques liés à la stratégie consistant à intégrer l'IA dans la RC :

• Risque projet : Compétences en intégration des IA agentiques
  Le chef de projet doit être formé à l'IA, ainsi que l'architecte technique
  [Criticité : Moyenne (2)]
  
  
• Risque fonctionnel : Intégration de l'IA : risques métier et technique
  • Plan préventif : une POC doit être réalisée sur une durée de 6 mois, pour évaluer techniquement et pour mesurer les apports en termes de coûts, délais et qualité à la RC.
    [Criticité : Haute (3)]
  • Prendre un prestataire expert en intégration de l'IA.

Ajout d'un risque à un élément pour le modèle d'intégration de l'IA dans la RC.

Avec le référentiel d'AE partagé, la collaboration entre parties prenantes est facilitée.
La discussion sur l'atténuation des risques peut s'engager.

Conclusion

Autant nous avons toujours été enthousiastes avec la version locale d’Enterprise Architect, autant nous sommes réservés concernant cette plateforme cloud, qui nous paraît fonctionnellement limitée et d’une effroyable complexité pour son intégration (voir l’annexe). Dans une matrice RACI (Réalisateur, Approbateur, Consulté, Informé) des responsabilités des parties prenantes, l'application WebEA semble réservée au C et au I. Remercions toutefois, l'équipe technique de Sparx Systems, qui a été constamment à nos côtés pour la mise en œuvre.

Lors de nos tests, son concurrent français Obeo SmartEA faisait mieux (voir nos articles dans les compléments de lecture). Contacté, Obeo nous dit que de nouvelles fonctionnalités seraient à l'étude, comme le requêtage en français du référentiel et la génération d’une partie du modèle. 

Le coq serait-il plus fort que le kangourou ?

Rhona Maxwel urbanisation-si.com @rhona_helena

"Ce qu'on appelle stratégie consiste essentiellement
à passer les rivières sur des ponts et à franchir les montagnes par les cols."

Anatole France

Annexe : Intégration de Pro Cloud Server

1 - Demander une version d'essai

Faire la demande : "Request Pro Cloud Server trial"

Une fois enregistré, vous recevrez par mail le fichier " _SSPCSTRIAL_RegistrationText.txt" contenant votre nom d'utilisateur, votre mot de passe et votre numéro de licence temporaire.

2 - Télécharger Pro Cloud Server

Downloads

Entrer le nom d'utilisateur et le mot de passe fourni dans le mail reçu.

3 - Exécuter le fichier *.msi

Exécuter "ssprocloudserver_x64.msi" et suivre les indications

Vérifier dans taskmgr le démarrage du service Windows : 

4 - Faire une demande de fichier "pcsrequest.csr" pour activer la licence

Une fois installé, dans le répertoire Client, lancer "Pro Cloud Config Client" afin de générer la demande d'activation de la licence en utilisant le mot de passe par défaut fourni dans le mail reçu de Sparx Systems.

Cliquer sur Licensing

Cliquer sur Create Request

Dans Installation ID, saisir le numéro de licence se trouvant dans le fichier "_SSPCSTRIAL_RegistrationText.txt" fourni par Sparx Systems lors de la demande d’essai ou lors de l’achat du produit.

Une fois validé, un fichier "pcsrequest.csr" est créé dans le répertoire que vous avez indiqué. 

Envoyer ce fichier à Sparx Systems à l'adresse du mail de réponse à votre demande d'essai.

5 - Activer le fichier licence reçu “pcslicensecert.lic”

Vous recevrez en retour un fichier “pcslicensecert.lic”, contenant la licence temporaire.

Procédure similaire à la demande, dans l'écran Pro Cloud Server Configuration Client :

Add > Indiquer le fichier licence.

Une fois la licence enregistrée, vous pouvez activer le protocole de communication OSLC entre le client WebEA et le serveur (Pro Cloud Server).

6 - Configurer le client avec l'outil Windows : Pro Cloud Configuration Client 

Pour créer la base de données pour vos modèles :

• dans le répertoire Client de l'installation, lancer "SSProCloudClient.exe" (Pro Cloud Configuration Client) 
  
  
• Onglet Database Managers > Add > Sélectionner le SGBDR open source Firebird embarqué dans Pro Cloud Server > Saisir un nom de fichier, par ex. : rhonamodel.feap > OK

Le nouveau “Database Manager” apparaît en orange, il reste à le configurer. Pour cela, le sélectionner, puis double-cliquer > Cocher Enabled et Enable Pro Features (OSLC, WebEA and Integration) qui est cliquable uniquement si la licence a été ajoutée. > OK

Pour activer le protocole OSLC pour le port 1804 pour HTTP :

Onglet Ports > Sélectionner le port 1804 > double-clic > une fois la licence reconnue, vous pouvez cocher OSLC Supported

Avec taskmgr, redémarrer le service Windows “Sparx Systems Professional Cloud”

7 - Créer un modèle dans Pro Server Cloud à partir de Enterprise Architect

Dans EA > Open Project

Connect To Cloud > Indiquer l’adresse IP du serveur, dans notre exemple, il s’agit de localhost, puis indiquer le port HTTP, ici 1804 (pour HTTPS, ce sera 1805).

Dans le nouveau projet, créer : 

• un package, par ex. “Test-Pro-Cloud-Server”
  
  
• un modèle ArchiMate à partir de l’assistant générant les vues de l’Open Group > dans la liste des perspectives > Enterprise Architecture > ArchiMate > Basic Viewpoints > Service Realization Viewpoint

Cliquer sur Create Model

Personnaliser la vue ArchiMate dans EA : 

Dans EA > Settings > Model > Options > Cloud > Cocher “Auto create Diagram Image” et “Auto create HTML Page” et “Enable Pro Cloud Server Connection” > Close

8 - Configurer le client avec l'outil web : WebConfig

WebConfig est l’équivalent web du client Windows de configuration vu précédemment (Pro Cloud Config Client).

Il s’agit d’une application web développée en PHP. Pour l’installer, il suffit d’installer XAMPP (XAMPP Apache + MariaDB + PHP + Perl), qui intègre le serveur HTTP Apache incluant PHP.

Télécharger XAMPP

Une fois installé, copier le répertoire WebConfig du répertoire d’installation de Pro Cloud Server dans le répertoire htdocs du répertoire d’installation de XAMPP

Démarrer le “Control Panel” de XAMPP sous Windows.

Démarrer uniquement Apache :

Une fois Pro Cloud Server et Apache démarrés, aller dans un navigateur et saisir : 
http://localhost/WebConfig/

On retrouve les fonctionnalités du client Windows de configuration : 

9 - Configurer les autorisations d'accès au référentiel partagé

De la même manière que pour Webconfig, copier le répertoire WebEA du répertoire d’installation de Pro Cloud Server dans le répertoire htdocs du répertoire d’installation de XAMPP

Le projet créé précédemment par Enterprise Architect et stocké dans le Pro cloud Server doit être paramétré dans le fichier "webea_config.ini" du répertoire "xampp\htdocs\WebEA\includes".

Remplacer les valeurs de tous les paramètres sscs_db_alias par le nom de votre projet. Dans notre démonstration, il s’agit de “rhonamodel”.

Les autres options pour le model3 sont inchangées.
Si Apache était démarré, arrêter-le et redémarrer-le grâce au XAMPP Control Panel.

10 - Accéder au référentiel partagé avec WebEA

Dans votre navigateur : http://localhost/WebEA

Prendre par exemple les accès complets nécessitant le code d'accès paramétré précédemment.

Cliquer sur Desktop.

Saisir la valeur du paramètre auth_code du fichier webea_config.ini. 

Un utilisateur, dument authentifié et autorisé, peut accéder
au modèle créé avec EA par l'architecte d'entreprise.

En fonction de la façon dont le modèle actuel a été configuré dans le fichier de configuration de WebEA et de votre accès de sécurité au modèle, vous pouvez avoir la possibilité de créer (+ vert <New>) une plage d’objets dans le modèle via WebEA. Voir "Un cas d’utilisation : Automatiser le ranking des mails pour la Relation Client" plus haut dans le corps de l'article.

Ces objets incluent : les packages, les diagrammes, les cas d’utilisation, les exigences, les composants, les modifications, les problèmes, les tests, les décisions, les défauts et les événements. (Package, Diagram, Review, Actor, Change, Component, Feature, Issue, Node, Requirement, Task, Use Case).

En plus d’ajouter de nouveaux éléments, vous pouvez également modifier les notes de n’importe quel objet, quel que soit son type, ainsi que les détails des tests d’éléments et des allocations de ressources pour n’importe quel élément du modèle, que vous l’ayez créé ou non. 

Vous pouvez :

• Créer des éléments : dans la vue principale WebEA - Propriétés de l’objet - Add New.
  
  
• Afficher les propriétés de l’élément auquel vous souhaitez ajouter une fonctionnalité, cliquer sur le bouton “Add New”. Un menu s’affiche et propose des options pour ajouter à l’élément chaque fonctionnalité à condition d'avoir les droits. (Other Objects, Tests, Resources, Features, Changes, Documents, Defects, Issues, Tasks, Risks).

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”.

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.

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.

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.

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.

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. 

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.

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. 

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).

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.

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

Woody Allen

Annexe : nos tests

• Quel outil ArchiMate pour modéliser vos architectures d’entreprise sources et cibles, évaluer les écarts, analyser les impacts et élaborer des trajectoires de transformation ? Obeo SmartEA S.1 Ep.1
    
• Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
    
• Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
    
• Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3
    
• Quelle solution pour concevoir la modélisation d’une architecture micro-services, l’intégrer dans une architecture d’entreprise et permettre une collaboration avec l’ensemble des acteurs projet ? Obeo ISD S.1 Ep.4
    
• Vous cherchez un outil pour gérer le mapping entre les objets métier et une base de données relationnelle, générer les scripts SQL et produire du code à partir de vos modèles ? Obeo ISD S.1 Ep.5
    
• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information
    
• Modelio
    
• Visual Paradigm (online)
    
• ADOIT : CE (BOC Group) et ADOIT : CE (compléments d’information)
    
• Archi (archimatetool)
    
• GenMyModel
    
• Camunda 
    
• Papyrus
    
• Eclipse Modeling Tools
    
• diagrams.net ou draw.io
    
• Texte vers UML et autres outils de "diagrammes en tant que code"
    
• Enterprise Architect
    
• WinDesign
    
• Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants
    
• Les meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont…

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é ?

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 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.

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. 

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.

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é ?

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).

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.

“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

• 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)
  
  
• Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• 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)
  
  
• L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• 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
  
  
• 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
  
  
• Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace

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.

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 :

• 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
• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
• Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

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

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.

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

• 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)

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 :

• 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
• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
• Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
• Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio

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

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.

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 :

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

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

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.

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 :

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

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, ...).

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

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.

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

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

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

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.

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 : 

• 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)

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

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.

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 éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel

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.

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