Department of Defense Architecture Framework

DoD Architecture Framework v1.5.
DoDAF Architecture Framework Version 2.0

Department of Defense Architecture Framework ( DoDAF ) är ett arkitekturramverk för USA:s försvarsdepartement (DoD) som tillhandahåller visualiseringsinfrastruktur för specifika intressenters problem genom synpunkter organiserade av olika åsikter . Dessa vyer är artefakter för att visualisera, förstå och assimilera den breda omfattningen och komplexiteten i en arkitekturbeskrivning genom tabellform , strukturell , beteendemässig , ontologisk , bildlig , tidsmässig , grafisk , probabilistisk eller alternativa konceptuella medel. Den nuvarande versionen är DoDAF 2.02.

Detta arkitekturramverk är speciellt lämpat för stora system med komplexa integrations- och interoperabilitetsutmaningar, och det är uppenbarligen unikt i sin användning av "operativa vyer". Dessa vyer erbjuder överblick och detaljer riktade till specifika intressenter inom deras domän och i samverkan med andra domäner där systemet kommer att fungera.

Översikt

DoDAF tillhandahåller en grundläggande ram för att utveckla och representera arkitekturbeskrivningar som säkerställer en gemensam nämnare för att förstå, jämföra och integrera arkitekturer över organisatoriska, gemensamma och multinationella gränser. Den upprättar dataelementdefinitioner, regler och relationer och en baslinje med produkter för konsekvent utveckling av system, integrerade eller federerade arkitekturer. Dessa arkitekturbeskrivningar kan inkludera familjer av system (FoS), system av system (SoS) och nätcentrerade möjligheter för samverkan och interaktion i icke-stridsmiljön.

DoD-komponenter förväntas överensstämma med DoDAF i största möjliga utsträckning vid utveckling av arkitekturer inom avdelningen. Överensstämmelse säkerställer att återanvändning av information, arkitekturartefakter, modeller och synpunkter kan delas med gemensam förståelse. Alla större amerikanska DoD-vapen- och IT-systemförvärv krävs för att utveckla och dokumentera en företagsarkitektur (EA) med hjälp av de synpunkter som föreskrivs i DoDAF. Även om det tydligt är inriktat på militära system, har DoDAF bred tillämpbarhet inom den privata, offentliga och frivilliga sektorn runt om i världen, och representerar ett av ett stort antal systemarkitekturramar .

  • Syftet med DoDAF är att definiera koncept och modeller som är användbara i DoDs sex kärnprocesser:
    1. Joint Capabilities Integration and Development (JCIDS)
    2. Planering, programmering, budgetering och genomförande (PPBE)
    3. Defense Acquisition System (DAS)
    4. Systemteknik (SE)
    5. Verksamhetsplanering (OPLAN)
    6. Capability Portfolio Management (CPM)
  • Dessutom var DoDAF 2.0:s specifika mål att:
    1. Upprätta vägledning för arkitekturinnehåll som funktion av syfte - "passar för ändamålet"
    2. Öka användbarheten och effektiviteten hos arkitekturer via en rigorös datamodell – DoDAF Meta Model (DM2) – så att arkitekturerna kan integreras, analyseras och utvärderas med mer precision.

Historia

Utvecklingen av DoDAF sedan 1990-talet. DoDAF V2.0 släpptes i maj 2009.

Den första versionen av utvecklingen DoDAF utvecklades på 1990-talet under namnet C4ISR Architecture Framework. Under samma period vidareutvecklades referensmodellen TAFIM , som initierades 1986. Det första C4ISR Architecture Framework v1.0, släppt den 7 juni 1996, skapades som svar på antagandet av Clinger-Cohen Act . Den tog upp 1995 års biträdande försvarsministerdirektiv om att en DoD-omfattande ansträngning skulle göras för att definiera och utveckla ett bättre sätt och en process för att säkerställa att C4ISR-kapaciteten var interoperabel och mötte krigsfighters behov. Fortsatt utvecklingsarbete resulterade i december 1997 i den andra versionen, C4ISR Architecture Framework v2.0.

I augusti 2003 släpptes DoDAF v1.0, som omstrukturerade C4ISR Framework v2.0 för att erbjuda vägledning, produktbeskrivningar och kompletterande information i två volymer och en skrivbordsbok. Det breddade tillämpbarheten av arkitekturens grundsatser och praxis till alla uppdragsområden snarare än bara C4ISR-gemenskapen. Detta dokument behandlade användning, integrerade arkitekturer, DoD och federala policyer, värdet av arkitekturer, arkitekturåtgärder, DoD-beslutsstödsprocesser, utvecklingstekniker, analytiska tekniker och CADM v1.01, och rörde sig mot ett förvarsbaserat tillvägagångssätt genom att lägga tonvikt på arkitekturdataelement som innefattar arkitekturprodukter. I februari 2004 släpptes dokumentationen för version 1.0 med volym "I: Definitioner och riktlinjer", "II: Produktbeskrivningar" och en "Deskbook". I april 2007 släpptes version 1.5 med en dokumentation av "Definitioner och riktlinjer", "Produktbeskrivningar" och "Arkitekturdatabeskrivning".

Den 28 maj 2009 godkändes DoDAF v2.0 av försvarsdepartementet. Den nuvarande versionen är DoDAF 2.02. DoDAF V2.0 publiceras på en offentlig webbplats.

