An Introduction to the DoD Architecture Framework v1.5

Transcription

1 An Introduction to the DoD Architecture Framework v1.5 Presented to Colorado Front Range INCOSE Chapter Colorado Springs 27 May

2 Agenda DODAF Overview DODAF 1.5 Volume I / Volume II DODAF 1.5 Volume III 2

3 Background The DoDAF Challenge As the Department transforms to support net-centric operations, the DoDAF must: Represent net-centric architectural constructs within the DoDAF views and products Use architecture in support of better decision making Goal and Objectives Support integration of key Net-Centric concepts and associated Service-Oriented Architecture (SOA) principles into the DoDAF Improve the quality and utility of the DoDAF for Mission Area, Component, and Program architectures to support Net-centricity Modifications should be backward compatible 3

4 C4ISR Architecture Framework History DoD needs an overarching architect for military information systems who can work across all Department and component boundaries and reach down to the operating forces (to the combat level) to identify what is needed to better integrate military information systems into combat operations. First Architecture Guidance With CINC participation, develop an integrated architecture for command, control, communications, computers, and intelligence (C4I) to increase effectiveness when operating across the boundaries among CINCs areas of responsibility. DSB Task Force Recommendations 93 Government Performance & Results Act 1995 CORM Recommendation Formulation of AWG AWG Final Report I am directing the acceleration of the development of C4I integration and architecture efforts through the C4ISR Framework 1.0 creation of a DoD-wide C4I Integrated product Team. I have designated the ASD(C3I), in his capacity as the department s C4I architect, to sponsor, organize, and manage this effort. DepSecDef Second USN Architecture Primer Tasking Memo C4ISR Integrated Task Force Navy WSA SEW Baseline System Architecture Architectures Performance Specification Tutorial M Naval Architecture Primer C4ISR Framework 2.1 C4ISR Framework 2.0 USD (A&T), ASD (C3I), Joint Staff Director for C4 Systems Strategic Direction DOD Framework 1.0 (Draft) We see the Architecture Framework as a critical element of the strategic direction in the Department, and accordingly direct that all ongoing and planned C4ISR or related architectures be developed in accordance with Version 2.0. Existing architectures will be described in accordance with the Framework during appropriate revision cycles USN WSA&E Process Navy establishes WSA&E

5 The DoDAF is the common architecture language in DoD The Department of Defense (DoD) Architecture Framework (DoDAF), Version 1.5, defines a common approach for DoD architecture description development, presentation, and integration. The Framework enables architecture descriptions to be compared and related across organizational boundaries, including Joint and multinational boundaries. 5

6 The goal of the DoDAF is Integrated Architecture The term integrated architecture refers to an architecture description that has integrated OVs, SVs, and TVs (i.e., there are common points of reference linking the OV and SV and also linking the SV and TV). The Operational Activity to Systems Function Traceability Matrix (SV- 5), for example, relates operational activities from the Operational Activity Model (OV-5) to system functions from the Systems Functionality Description (SV-4); the SV-4 system functions are related to systems in the Systems Interface Description (SV-1), thus bridging the OV and SV. An architecture is defined to be an integrated architecture when products and their constituent architecture data elements are developed such that architecture data elements defined in one view are the same (i.e., same names, definitions, and values) as architecture data elements referenced in another view. OV, SV, TV? As the story goes, when the original authors of C4ISR were crashing to finish the deliverable, they were so tired of saying Operational View, System View, and Technical View they started using the abbreviations OV, SV, TV, and those abbreviations have stuck. 6

7 PRODUCT AND ARCHITECTURE ELEMENT RELATIONSHIPS There are general relationships that logically interconnect the Framework products The architect needs to be continuously aware of these necessary relationships Produces an architecture that is consistent across the three views Provides clear traceability Figure 2-4 illustrates some relationships among the architecture data elements for a subset of the products 7

8 Overview of DoDAF 1.5 Volumes Volume 1: Definitions and Guidelines Provides executive summaries for topics covered in depth in other Volumes (e.g. Net- Centricity, Architecture Data Management, Decision Support/Overlays) Introduces methodologies Volume 2: Product Descriptions Provides a detailed overview on the Net-Centric concepts selected Provides Net-Centric guidance for each product & notional Ex. for some SV products Includes CADM 1.5. models and CADM-conformant data element tables Volume 3: Architecture Data Management Establishes a data strategy for the architecture community CADM 1.5: eliminates complexity with the addition of new supertypes, supports all DoDAF 1.5 requirements, complexity built into the business rules DoDAF Online Journal Includes Deskbook content currently in DoDAF 1.0 Volume 3 Additional content includes: Activity-Based Modeling (ABM), SOA and Federation Will be hosted on the DoD Architecture Registry System* (DARS) *DARS Website: 8

