Cadre d'architecture OTAN NAF 4.0 : planification de coalition et conception d'interopérabilité

Lorsque trente nations alliées ont besoin de connecter leurs systèmes de commandement et de contrôle pour une opération de coalition, quelqu'un doit répondre à deux questions avant qu'un seul câble soit branché : de quelle capacité la coalition a-t-elle besoin, et que doivent faire les systèmes de chaque nation pour la délivrer ? Le Cadre d'architecture OTAN version 4.0 — NAF 4.0 — est la méthode structurée que les nations utilisent pour répondre aux deux questions sous une forme que tout le monde peut lire, comparer et tester. Cet article examine les six points de vue de NAF 4.0, explique comment ils diffèrent du DODAF américain et du TOGAF d'entreprise, et montre comment le cadre est appliqué dans la planification pratique de la spirale du Réseautage de mission fédéré (FMN).

Pourquoi un cadre d'architecture partagé est important pour les coalitions

Sans un langage d'architecture commun, chaque nation décrit ses propres systèmes à sa façon. Une nation produit un diagramme PowerPoint ; une autre produit un modèle UML ; une troisième produit un document Word. Aucun de ces éléments ne peut être automatiquement comparé aux autres, et les lacunes d'interopérabilité entre eux ne peuvent être trouvées que manuellement — lentement, à grands frais et de façon incomplète. NAF 4.0 fournit le langage partagé. Lorsque toutes les nations utilisent les mêmes points de vue, le même méta-modèle et le même vocabulaire, une comparaison structurée entre l'architecture d'une nation et l'architecture cible de l'alliance devient réalisable. Les lacunes apparaissent comme des éléments manquants dans un modèle plutôt que comme des désaccords non documentés entre des documents.

Le cadre fournit également la traçabilité. Une norme technique dans le point de vue technique devrait être traçable à un service dans le point de vue service, qui devrait être traçable à un flux d'information dans le point de vue opérationnel, qui devrait être traçable à une exigence de capacité dans le point de vue capacité, qui devrait être traçable à un objectif stratégique dans le point de vue stratégique. Lorsque cette chaîne existe, tout partie prenante peut demander "pourquoi avons-nous besoin de cette version TLS particulière ?" et suivre la chaîne jusqu'au concept opérationnel qui l'exige. Lorsqu'elle n'existe pas, les systèmes accumulent une dette technique que personne ne peut justifier d'éliminer.

Les six points de vue NAF 4.0

Point de vue stratégique (St)

Le point de vue stratégique capture le contexte politique et stratégique dans lequel l'architecture opère. Dans l'usage de l'alliance, cela signifie le concept stratégique OTAN, le mandat de mission spécifique, les engagements des nations participantes et les mises en garde nationales qui contraignent ce que les forces de chaque nation peuvent faire. Les vues St expriment les résultats que la coalition doit délivrer et sous quelles contraintes politiques. Chaque capacité définie dans les points de vue ultérieurs doit être traçable à une exigence stratégique — un élément d'architecture qui ne peut pas être retracé au point de vue stratégique n'a aucune raison d'être dans l'architecture.

En pratique, le point de vue stratégique est le plus difficile à produire avec précision car il nécessite un engagement direct avec les parties prenantes politico-militaires qui ne pensent généralement pas en termes de modélisation d'architecture. Les architectes qui sautent cette étape et passent directement aux vues opérationnelles ou systèmes produisent des architectures techniquement cohérentes qui peuvent répondre aux mauvaises questions opérationnelles.

Point de vue capacité (C)

Le point de vue capacité définit ce que la force doit être capable de faire, structuré comme une taxonomie de capacités avec des dépendances entre elles et un phasage temporel sur un horizon de planification. Une capacité en termes NAF est une aptitude à atteindre un effet désiré — indépendamment de la façon dont elle est implémentée. "Partager une image aérienne reconnue à travers les nœuds C2 de coalition en quasi-temps réel" est une capacité ; "exploiter une passerelle Link 16 JREAP-C" est une solution potentielle. Garder le point de vue capacité agnostique en termes de solution est important : il préserve la liberté de satisfaire une capacité avec différentes implémentations dans différentes nations tout en restant interopérable à la frontière de service.