Andra härledda ramverk baserade på DoDAF inkluderar NATO Architecture Framework (NAF) och Ministry of Defense Architecture Framework . Liksom andra EA-metoder, till exempel The Open Group Architecture Framework (TOGAF), är DoDAF organiserat kring ett delat arkiv för att hålla arbetsprodukter. Förvaret definieras av det gemensamma databasschemat Core Architecture Data Model 2.0 och DoD Architecture Registry System (DARS). En nyckelfunktion i DoDAF är interoperabilitet, som är organiserad som en serie nivåer, kallade Levels of Information System Interoperability (LISI). Utvecklingssystemet måste inte bara tillgodose sina interna databehov utan även behoven i det operativa ramverk som det är satt in i.

Förmåga och uppdrag

Se diagrammet för en skildring av kapacitetsbetoningen, kopplad till uppdrag/handlingsförlopp, trådar, aktiviteter och arkitekturer.

Förmåga som beskrivs med arkitekturer

DoD har rört sig mot ett fokus på leverans av kapacitet, vilket är anledningen till att skapa systemet/tjänsten. Kapacitetsmodellerna beskriver förmågans taxonomi och förmågans utveckling. En kapacitetstråd skulle likställas med de specifika aktiviteterna, reglerna och systemen som är kopplade till den specifika kapaciteten.

Begreppet förmåga, som definieras av dess Meta-modell Data Group tillåter en att svara på frågor som:

  • Hur stödjer en viss förmåga eller förmågor det övergripande uppdraget/visionen?
  • Vilka resultat förväntas uppnås av en viss förmåga eller uppsättning förmågor?
  • Vilka tjänster krävs för att stödja en kapacitet?
  • Vad är den funktionella omfattningen och organisatoriska spännvidden för en förmåga eller uppsättning förmågor?
  • Vilka är vår nuvarande uppsättning kapaciteter som vi hanterar som en del av en portfölj?

Uppdraget eller handlingsförloppet beskrivs av ett operationskoncept (CONOPS) och är organiserat av Capabilities.

  • Funktionerna beskrivs av trådar.
  • Trådar beskrivs av Aktiviteter som utförs i serie eller parallellt.
  • Aktiviteterna är grupperade i uppdragsområden. Aktiviteter definierar operationer för en arkitektur.
  • Arkitekturerna är organiserade efter uppdragsområden. Arkitekturer ger korrekt resurser för de resurser som krävs av uppdraget eller handlingssättet.

Version 1.5 visningar

DoDAF V1.5 Länkar bland vyer.
DoD C4ISR Framework

DoDAF V1.5 definierar en uppsättning produkter, en vymodell , som fungerar som mekanismer för att visualisera, förstå och assimilera den breda omfattningen och komplexiteten i en arkitekturbeskrivning genom grafiska, tabellformade eller textmässiga medel. Dessa produkter är organiserade under fyra vyer:

  • Alla vyer (AV)
  • Driftvy (OV)
  • Systemvy (SV)
  • Teknisk standardvy (TV)

Varje vy visar vissa perspektiv på en arkitektur som beskrivs nedan. Endast en delmängd av den fullständiga DoDAF-vyn skapas vanligtvis för varje systemutveckling. Figuren representerar den information som länkar samman driftvyn, system- och tjänstervyn och teknisk standardvy. De tre vyerna och deras inbördes samband – drivna av gemensamma arkitekturdataelement – ​​utgör grunden för att härleda mått som interoperabilitet eller prestanda, och för att mäta effekten av värdena för dessa mått på operativt uppdrag och uppgiftseffektivitet.

Alla vyer

Alla view (AV)-produkter ger övergripande beskrivningar av hela arkitekturen och definierar arkitekturens omfattning och sammanhang. DoDAF V1.5 AV-produkterna definieras som:

AV-1 Översikt och sammanfattningsinformation
Omfattning, syfte, avsedda användare, avbildad miljö, analytiska resultat (om tillämpligt)
AV-2 Integrated Dictionary
Definitioner av alla termer som används i alla produkter.

Driftsvy

Operational View (OV)-produkter ger beskrivningar av uppgifterna och aktiviteterna, operativa element och informationsutbyte som krävs för att utföra DoD-uppdrag. OV tillhandahåller textuella och grafiska representationer av operationella noder och element, tilldelade uppgifter och aktiviteter och informationsflöden mellan noder. Den definierar vilken typ av information som utbyts, utbytesfrekvensen, de uppgifter och aktiviteter som stöds av dessa utbyten och arten av utbytena. DoDAF V1.5 OV-produkterna definieras som:

OV-1 Operationellt koncept på hög nivå Grafisk grafisk
och textuell beskrivning på hög nivå av verksamhetskonceptet (organisationer på hög nivå, uppdrag, geografisk konfiguration, anslutningsmöjligheter, etc.).
OV-2 Operational Node Connectivity Beskrivning
Operationella noder, aktiviteter som utförs vid varje nod och anslutningar och informationsflöde mellan noder.
OV-3 Matris för operativt informationsutbyte
Information som utbyts mellan noder och relevanta attribut för det utbytet såsom media, kvalitet, kvantitet och nivån av interoperabilitet som krävs.
OV-4 Organisationsrelationsdiagram
Kommando, kontroll, koordinering och andra relationer mellan organisationer.
OV-5 Operationell aktivitetsmodell
Aktiviteter, relationer mellan aktiviteter, input och output. Dessutom kan överlägg visa kostnad, presterande noder eller annan relevant information.
OV-6a Operationella reglermodell
En av de tre produkterna som används för att beskriva operationell aktivitetssekvens och timing som identifierar de verksamhetsregler som begränsar verksamheten.
OV-6b Driftstillståndsövergång Beskrivning
En av de tre produkterna som används för att beskriva operativ aktivitetssekvens och timing som identifierar svar från en affärsprocess på händelser.
OV-6c Operational Event-Trace Beskrivning
En av de tre produkterna som används för att beskriva operationell aktivitetssekvens och timing som spårar åtgärderna i ett scenario eller kritiskt händelseförlopp.
OV-7 Logisk datamodell
Dokumentation av datakraven och strukturella affärsprocessregler för Operational View. (I DoDAF V1.5. Detta motsvarar DIV-2 i DoDAF V2.0.)

System- och tjänstervy

Systems and services view (SV) är en uppsättning grafiska och textuella produkter som beskriver system och tjänster och sammankopplingar som tillhandahåller, eller stödjer, DoD-funktioner. SV-produkter fokuserar på specifika fysiska system med specifika fysiska (geografiska) platser. Relationen mellan arkitekturdataelement över SV till OV kan exemplifieras när system upphandlas och ställs in för att stödja organisationer och deras verksamhet. DoDAF V1.5 SV-produkterna är:

SV-1 Systems/Services Interface Description
Avbildar systemnoder och de system som finns på dessa noder för att stödja organisationer/mänskliga roller representerade av operativa noder för OV-2. SV-1 identifierar också gränssnitten mellan system och systemnoder.
SV-2 Systems/Services Communications Description
Visar relevant information om kommunikationssystem, kommunikationslänkar och kommunikationsnätverk. SV-2 dokumenterar de typer av kommunikationsmedia som stödjer systemen och implementerar deras gränssnitt som beskrivs i SV-1. Sålunda visar SV-2 kommunikationsdetaljerna för SV-1-gränssnitt som automatiserar aspekter av nållinjerna representerade i OV-2.
SV-3 Systems-Systems, Services-Systems, Services-Services Matriser
tillhandahåller detaljer om gränssnittsegenskaperna som beskrivs i SV-1 för arkitekturen, arrangerade i matrisform.
SV-4a/SV-4b System/tjänster Funktionalitet Beskrivning
SV-4a dokumenterar systemfunktionshierarkier och systemfunktioner, och systemdataflöden mellan dem. SV-4 från DoDAF v1.0 är betecknad som 'SV-4a' i DoDAF v1.5. Även om det finns en korrelation mellan OV-5 eller affärsprocesshierarkier och den systemfunktionella hierarkin för SV-4a, behöver det inte vara en en-till-en-mappning, och därför behöver den operativa aktiviteten till systemfunktionsspårbarhetsmatrisen ( SV-5a), som tillhandahåller den kartläggningen.
SV-5a, SV-5b, SV-5c Operationell aktivitet till systemfunktion, operationell aktivitet till system och tjänster Spårbarhetsmatriser
Operationell aktivitet till SV-5a och SV-5b är en specifikation av relationerna mellan uppsättningen operativa aktiviteter som är tillämpliga på en arkitektur och den uppsättning systemfunktioner som är tillämpliga på den arkitekturen. SV-5 och förlängning av SV-5 från DoDAF v1.0 är betecknade som 'SV-5a' respektive 'SV-5b' i DoDAF v1.5.
SV-6 Systems/Services Data Exchange Matrix
Specificerar egenskaperna hos systemdata som utbyts mellan system. Denna produkt fokuserar på automatiserat informationsutbyte (från OV-3) som implementeras i system. Icke-automatiserade informationsutbyten, såsom muntliga beställningar, fångas endast i OV-produkterna.
SV-7 System/tjänster Prestandaparametrar Matrix
Specificerar de kvantitativa egenskaperna för system och systemhårdvara/mjukvara, deras gränssnitt (systemdata som bärs av gränssnittet samt kommunikationslänksdetaljer som implementerar gränssnittet) och deras funktioner. Den specificerar de aktuella prestandaparametrarna för varje system, gränssnitt eller systemfunktion, och förväntade eller nödvändiga prestandaparametrar vid angivna tidpunkter i framtiden. Prestandaparametrar inkluderar alla tekniska prestandaegenskaper hos system för vilka krav kan utvecklas och specifikationer definieras. Den kompletta uppsättningen prestandaparametrar kanske inte är känd i de tidiga stadierna av arkitekturdefinitionen, så det bör förväntas att denna produkt kommer att uppdateras under hela systemets specifikation, design, utveckling, testning och möjligen även dess driftsättning och driftlivscykel faser.
SV-8 Systems/Services Evolution Beskrivning
Fångar utvecklingsplaner som beskriver hur systemet, eller arkitekturen som systemet är inbäddat i, kommer att utvecklas under en lång tidsperiod. I allmänhet är milstolparna i tidslinjen avgörande för en framgångsrik förståelse av evolutionens tidslinje.
SV-9 Systems/Services Technology Prognos
Definierar de underliggande nuvarande och förväntade stödteknologierna som har inriktats på med standardprognosmetoder. Förväntade stödjande tekniker är sådana som rimligen kan förutses med tanke på det nuvarande teknikläget och förväntade förbättringar. Ny teknik bör knytas till specifika tidsperioder, som kan korrelera med de tidsperioder som används i SV-8 milstolpar.
SV-10a System/tjänster Regelmodell
Beskriver reglerna under vilka arkitekturen eller dess system beter sig under specificerade förhållanden.
SV-10b System/tjänster Tillståndsövergång Beskrivning
En grafisk metod för att beskriva ett system (eller systemfunktion) svar på olika händelser genom att ändra dess tillstånd. Diagrammet representerar i princip uppsättningarna av händelser som systemen i arkitekturen kommer att reagera på (genom att vidta en åtgärd för att flytta till ett nytt tillstånd) som en funktion av dess nuvarande tillstånd. Varje övergång specificerar en händelse och en åtgärd.
SV-10c Systems/Services Event-Trace Description
Ger en tidsordnad undersökning av systemdataelement som utbyts mellan deltagande system (externt och internt), systemfunktioner eller mänskliga roller som ett resultat av ett visst scenario. Varje händelsespårningsdiagram bör ha en åtföljande beskrivning som definierar det specifika scenariot eller situationen. SV-10c i system- och tjänstvyn kan återspegla systemspecifika aspekter eller förbättringar av kritiska händelsesekvenser som beskrivs i driftvyn.
SV-11 Physical Schema
En av de arkitekturprodukter som ligger närmast den faktiska systemdesignen i Framework. Produkten definierar strukturen för de olika typer av systemdata som används av systemen i arkitekturen. (I DoDAF V1.5. Detta motsvarar DIV-3 i DoDAF V2.0.)