9 DoDAF 1.5 Three Volume-Suite State of DoD Architecting Net-Centricity Sources & Prioritization Decision Support Processes Survey, SME interviews, Feedback Workshop Inputs CADM 1.5 OPERATIONAL-NODE PHYSICAL-NODE INFORMATION SYSTEM Federation Strategy EVENT-TRIGGER OPERATIONAL-ACTIVITY SYSTEM-FUNCTION PERFORMANCE TECHNOLOGY STANDARD Volume 1 Volume 2 Volume 3 9

10 Product Overview Purpose: Document decomposition of attributes into specific characteristics that were applied to the architecture views Document content gathered from workshops and analysis with respect to the 5 Net- Centric Concepts Concept 1: Populate the NCE Concept 2: Utilize the NCE Concept 3: Support the Unanticipated User Concept 4: Leverage COIs to promote Jointness Concept 5: Support Shared Infrastructure Identify product impacts of characteristics and data elements for DoDAF Architecture Views 10

11 OV-1: High-Level Operational Concept Graphic Budget Planning Construction Mgmt General Description: High-level graphical/textual description of operational concept Contract Admin Disposal Mgmt Industry (various ops) Auditing Engineering Analysis & Approval Facilities Mgmt Funds Mgmt Health, Safety, Environment Adjudication Warfighter Operations Movement Maintenance Training DoD Business Operations Environment Initiate a transaction Manage a transaction Manage reference data Provide decision support Control access to and protect transaction and reference data Transmit and translate transactions and reference data Requirements Analysis Technology Projection Oversight Maintenance Accounting Planning Business Protection Environment Log Planning DoD Business Operations Business Protection Environment T&E Transportation Training Development Receiving Program Sch, Dir, Cont Procurement Personnel Admin Payment/ Disbursement Inventory Flow Mgmt Product Impacts: Include in its textual and graphic description how the architecture addresses Net- Centric Operations as applicable (i.e. identify connectivity to the GIG) Unanticipated user: Depict the target user and the anticipated unanticipated users; (Note: depiction of types of Users will be used to describe unanticipated user) 11

12 OV-2: Operational Node Connectivity Description Performs: Activity 2 Activity 3 Needline 2 Information Type Y Node A Performs: Activity 1 Needline 4 Activity 2 Information Type Z External Source M External Destination L Needline 3 Information Type W Node B Needline 1 Information Type Node C Performs: Activity 3 General Description: Operational nodes, connectivity, and information exchange needlines between nodes. Product Impacts: Consumers: Capture services users (i.e. consumers) as role for an operational nodes Capture Information Environment as a user/actor in the NCE Provider Capture service provider as a role for an operational node; may capture other user roles for a portal as well Unanticipated User: Future concept: External nodes (nodes that need to be accounted for to support federated architecture) 12

13 OV-5: Operational Activity Model Activity Hierarchy A1 Activity 1 A0 High-Level Operational Activity A2 Activity 2 A3 Activity 3 A1.1 A1.2 A3.1 A3.2 Activity 4 Activity 5 Activity 6 Activity 7 Level 1 Flow Diagram For Operational Activity (A0) Flow 1 A1 Activity 1 Flow 2 A2 Activity 2 Flow 3 A3 Activity 3 General Description: Capabilities, operational activities, relationships among activities, inputs, and outputs; overlays can show cost, performing nodes, or other pertinent information. Flow 4 A3.2.1 Activity 8 A3.2.2 Activity 9 Product Impacts: Post before processing: Depict the activity or activities of posting information. May show multiple outputs from a particular activity. Services: A service (specifically web services) is a set of system functions executed by a system, accordingly a service is a set of process activities. As such, services could be captured as mechanisms if you use IDEF 0. 13

14 SV-1: Systems Interface Description General Description: Identification of systems nodes, systems, and system items and their interconnections, within and between nodes NODE A Sys Func L SYSTEM 1 Sys Func M SYSTEM 5 ETERNAL CONNECTION Interface 1-b Interface 1-a Interface 2 NODE C Key Interface 3-a SYSTEM 4 Sys Func I Sys Func J NODE B SYSTEM 3 Sys Func N Sys Func L SYSTEM 1 Sys Func M Sys Func H SYSTEM Sys Func L 1 Sys Func M Interface 3-b Product Impacts: Service: Capture showing a system using and consuming a web service Service Interface: Show how the services are going to employ services, how are they going to interact with them Service Consumer and Anticipated Consumer: Primary consumers may be system nodes Service Registry: Capture the physical service registry Physical Components: The physical attributes about a service (hardware, location) may be visualized as a system node Service Provider: Visually represent a service provider as a system node Enterprise Service Bus: Visually represent the service bus with 3 dimensions: the ESB, repository and registry may be described Portals, web based applications: Capture nodes as edge users and portal/web based application would be depicted as a system Federated Catalogs: Decompose into different layers in order to see certain levels of service Ports/Protocols: Capture port/protocol for service, which is the mechanism to gain access to that information or capability (access point) 14

