Das NATO Architecture Framework (NAF)

Eine umfassende Analyse für Systems Engineering und Requirements Engineering

Network (Image by Ricardo Gomez Angel from Unsplash)

1. Einführung in das NATO Architecture Framework (NAF)

Das NATO Architecture Framework (NAF) ist ein standardisierter Ansatz zur Entwicklung und Beschreibung von Architekturen innerhalb der NATO und ihrer Partnernationen. Es stellt Regeln, Anleitungen und Vorlagen bereit, um ein gemeinsames Verständnis für den Vergleich und die Integration von Architekturen sicherzustellen.

1.1 Ursprung und Entwicklung

Die Notwendigkeit eines standardisierten Architektur-Frameworks innerhalb der NATO entstand maßgeblich aus der strategischen Initiative „NATO Network-Enabled Capabilities“ (NNEC), die auf dem Prager Gipfel 2002 beschlossen wurde. NNEC zielte darauf ab, die militärischen Fähigkeiten durch verbesserte Informationsvernetzung, Situationswahrnehmung, schnellere Entscheidungsfindung und verstärkte Zusammenarbeit zwischen den Nationen zu transformieren. Dabei wurde betont, dass der Mensch („People first“), dann die Prozesse und erst danach die Technologie im Vordergrund stehen sollten. So soll der Mensch als Teil eines Systems in den Fokus gerückt werden, um menschliche Anforderungen zu erfassen und deren Einfluss auf das Systemdesign zu berücksichtigen. Dies zeigt, dass NAF von Beginn an bestrebt war, über rein technische Systembeschreibungen hinauszugehen und organisatorische sowie menschliche Aspekte zu integrieren.

Um die Interoperabilität und den Informationsaustausch zwischen den heterogenen Systemen der verschiedenen NATO-Mitgliedsstaaten zu gewährleisten, wurde ein gemeinsamer Standard zur Beschreibung von Architekturen unerlässlich. Ohne eine solche gemeinsame Sprache wäre die effektive Integration multinationaler Streitkräfte und ihrer C3-Systeme (Consultation, Command and Control) kaum realisierbar gewesen.

Die Entwicklung und Pflege des NAF liegt in der Verantwortung des NATO Consultation, Command and Control Board (NC3B), das 1996 gegründet wurde und als übergeordnete Autorität für C3-Architekturen fungiert. Speziell die Entwicklung der Version 4 (NAFv4) war ein mehrjähriges Unterfangen (über vier Jahre), das vom Architecture Capability Team (ACaT) unter dem C3B geleitet wurde. Diese Entwicklung war ein kollaborativer Prozess, der maßgebliche Unterstützung und Beiträge von verschiedenen NATO-Nationen (insbesondere Großbritannien, Frankreich und Deutschland), Partnernationen, der Industrie und der NATO Science and Technology Organization (STO) erhielt. Diese breite Beteiligung unterstreicht die strategische Bedeutung des Frameworks für die Allianz und die Notwendigkeit eines Konsenses für ein Werkzeug, das für den multinationalen Einsatz konzipiert ist. NAFv4 wurde offiziell im Januar 2018 herausgegeben.

Zeitreihe der NAF Versionen

1.2 Kernziele und Zweck des NAF

Das primäre Ziel von NAFv4 ist es, einen einheitlichen Standard für die Entwicklung und Beschreibung von Architekturen sowohl für militärische als auch geschäftliche Zwecke bereitzustellen. Diese bewusste Ausrichtung auf einen dualen Anwendungsbereich spiegelt die zunehmende Realität wider, dass moderne Verteidigungsorganisationen verstärkt kommerzielle Technologien (Commercial off-the-Shelf, COTS) einsetzen und geschäftsähnliche Prozesse implementieren. Ein wesentliches Anliegen des NAF ist dabei, häufig fragmentierte Altsysteme („Legacy-Systeme“) und isolierte Prozesse in einer integrierten, flexiblen und anpassungsfähigen Architektur zusammenzuführen, die effektiv auf Veränderungen reagiert.

Weitere Kernziele umfassen:

• Standardisierung und gemeinsames Verständnis: Schaffung einer gemeinsamen Basis („common denominator“) für das Verständnis, den Vergleich und die Integration von Architekturen verschiedener Akteure. Architektur wird als gemeinsame Sprache positioniert, um interkulturelles Verständnis und Vertrauen zu fördern. Dieser Standardisierungsfokus adressiert direkt die Herausforderung, Systeme unterschiedlicher Nationen in NATO-Koalitionen effektiv zusammenzuführen.
• Fähigkeitsentwicklung und Interoperabilität: NAF dient als Schlüsselinstrument („key enabler“) für die Beschaffung und Bereitstellung kosteneffektiver und interoperabler militärischer Fähigkeiten. Es unterstützt den Aufbau multinationaler Systeme für Operationen.
• Kommunikation und Organisation: Bereitstellung einer Methode zur Organisation und Präsentation von Architekturen für verschiedene Stakeholder.
• Anleitung und Regelwerk: Spezifizierung von Anleitungen, Regeln und Produktbeschreibungen für die Entwicklung und Darstellung von Architekturinformationen.
• Entscheidungsunterstützung: Unterstützung von Entscheidungsprozessen bezüglich des Ressourceneinsatzes (Systeme, Prozesse) im Einklang mit der Unternehmensstrategie und den NATO-Zielen. Es geht also nicht nur um die Dokumentation des Ist-Zustandes, sondern um die aktive Nutzung von Architekturmodellen für Analyse, Planung und strategische Steuerung über den gesamten Lebenszyklus von Fähigkeiten.
• Umfassende Planungsunterstützung: Unterstützung bei der Planung von Fähigkeitsübergängen im Lebenszyklus, Risikomanagement, Anpassung an Veränderungen, Ausrichtung von Business und Technologie, Investitionsplanung und Kostenkontrolle.
• Standards-Konformität: Ausrichtung an internationalen Standards von Organisationen wie ISO, IEEE, The Open Group (TOG) und Object Management Group (OMG).

Beispiel für den Zusammenhang zwischen der übergeordneten Zielsetzung und einer Ressource (Quelle: 1)

1.3 Bedeutung für Interoperabilität und Fähigkeitsentwicklung

Die Fähigkeit verschiedener Systeme und Organisationseinheiten unterschiedlicher Nationen, nahtlos zusammenzuarbeiten (Interoperabilität), ist für die NATO von existenzieller Bedeutung. Nahezu alle militärischen Operationen seit dem Zweiten Weltkrieg fanden im Rahmen von Koalitionen statt. In solchen Szenarien ist es unerlässlich, dass die eingesetzten Systeme Informationen austauschen und gemeinsame Aufgaben erfüllen können. Traditionelle Entwicklungsansätze führten jedoch oft zu isolierten Systemen („Insellösungen“, engl. „stovepipes“), die nur unzureichend interoperabel waren.

Separater vertikaler Informationsfluss, ohne horizontale Vernetzung

NAF adressiert diese Herausforderung direkt, indem es als Standard für die Beschreibung von Architekturen dient und somit die Grundlage für die Entwicklung interoperabler Fähigkeiten schafft. Die Interoperabilität war der ursprüngliche Treiber für Enterprise Architecture im Verteidigungsbereich. NAF ermöglicht es, durch standardisierte Modelle und definierte Sichten Lücken und Überlappungen zwischen Prozessen und unterstützenden Systemen verschiedener Nationen zu identifizieren.

Framework, Views ,Viewpoints und Architekturmodell -Architekturen (Quelle:1)

Der modellbasierte Ansatz von NAF, gestützt auf Metamodelle, erlaubt strukturierte Beschreibungen von System-of-Systems (SoS)-Architekturen, automatisierte Kohärenzprüfungen durch Nachverfolgung von Beziehungen und den Vergleich verschiedener Systemalternativen, was die Interoperabilität maßgeblich fördert.

Darüber hinaus unterstützt NAF den gesamten Prozess der Fähigkeitsentwicklung. Es hilft, die strategische Vision der NATO und die daraus abgeleiteten Fähigkeitsanforderungen zu erfassen und in eine strukturierte Fähigkeitstaxonomie zu zerlegen. Durch die Verknüpfung von Architekturelementen mit Fähigkeiten stellt NAF sicher, dass Systementwürfe auf operative Bedürfnisse und strategische Ziele ausgerichtet sind und diese unterstützen. Architektur-Repositories und Bibliotheken, die durch NAF ermöglicht werden, fördern die Wiederverwendung von Architekturbestandteilen und verbessern so die Interoperabilität und Effizienz bei der Entwicklung neuer oder angepasster Fähigkeiten. Der Übergang von textbasierten Beschreibungen zu standardisierten Modellen, wie ihn NAF fördert, reduziert Ambiguitäten und verbessert die Kommunikation und das gemeinsame Verständnis in der multinationalen und multikulturellen Umgebung der NATO.