Teknisk standardvy

Teknisk standardvy (TV)-produkter definierar tekniska standarder, implementeringskonventioner, affärsregler och kriterier som styr arkitekturen. DoDAF V1.5 TV-produkter är följande:

  • StdV-1 Technical Standards Profile - Extraktion av standarder som gäller för den givna arkitekturen. (I DoDAF V1.5. Omdöpt till StdV-1 i DoDAF V2.0.)
  • StdV-2 Technical Standards Forecast - Beskrivning av framväxande standarder som förväntas gälla för den givna arkitekturen, inom en lämplig uppsättning tidsramar. (I DoDAF V1.5. Bytt namn till StdV-2 i DoDAF V2.0.)

Version 2.0 synpunkter

Diagram över DoDAF V2.0 synpunkter.
Utveckling av DoDAF V1.5 Views till DoDAF V2.0 Viewpoints.
Kartläggning av DoDAF V1.5-vyer till DoDAF V2.0-vyer.

I DoDAF V2.0 är arkitektoniska synpunkter sammansatta av data som har organiserats för att underlätta förståelsen. För att anpassa sig till ISO-standarder, där så är lämpligt, har terminologin ändrats från åsikter till synpunkter (t.ex. är den operativa synen nu den operativa synpunkten).

All Viewpoint (AV)
Beskriver de övergripande aspekterna av arkitekturkontext som relaterar till alla synpunkter.
Capability Viewpoint (CV)
Nytt i DoDAF V2.0. Artikulerar kapacitetskraven, leveranstidpunkten och den distribuerade kapaciteten.
Data and Information Viewpoint (DIV)
Nytt i DoDAF V2.0. Artikulerar datarelationer och anpassningsstrukturer i arkitekturinnehållet för kapacitets- och driftskrav, systemutvecklingsprocesser och system och tjänster.
Operational Viewpoint (OV)
Inkluderar de operationella scenarierna, aktiviteterna och kraven som stöder kapacitet.
Project Viewpoint (PV)
Nytt i DoDAF V2.0. Beskriver sambanden mellan verksamhets- och kompetenskrav och de olika projekt som genomförs. Projektsynspunkten beskriver också beroenden mellan kapacitets- och operativa krav, systemutvecklingsprocesser, systemdesign och servicedesign inom försvarsinsamlingsprocessen.
Services Viewpoint (SvcV)
Nytt i DoDAF V2.0. Presenterar designen för lösningar som artikulerar artisterna, aktiviteterna, tjänsterna och deras utbyten, tillhandahåller eller stödjer operativa och kapacitetsfunktioner.
Standards Viewpoint (StdV)
Bytt namn från Technical Standards View. Artikulerar tillämpliga operationella, affärsmässiga, tekniska och branschpolicyer, standarder, vägledning, begränsningar och prognoser som gäller för kapacitet och driftkrav, systemutvecklingsprocesser och system och tjänster.
Systems Viewpoint (SV)
Artikulerar, för legacy support , designen för lösningar som artikulerar systemen, deras sammansättning, sammankoppling och sammanhang som tillhandahåller eller stödjer drift- och kapacitetsfunktioner. Obs, systemet har ändrats i DoDAF V2.0 från DoDAF V1.5: Systemet är inte bara hårdvara och mjukvara. System definieras nu i den allmänna meningen av en sammansättning av komponenter - maskin, människa - som utför aktiviteter (eftersom de är undertyper av Performer) och som interagerar eller är beroende av varandra. Detta kan vara vad som helst, dvs allt från små delar av utrustning som har interagerande eller inbördes beroende element, till Family of Systems (FoS) och System of Systems (SoS). Observera att system består av materiel (t.ex. utrustning, flygplan och fartyg) och personaltyper.

