urbanisation-si.com

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