Department of Defense Architecture Framework

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 nécessité 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.

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

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

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.

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'architecture.
• 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 Assistant 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.

Les services d'entreprise GIG permettent le balisage, le partage, la recherche, et la récupération des données.

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.

Les produits OV fournissent les descriptions des tâches et activités, des éléments opérationnels, et des échanges d'information requis pour accomplir les missions du département de la défense. La vue OV fournit des représentations textuelles et graphiques des nœuds et éléments opérationnels, des tâches et activités affectées, 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ées 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 nœuds 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 nœuds, 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.

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.

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.

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

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

• Octobre 2003. Publication de la version 1.0. DODAF a pris la suite de C4ISR.

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

Un certain nombre d'outils de développement aident les architectes d'entreprise à créer les artéfacts ; on en donne trois exemples ci-dessous :

• MEGA for DODAF
• ARIS Defense Solution
• BiZZdesign Architect

D'autres outils fournissent des répertoires complets de ces artéfacts.

• Enterprise Elements Repository