Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
La phase C doit mettre en place l’implémentation et l’exécution des constituants métier indépendamment de la phase D technique qui doit établir la correspondance physique et technologique avec les composants des phases précédentes.
Un synoptique a été abordé dans l’article :
La phase C est divisée en 2 : l’architecture des données et l’architecture applicative.
On retrouve les mêmes principes des autres méthodes d’architecture d’entreprise comme l’urbanisation du Système d’Information ou Praxeme qui sont :
- d’avoir une interface entre la couche métier et la couche technique, indépendante de celle ci, ce rôle est joué par la phase C.
- de faire correspondre à chaque bloc de données un bloc applicatif qui en est l’unique propriétaire et qui est le seul à pouvoir les modifier.
L’objectif de la phase D est d’avoir une infrastructure et des composants logiciels cohérents qu’ils proviennent de progiciels du commerce, d’ERP ou bien de développement maison.
TOGAF ne préconise aucune architecture, mais ses concepts intrinsèques sont ceux 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.
Encore une fois comme dans l’urbanisation du SI, 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 tous nos articles consacrés à SOA à l’annexe 2 (à la fin de ce billet) : l’architecture SOA (Service Oriented Architecture)
Conclusion
L'EA est comme l'urbanisation du SI une méthode à la fois top-down et bottom-up avec comme objectif la modélisation globale de l'ensemble des ressources de l'entreprise (stratégie, processus métier, briques fonctionnelles et applicatives, infrastructures techniques, ...), donc la volonté de définir un référentiel d'entreprise.
Le but est d'avoir la description généralisée du fonctionnement de l'entreprise, de sa stratégie, de ses procesus métiers, ..., de l'architecture du Système Informatique, les applications, les SGBD, les machines, réseaux, ..., des relations entre les niveaux.
Les prises de décision sont ainsi facilitées en montrant les impacts potentiels sur l'organisation, les processus, le SI, ...
Toutes les parties prenantes de l'entreprise ont une vision globale, organisée des ressources de l'entreprise grace au référentiel d'entreprise.
SOA (Service Oriented Architecture) est plus une méthode de gouvernance de SI qu'une technique d'architecture, c'est ce qui explique la diminution des coûts et l'augmentation des performances.
Comme tout projet, l'architecture d'entreprise est l'affaire de tous, la DSI et les directions métiers qui ne doivent pas considérer que ça regarde uniquement les techniciens.
L'alignement stratégique implique forcément une collaboration entre la DSI et les directions métiers.
L'architecture est la route qui conduit à la mutualisation et à la réutilisation.
Ces concepts n'apparaissent pas spontanément, il faut utiliser des patterns et des bonnes pratiques de conception qui coûtent plus cher au début mais qui seront rentabilisés lors des évolutions futures.
La stratégie des directions métiers doit être partagée avec la DSI pour que ces méthodes soit en adéquation avec les buts poursuivis par l'organisation.
Rhona Maxwel
@rhona_helena
"Les femmes vont plus loin en amour que la plupart des hommes ; mais les hommes l’emportent sur elles en amitié."
La Bruyère
Annexe 1 : les précédentes étapes de notre étude de cas TOGAF
- Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio
- 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
- Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)
- Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM
- Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst
- Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)
- Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)
- Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas
- Le diagramme SysML des exigences de la phase A Vision de TOGAF : étape 4.2 de l’étude de cas
- Le diagramme d’évènements de la phase A Vision de TOGAF : étape 5 de l’étude de cas Modelio
- Le diagramme des concepts de la solution de la phase A Vision de TOGAF : étape 6 de l’étude de cas Modelio
- Le diagramme de chaîne de valeur de la phase A Vision de TOGAF : étape 7 de l’étude de cas Modelio
- Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
- Le dictionnaire métier de la phase B Architecture métier de TOGAF - étape 9 de l’étude de cas
- Le diagramme d’organisation des acteurs de la phase B Architecture métier de TOGAF - étape 10 de l’étude de cas
- Comment modéliser les flux échangés entre une entreprise et les acteurs externes en phase B architecture métier de TOGAF ? – étape 11 de l’étude de cas
- Diagramme des rôles joués par les acteurs en phase B architecture métier de TOGAF ? – étape 12 de l’étude de cas
- Diagramme d’organisation et de localisation en phase B architecture métier de TOGAF – étape 13 de l’étude de cas
- Diagramme de localisation en phase B architecture métier de TOGAF – étape 14 de l’étude de cas
- Diagramme de décomposition fonctionnelle en phase B architecture métier de TOGAF – étape 15 de l’étude de cas
- Diagramme objectifs-services métier en phase B architecture métier de TOGAF – étape 16 de l’étude de cas
- Diagramme de processus métier en phase B architecture métier de TOGAF – étape 17 de l’étude de cas
- Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems
- Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio
- Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio
- Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio
- Diagramme des entités métier en phase B architecture métier de TOGAF - étape 22 du didacticiel
- Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas
Annexe 2 : l’architecture SOA (Service Oriented Architecture)
- 4/11 Projet informatique : passer du moyen âge à l'ère industrielle. Résolvez l'équation : ROI = SOA
- Gouvernance SOA : La phase de Design Time (1)
- Gouvernance SOA : la phase de Design Time (2)
- Gouvernance SOA : la phase de Design Time (3)
- Gouvernance SOA : la phase de Design Time (4)
- Gouvernance SOA : la phase de Design Time (5)
- Gouvernance SOA : la phase de Run Time
- Gouvernance SOA : la phase de Change Time
- Un bon contrat, n'est pas un contrat signé mais un contrat standardisé
- Le contrat standardisé (suite)
- Gouvernance SOA : lachez tout !
- Faites vos gammes : les design patterns de la gouvernance SOA
- Gouvernance SOA : métier ou informatique, à votre service !
- Gouvernance SOA : Principes de l'Architecture Orientée Service
- Gouvernance SOA : Concevoir un système orienté service
- Gouvernance SOA : Concevoir une architecture de référence
- Gouvernance SOA : Caractérisation des services
- Gouvernance SOA : Les services déduits des modèles de données
- Gouvernance SOA : Les services applicatifs
- Gouvernance SOA : Les services d'orchestration de processus
- Gouvernance SOA : Les services de communication
- Gouvernance SOA : Les services d'administration
- Gouvernance SOA : Les services de sécurité
- Gouvernance SOA : Identification des échanges
A découvrir aussi
- Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces
- Diagramme d’organisation et de localisation en phase B architecture métier de TOGAF – étape 13 de l’étude de cas
- Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 757 autres membres