2. Evolution des NAF: Von NAFv3 zu NAFv4

Das NATO Architecture Framework hat sich über die Jahre weiterentwickelt, um den sich ändernden Anforderungen und den gewonnenen Erfahrungen Rechnung zu tragen. Die Umstellung von Version 3 auf Version 4 markiert dabei einen signifikanten Schritt.

2.1 Überblick über NAF-Versionen

NAFv3 wurde 2007 veröffentlicht. Es baute stark auf bestehenden nationalen Frameworks auf, insbesondere dem UK Ministry of Defence Architecture Framework (MODAF), das wiederum aus dem US Department of Defense Architecture Framework (DoDAF) Version 1.0 entwickelt wurde. NAFv3 übernahm die Kernstruktur der Sichten (Views/Subviews) von DoDAF und MODAF. Das zugrundeliegende Metamodell von NAFv3, das NATO Meta Model (NMM), war eng an das MODAF-Metamodell angelehnt oder basierte direkt darauf. In NAFv3 wurde der Begriff „Subview“ verwendet, um spezifische Diagrammtypen oder Sichtdefinitionen zu bezeichnen, wie z.B. die NOV-1 High-Level Operational Concept Description.

NAFv4 wurde im Januar 2018 eingeführt, mit aktualisierter Dokumentation im September 2020. Es wurde entwickelt, um die erkannten Limitationen von NAFv3 zu adressieren. Die Entwicklung von NAF zeigt eine klare Linie von DoDAF über MODAF zu NAFv3 und schließlich NAFv4. Diese Abstammung erklärt konzeptionelle Ähnlichkeiten, aber auch die Notwendigkeit von Anpassungen und Weiterentwicklungen, um spezifischen NATO-Anforderungen gerecht zu werden. Die Existenz mehrerer Versionen verdeutlicht, dass NAF ein lebendes Framework ist, das auf Basis praktischer Erfahrungen, Nutzerfeedback und der Entwicklung internationaler Standards kontinuierlich angepasst wird.

2.2 Wesentliche Änderungen und Verbesserungen in NAFv4

Die Einführung von NAFv4 war motiviert durch mehrere Schwachstellen der Vorgängerversion. NAFv3 wurde in Projekten nicht konsistent angewendet, bot keinen einheitlichen Architekturansatz, war aufgrund begrenzter Ressourcen schwierig zu pflegen und entsprach nicht mehr den aktuellen internationalen Standards wie ISO/IEC/IEEE 42010. Auch gab es terminologische Unklarheiten, beispielsweise bei der Verwendung der Begriffe „View“ und „Viewpoint“.

NAFv4 adressiert diese Punkte durch folgende wesentliche Änderungen:

1. Einführung einer Methodik: NAFv4 enthält eine eigene Methodik, die beschreibt, wie Architekturen entwickelt und Architekturprojekte durchgeführt werden sollen. Dies umfasst Aspekte wie die Einrichtung der Architekturumgebung, Governance, Management, Definition und Bewertung von Architekturen. Damit wird eine Lücke geschlossen, da NAFv3 primär ein Inhalts-Framework ohne detaillierte Prozessanleitung war.
2. Adaption von Industrie-Metamodellen: Anstelle eines proprietären NATO Meta Models (NMM) oder der engen Anlehnung an MODAF setzt NAFv4 auf etablierte, kommerzielle Metamodelle: ArchiMate® von The Open Group® und das Unified Architecture Framework (UAF)® Domain Meta-Model (DMM)® der Object Management Group® (OMG). Für beide Metamodelle werden spezifische Modellierungsrichtlinien bereitgestellt. Dieser Wechsel zu Industriestandards ist eine der fundamentalsten Änderungen. Er zielt darauf ab, die Werkzeugunterstützung zu verbessern, den Pflegeaufwand für ein eigenes Metamodell zu reduzieren und die Interoperabilität auch mit nicht-militärischen Partnern zu erleichtern.
3. Verbesserte Standards-Konformität: NAFv4 strebt eine stärkere Ausrichtung an internationalen Standards an, insbesondere ISO/IEC/IEEE 42010 für Architekturbeschreibungen, aber auch Konzepte aus TOGAF und OMG-Standards werden berücksichtigt. Beispielsweise wird die Terminologie von ISO 42010 (z.B. die klare Unterscheidung zwischen Viewpoint als Spezifikation und View als Instanz) konsequenter verwendet als in NAFv3.
4. Überarbeitete Struktur und Benutzerfreundlichkeit: Das Layout von NAFv4 und die Darstellung der Sichten (Viewpoints) wurden überarbeitet, um die Verständlichkeit und Benutzerfreundlichkeit zu verbessern. Die Organisation der Viewpoints in einer Grid-Struktur ist dabei ein zentrales Element.
5. Erweiterter Anwendungsbereich: NAFv4 gibt Anleitungen sowohl für Enterprise Architekturen als auch für Systemarchitekturen und zielt explizit auf militärische und geschäftliche Anwendungsfälle ab.
6. Extensibilität: Das Framework ist so konzipiert, dass es von NATO-Mitgliedsstaaten und Partnern erweitert werden kann, um spezifischen nationalen Anforderungen gerecht zu werden. Beispielsweise haben Deutschland und die Schweiz eigene Sichten, etwa für das Requirements Engineering, hinzugefügt. Diese Flexibilität ist ein pragmatischer Ansatz, um die Akzeptanz und Anwendbarkeit in unterschiedlichen Kontexten zu erhöhen, während ein gemeinsamer Kern erhalten bleibt.

Viewpoints in Architekturen nach ADMBw beinhalten Requirements als zusätzliche Zeile (Quelle: 1)

2.3 Kompatibilität und Übergang

Um den Übergang von NAFv3 zu erleichtern und die Wiederverwendung bestehender Architekturen zu ermöglichen, enthält NAFv4 spezifische Hinweise zur Kompatibilität. Die Methodik in NAFv4 erläutert, wie NAFv3-Sichten (bzw. Subviews) wiederverwendet werden können, und die Zellen im NAFv4-Grid enthalten Referenzen auf die entsprechenden NAFv3-Views. Diese Vorgehensweise zeigt, dass die NATO den erheblichen Investitionsaufwand anerkennt, der in NAFv3-Architekturen steckt, und einen evolutionären Übergang anstelle eines radikalen Bruchs unterstützt, um die Akzeptanz von NAFv4 zu fördern.

3. Das methodische Framework von NAFv4

NAFv4 bietet einen umfassenden Rahmen, der nicht nur beschreibt, was eine Architektur enthalten soll, sondern auch wie sie entwickelt und gemanagt wird.

3.1 Kernkomponenten: Methodik, Sichten, Metamodelle

Die Struktur von NAFv4 basiert auf drei Hauptpfeilern:

1. Methodik: Definiert den Prozess zur Entwicklung von Architekturen und zur Durchführung von Architekturprojekten. Sie umfasst Anleitungen zur Einrichtung der Architekturumgebung, zur Governance, zum Management, zur Definition und zur Bewertung von Architekturen. Die Methodik basiert auf anerkannten Best Practices und Standards.
2. Sichten (Viewpoints): Legt die Konventionen für die Erstellung, Interpretation und Nutzung von Architektur-Views fest, um die Architektur effektiv an verschiedene Stakeholder zu kommunizieren. Jeder Viewpoint adressiert spezifische Anliegen („concerns“) der Stakeholder. NAFv4 verwendet den Begriff „Viewpoint“ korrekt im Sinne von ISO 42010 als Spezifikation für einen „View“ (die konkrete Darstellung).
3. Metamodelle: Spezifiziert die konformen kommerziellen Metamodelle — ArchiMate und UAF DMM — die zur Erstellung der definierten Views verwendet werden können.

Diese klare Dreiteilung in Prozess (Methodik), Inhaltsspezifikation (Viewpoints) und zugrundeliegende Sprache/Struktur (Metamodelle) bietet einen logischen und umfassenden Ansatz für das Architekturmanagement.

