Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio - urbanisation-si, modelisation-metier, processus-metier, expression-des-besoins

urbanisation-si

urbanisation-si

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

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 209 autres membres