Dans la planification spirale FMN, le point de vue capacité est l'endroit où la portée de chaque spirale est définie. La Spirale 4 FMN ajoute des capacités au-delà de la Spirale 3, et ces capacités incrémentielles sont exprimées dans le point de vue capacité avant que des décisions de système ou de service ne soient prises. Les nations utilisent le même point de vue pour déclarer quelles capacités FMN elles s'engagent à implémenter et dans quel délai — produisant la matrice de conformité que la gouvernance FMN suit.

Point de vue opérationnel (Op)

Le point de vue opérationnel est le pont entre ce que la force doit faire et les systèmes qui lui permettent de le faire. Il décrit le concept opérationnel : les rôles impliqués (commandant, officier de liaison, opérateur de capteur), les activités qu'ils exécutent, les informations qu'ils échangent pour les exécuter, et les exigences d'information que ces échanges génèrent. Le point de vue opérationnel de NAF 4.0 produit des diagrammes tels que le modèle d'activité opérationnelle (Op-A) et le modèle d'information (Op-Iv), qui ensemble montrent quelles informations circulent entre qui et dans quelles conditions.

Pour la conception d'interopérabilité, le point de vue opérationnel est l'endroit où les flux d'information de la coalition sont rendus explicites. Un échange d'information entre un système C2 national et un système de capteur allié devient un nœud défini dans le modèle Op, avec un type d'information défini et une exigence de délai définie. Cette définition conduit ensuite les choix de service et de technique dans les points de vue inférieurs. Un problème d'interopérabilité qui n'est pas représenté dans le point de vue opérationnel ne peut pas être systématiquement abordé dans les points de vue systèmes ou service.

Point de vue systèmes (Sy)

Le point de vue systèmes décrit les systèmes physiques et logiques qui réalisent le concept opérationnel. Il montre les fonctions des systèmes, les interfaces des systèmes, les flux de données entre systèmes et les plateformes physiques sur lesquelles les systèmes sont déployés. C'est le point de vue le plus familier pour les ingénieurs systèmes et les intégrateurs — il correspond largement aux vues de niveau système dans DODAF (SV-1 à SV-10) et au domaine d'architecture système en pratique générale.

Dans une architecture de coalition, le point de vue systèmes doit représenter à la fois l'infrastructure commune de l'alliance (comme les services de base FMN) et les systèmes nationaux de chaque nation qui s'y connectent. Les spécifications d'interface à la frontière entre les systèmes nationaux et l'infrastructure d'alliance sont les livrables critiques de ce point de vue — ils doivent être suffisamment précis pour écrire un test de conformité.

Point de vue service (Sv)

Le point de vue service spécifie les services au sens de l'architecture orientée services (SOA) ou API : des unités fonctionnelles bien définies avec des interfaces publiées que les systèmes exposent pour consommation par d'autres systèmes. Ce point de vue a été substantiellement renforcé dans NAF 4.0 par rapport aux versions antérieures, reflétant le passage dans l'architecture d'interopérabilité de coalition de l'intégration système point-à-point vers la fédération basée sur les services.

Dans FMN, le point de vue service est central. L'architecture FMN définit un portefeuille de services de Réseautage de mission fédéré — voix, messagerie instantanée, partage de fichiers, échange COP, annuaire, gestion des identités — avec des interfaces et des comportements spécifiés. Chaque service dans le catalogue FMN a une entrée de point de vue service que les nations peuvent implémenter indépendamment, sachant que les implémentations conformes interopéreront. C'est architecturalement similaire à la façon dont la couche application d'Internet fonctionne : les implémentations indépendantes d'une spécification partagée produisent des services interopérables.

Point de vue technique (Tr)

Le point de vue technique répertorie les normes, les profils techniques et les contraintes auxquels les systèmes et les services doivent se conformer. C'est la couche de référence normative : un système qui apparaît dans le point de vue systèmes doit se conformer aux normes répertoriées pour lui dans le point de vue technique. Dans FMN, le point de vue technique contient les références STANAG spécifiques, les versions de protocole, les exigences de suite de chiffrement et les spécifications d'interface qui réalisent les services de chaque spirale.

Le point de vue technique est l'endroit où l'architecture NAF 4.0 recoupe le plus directement les marchés publics. Une spécification de marchés publics pour un système national qui se connectera au FMN devrait pouvoir extraire ses exigences techniques directement du point de vue technique — et le système résultant devrait passer les tests de conformité contre ces mêmes exigences. Lorsque cette chaîne tient, le document d'architecture est une spécification vivante ; lorsqu'elle se rompt, l'architecture devient un artefact historique qui n'a aucun rapport avec ce qui a réellement été acheté.