Mit dem Fortschreiten der Systems-Engineering-Methoden bietet SysMLv2 eine vielversprechende Möglichkeit, NAF-Modelle noch präziser, konsistenter und durchgängiger zu modellieren — insbesondere im Zusammenspiel mit dem UAF DMM, das bereits auf UML/SysML basiert. SysMLv2 erweitert die Ausdrucksstärke für Systemarchitekturen, Schnittstellen und Verhaltensmodelle und ist dadurch prädestiniert für den Einsatz im NAF-Kontext.

3.2 Architekturprinzipien und Grundlagen

Ein wesentlicher Bestandteil der NAFv4-Methodik ist die Betonung von Architekturprinzipien als Leitlinien für den Entwurfsprozess. Die „Foundation for Architecting“ umfasst neben Begriffen, Konzepten und Aktivitäten auch explizit Architekturprinzipien.

Architekturprinzipien werden als normative Aussagen definiert, die Eigenschaften eines Systems oder Prozesses vorschreiben und Gestaltungsspielräume einschränken. Sie entwickeln sich von anfänglichen Grundüberzeugungen („Credos“) zu spezifischen, begründeten Regeln („Norms“). NAFv4 beschreibt einen strukturierten Prozess zur Handhabung dieser Prinzipien:

• Treiber definieren: Identifikation von Zielen, Risiken, Anforderungen etc., die die Prinzipien motivieren.
• Prinzipien bestimmen: Ableitung von Kandidatenprinzipien aus den Treibern.
• Prinzipien spezifizieren: Detaillierte Ausarbeitung mit Begründung und Implikationen (Übergang von Credo zu Norm).
• Prinzipien klassifizieren: Einordnung nach Dimensionen wie Geltungsbereich, Abstraktionsebene etc.
• Prinzipien validieren und akzeptieren: Abstimmung mit Stakeholdern und formale Annahme.
• Prinzipien anwenden: Nutzung der Prinzipien zur Steuerung von Entwurfsentscheidungen.
• Konformität managen: Überwachung der Einhaltung und Handhabung von Abweichungen.
• Änderungen handhaben: Anpassung der Prinzipien bei sich ändernden Rahmenbedingungen.

Jedes Prinzip sollte einen Namen, eine Aussage, eine Begründung (Rationale) und die daraus folgenden Implikationen umfassen. Diese Formalisierung hebt Prinzipien von vagen Richtlinien zu konkreten Governance-Instrumenten im Architekturprozess. Sie werden während des gesamten Architektur-Lebenszyklus angewendet und überprüft, was zur Kohärenz und Qualität der Architekturen beiträgt.

3.3 Der NAF-Lebenszyklus und Architekturprozess

Die NAFv4-Methodik beschreibt einen Architektur-Lebenszyklus, der Architekturtätigkeiten in Phasen gruppiert. Wichtig ist, dass diese Phasen flexibel orchestriert werden können. Aktivitäten können wiederholt und Iterationen durchgeführt werden, um die Architekturziele zu erreichen. Dies spiegelt die nicht-lineare Natur der Architekturentwicklung in komplexen Vorhaben wider.

Ein Beispiel für eine Implementierung dieses Lebenszyklus umfasst folgende Phasen:

1. Etabliere Architecture Landscape (AL): Vorbereitung der Architekturfähigkeit (Organisation, Prozesse, Werkzeuge).
2. Manage Architecture Motivation Data (MD): Abgleich der Architekturaktivitäten mit Zielen, Anforderungen, Standards und anderen Treibern.
3. Etabliere Architecture Vision (AV): Definition der Vision, des Umfangs und der Vorgehensweise für die Architektur.
4. Beschreibe Alternatives of Architectures (AD): Entwicklung und Beschreibung von Architektur-Alternativen.
5. Bewerte Architecture Alternatives (AE) und Propose Trade-offs: Bewertung der Alternativen anhand definierter Kriterien.
6. Plan Migration (MP): Entwicklung eines Plans zur Umsetzung der Zielarchitektur, Integration von Implementierungsprojekten.
7. Gewährleiste Application of Architecture (AG): Sicherstellung, dass die Implementierung der Architektur entspricht.
8. Entscheide Architecture Change (AC): Management von Änderungsanträgen an der Architektur.

Architecting Ebenen (Quelle: 2)

Diese Phasenstruktur weist konzeptionelle Ähnlichkeiten zu etablierten Frameworks wie dem Architecture Development Method (ADM) von TOGAF auf, was die Integration erleichtert, falls Organisationen beide Frameworks nutzen.

Zur Überwachung und Steuerung des Prozesses dienen zwei zentrale Management-Artefakte:

• Architecture Management Plan: Dokumentiert die geplanten Zyklen, Iterationen, Synchronisationspunkte mit anderen Architekturen oder Projektphasen und die Erfolgskriterien.
• Architecture Dashboard: Synthetisiert Daten zur Überwachung des Fortschritts der Architekturtätigkeiten im Hinblick auf die Ziele. Es visualisiert Schlüsselmeilensteine, den Status der Phasen, potenzielle Abweichungen (Alerts) und getroffene Entscheidungen.

Die explizite Einbeziehung von Phasen für das Management von Motivationstreibern (MD), Governance (AG) und Änderungen (AC) sowie die unterstützenden Management-Artefakte unterstreichen, dass NAFv4 nicht nur die Erstellung, sondern auch die kontinuierliche Pflege und Steuerung der Architektur über ihren Lebenszyklus hinweg unterstützt.

3.4 Die NAF-Grid-Struktur: Subjekte und Aspekte

Ein zentrales Organisationsprinzip für die NAFv4-Viewpoints ist die Grid-Struktur. Diese zweidimensionale Matrix, ähnlich dem Zachman Framework, dient dazu, die Vielzahl der Viewpoints logisch und konsistent zu ordnen und Architekten bei der Navigation zu unterstützen.

• Zeilen (Rows) — Subjects of Concern (Domänen): Repräsentieren verschiedene Abstraktionsebenen oder Domänen der Architekturbeschreibung. Typische Zeilen sind: Concept, Service Specification, Logical Specification, Physical Resource Specification und Architecture Foundation.
• Spalten (Columns) — Aspects of Concern (Aspekte/Modellarten): Repräsentieren verschiedene Perspektiven oder Arten von Informationen, die über die Subjekte in den Zeilen dargestellt werden. Typische Spalten sind: Taxonomy/Classification, Structure, Connectivity, Behaviour (oft unterteilt in Processes/Activities, States, Sequences), Information, Constraints und Roadmap.

Jede Zelle in diesem Grid repräsentiert einen spezifischen Viewpoint (z.B. C1 Capability Taxonomy, L3 Node Interactions, P6 Resource Sequence). Insgesamt definiert NAFv4 47 solcher Viewpoints.

Das Grid dient als mentale Landkarte und Navigationshilfe durch die Viewpoints. Es hilft Architekten, relevante Sichten zu finden und deren Kontext innerhalb der Gesamtarchitektur zu verstehen. Indem es dazu anregt, verschiedene Aspekte (Spalten) für jede Subjekt-Ebene (Zeile) zu betrachten, kann das Grid auch als Hilfsmittel zur Sicherstellung einer gewissen Vollständigkeit der Architekturbeschreibung dienen. Beispielsweise fordert das Grid bei der Definition von Fähigkeiten (Concept-Zeile) dazu auf, nicht nur die Taxonomie (C1), sondern auch Abhängigkeiten (C3), Prozesse (C4), Effekte (C5), Performance (C7), Randbedingungen (C8) und die zeitliche Entwicklung (Cr) zu berücksichtigen.

Es ist jedoch wichtig zu betonen, dass NAFv4 explizit fordert, die Auswahl der Viewpoints an die spezifischen Anliegen der Stakeholder und die jeweilige Architekturaufgabe anzupassen. Das Grid ist somit eine Orientierungshilfe und keine Vorschrift, jede Zelle auszufüllen. Dies beugt einer potenziellen Rigidität vor, die manchmal mit matrixbasierten Frameworks assoziiert wird.

3.5 Unterstützte Metamodelle: ArchiMate und UAF DMM

Das Metamodell definiert die grundlegenden Bausteine (Elementtypen, Beziehungstypen) und Regeln für die Erstellung konsistenter Architekturmodelle. Wie bereits erwähnt, hat NAFv4 einen entscheidenden Schritt vollzogen, indem es auf die Verwendung etablierter, kommerzieller Metamodelle setzt:

