- Department of defense architecture framework
-
Department of Defense Architecture Framework
Le Department of Defense Architecture Framework (DoDAF) est un cadre d'architecture destiné au développement d'une architecture de systèmes ou d'une architecture d'entreprise (EA). Tous les achats majeurs d'armes et de systèmes d'information du département de la défense du gouvernement des États-Unis doivent développer une architecture d'entreprise et documenter cette architecture en utilisant l'ensemble de vues prescrites dans DoDAF.
Sommaire
Présentation générale
Origine
DoDAF est le cadre d'implémentation choisi par le département de la défense des États-Unis pour la mise en conformité des architectures par rapport au Clinger-Cohen Act et aux circulaires A-11 et A-130 de l'United States Office of Management and Budget. Il est administré par le groupe de travail DoDAF du sous-secrétaire à la défense pour la Business Transformation. DoDAF s'appelait auparavant C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) AF. D'autres cadres dérivés basés sur DoDAF sont le cadre d'architecture de l'OTAN (NAF) et le cadre d'architecture du ministère de la défense du Royaume-Uni (MODAF).
Le besoin d'intégration et de fédération des architectures a entraîné la necessité de prendre en compte une représentation cohérente des concepts réseau-centré. D'autre part, les services web et l'architecture orientée services, qui sont des catalyseurs des architectures réseau-centré, sont aussi intégrés dans cette vision.
Champ d'application
Alors que ce cadre est clairement destiné à des systèmes militaires, il a des possibilités d'applications très larges dans les secteurs privé, public et du bénévolat dans le monde, et ne représente qu'un cadre d'architecture parmi d'autres.
Il est apparemment unique (avec MODAF) par son usage de " vues opérationnelles " qui détaillent le domaine opérationnel du client externe dans lequel le système en développement va opérer (ref. Cadre Zachman).
Il est bien adapté à de grands systèmes dans une architecture intégrée (integrated architecture) complexe et des enjeux d'interopérabilité.
Il s'adapte également à des architectures fédérées (federated architecture).
Référentiel en deux couches données / présentation
Comme d'autres approches d'architectures d'entreprise, par exemple The Open Group Architecture Framework (TOGAF), DoDAF est organisé autour d'un référentiel partagé pour gérer les produits.
La structure du cadre d'architecture comporte deux couches :
- la couche des données (éléments de données, attributs et relations)
- la couche de présentation (produits et vues).
Les produits sont un moyen de visualiser l'architecture de données par des graphiques, des tables, des textes. Les vues permettent de visualiser l'architecture de données en organisant les données logiquement dans une perspective spécifique ou holistique.
Le référentiel est défini par le Core Architecture Data Model 2.0 (CADM -- essentiellement un schéma de base de données commun) et le système de référentiel de l'architecture du DoD (DARS).
Une caractéristique déterminante de DoDAF est l'interopérabilité, qui est organisée selon une série de niveaux, appelés Niveaux d'interopérabilité de systèmes d'information (Levels Information System Interoperability, LISI). Le système en développement ne doit pas seulement satisfaire ses besoins internes en données mais aussi ceux du cadre opérationnel dans lequel il est placé.
Trois éléments clés
Le cadre DoDAF s'appuie sur des directives précises, notamment la stratégie des données réseau-centré (Net-Centric Data Strategy, NCDS, 2003).
La vision de la gestion des données décrite dans DoDAF est basée sur les trois éléments clés identifiés dans NCDS :
- des groupes collaboratifs d'utilisateurs, appelés communautés d'intérêt, qui doivent échanger de l'information pour atteindre leurs objectifs partagés,
- les standards de métadonnées, pour décrire l'information sur les données,
- les services d'entreprise Global Information Grid (GIG) qui permettent la découverte et le partage des données.
Communautés d'intérêt
Article détaillé : Communauté d'intérêt.DoDAF emploie la notion de communauté d'intérêt au sujet des groupes d'utilisateurs qui doivent échanger de l'information pour des objectifs, intérêts, missions, processus d'affaires partagés, et qui doivent pour cette raison disposer d'un vocabulaire partagé pour les informations échangées.
Standards de métadonnées
Article détaillé : Standards de métadonnées.DoDAF est un cadre d'architecture dirigé par les données (exigence data-driven) :
- C4ISR puis DoDAF ont été développés pour fournir une compréhension commune du contenu des données principales (core data) pour différentes vues d'architecure.
- CADM a été développé par la communauté des architectes du département de la défense pour fournir une compréhension partagée des métadonnées et de la sémantique structurelles pour les éléments de données de l'architecture DoDAF.
Les données sont définies par les objectifs de l'architecture et les exigences des processus de décision définies par la maîtrise d'ouvrage de chaque processus. Elles permettent de travailler ensuite sur quatre types de vues.
CADM permet de définir les modèles de données aux niveaux conceptuel, logique et physique. Cette description est présentée dans le volume III de la version 1.5 (métadonnées, registres de métadonnées).
Le département de la défense gère un registre de métadonnées qui permet d'accéder aux métadonnées structurelles et sémantiques qui décrivent l'architecture. OASD-NII (Office of the Assitant Secretary of Defense Networks and Information Integration) Architectures and Interoperability (A&I) a enregistré CADM et CADM XML Schema en tant que spécifications sémantiques et structurelles pour les éléments de données de l'architecture DoDAF.
Services d'entreprise "GIG"
Article détaillé : Global Information Grid.Les services d'entreprise GIG permettent le balisage, le partage, la recherche, et la récupération des données.
Vues d'artéfact
Les vues DoDAF views sont organisées en quatre ensemble de vues de base :
- Articulation de toutes les vues All View (AV),
- Vue opérationnelle Operational View (OV),
- Vue systèmes Systems View (SV),
- et vue des standards techniques Technical Standards View (TV).
On n'emploie généralement qu'un sous-ensemble des vues complètes DoDAF pour chaque développement de système.
Toutes vues - All View (AV)
Les produits AV fournissent des descriptions d'ensemble de l'architecture entière et définissent le champ et le contexte de l'architecture. Les produits AV sont :
- AV-1 Overview and Summary Information - Champ, objectif, utilisateurs, environnement, conclusions analytiques (si applicable)
- AV-2 Integrated Dictionary - Définitions de tous les termes utilisés dans tous les produits.
Vue opérationnelle - Operational View (OV)
Les produits OV fournissent les descriptions des tâches et activités, des éléments opérationnels, et des échanges d'information requis pur accomplir les missions du département de la défense. La vue OV fournit des représentations textuelles et graphiques des noeuds et éléments opérationnels, des tâches et activités affectés, et des flux d'information entre les nœuds. Elle définit le type d'information échangée, la fréquence des échanges, les tâches et activités supportés par ces échanges et la nature des échanges.
Les produits OV sont les suivants :
- OV-1 High Level Operational Concept Graphic - Description graphique et textuelle de haut niveau du concept opérationnel (organisations de haut niveau, missions, configuration géographique, connectivité, etc).
- OV-2 Operational Node Connectivity Description - Nœuds opérationnels, activités exécutées sur chaque nœud, connectivités et flux d'information entre les nœuds.
- OV-3 Operational Information Exchange Matrix - Information échangée entre les noeuds et attributs correspondants de cet échange comme le média, la qualité, la quantité, et le niveau d'interopérabilité exigé.
- OV-4 Organizational Relationships Chart - Commandement, contrôle, coordination, et autres relations dans les organisations.
- OV-5 Operational Activity Model - Activités, relations dans les activités, inputs et outputs. De plus, les recouvrements peuvent montrer les coûts, les noeuds, ou d'autres informations pertinentes.
- OV-6a Operational Rules Model - L'un des trois produits utilisés pour décrire la séquence d'activité opérationnelle permettant d'identifier les règles métier qui induisent des contraintes sur le fonctionnement opérationnel.
- OV-6b Operational State Transition Description - L'un des trois produits utilisés pour décrire la séquence d'activité operationnelle permettant d'identifier les réponses d'un processus métier à des événements.
- OV-6c Operational Event-Trace Description - L'un des trois produits utilisés pour décrire la séquence d'activité opérationnelle permettant de suivre les actions dans un scénario ou une séquence critique d'événements.
- OV-7 Logical Data Model - Documentation des exigences de données et des règles métier structurantes de la vue opérationnelle.
Vues systèmes - Systems View (SV)
Les produits SV fournissent des descriptions graphiques et textuelles des systèmes et des interconnexions entre systèmes qui supportent les fonctions du département de la défense. Les interconnexions entre systèmes définies dans OV sont décrites dans les vues systèmes SV.
Les produits SV sont les suivants :
- SV-1 System Interface Description - Identification des systèmes, composants de systèmes et de leurs interfaces, à l'intérieur et entre les nœuds.
- SV-2 Systems Communications Description - Nœuds physiques et leurs principes de communication.
- SV-3 Systems-Systems Matrix - Relations entre les systèmes dans une architecture donnée. Elle peut être conçue pour montrer les relations intéressantes, par exemple les interfaces de type système, les interfaces planifiées existantes, etc.
- SV-4 Systems Functionality Description - Fonctions exécutées par les systèmes et les flux d'information entre les fonctions de système.
- SV-5 Operational Activity to Systems Functionality Traceability Matrix - Caryographie des fonctions système jusqu'aux activités opérationnelles.
- SV-6 Systems Data Exchange Matrix - Détail des données échangées entre les éléments du système et applications allouées aux éléments du système.
- SV-7 Systems Performance Parameters Matrix - Caractéristiques de performance des éléments matériel et logiciel de chaque système, pour l'échéance appropriée.
- SV-8 Systems Evolution Description - Planification des étapes de migration de la suite système vers une suite plus efficace, ou évolution d'un système actuel vers une implémentation future.
- SV-9 Systems Technology Forecast - Technologies émergentes, produits logiciels et matériels qui doivent être disponibles dans un délai donné, et qui affecteront le développement futur de l'architecture.
- SV-10a Systems Rules Model - L'un des trois produits utilisés pour décrire la séquence d'activité des systèmes -- Contraintes imposées sur la fonctionnalité des systèmes en raison de certains aspects de la conception ou de l'implémentation des systèmes.
- SV-10b Systems State Transition Description - L'un des trois produits utilisés pour décrire la séquence d'activité des systèmes -- Réponses d'un système aux événements.
- SV-10c Systems Event-Trace Description - L'un des trois produits utilisés pour décrire la séquence d'activité des systèmes -- Raffinements spécifiques des séquences critiques d'événements décrites dans la vue opérationnelle.
- SV-11 Physical Schema - Implémentation physique de l'information du Modèle Logique de Données, par exemple, formats de messages, structures de fichiers, et schéma physique.
Vue des standards techniques - Technical Standards View (TV)
Les produits TV définissent les standards techniques, les conventions d'implémentation, les règles métier et les critères qui gouvernent l'architecture.
Les produits TV sont les suivants :
- TV-1 Technical Standards Profile - Sélection des standards qui s'appliquent à l'architecture considérée.
- TV-2 Technical Standards Forecast - Description des standards émergents qui sont susceptibles de s'appliquer à l'architecture considérée, dans un délai raisonnable.
Mise en oeuvre
Création d'une architecture intégrée utilisant DoDAF
DoDAF v1.0 a défini une liste de produits comme l'“ensemble minimum de produits requis pour satisfaire la définition d'un OV, SV et TV.”
Nota : alors que DoDAF ne liste pas l'artéfact OV-1 comme un produit essentiel, son développement est fortement encouragé. La séquence des artéfacts listée ci-dessous suggère un ordre dans lequel les artéfacts peuvent être développés. La séquence réelle de la génération de vues et leur adaptation potentielle varie en fonction du domaine d'application et des besoins spécifiques de l'initiative.
- AV-1
- AV-2
- OV-1
- OV-5
- OV-2
- OV-3
- SV-1
- TV-1
L'une des préoccupations sur DoDAF est la manière avec laquelle ces produits satisfont réellement les besoins des parties prenantes pour n'importe quel domaine d'intérêt. On peut considérer les produits DoDAF, ou au moins les trois vues, comme des points de vue ANSI/IEEE 1471-2000 ou ISO/IEC 42010. Mais afin de construire une description d'architecture qui corresponde à ANSI/IEEE 1471-2000 ou ISO/IEC 42010, il est nécessaire d'identifier clairement les parties prenantes et leurs enjuex qui correspondent à chaque produit DoDAF sélectionné. Sinon, il y a un risque (vu dans au moins des initiatives d'architecture DoDAF) de construire des produits qui n'auraient aucun client.
Représentation
Les représentations des produits DoDAF peuvent être obtenues par de nombreuses techniques de diagramme : tables, ICAM Definition Language, modèle entité-relation, UML/ SysML, et d'autres techniques spécifiques qui dépendent du produit, de l'outil utilisé, et des préférences du sous-traitant ou du client.
Il y a une initiative UPDM (UML Profile for DoDAF and MODAF) dans l'OMG pour standardiser la représentation des produits DoDAF lorsqu'on utilise UML.
DoDAF décrit d'une façon générique la représentation des artéfacts à générer, mais il autorise une flexibilité considérable en ce qui concerne les formats spécifiques et les techniques de modélisation. Le DoDAF deskbook indique des exemples d'utilisation traditionnelle en ingénierie des systèmes et en ingénierie informatique, et également, le format UML. DoDAF autorise une marge d'utilisation dans le format des produits, sans obliger à l'utilisation d'ne technique de diagramme plutôt qu'une autre.
En plus de la représentation graphique, il y a une exigence particulière concernant la fourniture de métadonnées au référentiel Defense Information Technology Portfolio Repository (DITPR) ou d'autres référentiels d'architecture.
Versions et calendrier
- Février 2004. Publication de Definitions and Guidelines (87 pages) et Product Descriptions (254 pages).
- Avril 2007 : publication de la version 1.5
- (en) DoDAF 1.5 Volume I - Definitions and guidelines - Définitions et lignes directrices. 23/04/2007 (46 pages).
- (en) DoDAF 1.5 Volume II - Product descriptions - Description des produits. 23/04/2007 (284 pages).
- (en) DoDAF 1.5 Volume III - Architecture Data description - Description des données d'architecture. 23 avril 2007, en particulier les métadonnées et le registre de métadonnées du Do (223 pages).
Outils
Un certain nombre d'outils de développement aident les architectes d'entreprise à créer les artéfacts ; on en donne un exemple ci-dessous :
D'autres outils fournissent des répertoires complets de ces artéfacts.
Harmonisation entre les cadres d'architecture nationaux
L'OMG a démarré un projet visant à standardiser un profil UML pour des cadres d'architecture militaires : UPDM (UML Profile for DoDAF and MODAF).
De plus, le IDEAS Group est un projet de quatre nations (Australie, Canada, Royaume-Uni, USA + OTAN comme observateurs) qui vise à standardiser un modèle conceptuel pour des cadres d'architecture militaires.
Source
- (en) Cet article est partiellement ou en totalité issu d’une traduction de l’article de Wikipédia en anglais intitulé « Department of Defense Architecture Framework ».
Voir aussi
- MODAF
- AGATE
- Architecture de systèmes
- Architecture réseau-centré, le modèle d'architecture du Département de la Défense que supporte DoDAF
- Architecture orientée services, la méthodologie correspondant à l'architecture réseau-centré du DoD
- Cadre Zachman
- The Open Group Architecture Framework (TOGAF)
- (en) Net-Centric Operations and Warfare , la directive et l'implémentation de l'architecture réseau-centré au départmement de la défense
- (en) Item Unique Identification, une initiative pour supporter les opérations réseau-centré
- (en) ANSI/IEEE 1471-2000 (ISO/IEC DIS 25961) Recommandation pour la description d'architecture de systèmes logiciels complexes
- (en) Federal Enterprise Architecture (FEA), l'initiative d'architecture d'entreprise du gouvernement fédéral, avec laquelle DoDAF a des dépendances
- (en) Clinger Cohen Act, la législation qui a rendu obligatoire le développement de l'architecture d'entreprise dans le gouvernement fédéral
Liens externes
- (en) IDGA's DoD Architectures Conference - Considéré largement comme l'un des événements clés annuels sur le sujet.
- (en) DoDAF Promulgation Memo Feb 9, 2004 - DODAF Policy Directive mandates use, all Architectures approved after 12/01/2003 must be DODAF compliant.
- (en)DoDAF 1.0 Deskbook - Provides supplementary "how to" information relating to architectures.
- (en) AITCNET DoDAD Link alternate link for download
- (en) BEA 4.1 - DoD Business Enterprise Architecture BEA 4.1 (Mars 2007)
Catégories : Cadre d'architecture | Département de la Défense des États-Unis
Wikimedia Foundation. 2010.