Arkitekturerna för DoDAF V1.0 och DoDAF V1.5 kan fortsätta att användas. När det är lämpligt (vanligtvis angivet av policy eller av beslutsfattaren), kommer DoDAF V1.0- och V1.5-arkitekturer att behöva uppdatera sin arkitektur. När arkitekturen före DoDAF V2.0 jämförs med arkitekturen DoDAF V2.0, måste konceptskillnader (som Node) definieras eller förklaras för den nyare arkitekturen. När det gäller DoDAF V1.5-produkter har de omvandlats till delar av DoDAF V2.0-modellerna. I de flesta fall stöder DoDAF V2.0 Meta-modellen DoDAF V1.5 datakoncept, med ett anmärkningsvärt undantag: Node. Node är ett komplext, logiskt begrepp som representeras med mer konkreta begrepp.

All Viewpoint (AV)

AV-1 Översikt och sammanfattningsinformation
Beskriver ett projekts visioner, mål, mål, planer, aktiviteter, händelser, förhållanden, åtgärder, effekter (resultat) och producerade objekt.
AV-2 Integrated Dictionary
Ett arkitektoniskt dataarkiv med definitioner av alla termer som används genomgående

Capability Viewpoint (CV)

CV-1 Vision
Tar upp företagets problem som är förknippade med den övergripande visionen för transformationssträvanden och definierar därmed det strategiska sammanhanget för en grupp av förmågor. Syftet med CV-1 är att tillhandahålla ett strategiskt sammanhang för de förmågor som beskrivs i Arkitekturbeskrivningen.
CV-2 Capability Taxonomy
Fångar förmåga taxonomier. Modellen presenterar en hierarki av förmågor. Dessa funktioner kan presenteras i samband med en tidslinje. CV-2 specificerar alla funktioner som refereras till i en eller flera arkitekturer.
CV-3 Capability Phasing
Det planerade uppnåendet av förmåga vid olika tidpunkter eller under specifika tidsperioder. CV-3 visar förmågans infasning vad gäller aktiviteter, förutsättningar, önskade effekter, regler som efterlevs, resursförbrukning och produktion samt åtgärder, utan hänsyn till utförare och lokaliseringslösningar CV-4 Kapacitetsberoenden Beroendena mellan planerade
förmågor
och definitionen av logiska grupperingar av förmågor.
CV-5 Förmåga till kartläggning av organisationsutveckling
Uppfyllelsen av kapacitetskrav visar den planerade kapacitetsutbyggnaden och sammankopplingen för en viss kapacitetsfas. CV-5 visar den planerade lösningen för fasen vad gäller utförare och platser och deras associerade koncept.
CV-6 Mappning av förmåga till operativa aktiviteter
En kartläggning mellan de förmågor som krävs och de operativa aktiviteter som dessa förmågor stödjer.
CV-7 Capability to Services Mapping
En mappning mellan de funktioner och de tjänster som dessa funktioner möjliggör.

Data and Information Viewpoint (DIV)

DIV-1 konceptuell datamodell
De erforderliga datakoncepten på hög nivå och deras relationer.
DIV-2 Logical Data Model
Dokumentationen av datakraven och strukturella affärsprocesser (aktivitetsregler). I DoDAF V1.5 var detta OV-7.
DIV-3 Physical Data Model
Det fysiska implementeringsformatet för logiska datamodellentiteter, t.ex. meddelandeformat, filstrukturer, fysiskt schema. I DoDAF V1.5 var detta SV-11.

Notera, se logisk datamodell för diskussion om förhållandet mellan dessa tre DIV-datamodeller, med jämförelse av de konceptuella, logiska och fysiska datamodellerna.

Operationell synvinkel (OV)

OV-1 Högnivå Operational Concept Graphic
Den grafiska/textuella beskrivningen på hög nivå av driftkonceptet.
OV-2 Operativt resursflöde Beskrivning
En beskrivning av de resursflöden som utbyts mellan operativa aktiviteter.
OV-3 Operationell resursflödesmatris
En beskrivning av de utbytta resurserna och de relevanta attributen för utbytena.
OV-4 Diagram över organisationsrelationer
Det organisatoriska sammanhanget, rollen eller andra relationer mellan organisationer.
OV-5a Operationell aktivitet Nedbrytningsträd
Förmågor och aktiviteter (operativa aktiviteter) organiserade i en hierarkisk struktur.
OV-5b Operationell aktivitetsmodell
Kontexten av förmågor och aktiviteter (operativa aktiviteter) och deras relationer mellan aktiviteter, input och output; Ytterligare data kan visa kostnader, artister eller annan relevant information.
OV-6a Driftregelmodell
En av tre modeller som används för att beskriva aktivitet (operativ aktivitet). Den identifierar affärsregler som begränsar verksamheten.
OV-6b Tillståndsövergång Beskrivning
En av tre modeller som används för att beskriva operativ aktivitet (aktivitet). Den identifierar affärsprocesser (aktivitet) svar på händelser (vanligtvis mycket korta aktiviteter).
OV-6c Event-Trace Beskrivning
En av tre modeller som används för att beskriva aktivitet (operativ aktivitet). Den spårar handlingar i ett scenario eller händelseförlopp.

Projektsynpunkt (PV)

PV-1 Projektportföljrelationer
Den beskriver beroenderelationerna mellan organisationerna och projekten och de organisatoriska strukturer som behövs för att hantera en portfölj av projekt.
PV-2 Project Timelines
Ett tidslinjeperspektiv på program eller projekt, med nyckelmilstolpar och ömsesidigt beroende.
PV-3 Project to Capability Mapping
En kartläggning av program och projekt till förmågor för att visa hur de specifika projekten och programelementen hjälper till att uppnå en förmåga.