1. ArchiMate®: Ein offener Standard von The Open Group, der eine Sprache zur Beschreibung von Enterprise Architekturen über Business-, Anwendungs- und Technologie-Layer hinweg bietet. NAFv4 referenziert dabei auf ArchiMate. Spezifische Richtlinien beschreiben, wie ArchiMate-Elemente zur Erstellung von NAFv4-Views verwendet werden sollen.
2. Unified Architecture Framework (UAF)® Domain Meta-Model (DMM)®: Ein Standard der OMG, der darauf abzielt, eine standardisierte Art und Weise zur Beschreibung von Architekturen gemäß DoDAF und MODAF unter Verwendung von UML/SysML zu bieten. NAFv4 referenziert auf UAF DMM. Auch hierfür gibt es spezifische Modellierungsrichtlinien. UAF selbst basiert auf dem Unified Profile for DoDAF und MoDAF (UPDM).

Die Entscheidung für diese beiden Industriestandards ermöglicht es NAF, von deren breiter Akzeptanz, Werkzeugunterstützung und dem verfügbaren Know-how in der Industrie zu profitieren. Es reduziert den Aufwand für die NATO, ein eigenes, komplexes Metamodell zu pflegen und weiterzuentwickeln.

4. NAF im Vergleich zu anderen Enterprise Architecture Frameworks

Um die Positionierung und die spezifischen Eigenschaften von NAF besser zu verstehen, ist ein Vergleich mit anderen weit verbreiteten Enterprise Architecture (EA) Frameworks hilfreich.

4.1 Gegenüberstellung: NAF, DoDAF, TOGAF

Diese drei Frameworks repräsentieren unterschiedliche Schwerpunkte und Anwendungsbereiche im EA-Spektrum:

NAF (NATO Architecture Framework):

• Kontext: NATO und Partnernationen.
• Ziel: Multinationale Interoperabilität, Fähigkeitsentwicklung, Unterstützung militärischer und geschäftlicher Prozesse.
• Umfang: Enterprise- und Systemarchitekturen.
• Methodik: In NAFv4 definiert.
• Metamodell: NAFv4 nutzt ArchiMate oder UAF DMM.
• Struktur: Grid-basierte Viewpoints (ca. 47 in NAFv4).
• Herkunft: Abgeleitet von DoDAF/MODAF.

DoDAF (Department of Defense Architecture Framework):

• Kontext: US-Verteidigungsministerium (DoD).
• Ziel: Unterstützung von Entscheidungsprozessen im DoD, Sicherstellung der Interoperabilität innerhalb des DoD.
• Umfang: DoD Enterprise- und Systemarchitekturen.
• Methodik: Definierter 6-Schritte-Prozess.
• Metamodell: DoDAF Meta-Model (DM2).
• Struktur: Umfassender Satz von Views (über 50 in DoDAF 2.0), gruppiert in 8 Viewpoints (AV, CV, DIV, OV, PV, SvcV, StdV, SV).
• Herkunft: Entwicklung innerhalb des DoD, basierend auf C4ISR Framework.

TOGAF (The Open Group Architecture Framework):

• Kontext: Industrieübergreifender Standard (The Open Group).
• Ziel: Bereitstellung einer Methode und von Ressourcen zur Etablierung und zum Betrieb einer EA-Praxis.
• Umfang: Gesamter EA-Lebenszyklus, Governance.
• Methodik: Kernkomponente ist das Architecture Development Method (ADM).
• Metamodell: TOGAF Content Metamodel.
• Struktur: Basiert auf ADM-Phasen, Building Blocks, Architecture Continuum.
• Herkunft: Entwicklung durch The Open Group, basierend auf früheren Frameworks (z.B. TAFIM).

Diese Gegenüberstellung zeigt, dass Frameworks auf einem Spektrum von generisch (TOGAF) bis sehr spezifisch (DoDAF, FEAF) angesiedelt sind. NAF positioniert sich im militärischen Bereich, strebt aber durch die explizite Einbeziehung von Geschäftsprozessen und die Nutzung von Industriestandards eine breitere Anwendbarkeit an als das rein nationale DoDAF. Ein weiterer Unterschied liegt im Fokus: TOGAF ist stark methodenorientiert (ADM), während DoDAF traditionell als inhaltsorientiert (Views) galt, obwohl es einen Prozess definiert. NAFv4 versucht hier eine Balance zu finden, indem es sowohl eine Methodik als auch eine detaillierte Viewpoint-Struktur bietet. Es gibt zudem einen Trend zur Konvergenz: NAFv4 adaptiert Industriestandards, UAF (in NAFv4 nutzbar) entstand aus der Vereinheitlichung von DoDAF/MODAF-Profilen, und in der Praxis werden Frameworks oft kombiniert, z.B. die TOGAF ADM mit NAF- oder DoDAF-Inhalten.

4.2 Spezifische Merkmale des NAF (Fokus, Stärken, Schwächen)

NAF, insbesondere in Version 4, weist spezifische Charakteristika auf:

• Fokus: Der Kernfokus liegt auf der Sicherstellung multinationaler Interoperabilität und der Unterstützung der Fähigkeitsentwicklung im Kontext von NATO-Operationen und -Planungen. Es ist explizit auf die Handhabung der Komplexität von System-of-Systems (SoS) ausgelegt, die im Verteidigungsbereich vorherrscht.

Stärken (NAFv4):

• NATO-Standard: Bietet einen vereinheitlichten Ansatz für die Allianz und ihre Partner.
• Integrierte Methodik: Umfasst einen definierten Prozess für Architekturentwicklung und -management.
• Nutzung von Industriestandards: Die Adaption von ArchiMate und UAF DMM verbessert die Werkzeugunterstützung, erleichtert die Integration mit zivilen Standards und erweitert den Pool potenzieller Experten. Dies ist ein signifikanter Vorteil gegenüber NAFv3, das unter mangelnder Standardkonformität und Pflegeaufwand litt.
• Strukturierte Sichten: Das Grid-System bietet eine klare Organisation der Viewpoints.
• Verbesserte Benutzerfreundlichkeit: NAFv4 gilt als klarer und verständlicher strukturiert als NAFv3.
• Extensibilität: Erlaubt nationale Anpassungen und Erweiterungen.
• SE-Anbindung: Starke Verbindung zum Systems Engineering durch die Unterstützung von UAF, das auf SysML/UML basiert.

Schwächen/Herausforderungen:

• Komplexität: Mit 47 Viewpoints und der Option zweier Metamodelle ist NAFv4 ein umfassendes, potenziell komplexes Framework, dessen effektive Nutzung erfahrene Architekten und sorgfältiges Tailoring erfordert. Die Breite, die Flexibilität ermöglicht, kann ohne disziplinierte Anwendung zur Belastung werden.
• Konsistenz: Trotz Verbesserungen bleibt die Sicherstellung der Konsistenz über verschiedene Sichten, Teams und möglicherweise Metamodelle hinweg eine Herausforderung. Eine klare Spezifikation der erwarteten Inhalte für jeden Viewpoint und starke Governance sind entscheidend, um tatsächlich vergleichbare und integrierbare Architekturen zu gewährleisten. Semantische Unklarheiten bei Modellelementen können ebenfalls zu Problemen führen, wenn sie nicht sorgfältig gehandhabt werden.
• Werkzeuginteroperabilität: Die Unterstützung zweier Metamodelle kann die Interoperabilität zwischen Projekten erschweren, die unterschiedliche Modellierungsansätze gewählt haben, es sei denn, effektive Austauschmechanismen sind etabliert.

4.3 Interoperabilität zwischen den Frameworks

Die Fähigkeit, Architekturen, die mit unterschiedlichen Frameworks erstellt wurden, zu verstehen oder gar zu integrieren, ist ein wichtiges Anliegen. NAFv4 verbessert die potenzielle Interoperabilität durch die Adaption von Industriestandards. Insbesondere die Nutzung des UAF DMM schafft eine starke konzeptionelle Brücke zu DoDAF und MODAF, da UAF aus dem Bestreben entstand, diese beiden Frameworks mittels UML/SysML-Profilen zu vereinheitlichen (UPDM). Architekturen, die NAFv4 mit UAF verwenden, teilen somit eine gemeinsame semantische Basis und Modellierungsparadigmen mit modernen DoDAF/MODAF-basierten Ansätzen.

