Introduction to DoD Architecture Framework (DoDAF)

Transcription

1 Introduction to DoD Architecture Framework (DoDAF) Beverly Hawk 1 Jonnathan Kim 2 What i thi paper? Thi paper, Introduction to the DoD Architecture Framework (DoDAF), i an ultra-brief overview of DoDAF. The intent i to provide potential uer a quick overview of DoDAF and related architecture product. DoDAF provide a framework to completely decribe ytem pecification, deign procee, trade parameter, etc. What i DoDAF? Modern day warfighting operation involve complex et of hardware, oftware, and uer. In decribing the development and integration of uch complex ytem, it i neceary to provide a common and conitent approach to decribe the ytem and procee. DoDAF provide guidance for decribing architecture for warfighting operation, buine operation, and procee. [1] Utilizing thi framework provide a common approach for architecture decription, development, preentation, and integration. Before going further in decribing thi common approach, it i neceary to undertand the term architecture which i frequently ued, and often miued. IEEE define architecture a the organizational tructure of a ytem and component. Baed on thi definition, the DoD Integrated Architecture Panel define architecture a the tructure of component, their relationhip, and the principle and guideline governing their deign and evolution over time. IEEE STD alo tate An architecture i the fundamental organization of a ytem embodied in it component, their relationhip to each other, and to the environment, and the principle guiding it deign and evolution. From thi definition, we can further expand the decription of the architecture framework a a tool which hould decribe a method for deigning an information ytem in term of a et of building block, and for howing how the building block fit together. It hould contain a et of tool and provide a common vocabulary. It hould alo include a lit of recommended tandard and compliant product that can be ued to implement the building block. Where i the beef? How doe DoDAF help u decribe a ytem or a proce? Firt of all, DoDAF define the perpective from which a ytem i decribed. Figure 1 depict three view. A ytem can be decribed from the operational perpective. The product generated from the operational perpective i termed Operation View. The OV decribe the tak, activitie, operational element, and information exchange required to accomplih a DoD miion. The Sytem View (SV) decribe an architecture in term of ytem and interconnection to accomplih a DoD miion. The Technical View (TV) i a et of rule and tandard governing the arrangement, interaction, and interdependency. The TV provide a et of rule and tandard to promote efficiency and interoperability in TV-1 and to enure that developer can adequately plan for evolution in TV-2. The All View (AV) decribe the overarching apect of the architecture that are pertinent to all the view but are not pecific to a ingle view. The complete et of the view i delineated in Table 1. A hown in the table, there are many product that contitute the DoDAF view. 1 EPG, hawk@epg.army.mil 2. GaN Corporation, jkim@gancorp.com

2 Activitie / Tak Operationa l View Operationa l Element Information Flow Sytem Sytem View Data Flow Standard Technical Standard View Rule Communication Figure 1. DoDAF View (Reference [1]) Convention [Note: Reference [1] doe not how the AV in Figure 1.] Each view product i inter-related to other view product to provide a complete picture of a ytem. For example, the SV-5 relate operational activitie from the OV-5 to ytem function from SV-4; the SV-4 ytem function are related to ytem in the SV-1; thu bridging the operational and ytem view. The high-level operational concept hould drive the OV; the OV in turn drive the SV to identify hortfall and ytem requirement, and the SV requirement drive the TV to addre a common et of applicable tandard. To be internally conitent and integrated, an architecture decription mut provide explicit linkage among it variou view. [1] It i important to note that it i poible ue a ubet of thee view to completely decribe a ytem or a proce. It i up to the architect to define a et of appropriate view for the intended ue of the architecture. How do we generate the view? Each view i generated with graphic, table, or text to completely decribe the pecified objective of the view. Reference [1] provide a general guideline of 5 tep for building architecture decription. They are: Step 1: Determine the intended ue of the architecture decription. Step 2: Determine the architecture decription cope, context, environment, and any other aumption to be conidered. Step 3: Determine what information the architecture decription need to capture baed on the intended ue. Step 4: Determine product to be built. Step 5: Gather the architecture data and build the requiite product.