Services Viewpoint (SvcV)

SvcV-1 Tjänster Kontext Beskrivning
Identifieringen av tjänster, tjänsteartiklar och deras sammankopplingar.
SvcV-2 Services Resursflöde Beskrivning
En beskrivning av resursflöden som utbyts mellan tjänster.
SvcV-3a System-Services Matrix
Relationerna mellan eller mellan system och tjänster i en given arkitektonisk beskrivning.
SvcV-3b Services-Services Matrix
Relationerna mellan tjänster i en given arkitektonisk beskrivning. Den kan utformas för att visa intresserelationer (t.ex. gränssnitt av tjänsttyp, planerade kontra befintliga gränssnitt).
SvcV-4 Tjänster Funktionalitet Beskrivning
Funktionerna som utförs av tjänster och tjänstens dataflöden mellan tjänstefunktioner (aktiviteter).
SvcV-5 Operationell aktivitet till tjänster Spårbarhetsmatris
En kartläggning av tjänster (aktiviteter) tillbaka till operativa aktiviteter (aktiviteter).
SvcV-6 Services resursflödesmatris
Den tillhandahåller detaljer om tjänstens resursflödeselement som utbyts mellan tjänster och attributen för det utbytet.
SvcV-7 Services Measures Matrix
Måtten (måtten) för tjänstemodellelementen för lämplig(a) tidsram(ar).
SvcV-8 Services Evolution Beskrivning
De planerade stegen mot att migrera en svit av tjänster till en mer effektiv svit eller mot att utveckla nuvarande tjänster till en framtida implementering.
SvcV-9 Services Technology & Skills Prognos
De framväxande teknologierna, mjukvara/hårdvaruprodukter och färdigheter som förväntas vara tillgängliga inom en given tidsram och som kommer att påverka framtida tjänsteutveckling.
SvcV-10a Serviceregelmodell
En av tre modeller som används för att beskriva tjänstens funktionalitet. Den identifierar begränsningar som åläggs systemfunktionalitet på grund av någon aspekt av systemdesign eller implementering.
SvcV-10b Services State Transition Beskrivning
En av tre modeller som används för att beskriva tjänstens funktionalitet. Den identifierar svar från tjänster på händelser.
SvcV-10c Services Event-Trace Beskrivning
En av tre modeller som används för att beskriva tjänstens funktionalitet. Den identifierar tjänstespecifika förbättringar av kritiska händelsesekvenser som beskrivs i Operational Viewpoint.

Standard Viewpoint (StdV)

StdV-1 Standards Profile
Listan över standarder som gäller för lösningselement. I DoDAF V1.5 var detta TV-1.
StdV-2 Standards Prognos
Beskrivningen av nya standarder och potentiell påverkan på nuvarande lösningselement, inom en uppsättning tidsramar. I DoDAF V1.5 var detta TV-2.

System Viewpoint (SV)

SV-1 Systems Interface Description
Identifiering av system, systemobjekt och deras sammankopplingar.
SV-2 Systems Resursflöde Beskrivning
En beskrivning av resursflöden som utbyts mellan system.
SV-3 Systems-Systems Matrix
Relationerna mellan system i en given arkitektonisk beskrivning. Den kan utformas för att visa intresserelationer (t.ex. gränssnitt av systemtyp, planerade kontra befintliga gränssnitt).
SV-4 Systemfunktioner Beskrivning
De funktioner (aktiviteter) som utförs av system och systemdataflöden mellan systemfunktioner (aktiviteter).
SV-5a Operationell aktivitet till systemfunktion Spårbarhetsmatris
En kartläggning av systemfunktioner (aktiviteter) tillbaka till operationella aktiviteter (aktiviteter).
SV-5b Operationell aktivitet till systemspårbarhetsmatris
En kartläggning av system tillbaka till förmågor eller operativa aktiviteter (aktiviteter).
SV-6 Systems resursflödesmatris
Ger detaljer om systemresursflödeselement som utbyts mellan system och attributen för det utbytet.
SV-7 Systemmåttmatris
Måtten (måtten) för systemmodellelementen för lämplig(a) tidsram(ar).
SV-8 System Evolution Beskrivning
De planerade stegen mot att migrera en svit av system till en mer effektiv svit, eller mot att utveckla ett nuvarande system till en framtida implementering.
SV-9 Systemteknik och kompetensprognoser
Framväxande teknologier, mjukvara/hårdvaruprodukter och färdigheter som förväntas vara tillgängliga inom en given tidsram och som kommer att påverka framtida systemutveckling.
SV-10a Systemregelmodell
En av tre modeller som används för att beskriva systemfunktionalitet. Den identifierar begränsningar som åläggs systemfunktionalitet på grund av någon aspekt av systemdesign eller implementering.
SV-10b Systemtillståndsövergång Beskrivning
En av tre modeller som används för att beskriva systemfunktionalitet. Den identifierar systemens svar på händelser.
SV-10c Systems Event-Trace Beskrivning
En av tre modeller som används för att beskriva systemfunktionalitet. Den identifierar systemspecifika förbättringar av kritiska händelsesekvenser som beskrivs i Operational Viewpoint.

Skapa en integrerad arkitektur med hjälp av DoDAF