Die Interoperabilität mit generischeren Frameworks wie TOGAF wird durch explizite Mappings zwischen den Prozessschritten (z.B. TOGAF ADM) und den Inhaltsstrukturen (z.B. NAF Viewpoints) unterstützt, wie sie in Studien untersucht wurden. Dies ermöglicht es Organisationen, beispielsweise den etablierten ADM-Prozess von TOGAF zu nutzen, aber die spezifischen NAF-Viewpoints zur Beschreibung der Architekturinhalte zu verwenden.

Technische Interoperabilität auf Werkzeugebene bleibt jedoch eine Herausforderung. Obwohl Werkzeuge existieren, die mehrere Frameworks unterstützen oder Transformations- und Austauschfähigkeiten bieten, erfordert der Austausch von Architekturdaten zwischen unterschiedlichen Umgebungen (z.B. ArchiMate-basiert vs. UAF-basiert) oft spezifische Konnektoren, Mappings und Transformationsregeln. Die Standardisierung durch NAFv4 erleichtert dies, eliminiert aber nicht die Notwendigkeit technischer Integrationslösungen und klarer Governance.

4.4 Gegenüberstellung NAF vs. DoDAF vs. TOGAF

Die folgende Tabelle fasst die wesentlichen Merkmale der drei verglichenen Frameworks zusammen:

Einordnung von NAFv4 im Kontext anderer bedeutender Frameworks

5. NAF im Systems Engineering (SE)

NAFv4 ist nicht nur ein Enterprise Architecture Framework, sondern bietet auch spezifische Unterstützung für den Bereich des Systems Engineering (SE), insbesondere durch die Integration von Konzepten und Methoden des Model-Based Systems Engineering (MBSE).

5.1 Unterstützung des Systementwurfs und der Modellierung

NAFv4 stellt explizit Anleitungen für die Beschreibung von Systemarchitekturen bereit. Es ermöglicht die Modellierung wesentlicher Aspekte eines Systems, darunter:

• Systemstruktur: Komponenten, Subsysteme, deren Aufbau und Beziehungen.
• Schnittstellen: Definition der Punkte, an denen Systeme oder Komponenten interagieren.
• Verbindungen: Darstellung der Kommunikations- und Abhängigkeitspfade zwischen Komponenten.
• Verhalten: Beschreibung der Funktionen, Zustände, Abläufe und Interaktionen des Systems.
• Anforderungen: Verknüpfung der Architekturelemente mit den zugrundeliegenden Anforderungen.

Die Nutzung von NAF im Kontext von MBSE bedeutet, dass diese Beschreibungen nicht primär als textuelle Dokumente, sondern als formale Modelle erstellt werden. Diese Modelle dienen als zentrale Informationsquelle für Kommunikation, Analyse, Verifikation und Validierung während des gesamten Systemlebenszyklus. Die Struktur von NAF bietet dabei den Rahmen, um diese detaillierten Systemmodelle, die oft in Sprachen wie SysML (Systems Modeling Language) erstellt werden (insbesondere bei Verwendung des UAF DMM), zu organisieren und in einen größeren Kontext (z.B. Fähigkeiten, Services) einzuordnen.

Die bevorstehende Verbreitung von SysMLv2 eröffnet hier neue Möglichkeiten: Mit einem formaleren semantischen Kern, einer besseren Unterstützung für Modellabfragen (queries), modularer Modellstruktur und klarerer Semantik ist SysMLv2 besonders gut geeignet, um NAF-Modelle sowohl aus Systems- als auch Architekturperspektive präzise zu realisieren. Besonders in sicherheitskritischen und komplexen SoS-Architekturen kann dies die Traceability und Validierung deutlich verbessern.

NAF erleichtert somit einen strukturierten Entwurfsprozess, der von den operativen Anforderungen und Fähigkeiten bis hin zu detaillierten logischen und physischen Systemspezifikationen reicht und dabei die Nachvollziehbarkeit sicherstellt.

5.2 Modellierung von Systemstrukturen und -verhalten

NAFv4 bietet spezifische Viewpoints zur detaillierten Modellierung von Systemstrukturen und -verhalten, wobei eine klare Trennung zwischen logischer und physischer Sichtweise vorgenommen wird — ein fundamentales Prinzip im SE:

Logische Ebene (L-Viewpoints): Beschreibt was das System tun soll und aus welchen konzeptionellen Komponenten es besteht, unabhängig von der konkreten Implementierung.

• Struktur: L1 (Node Types) definiert logische Knoten oder Komponenten.
• Verbindungen/Interaktionen: L3 (Node Interactions) modelliert die Beziehungen und den Informationsaustausch zwischen logischen Knoten.
• Verhalten:
• L4 (Logical Activities) beschreibt die auszuführenden Aktivitäten oder Funktionen (oft als Aktivitätsdiagramme).
• L5 (Logical States) modelliert die Zustände und Zustandsübergänge des Systems oder seiner Komponenten (oft als Zustandsdiagramme).
• L6 (Logical Sequence) stellt die zeitliche Abfolge von Interaktionen dar (oft als Sequenzdiagramme).
• Daten: L7 (Information Model) definiert die Struktur der ausgetauschten Informationen.
• Randbedingungen: L8 (Logical Constraints) erfasst Regeln, die das logische Design beeinflussen.

Physische Ebene (P-Viewpoints): Beschreibt wie das System implementiert wird, mit welchen konkreten Hard- und Software-Ressourcen.

• Struktur: P1 (Resource Types) und P2 (Resource Structure) definieren die physischen Komponenten und deren Aufbau.
• Verbindungen/Interaktionen: P3 (Resource Connectivity) modelliert die physischen Verbindungen und Schnittstellen.
• Verhalten:
• P4 (Resource Functions) beschreibt die Funktionen, die von den physischen Ressourcen ausgeführt werden.
• P5 (Resource States) modelliert die Zustände der physischen Ressourcen.
• P6 (Resource Sequence) stellt die Interaktionen zwischen physischen Ressourcen dar.
• Daten: P7 (Data Model) definiert das physische Datenmodell.
• Randbedingungen: P8 (Resource Constraints) erfasst physische oder implementierungsspezifische Regeln.

Die Unterstützung verschiedener Verhaltensmodelle (Prozessfluss L4/P4, Zustandsübergänge L5/P5, Interaktionssequenzen L6/P6) ermöglicht eine umfassende Beschreibung und Analyse der Systemdynamik aus unterschiedlichen Perspektiven. Die klare Trennung von Logik und Physik erleichtert die Analyse auf verschiedenen Abstraktionsebenen und unterstützt die systematische Ableitung der physischen Implementierung aus den logischen Anforderungen.

5.3 Integration von Systemkomponenten

Die Integration verschiedener Systemkomponenten, insbesondere in komplexen System-of-Systems (SoS)-Umgebungen, ist eine Kernherausforderung im Verteidigungsbereich. NAF unterstützt diese Integration durch:

• Explizite Modellierung von Schnittstellen und Verbindungen: Viewpoints wie S3 (Service Interfaces), L3 (Node Interactions) und P3 (Resource Connectivity) fokussieren auf die Definition der Interaktionspunkte und Kommunikationswege zwischen Systemen oder Komponenten. Dies ist entscheidend für die Sicherstellung der Interoperabilität, da Komponenten oft unabhängig voneinander entwickelt werden.
• Definition des Informationsaustauschs: Viewpoints im Informationsaspekt (L7, P7, S7) legen fest, welche Daten oder Informationen über die definierten Schnittstellen ausgetauscht werden.
• Strukturierung von SoS-Architekturen: NAF bietet einen Rahmen zur Beschreibung komplexer SoS. Die standardisierte Modellierung von Komponenten, Schnittstellen und Interaktionen auf verschiedenen Ebenen bildet die Grundlage für die Anwendung von SoS Engineering (SoSE)-Prinzipien.
• Unterstützung durch MBSE: Die Anwendung von NAF im MBSE-Kontext fördert die multidisziplinäre Systemintegration, da Modelle als gemeinsame, konsistente Basis für verschiedene Ingenieurdisziplinen dienen.

Der starke Fokus von NAF auf die Definition von Schnittstellen, Interaktionen und Konnektivität ist direkt auf die Notwendigkeit zurückzuführen, die Interoperabilität in multinationalen Koalitionen und komplexen SoS sicherzustellen.

5.4 Relevante NAF-Sichten für SE