NAF versus DODAF versus TOGAF

NAF 4.0 et DODAF 2.02 sont des cousins proches, pas des concurrents. Ils partagent une ascendance commune et leurs vues peuvent être mises en correspondance au niveau conceptuel. La différence principale est la gouvernance : DODAF est une norme nationale du DoD américain ; NAF est la norme d'alliance qui lie les nations OTAN et les nations partenaires qui l'adoptent. Les organisations américaines travaillant sur des programmes OTAN produisent généralement des architectures qui satisfont les deux cadres simultanément, car les structures de vues sont suffisamment compatibles pour qu'un modèle puisse générer des produits conformes dans les deux. Là où ils divergent, c'est dans le détail du méta-modèle : NAF 4.0 est construit sur MODEM (le modèle objet MODAF), qui est plus formellement spécifié que le méta-modèle DM2 sous-jacent de DODAF dans certains domaines.

TOGAF occupe un domaine entièrement différent. The Open Group Architecture Framework est une méthode d'architecture IT d'entreprise construite autour de la méthode de développement d'architecture (ADM), qui structure le travail d'architecture comme une série de phases itératives axées sur la délivrance de changements d'entreprise permis par l'IT. TOGAF n'a aucun modèle inhérent de concepts opérationnels, de missions militaires ou de taxonomies de capacités — il est orienté vers la prestation de services IT, la gestion du portefeuille d'applications et la gouvernance du changement organisationnel. Les organisations de défense utilisent parfois TOGAF dans leurs programmes d'acquisition IT de défense internes, en le faisant fonctionner aux côtés de NAF plutôt qu'à la place de lui. Les deux cadres servent des parties prenantes différentes : NAF répond à la question de comment les forces de coalition opéreront ensemble ; TOGAF répond à la question de comment une organisation gérera son IT pour soutenir ses processus métier.

NAF dans la planification spirale FMN

Le programme de Réseautage de mission fédéré utilise NAF comme son langage d'architecture tout au long du cycle de planification spirale. Chaque spirale FMN est définie par une architecture cible exprimée en vues NAF, et la conformité nationale est mesurée par rapport à cette cible. Le processus se déroule comme suit. Premièrement, le Cadre de capacités FMN identifie les incréments de capacité que la spirale doit délivrer — un livrable du point de vue capacité. Deuxièmement, le groupe de travail d'architecture FMN produit des vues opérationnelles qui décrivent comment ces capacités seront exercées en pratique. Troisièmement, des spécifications de service sont rédigées pour chaque service dans le catalogue de la spirale — des produits du point de vue service. Quatrièmement, des profils techniques sont identifiés pour chaque service — des produits du point de vue technique. Cinquièmement, les nations évaluent leurs propres architectures par rapport à la cible FMN, identifiant les lacunes entre leurs systèmes existants et les services requis.

Les nations qui ont investi dans l'outillage et la discipline NAF peuvent effectuer cette analyse des lacunes de façon semi-automatique : comparer les entrées du point de vue technique de la nation par rapport aux exigences du point de vue technique FMN et générer une liste structurée de non-conformités. Les nations sans pratique d'architecture nationale mature effectuent la même analyse manuellement, ce qui est plus lent et plus sujet aux erreurs mais produit la même catégorie de résultat. La liste des lacunes devient l'entrée du plan de développement des capacités nationales — la feuille de route des acquisitions, mises à niveau et configurations qui amèneront la nation en conformité FMN pour la spirale. Pour plus de détails sur ce que la Spirale 4 FMN exige spécifiquement, voir notre analyse des exigences de la Spirale 4 FMN.

CWIX — la Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — est l'événement annuel où la conformité FMN est testée en pratique plutôt que sur papier. La relation entre l'architecture NAF et les tests CWIX est directe : les cas de test exécutés au CWIX doivent être dérivés des spécifications d'interface dans les points de vue service et technique NAF. Notre analyse de la feuille de route spirale FMN couvre comment les spirales successives s'appuient les unes sur les autres et à quoi ressemble la trajectoire future du développement des capacités FMN.