Illustration av den integrerade arkitekturen.

DODAF 2.0 Architects Guide upprepade DOD-instruktion 4630.8 definition av en integrerad arkitektur som "En arkitektur som består av flera vyer som underlättar integration och främjar interoperabilitet mellan funktioner och bland integrerade arkitekturer. För arkitekturutvecklingsändamål betyder termen integrerad att data krävs i mer än en av de arkitektoniska modellerna är allmänt definierad och förstådd över dessa modeller. Integrerade arkitekturer är en egenskap eller designprincip för arkitekturer på alla nivåer: Capability, Component, Solution och Enterprise (i sammanhanget av DoD Enterprise Architecture (EA) som är en federation [av] arkitekturer). I enklare termer ses integration i kopplingen från objekt som är vanliga bland arkitekturprodukter, där objekt som visas i en arkitekturprodukt (såsom webbplatser som används eller gränssnittssystem eller tillhandahållna tjänster) bör ha samma nummer, namn och betydelse visas i relaterade arkitekturproduktvyer."

Det finns många olika tillvägagångssätt för att skapa en integrerad arkitektur med hjälp av DoDAF och för att bestämma vilka produkter som krävs. Tillvägagångssättet beror på kraven och de förväntade resultaten; dvs vad den resulterande arkitekturen kommer att användas till. Som ett exempel listade DoDAF v1.0 följande produkter som "den minsta uppsättning produkter som krävs för att uppfylla definitionen av en OV, SV och TV." En anmärkning: även om DoDAF inte listar OV-1-artefakten som en kärnprodukt, uppmuntras dess utveckling starkt. Sekvensen av artefakterna nedan ger en föreslagen ordning i vilken artefakterna kan utvecklas. Den faktiska sekvensen för generering av vyer och deras potentiella anpassning är en funktion av applikationsdomänen och ansträngningens specifika behov.

  • AV-1: Översikt och sammanfattningsinformation
  • AV-2 : Integrated Dictionary
  • OV-1 : Hög nivå operativt koncept grafik
  • OV-5: Operationell aktivitetsmodell
  • OV-2 : Operationell nodanslutningsbeskrivning
  • OV-3 : Operationell informationsutbytesmatris
  • SV-1: Beskrivning av systemgränssnitt
  • TV-1 : Teknisk standardprofil

En fråga om DoDAF är hur väl dessa produkter möter faktiska intressenters oro för ett givet system av intresse. Man kan se DoDAF-produkter, eller åtminstone de tre vyerna, som ANSI/IEEE 1471-2000 eller ISO/IEC 42010 synpunkter . Men för att bygga en arkitekturbeskrivning som motsvarar ANSI/IEEE 1471-2000 eller ISO/IEC 42010, är ​​det nödvändigt att tydligt identifiera de intressenter och deras problem som är kopplade till varje vald DoDAF-produkt. Annars finns risken att producera produkter utan kunder.

DoDAF V1.5 Produktmatris

Figuren "DoDAF V1.5 Products Matrix" visar hur DoD Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E specificerar vilka DoDAF V1.5-produkter som krävs för varje typ av analys, i samband med Net-Ready Key Performance Parameter (NR-KPP):

  • Initial Capabilities Document (ICD). Dokumenterar behovet av en materiellösning för ett specifikt kapacitetsgap som härrör från en initial analys av alternativ som utförs av den operativa användaren och, vid behov, en oberoende analys av alternativ. Den definierar kapacitetsgapet i termer av funktionsområdet, det relevanta utbudet av militära operationer, önskade effekter och tid.
  • Capability Development Document (CDD). Ett dokument som samlar in den information som krävs för att utveckla ett eller flera föreslagna program, normalt med hjälp av en evolutionär förvärvsstrategi. CDD skisserar en överkomlig ökning av militärt användbar, logistiskt stödd och tekniskt mogen kapacitet.
  • Capability Production Document (CPD). Ett dokument som tar upp de produktionselement som är specifika för ett enskilt steg i ett förvärvsprogram.
  • Information Support Plan (ISP). Identifiering och dokumentation av informationsbehov, infrastrukturstöd, IT- och NSS-gränssnittskrav och beroenden med fokus på nätcentrerad, interoperabilitet, stödbarhet och tillräcklighet (DODI 4630.8).
  • Skräddarsydd informationsstödsplan (TISP). Syftet med TISP-processen är att tillhandahålla ett dynamiskt och effektivt fordon för vissa program (ACAT II och nedan) för att skapa krav som krävs för I&S-certifiering. Utvalda programansvariga kan begära att få skräddarsy innehållet i sin ISP (ref ss). För program som inte utsetts till OSD-specialintresse av ASD (NII) /DOD CIO, kommer komponenten att fatta det slutgiltiga beslutet om detaljerna i den skräddarsydda planen med förbehåll för de minimikrav som anges i TISP-procedurerna länkade från CJCSI 6212-resurssidan och eventuella särskilda behov som identifieras av J-6 för I&S-certifieringsprocessen.

Representation

Representationer för DoDAF-produkterna kan hämtas från många diagramtekniker inklusive:

Det finns ett UPDM- arbete (Unified Profile for DoDAF och MODAF) inom OMG för att standardisera representationen av DoDAF-produkter när UML används.