Für Systems Engineers sind insbesondere folgende NAFv4-Viewpoints von zentraler Bedeutung:

• Logical Viewpoints (L1-L8, Lr): Bilden den Kern der logischen Systembeschreibung und entsprechen typischen SE-Artefakten wie Blockdiagrammen, Interaktionsdiagrammen und Zustandsmodellen.
• Physical Resource Viewpoints (P1-P8, Pr): Definieren die konkrete technische Umsetzung und sind essenziell für die detaillierte Systemauslegung und Implementierungsplanung.
• Mapping Viewpoints (z.B. L4-P4): Stellen die wichtige Verbindung zwischen der logischen und physischen Ebene her und dokumentieren Designentscheidungen bezüglich der Implementierung von Funktionen.
• Service Viewpoints (insb. S3, S4, S6, S7): Sind besonders relevant bei serviceorientierten Architekturen (SOA) oder wenn der Fokus auf den nach außen angebotenen oder genutzten Diensten eines Systems liegt, um Integration und Interoperabilität zu gewährleisten.

5.5 NAF und Model-Based Systems Engineering (MBSE)

Es besteht eine starke Synergie zwischen NAF und MBSE. NAF liefert den strukturellen Rahmen und definiert, welche Aspekte (Viewpoints) für einen bestimmten Zweck modelliert werden sollen. MBSE, insbesondere unter Verwendung von SysML im Kontext des NAF-konformen UAF DMM, liefert die detaillierte Modellierungssprache und die Techniken, wie diese Aspekte präzise und formal beschrieben werden.

Diese Kombination ermöglicht es, die Vorteile von MBSE im strukturierten Kontext von NAF zu nutzen:

• Zentrale Modellbasis: Modelle ersetzen dokumentenzentrierte Ansätze.
• Verbesserte Kommunikation und Konsistenz: Formale Modelle reduzieren Ambiguität.
• Analyse und Simulation: Formale Modelle können mit Werkzeugen analysiert, simuliert und validiert werden. NAF’s strukturierter Ansatz mit definierten Beziehungen unterstützt automatisierte Kohärenzprüfungen.
• Traceability: Die Verknüpfungen innerhalb der Modelle ermöglichen eine durchgängige Nachverfolgbarkeit.

NAF dient somit als Organisationsstruktur und Anforderungskatalog für die MBSE-Modellierungsaktivitäten, während MBSE die Methoden und Werkzeuge zur Erfüllung der NAF-Anforderungen bereitstellt.

5.6 Verknüpfung NAF Viewpoints mit SE Aktivitäten

Die folgende Tabelle zeigt beispielhaft, wie typische SE-Aktivitäten durch NAFv4-Viewpoints unterstützt werden können:

Orientierungshilfe für Systems Engineers bei der NAF Adaption

6. NAF im Requirements Engineering (RE)

Requirements Engineering (RE) ist der Prozess der Definition, Dokumentation und Verwaltung von Anforderungen. NAF interagiert eng mit RE, indem es einen Rahmen für die Kontextualisierung und Nachverfolgung von Anforderungen innerhalb der System- und Unternehmensarchitektur bietet.

6.1 Unterstützung bei Erfassung und Analyse von Anforderungen

NAF hilft dabei, Benutzeranforderungen, Prozesse und Konzepte in eine übergeordnete Lösungsarchitektur zu überführen, aus der einzelne Projekte abgeleitet werden können. Es unterstützt die frühen Phasen des RE durch:

• Kontextualisierung: Die Concept Viewpoints (C-Views) erfassen den strategischen und operativen Kontext, aus dem Anforderungen entstehen. C2 (Enterprise Vision) definiert übergeordnete Ziele, C5 (Effects) beschreibt die gewünschten Ergebnisse oder Wirkungen, die oft direkt Anforderungen entsprechen oder diese ableiten lassen, und C1 (Capability Taxonomy) strukturiert die benötigten Fähigkeiten.
• Identifikation von Treibern: Die NAF-Methodik beinhaltet die explizite Verwaltung von Motivationselementen wie Zielen, Anforderungen und Standards.
• Erfassung von Randbedingungen: C8 (Planning Assumptions/Constraints) sowie L8/P8 (Logical/Physical Constraints) und S8 (Service Policy) ermöglichen die Dokumentation von Regeln und Einschränkungen, die Anforderungen beeinflussen.
• Definition von Qualitätsmerkmalen: C7 (Performance Parameters) hilft bei der Spezifikation messbarer Leistungsanforderungen.

Beispiel für die Ableitung Funktionaler und Nichtfunktionaler Forderungen aus Auflagen, Vorgaben und Rahmenbedingungen (Quelle: 1)

Obwohl NAF diese Mechanismen zur Erfassung des Anforderungskontexts bietet, enthält das Standard-NAFv4-Framework keine dedizierten Diagrammtypen spezifisch für die detaillierte Anforderungsspezifikation (wie z.B. Use Case Diagramme oder Anforderungshierarchien). Solche Sichten werden oft durch nationale Erweiterungen hinzugefügt. Die Stärke von NAF liegt daher weniger in der primären Anforderungsdefinition als vielmehr in der Integration und Nachverfolgung von (oft extern definierten) Anforderungen im Architekturkontext. Der strukturierte Ansatz von NAF (und seinen Verwandten wie MODAF) bringt jedoch eine gewisse Rigorosität in den Anforderungserfassungsprozess, indem er zur systematischen Analyse zwingt.

6.2 Verwaltung und Nachverfolgung von Anforderungen im NAF-Kontext

Die Nachverfolgbarkeit von Anforderungen („Requirements Traceability“) ist entscheidend, um sicherzustellen, dass alle Anforderungen im Systemdesign berücksichtigt, implementiert und getestet werden. NAF unterstützt dies maßgeblich durch seine modellbasierte Natur:

• Verknüpfung über Modellbeziehungen: Die in den NAF-Metamodellen (ArchiMate oder UAF DMM) definierten Beziehungen zwischen Architekturelementen bilden die Grundlage für die Traceability. Anforderungen (als Objekte im Modell repräsentiert, ggf. durch Erweiterungen) können mit Fähigkeiten (C1), Effekten (C5), Services (S1), logischen Aktivitäten (L4), physischen Funktionen (P4) usw. verknüpft werden. Dadurch entsteht eine nachvollziehbare Kette von der Anforderung bis zur Implementierung.13
• Unterstützung durch MBSE: Die Anwendung von NAF im MBSE-Kontext mit entsprechenden Werkzeugen erleichtert die Erstellung, Verwaltung und Analyse dieser Trace-Links erheblich.
• Integration ins Lifecycle Management: Die NAF-Methodik sieht Phasen für die Verwaltung von Motivationselementen (MD) und Architekturänderungen (AC) vor. Dies ermöglicht die Integration von RE-Prozessen wie Anforderungs-Baselining, Änderungsmanagement und Auswirkungsanalyse in den Gesamtprozess. So wird sichergestellt, dass Änderungen an Anforderungen im Architekturkontext bewertet werden und umgekehrt.

6.3 Relevante NAF-Sichten und Prozesse für RE

Für Requirements Engineers sind folgende Teile des NAFv4 besonders relevant:

• Concept Viewpoints (C1-C8, Cr): Diese bilden die primäre Schnittstelle zum RE, da sie die strategischen Ziele, benötigten Fähigkeiten, gewünschten Effekte, Randbedingungen und Leistungsanforderungen erfassen, die die Grundlage für detaillierte Anforderungen bilden.
• Service Viewpoints (insb. S1, S8): Definieren die benötigten Services und die dazugehörigen Regeln oder Policies.
• Mapping Viewpoints (insb. C1-S1): Zeigen explizit die Verbindung zwischen Fähigkeiten und den Services auf, die zu ihrer Realisierung benötigt werden.
• Architecture Foundation Viewpoints (insb. A1, A8): Erfassen Metadaten, Definitionen und anzuwendende Standards, die auch für Anforderungen relevant sind.
• Methodik-Phasen (MD, AV, AC): Dies sind die Phasen im Architekturprozess, in denen die Interaktion mit dem RE am intensivsten ist (Definition der Motivation, Abgleich der Vision, Management von Änderungen).
• Nationale Erweiterungen: Spezifische Anforderungssichten, falls von der anwendenden Nation definiert.