3 For each view, the architecture of interet i decribed from that perpective. OV hould provide information about the operational node (who i reponible for the proce) and information flow among the operational node. The SV identify what the ytem are, how they are connected, and what they do. A an example, the OV can decribe how organization and people work together to accomplih a miion. The SV can decribe what pecific ytem are utilized to accomplih the miion. The TV decribe a et of pecification of the relevant technologie that are exiting (TV-1) and forecated (TV-2). Thee architectural product are graphical or textual repreentation of the data et which define variou attribute of the architecture. Since a given data element will frequently occur in more than one product, it i crucial to build a conitent et of data element. For example, a data element table can define data attribute uch a type and characteritic. The notation and format to generate the view can vary depending on application and uer. However, for objective oriented (OO) application, the Unified Modeling Language (UML) i often ued a the tandard method of repreentation. Reference [2] decribe how UML i ued to document OV and SV in detail. When the DoDAF architecture product are being developed, it i crucial to retain the information that decribe the cope and complexitie of the architectural data and data relationhip for viualizing and undertanding. There are tandard format and automated tool available to document the view. The All- DoD Core Architecture Data Model (CADM) wa developed a the DoD tandard architecture data model for Framework baed architecture data element. For development of the product, DoDAF doe not pecify or advocate a methodology or a notation, but DoDAF provide guidance for the product to contain the required intance of data element and relationhip. What have we done? We at EPG have developed architecture product, per DoDAF guidance, coniting of graphical and textual item providing an architecture decription of characteritic pertinent to our Tet Tool Kit for C4I teting. Our architecture flow into the ATEC teting architecture to complete tet and evaluation requirement. Where do I get more information? There are two main volume of DoD Architecture Framework Verion 1.0. Thee volume are available on the web Alo, there are many publication and clae available to learn about DoDAF. Reference: [1] DoD AF Vol 1, Definition and Guideline, 9 February [2] DoD AF Vol 2, Production, 9 February 2004.

4 Framework Product Applicable View Framework Product Name General AV-1 All View Overview and Summary Information Scope, purpoe, intended uer, environment depicted, analytical finding AV-2 All View Integrated Dictionary Architecture data repoitory with definition of all term ued in all product OV-1 Operational High-Level Operational High-level graphical/ textual decription of operational concept Concept Graphic OV-2 Operational Operational Node Connectivity Operational node, connectivity and information exchange needline between node OV-3 Operational Operational Information Exchange Matrix Information exchanged between node and the relevant attribute of that exchange OV-4 Operational Organizational Relationhip Organizational, role, or other relationhip among organization Chart OV-5 Operational Operational Activity Model Capabilitie, Operational Activitie, relationhip among activitie, input and output. Overlay can how cot, performing node, or other pertinent information OV-6a Operational Operational Rule Model One of the three product ued to decribe operational activity identifie buine rule that contrain operation OV-6b Operational Operational State Tranition One of three product ued to decribe operational activity identifie buine proce repone to event OV-6c Operational Operational Event-Trace One of three product ued to decribe operational activity trace action in a cenario or equence of event OV-7 Operational Logical Data Model Documentation of the ytem data requirement and tructural buine proce rule of the Operational View. SV-1 Sytem Sytem Interface Identification of ytem node, ytem, and ytem item and their interconnection, within and between node SV-2 Sytem Sytem Communication Sytem node, ytem, and ytem item, and their related communication lay-down SV-3 Sytem Sytem-Sytem Matrix Relationhip among ytem in a given architecture; can be deigned to how relationhip of interet, e.g., ytem-type interface, planned v. exiting interface, etc. SV-4 Sytem Sytem Functionality Function performed by ytem and the ytem data flow among ytem function SV-5 Sytem Operational Activity to Sytem Function Traceability Mapping of ytem back to capabilitie or of ytem function back to operational activitie Matrix SV-6 Sytem Sytem Data Exchange Matrix Provide detail of ytem data element being exchanged between ytem and the attribute of that exchange SV-7 Sytem Sytem Performance Parameter Matrix Performance characteritic of ytem view element, for the appropriate timeframe() SV-8 Sytem Sytem Evolution Planned incremental tep toward migrating a uite of ytem to a more efficient uite, or toward evolving a current ytem to a future implementation SV-9 Sytem Sytem Technology Forecat Emerging technologie and oftware/hardware product that are expected to be available in a given et of timeframe, and that will affect future development of the architecture SV-10a Sytem Sytem Rule Model One of three product ued to decribe ytem functionality identifie contraint that are impoed on ytem functionality due to ome apect of ytem deign or implementation SV-10b Sytem Sytem State Tranition One of three product ued to decribe ytem functionality identifie repone of a ytem to event SV-10c Sytem Sytem Event-Trace One of three product ued to decribe ytem functionality identifie ytem-pecific refinement of critical equence of event decribed in the operational view SV-11 Sytem Phyical Schema Phyical implementation of the Logical Data Model entitie, e.g., meage format, file tructure, phyical chema TV-1 Technical Technical Standard Profile Liting of tandard that apply to ytem view element in a given architecture TV-2 Technical Technical Standard Forecat of emerging tandard and potential impact on current ytem view element, within a et of timeframe Table 1. DoD AF Product

5 APPENDIX 1 Electronic Proving Ground DoDAF Product