Die operative Sicht ( OV ) ist eine der grundlegenden Sichten, die in der Unternehmensarchitektur (EA) des Department of Defense Architecture Framework V1.5 (DoDAF) definiert sind und mit dem Einsatzkonzept in Zusammenhang stehen . Unter DODAF 2, das 2009 in Betrieb genommen wurde, werden die Sammlungen von Sichten nun als „Sichtpunkte“ und nicht mehr als Sichten bezeichnet.
Andere Enterprise-Architektur-Frameworks verfügen möglicherweise über operative Sichten. Beispielsweise besitzt das MODAF eine operative Sichtweise, und das NATO-Architektur-Framework enthält eine operative Sicht (eine Sammlung von Untersichten). Dieser Artikel erläutert den Aufbau der operativen Sicht des DoDAF V1.5 genauer.
Überblick
Die „operative Sicht“ (OV) im DoDAF- Unternehmensarchitektur-Framework (Version 1/1.5) („operativer Standpunkt“ in DODAF 2) beschreibt die Aufgaben und Aktivitäten, operativen Elemente und den Informationsaustausch, die zur Durchführung von Operationen erforderlich sind. Eine reine operative Sicht ist materialunabhängig. Operationen und ihre Beziehungen können jedoch durch neue Technologien wie Kollaborationstechnologien beeinflusst werden, wobei Prozessverbesserungen bereits in der Praxis umgesetzt werden, bevor Richtlinien die neuen Verfahren widerspiegeln können. [ 1 ]
Die operative Sichtweise ermöglicht es, den Bedarf lösungs- oder implementierungsfrei zu beschreiben. In manchen Fällen ist es jedoch notwendig, die Durchführung von Prozessen unter Berücksichtigung der Einschränkungen bestehender Systeme zu dokumentieren, um zu untersuchen, wie neue Systeme die Prozesse optimieren könnten. In solchen Fällen kann die operative Sichtweise wesentliche Einschränkungen und Anforderungen beinhalten, die berücksichtigt werden müssen. Daher kann es erforderlich sein, Architekturdaten der Systemsicht (SV) als Overlays oder ergänzende Informationen in die Produkte der operativen Sichtweise einzubinden. [ 1 ]
Themen der operativen Sicht
DoDAF
Das Architekturframework des US-Verteidigungsministeriums (DoDAF) definiert einen Standard zur Organisation einer Systemarchitektur in komplementäre und konsistente Sichten. Es eignet sich besonders für große Systeme mit komplexen Integrations- und Interoperabilitätsherausforderungen und ist offenbar einzigartig in seiner Verwendung von „operativen Sichten“, die den Betriebsbereich des externen Kunden detailliert beschreiben, in dem das entwickelte System eingesetzt werden soll.
Das DoDAF definiert eine Reihe von Produkten, die als Mechanismen zur Visualisierung, zum Verständnis und zur Aneignung des breiten Spektrums und der Komplexität einer Architekturbeschreibung mittels grafischer, tabellarischer oder textueller Mittel dienen. Diese Produkte sind in vier Ansichten unterteilt:
- Übergreifende Gesamtansicht (AV),
- Operative Sicht (OV),
- Systems View (SV) und die
- Technische Normenansicht (TV).
Jede Ansicht stellt bestimmte Perspektiven einer Architektur dar, wie nachfolgend beschrieben. Für jede Systementwicklung wird üblicherweise nur eine Teilmenge des vollständigen DoDAF-Ansichtssatzes erstellt. Die Abbildung veranschaulicht die Informationen, die die operative Ansicht, die System- und Serviceansicht sowie die technische Standardansicht miteinander verknüpfen. Die drei Ansichten und ihre – durch gemeinsame Architekturdatenelemente – Wechselbeziehungen bilden die Grundlage für die Ableitung von Kennzahlen wie Interoperabilität oder Leistung sowie für die Messung der Auswirkungen dieser Kennzahlen auf die Effektivität von operativen Missionen und Aufgaben. [ 2 ]
OV-Produkte
Das Department of Defense Architecture Framework (DoDAF) definiert sieben verschiedene Arten von Operational View-Produkten. [ 1 ] In diesem Abschnitt werden sieben OV-Produkte beschrieben:
- Grafik zum übergeordneten operativen Konzept (OV-1)
- Beschreibung der Konnektivität operativer Knoten (Ressourcenfluss) (OV-2)
- Matrix zum Austausch operativer Informationen (Ressourcenfluss) (OV-3)
- Organigramm (OV-4)
- Operatives Aktivitätsmodell (OV-5)
- Betriebsregelnmodell, Zustandsübergangsbeschreibung und Ereignisablaufbeschreibung (OV-6a, 6b und 6c)
- Logisches Datenmodell (OV-7)
Grafik zum übergeordneten operativen Konzept
DoD Electronic Commerce Concept of Operations (OV-1).
Grafik zum operativen Konzept der gemeinsamen netzwerkfähigen Waffensysteme (NEW) (OV-1).
Gemeinsames Einsatzkonzept der Task Force (OV-1).
Beispiel OV-1 für NCOW.
- Grafische Darstellung des operativen Konzepts auf hoher Ebene (OV-1): Grafische und textliche Beschreibung des operativen Konzepts auf hoher Ebene (Organisationen auf hoher Ebene, Aufgaben, geografische Konfiguration, Vernetzung usw.).
Beschreibung der Konnektivität von Betriebsknoten
OV-2-Vorlage.
Beispiel eines OV-2-Formulars zur Darstellung von Dienstleistern.
UML OV-2 Vorlage.
- Beschreibung der Konnektivität operativer Knoten (OV-2): Operative Knoten, an jedem Knoten durchgeführte Aktivitäten sowie Konnektivitäten und Informationsfluss zwischen den Knoten.
Matrix für den Austausch operativer Informationen
OV-3 – Vorlage.
- Operational Information Exchange Matrix (OV-3): Informationen, die zwischen Knoten ausgetauscht werden, und die relevanten Attribute dieses Austauschs wie Medium, Qualität, Quantität und der erforderliche Grad an Interoperabilität.
Organigramm
OV-4 – Vorlage.
UML OV-4 Beispiel.
- Organigramm (OV-4): Befehls-, Kontroll-, Koordinations- und sonstige Beziehungen zwischen Organisationen.
Operatives Aktivitätsmodell
Organigramm der operativen Aktivitäten (OV-5) – Vorlage.
Operatives Aktivitätsdiagramm (OV-5) – Vorlage.
OV-5 – Vorlage mit fiktiven Anmerkungen.
UML-Beispiel OV-5.
- Operatives Aktivitätsmodell (OV-5): Aktivitäten, Beziehungen zwischen Aktivitäten, Inputs und Outputs. Zusätzlich können Overlays Kosten, Leistungsknoten oder andere relevante Informationen anzeigen.
Andere OV-Produkte
- Betriebsregelnmodell, Zustandsübergangsbeschreibung und Ereignisablaufbeschreibung (OV-6a, 6b und 6c)
- Operatives Regelmodell (OV-6a): Eines der drei Produkte, die zur Beschreibung der Abfolge und des Zeitpunkts operativer Aktivitäten verwendet werden und die Geschäftsregeln identifizieren, die den Betrieb einschränken.
- Beschreibung des Übergangs in den Betriebszustand (OV-6b): Eines der drei Produkte, die zur Beschreibung der Abfolge und des Zeitpunkts von Betriebsaktivitäten verwendet werden und die Reaktionen eines Geschäftsprozesses auf Ereignisse identifizieren.
- Operational Event-Trace Description (OV-6c): Eines der drei Produkte, die zur Beschreibung der Abfolge und des Zeitpunkts von Betriebsaktivitäten verwendet werden und die Aktionen in einem Szenario oder einer kritischen Ereignissequenz nachverfolgen.
- Logisches Datenmodell (OV-7): Dokumentation der Datenanforderungen und strukturellen Geschäftsprozessregeln der operativen Sicht.
Ausführbare Betriebsarchitektur
Neben der Untersuchung des Verhaltens im Zeitverlauf lassen sich auch die gesamten dynamischen Missionskosten im Zeitverlauf hinsichtlich der Kosten für Personal- und System-/Netzwerkressourcen sowie deren Prozesse bewerten. Die Kostenanalyse in ausführbaren Architekturen ist ein erster Schritt in einer architekturbasierten Investitionsstrategie. Ziel ist es, Architekturen an Finanzierungsentscheidungen auszurichten, um sicherzustellen, dass Investitionsentscheidungen direkt mit den Missionszielen und deren Ergebnissen verknüpft sind. Die Abbildung rechts veranschaulicht den Aufbau eines solchen dynamischen Modells. [ 1 ]
Zustandsübergänge in ausführbaren Architekturmodellen beschreiben Bedingungen, die das Verhalten von Prozessereignissen bei der Reaktion auf Eingaben und der Erzeugung von Ausgaben steuern. Ein Zustand legt die Reaktion eines Prozesses auf Ereignisse fest. Diese Reaktion kann je nach aktuellem Zustand und den geltenden Regeln oder Bedingungen variieren. Verteilungseinstellungen bestimmen die Ausführungszeit von Prozessen. Beispiele für Verteilungsstrategien sind: konstante Werte, Ereignisliste, konstanter Intervallabstand, Normalverteilung , Exponentialverteilung usw. Die Priorität bestimmt die Verarbeitungsstrategie, wenn zwei Eingaben gleichzeitig einen Prozess erreichen. Eingaben mit höherer Priorität werden in der Regel vor Eingaben mit niedrigerer Priorität verarbeitet. [ 1 ]
Prozesse, die mehrere Eingaben erhalten, müssen definieren, wie sie reagieren. Beispiele für Reaktionen sind: die Eingaben unabhängig voneinander in der Reihenfolge ihres Eintreffens verarbeiten, erst verarbeiten, wenn alle Eingaben verfügbar sind, oder sofort nach Erkennung einer Eingabe verarbeiten. Prozesse, die mehrere Ausgaben erzeugen, können Wahrscheinlichkeiten (insgesamt 100 Prozent) enthalten, unter denen jede Ausgabe erzeugt wird. Histogramme sind Beispiele für generierte Zeitbeschreibungen. Sie stellen Prozesse, menschliche und Systemressourcen sowie deren Auslastung im Zeitverlauf während einer Simulation grafisch dar. Diese Histogramme werden verwendet, um dynamische Wirkungsanalysen des Verhaltens der ausführbaren Architektur durchzuführen. Abbildung 4-23 zeigt beispielhaft die Ergebnisse einer Simulation der Personalressourcenkapazität. [ 1 ]