Für eine effektive Nachverfolgbarkeit müssen Requirements Engineers nicht nur die C-Views verstehen, sondern auch nachvollziehen können, wie diese über Mappings und Beziehungen im Metamodell mit den Elementen der Service-, Logik- und Physik-Ebene verbunden sind. Nur so kann sichergestellt werden, dass Anforderungen korrekt durch alle Architekturschichten hindurch bis zur Implementierung verfolgt und validiert werden können.

7. Traceability im NAF: Bedeutung und Herausforderungen

Nachverfolgbarkeit (Traceability) ist die Fähigkeit, Beziehungen zwischen verschiedenen Artefakten im Entwicklungs- und Betriebszyklus eines Systems herzustellen und zu verfolgen. Im Kontext von NAF bedeutet dies typischerweise die Verknüpfung von Anforderungen, Fähigkeiten, Architekturelementen (Services, logische/physische Komponenten, Schnittstellen), Testfällen und anderen relevanten Informationen.

7.1 Definition und Wichtigkeit der Nachverfolgbarkeit in komplexen Verteidigungssystemen (System-of-Systems)

Traceability ist die Fähigkeit, den Ursprung, die Entwicklung und den Status von Anforderungen und anderen Artefakten über den gesamten Lebenszyklus hinweg nachzuvollziehen. Sie stellt sicher, dass eine klare Verbindung zwischen dem ursprünglichen Bedarf und der finalen Implementierung besteht.

In komplexen Verteidigungssystemen, die oft als System-of-Systems (SoS) konzipiert sind — also als Verbund unabhängiger, aber kooperierender Systeme — ist Traceability von überragender Bedeutung. Die Gründe hierfür sind vielfältig:

• Komplexitätsmanagement: SoS zeichnen sich durch eine hohe Anzahl von Komponenten, Schnittstellen und Interaktionen aus. Traceability hilft, diese Komplexität beherrschbar zu machen, indem Abhängigkeiten explizit gemacht werden.
• Sicherstellung der Missionserfüllung: Es muss nachgewiesen werden, dass die Kombination der Einzelsysteme die übergeordneten militärischen Fähigkeiten und Missionsziele erfüllt. Traceability von Fähigkeiten zu Systemfunktionen ist hierfür unerlässlich.
• Interoperabilität: Die Fähigkeit von Systemen verschiedener Hersteller oder Nationen zur Zusammenarbeit hängt von klar definierten und nachvollziehbaren Schnittstellen und Interaktionen ab.
• Verifikation und Validierung (V&V): Traceability ist die Grundlage für V&V. Es muss gezeigt werden, dass jede Anforderung durch Designelemente adressiert und durch Tests überprüft wird.
• Änderungsmanagement und Auswirkungsanalyse: Bei Änderungen an einem Teil des Systems (z.B. einer Anforderung oder Komponente) ermöglicht Traceability die Identifikation aller betroffenen anderen Teile. Dies ist entscheidend für die Bewertung der Auswirkungen und die sichere Durchführung von Änderungen in komplexen, vernetzten Umgebungen. Ohne Traceability sind Änderungen riskant, zeitaufwendig und fehleranfällig.
• Risikomanagement: Durch die Nachverfolgung von Anforderungen zu Risiken und mitigierenden Maßnahmen können potenzielle Schwachstellen frühzeitig erkannt und adressiert werden.
• Compliance und Nachweisführung: Im regulierten Verteidigungsbereich ist der Nachweis, dass alle Anforderungen und Standards erfüllt wurden, zwingend erforderlich. Traceability liefert die dafür notwendige Dokumentation.
• Kommunikation und Verständnis: Traceability verbessert das gemeinsame Verständnis der Zusammenhänge im System bei allen Beteiligten.

Die hohe Vernetzung, die Unabhängigkeit der konstituierenden Systeme und das oft emergente Verhalten von SoS machen eine manuelle Nachverfolgung praktisch unmöglich und unterstreichen die Notwendigkeit modellbasierter Ansätze wie NAF in Verbindung mit leistungsfähigen Werkzeugen.

7.2 Herausforderungen der Traceability im NAF

Trotz der klaren Notwendigkeit ist die Umsetzung und Aufrechterhaltung umfassender Traceability im Kontext von NAF mit erheblichen Herausforderungen verbunden:

• Skalierbarkeit und Komplexität: Die schiere Menge an Architekturelementen (Anforderungen, Fähigkeiten, Services, logische/physische Komponenten, Schnittstellen etc.) und deren Beziehungen in großen Verteidigungsprojekten ist enorm. Die manuelle Verwaltung dieser Links ist nicht praktikabel.
• Konsistenz über Sichten und Ebenen: Informationen über ein bestimmtes Element können in verschiedenen NAF-Views und auf unterschiedlichen Abstraktionsebenen dargestellt werden. Die Sicherstellung der Konsistenz dieser Informationen und der dazugehörigen Trace-Links ist schwierig, insbesondere wenn verschiedene Teams oder Werkzeuge beteiligt sind. Semantische Unklarheiten oder unterschiedliche Detaillierungsgrade können die Konsistenzprüfung erschweren.
• Heterogenität der Artefakte: Traceability muss oft über verschiedene Arten von Artefakten hinweg etabliert werden, z.B. von textuellen Anforderungen in einem RE-Tool zu grafischen Modellen in einem MBSE-Tool (NAF/UAF/SysML), zu Code, zu Testfällen in einem Testmanagement-Tool. Die Integration dieser heterogenen Datenquellen ist komplex.
• Werkzeugunterstützung und Interoperabilität: Effektive Traceability erfordert leistungsfähige Werkzeuge, die das Definieren, Speichern, Verwalten, Visualisieren und Abfragen von Trace-Links unterstützen. Oft werden jedoch verschiedene Werkzeuge von unterschiedlichen Teams oder Organisationen eingesetzt. Die Interoperabilität zwischen diesen Werkzeugen ist eine häufige Hürde. Selbst innerhalb von NAFv4 kann die Verwendung unterschiedlicher Metamodelle (ArchiMate vs. UAF) zu Kompatibilitätsproblemen führen, wenn keine geeigneten Austauschmechanismen vorhanden sind.
• Prozessdisziplin und Aufwand: Das Erstellen und Pflegen von Trace-Links erfordert disziplinierte Prozesse über den gesamten Lebenszyklus. Es kann als zusätzlicher Aufwand wahrgenommen werden, dessen Nutzen nicht immer sofort ersichtlich ist. Die in NAFv3 beobachtete inkonsistente Anwendung deutet darauf hin, dass die Etablierung der notwendigen Prozesse und Disziplin eine Herausforderung darstellt.
• Dynamik und Evolution: Architekturen und Anforderungen ändern sich im Laufe der Zeit. Die Trace-Links müssen kontinuierlich aktualisiert werden, um korrekt zu bleiben, was einen erheblichen Wartungsaufwand bedeutet.

Diese Herausforderungen verdeutlichen, dass die Einführung von NAF allein keine Garantie für gute Traceability ist. Es bedarf vielmehr einer Kombination aus dem Framework, geeigneten Werkzeugen, klar definierten Prozessen und der notwendigen organisatorischen Disziplin.

Die Traceability-Problematik über mehrere Schichten hinweg kann durch SysMLv2 deutlich entschärft werden, da das neue Metamodell explizite Unterstützung für Anforderungen, Beziehungsdefinitionen und Querverweise enthält. In Verbindung mit dem NAF-konformen Metamodell (z. B. UAF) lassen sich Traceability-Links zwischen Anforderungen, Funktionen, Komponenten und Tests deutlich robuster definieren und automatisiert verarbeiten.

Und auch fortschrittliche Technologien wie Graphendatenbanken und Embeddings bieten neue Lösungsansätze, um die Traceability zu verbessern.

8. Graphendatenbanken und Embeddings zur Verbesserung der NAF-Traceability

Die inhärente Komplexität und die Herausforderungen der Traceability in NAF-basierten Architekturen, insbesondere in SoS-Kontexten, erfordern fortschrittliche technologische Unterstützung. Graphendatenbanken und Embedding-Techniken bieten vielversprechende Ansätze, um die Modellierung, Analyse und Verwaltung von Beziehungen zwischen NAF-Artefakten zu verbessern.

8.1 Rolle von Graphendatenbanken für die Modellierung von NAF-Beziehungen