15 SV-4: Systems Functionality Description ETERNAL SOURCE 1 FLOW 1 ETERNAL System SINK 1 Function 1 FLOW 3 FLOW 2 FLOW 4 ETERNAL SOURCE 2 FLOW 5 System Function 2 System FLOW 6 FLOW 9 Function 3 System REPOSITORY Function 4 FLOW 8 FLOW 7 FLOW 10 ETERNAL SINK 2 FUNCTION 1 SUBFUNCTION 11 SUBFUNCTION 12 SUBFUNCTION 13 SUBFUNCTION 121 SUBFUNCTION 122 General Description: Functions performed by systems and the system data flows among system functions Product Impacts: Service Location: Properties of SDF may capture where the service is registered Web Service: Define a web service Service Listing/Catalog: Capture the detail of services related to discovery of that service Service Function: Capture services and decompose into system functions Interface Publishing Spec: Different from the service provider and may be defined Service Description: Capture attributes of SDF/SST including applicable extensions Interface Specification: Capture the defined interface specifications (i.e. WSDL) 15

16 SV-5: Operational Activity to Systems Function Traceability Matrix Operational Activities General Description: Mapping of systems back to capabilities or of system functions back to operational activities System Functions Product Impacts: Capabilities Supported: The SV-5 may depict the traceability to operational activities Policies: A derivation of the SV-5 may capture the service levels required from the services as captured in the OV-6a and the service levels provided from the SV-10a (Post version 2.0 proposal, i.e. SV-5a.) Proposed recommendation- note update to product SV- 5A - Activity to System functions SV- 5B - Activity to System SV- 5C - Activity to Service. 16

17 SV-10c: Systems Event-Trace Description Systems/Functions System/ MESSAGES/TIME Function 1 time 1 Event 1 {formula relating time 1 to time 2} System/ Function 2 System/ Function 3 General Description: One of three products used to describe system functionality- identifies system-specific refinements of critical sequences of events described in the Operational View time 2 time 3 {formula relating time 3 to time 3'} time 3' time n Event 2 Event 3 Event 5 Event 7 Event 4 Event 6 Event 8 Product Impacts: Orchestration: Depict the orchestration between services (the various events between services) Service Registry: Capture service registry as services are registered Service Dependencies: Capture service dependencies Post before Processing: Show how the service passes information to another service before a user gets the information for processing 17

18 TV-1: Technical Standards Profile General Description: Listing of standards that apply to Systems View elements in a given architecture. DISR Service Area Service Information-Processing Standards Higher Order Languages Software Life-Cycle Process Geospatial Data Interchange Motion Imagery Data Interchange - Video Distributed-Object Computing Information-Transfer Standards Data Flow Network Command and Control Information (C2I) Network Physical Layer Network Interface Layer Management File Transfer Standards Remote Terminal Standards Network Time Synchronization Standards Web Services Standards Connectionless Data Transfer Transport Services Standards Information Modeling, Metadata, and Activity Modeling Information Exchange Standards Data Modeling Object-Oriented Modeling Human Computer Interface Mandates Information Security / Information Password Security Infrastructure Standards Application Software Entity Security Standards Virtual Private Network Service Intrusion Detection Service Human-Computer Interface Security Standards DISR Standard and Source Document Product Impacts: Specifications: Capture deviations, extensions, departures from specifications, particularly those around COI 18

19 Objectives of Volume III Implement the Net-Centric Data Strategy within the Architecture Community of Practice Prescribe discovery metadata to facilitate the registration and discovery of architecture content across the Department of Defense Describe how architecture registries and repositories will be federated utilizing web services Incorporate the Core Architecture Data Model as an integral component of the DoDAF 19

20 CADM Evolution DODAF 1.0 DODAF 1.5 DODAF 2.0 CADM 1.04 CADM 1.5 CADM 2.0 CADM 1.0 SERIES 20

21 CADM 1.5 Characteristics Extends CADM 1.04 Incorporates Net-Centric Requirements Remains backwards-compatible with CADM 1.0 Mapping Business Rules; Processes Details Substantial Streamlining: 135 Entities Meta-modeling of Relationships & Legacy Architecture Concepts Flexible but Stable Framework for Future DoDAF Versions 21

22 Architecture& Requirements Team Colorado Springs Points of Contact Team Leads Michael Johnston Andy Hall Team Contacts Bruce Winchester, Kirk Moen, Donny Holaschutz TSAT Architecture Judy Moldenhauer- AFSCN Requirements, MM III, SMD Crypto Architecture Dan Hutton AFSCN NMS Melissa McCullough, Ann Cobb AFSCN Architecture Jim Doughty ITW/AA Architecture Andy Hall NASA Constellation Architecture Linda Davis SE&I OSP, Space Radar Matt Wingert, Vern Miller GPS SATAF, GPS Ops Support 22

23 Questions? 23