DoDAF beskriver generiskt i representationen av artefakterna som ska genereras, men tillåter stor flexibilitet vad gäller de specifika formaten och modelleringsteknikerna. DoDAF-skrivbordsboken ger exempel på att använda traditionella systemtekniker och datatekniker , och för det andra UML-format. DoDAF proklamerar latitud i arbetsproduktformat, utan att bekänna en diagramteknik framför en annan.

Förutom grafisk representation finns det vanligtvis ett krav på att tillhandahålla metadata till Defence Information Technology Portfolio Repository (DITPR) eller andra arkitektoniska arkiv.

Meta-modell

DoDAF har en metamodell som ligger till grund för ramverket, som definierar de typer av modelleringselement som kan användas i varje vy och relationerna mellan dem. DoDAF versioner 1.0 till 1.5 använde CADM -metamodellen, som definierades i IDEF1X (senare i UML) med ett XML-schema härlett från den resulterande relationsdatabasen. Från version 2.0 har DoDAF antagit IDEAS Group foundation ontologi som grund för sin nya metamodell. Denna nya metamodell kallas "DM2"; en akronym för "DoDAF Meta-Model". Var och en av dessa tre nivåer av DM2 är viktig för en viss tittare av avdelningsprocesser:

  1. Den konceptuella nivån eller Conceptual Data Model (CDM) definierar datakonstruktionerna på hög nivå från vilka arkitektoniska beskrivningar skapas i icke-tekniska termer, så att chefer och chefer på alla nivåer kan förstå databasen för Architectural Description. Representerad i DoDAF V2.0 DIV-1 Viewpoint.
  2. Den logiska datamodellen (LDM) lägger till teknisk information, såsom attribut till CDM, och vid behov förtydligar relationer till en entydig användningsdefinition. Representerad i DoDAF V2.0 DIV-2 Viewpoint.
  3. Physical Exchange Specification (PES) består av LDM med allmänna datatyper specificerade och implementeringsattribut (t.ex. källa, datum) tillagda och sedan genererade som en XSD. Representerad i DoDAF V2.0 DIV-3 Viewpoint.

Syften med DM2 är:

  1. Etablera och definiera det begränsade ordförrådet för beskrivning och diskurs om DoDAF-modeller (tidigare "produkter") och deras användning i de 6 kärnprocesserna
  2. Specificera semantiken och formatet för federerat EA-datautbyte mellan: arkitekturutvecklings- och analysverktyg och arkitekturdatabaser över DoD Enterprise Architecture (EA) Community of Interest (COI) och med andra auktoritativa datakällor
  3. Stöd för upptäckt och förståelse av EA-data:
    1. Upptäckt av EA-data med hjälp av DM2-kategorier av information
    2. Förståbarhet av EA-data med DM2:s exakta semantik utökad med språklig spårbarhet (alias)
  4. Tillhandahålla en grund för semantisk precision i arkitekturbeskrivningar för att stödja heterogen arkitekturbeskrivningsintegrering och analys till stöd för beslutsfattande i kärnprocesser.

DM2 definierar arkitektoniska dataelement och möjliggör integration och sammanslutning av arkitektoniska beskrivningar. Det skapar en grund för semantisk (dvs förståelse) konsistens inom och över arkitekturbeskrivningar. På detta sätt stödjer DM2 utbyte och återanvändning av arkitektonisk information mellan JCAs, Components och Federal and Coalition partners, vilket underlättar förståelsen och implementeringen av interoperabilitet mellan processer och system. När DM2 mognar för att möta de pågående datakraven från processägare, beslutsfattare, arkitekter och nya teknologier, kommer den att utvecklas till en resurs som mer fullständigt stödjer kraven på arkitektonisk data, publicerad på ett konsekvent förståeligt sätt och kommer att möjliggöra större lätt för att upptäcka, dela och återanvända arkitektonisk data över organisatoriska gränser.

För att underlätta användningen av information i datalagret, beskriver DoDAF en uppsättning modeller för att visualisera data genom grafiska, tabellformiga eller textmässiga medel. Dessa synpunkter hänför sig till intressenternas krav för att ta fram en arkitektonisk beskrivning.

Relation till andra arkitekturramar

UPDM (Unified Profile for DoDAF och MODAF ) är ett OMG-initiativ för att standardisera UML- och SysML-användning för ramverk för försvarsarkitektur i USA och Storbritannien . Dessutom har den multinationella IDEAS Group , som stöds av Australien, Kanada, Sverige, Storbritannien, USA, med NATO- observatörer, lanserat ett initiativ för att utveckla en formell ontologi för företagsarkitekturer.

Se även


Vidare läsning

  •   Dennis E. Wisnosky och Joseph Vogel. Dodaf Wizdom: en praktisk guide för att planera, hantera och genomföra projekt för att bygga företagsarkitekturer med hjälp av ramverket för försvarsarkitektur . Wizdom Systems, Inc., 2004. ISBN 1-893990-09-5 .
  •   Dr Steven H. Dam (2015). DoD Architecture Framework 2.0: En guide för att tillämpa systemteknik för att utveckla integrerade, körbara arkitekturer . CreateSpace Independent Publishing Platform, 2015. ISBN 1-502757-62-1 .

externa länkar

  • CJCSI 6212.01 Series
  • European Space Agency Architectural Framework (ESAAF) - ett ramverk för europeiska rymdbaserade system av system [ 1]
Hämtad från " https://en.wikipedia.org/w/index.php?title=Department_of_Defense_Architecture_Framework&oldid=1121090334 "