NAF-Architekturen, insbesondere wenn sie modellbasiert mit Metamodellen wie ArchiMate oder UAF DMM erstellt werden, beschreiben eine Vielzahl von Elementen (Capabilities, Services, Nodes, Resources, Requirements etc.) und die komplexen Beziehungen zwischen ihnen (z.B. realisiert, hängt ab von, tauscht aus mit, ist Teil von). Diese Struktur aus Knoten (Elementen) und Kanten (Beziehungen) entspricht nativ einem Graphen.

Traditionelle relationale Datenbanken sind oft nicht optimal für die Speicherung und Abfrage solch hochgradig vernetzter Daten geeignet. Graphendatenbanken hingegen sind speziell dafür konzipiert, Daten als Graphen zu speichern und komplexe Beziehungsabfragen effizient auszuführen. Ihre Anwendung im NAF-Kontext bietet mehrere Vorteile:

• Natürliche Repräsentation: Das NAF-Metamodell und die daraus instanziierten Architekturen lassen sich direkt als Graph abbilden, wobei NAF-Elemente zu Knoten und NAF-Beziehungen zu Kanten werden. Dies vermeidet umständliche Tabellen-Joins, die in relationalen Datenbanken für Beziehungsabfragen nötig wären.
• Effiziente Beziehungsabfragen: Graphendatenbanken ermöglichen schnelle Abfragen über beliebig viele Beziehungsschritte (Multi-Hop-Queries). Dies ist ideal für Traceability-Analysen, z.B. um alle physischen Ressourcen zu finden, die zur Realisierung einer bestimmten Fähigkeit beitragen, auch wenn die Verbindung über mehrere Zwischenelemente (Services, logische Knoten) verläuft.
• Flexible Schema-Entwicklung: Graphendatenbanken sind oft schema-flexibler als relationale Datenbanken, was die Integration verschiedener Sichten und die Weiterentwicklung des Architekturmodells erleichtern kann.
• Visualisierung und Exploration: Die Graphstruktur eignet sich gut für intuitive Visualisierungen der Architekturzusammenhänge, was die Exploration und das Verständnis komplexer Abhängigkeiten unterstützt.
• Analyse von Mustern und Strukturen: Graphalgorithmen (z.B. Pfadfindung, Zentralitätsanalyse, Community Detection) können direkt auf der Datenbank ausgeführt werden, um strukturelle Muster, Abhängigkeiten, potenzielle Schwachstellen (z.B. Single Points of Failure) oder Inkonsistenzen in der Architektur aufzudecken.

Durch die Nutzung einer Graphendatenbank als zentrales Repository für NAF-Architekturdaten (möglicherweise gespeist aus verschiedenen Modellierungswerkzeugen) kann eine leistungsfähige Basis für umfassende Traceability-Analysen und Architektureinsichten geschaffen werden. Konzepte wie Knowledge Graphs, die strukturierte Informationen in Graphform repräsentieren, sind hier direkt anwendbar.

8.2 Rolle von Embeddings für semantische Analyse und Suche

Während Graphendatenbanken die expliziten Beziehungen im NAF-Modell abbilden, können Embedding-Techniken helfen, implizite oder semantische Beziehungen zwischen Artefakten aufzudecken.

Embeddings repräsentieren Objekte — wie Begriffe, Dokumente, Anforderungen — als dichte Vektoren in einem hochdimensionalen Vektorraum. In diesem Raum spiegelt die räumliche Nähe der Vektoren die semantische Ähnlichkeit der zugrunde liegenden Objekte wider: Je ähnlicher zwei Artefakte inhaltlich sind, desto näher liegen ihre Vektoren beieinander.

Im NAF-Kontext können Embeddings auf verschiedene Arten eingesetzt werden:

• Text-Embeddings: Viele NAF-Artefakte enthalten textuelle Beschreibungen (z.B. Namen, Definitionen von Capabilities, Beschreibungen von Services oder Requirements). Text-Embedding-Modelle können diese Texte in Vektoren umwandeln.
• Semantische Suche: Anstatt nach exakten Schlüsselwörtern zu suchen, können Benutzer semantisch ähnliche Artefakte finden. Beispielsweise könnte eine Suche nach “Luftüberwachung” auch Capabilities oder Services finden, die als “Air Surveillance” oder “Radaraufklärung” beschrieben sind, obwohl die Worte nicht identisch sind.
• Identifikation von Duplikaten/Überlappungen: Ähnliche Vektoren können auf potenziell redundante oder überlappende Capabilities, Services oder Anforderungen hinweisen, die möglicherweise konsolidiert werden könnten.
• Anforderungsanalyse: Ähnlichkeitsanalysen können helfen, Gruppen von zusammengehörigen Anforderungen zu identifizieren oder Inkonsistenzen aufzudecken.

3D-Visualisierung konvexer Hüllen (Convex Hulls), mit Ausreißerbetrachtung

Graph-Embeddings: Diese Techniken lernen Vektorrepräsentationen für Knoten und/oder Kanten in einem Graphen, basierend auf der Graphstruktur (z.B. Nachbarschaft, Pfade). Angewendet auf den NAF-Architektur-Graphen, können Graph-Embeddings:

• Strukturelle Ähnlichkeit finden: Knoten (NAF-Elemente) mit ähnlichen Rollen oder Verbindungsmustern in der Architektur können identifiziert werden, auch wenn sie in unterschiedlichen Teilen des Modells liegen.
• Link Prediction: Vorhersage potenziell fehlender Beziehungen zwischen NAF-Elementen basierend auf gelernten Mustern im Graphen. Dies kann helfen, Lücken in der Traceability zu identifizieren.
• Anomalieerkennung: Knoten oder Beziehungen mit ungewöhnlichen Embedding-Vektoren (im Vergleich zu ähnlichen Elementen) könnten auf Modellierungsfehler oder interessante architektonische Muster hinweisen.

8.3 Verbesserte Traceability durch Kombination

Die Kombination von Graphendatenbanken und Embeddings bietet ein leistungsfähiges Instrumentarium zur Verbesserung der Traceability in NAF:

• Explizite und implizite Links: Graphendatenbanken verwalten die explizit modellierten Trace-Links. Embeddings ermöglichen die Entdeckung impliziter, semantischer Beziehungen, die über die expliziten Links hinausgehen.
• Kontextsensitive Suche: Die Suche nach relevanten Artefakten kann sowohl die explizite Struktur (via Graph-Queries) als auch die semantische Ähnlichkeit (via Embedding-Vergleich) berücksichtigen.
• Umfassende Auswirkungsanalyse: Bei einer Änderung kann die Auswirkungsanalyse sowohl expliziten Links im Graphen folgen als auch semantisch ähnliche, potenziell ebenfalls betroffene Artefakte identifizieren.
• Konsistenzprüfung: Inkonsistenzen können nicht nur durch strukturelle Prüfungen im Graphen, sondern auch durch semantische Analysen (z.B. widersprüchliche Beschreibungen verbundener Elemente) aufgedeckt werden.
• Automatisierung: Diese Techniken ermöglichen einen höheren Grad an Automatisierung bei der Analyse und Verwaltung der Traceability-Informationen, was angesichts der Komplexität von NAF-Architekturen unerlässlich ist.

Die Anwendung dieser Techniken kann dazu beitragen, die Herausforderungen der Traceability in NAF zu überwinden und tiefere Einblicke in die komplexen Zusammenhänge von Verteidigungsarchitekturen zu gewinnen.

Für eine leistungsfähige semantische Analyse und Modellanreicherung können auch Open Data aus öffentlichen Quellen wie dem EU Open Data Portal (https://data.europa.eu/) verwendet werden. So lassen sich z. B. Umweltdaten, Bevölkerungsstatistiken oder Infrastrukturinformationen in Form von semantischen Vektoren integrieren. Dies verbessert nicht nur die Kontextualisierung von Architekturelementen, sondern erlaubt auch die Ableitung potenzieller Wechselwirkungen oder Risiken auf Basis externer Faktenlage. Durch die Anbindung an die EU Open Data Plattform lassen sich künftig auch sich verändernde Rahmenbedingungen und neue regulatorische Anforderungen dynamisch in die semantische Analyse integrieren — für eine zukunftsfähige, faktenbasierte Architekturentwicklung.

Quellen:

1. So funktioniert die Methode Architektur

https://www.bundeswehr.de/resource/blob/5572722/861aec24e980bb717e254fb2e16f4e42/grundlagen-methode-architektur-nach-nafv4-en-data.pdf

2. NATO — NATO Architecture Framework, Version 4