Understanding the DoD Architecture Framework Products

Slides:



Advertisements
Similar presentations
Requirements Engineering Processes – 2
Advertisements

June 27, 2005 Preparing your Implementation Plan.
1 Senn, Information Technology, 3 rd Edition © 2004 Pearson Prentice Hall James A. Senns Information Technology, 3 rd Edition Chapter 7 Enterprise Databases.
Chapter 1: The Database Environment
Chapter 7 System Models.
Requirements Engineering Process
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 1 Embedded Computing.
Systems Architecting An introduction.
Object Oriented Development For DoDAF System of Systems
1 IEEE Media Independent Handoff Overview of services and scenarios for 3GPP2 Stefano M. Faccin Liaison officer to 3GPP2.
UNITED NATIONS Shipment Details Report – January 2006.
Document #07-2I RXQ Customer Enrollment Using a Registration Agent (RA) Process Flow Diagram (Move-In) (mod 7/25 & clean-up 8/20) Customer Supplier.
1 Hyades Command Routing Message flow and data translation.
1 Introducing the Specifications of the Metro Ethernet Forum MEF 19 Abstract Test Suite for UNI Type 1 February 2008.
18 Copyright © 2005, Oracle. All rights reserved. Distributing Modular Applications: Introduction to Web Services.
Introduction to Navigation Specifications
Module N° 7 – Introduction to SMS
EA Demonstration Study : Dissemination Forum – 8 June EA Views and Sub-views Patrick Bardet EA Unit.
EA Demonstration Study : Dissemination Forum – 8 June EAEA Framework Proposal Paolo Monaco EA Unit.
BUILDING THE CAPACITY TO ACHIEVE HEALTH & LEARNING OUTCOMES
Making the System Operational
Site Safety Plans PFN ME 35B.
1 Implementing Internet Web Sites in Counseling and Career Development James P. Sampson, Jr. Florida State University Copyright 2003 by James P. Sampson,
Privacy Impact Assessment Future Directions TRICARE Management Activity HEALTH AFFAIRS 2009 Data Protection Seminar TMA Privacy Office.
Week 2 The Object-Oriented Approach to Requirements
EMS Checklist (ISO model)
Chapter 5 – Enterprise Analysis
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
1 Quality Indicators for Device Demonstrations April 21, 2009 Lisa Kosh Diana Carl.
Testing Workflow Purpose
Legacy Systems Older software systems that remain vital to an organisation.
Use Case Diagrams.
1 INCOSE Chesapeake Chapter Enterprise SE Panel Discussion L. Mark Walker/LMC 21 March 2007.
Heppenheim Producer-Archive Interface Specification Status of standardisation project Main characteristics, major changes, items pending.
Chapter 2 Using Information Technology for Competitive Advantage Copyright 2001, Prentice-Hall, Inc. MANAGEMENT INFORMATION SYSTEMS 8/E Raymond McLeod,
Database System Concepts and Architecture
Executional Architecture
Functional Areas & Positions
Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
Chapter 10: The Traditional Approach to Design
Systems Analysis and Design in a Changing World, Fifth Edition
James A. Senn’s Information Technology, 3rd Edition
Database Administration
© Prentice Hall CHAPTER 15 Managing the IS Function.
PSSA Preparation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 13 Slide 1 Application architectures.
NIMS Resource Management IS-700.A – January 2009 Visual 5.1 NIMS Command and Management Unit 5.
© Copyright 2011 John Wiley & Sons, Inc.
Representations and Models: SysML and Beyond David Long Vitech Corporation SEDC
DoDAF V2.0 Community Update Overview
DoD Architecture Framework Overview
Connecting People With Information DoD Net-Centric Services Strategy Frank Petroski October 31, 2006.
Security Extensions to the DOD Architecture Framework Kevin Richardson Information Assurance Lab Auburn University Computer Science and Software Engineering.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Software Configuration Management
Technical Integrity Assurance For Product Development W. Henson Graves Lockheed Martin Aeronautics Company Russ Campbell.
Copyright © 1997 by Rational Software Corporation Midterm Exam  When: 3:30 – 4:50PM, Thursday, October 4, 2012  Where: HM 201s  Format  Close book.
Software Requirements Engineering CSE 305 Lecture-2.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Lecture 7: Requirements Engineering
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
I n t e g r i t y - S e r v i c e - E x c e l l e n c e As of: 3/1/2016 Air Force Weather Agency CEISC Committee Focus Shift - Proposed Modification to.
IPDA Architecture Project International Planetary Data Alliance IPDA Architecture Project Report.
Physical Data Model – step-by-step instructions and template
NDIA Architecture Analysis for System-of-System (SoS) Interoperability Assessment Karen L. Lauro, Ph.D Oct 21, 2003.
CV-1: Vision The overall vision for transformational endeavors, which provides a strategic context for the capabilities described and a high-level scope.
Version 3 April 21, 2006 Takahiro Yamada (JAXA/ISAS)
DoD Architecture Framework Overview
, editor October 8, 2011 DRAFT-D
Systems Architecture & Design Lecture 3 Architecture Frameworks
Presentation transcript:

Understanding the DoD Architecture Framework Products Mason Myers DoD Architecture Framework Overview October 27, 2004

Federal Policy/Guidance on Architectures DoD Architecture Framework Information Technology Management Reform Act (1996) mandates that Chief Information Officers of Executive Agencies are responsible for “developing, maintaining, and facilitating implementation of sound and integrated information technology architecture for the executive agency” OMB Circular A-130 defines Enterprise Architecture as “the explicit description and documentation of the current and desired relationships among business and management processes and information technology” DoD Architecture Framework Overview October 27, 2004

DoD Policy on Using Architectures DoDD 8000.1, Management of DoD Information Resources and Information Technology DoDD 8100.01, Global Information Grid Overarching Policy DoDD 5000.1, The Defense Acquisition System, (12May2003) DoDI 5000.2, Operation of the Defense Acquisition System, (12May2003) CJCSI 3170.01C, Joint Capabilities Integration and Development System CJCSI 6212.01C, Interoperability and Supportability of National Security Systems and Information Technology Systems DoDD 4630.5, Interoperability and Supportability of Information and National Security Systems DoDI 4630.8, Procedures for Interoperability and Supportability of Information Technology and National Security Systems Recent DoD policy highlights use of architectures for: Understanding the DoD as an enterprise Identification of operational requirements Rationalization of IT investment decisions Improvements to interoperability among various systems DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework DoDD 5000.1 and .2 Oversight & Review ACAT ID/IAM Programs* Defense Acquisition Executive Chief Information Officer Defense Acquisition Board IT Acquisition Board Weapon Systems C3ISR Systems Major AIS Overarching Integrated Product Teams (OIPT) C3I Overarching Integrated Product Team (OIPT) *Note: Space Programs have been delegated to the Air Force and most missile defense programs to the Missile Defense Agency DoD Architecture Framework Overview October 27, 2004

Architecture Definition Architecture “The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.” DoD Integrated Architecture Panel, 1995, based on IEEE STD 610.12 “An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” IEEE STD 1471-2000 Architecture = Structure of Components Relationships Principles & Guidelines + + DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework (DoDAF) Purpose DoD Architecture Framework An architecture framework is a tool It should describe a method for designing an information system in terms of a set of building blocks and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. DoD Architecture Framework Overview October 27, 2004

History of DoD Architecture Framework DoD Architecture Framework Version 2.0 2003 C4ISR Architecture Framework Version 2.0 Architecture Framework Working Group DoD Architecture Coordination Council C4ISR Architecture Working Group Dec 1997 C4ISR Architecture Framework Version 1.0 C4ISR ITF Integrated Architectures Panel Prior Community Experiences June 1996 DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework DoD Architecture Framework DoDAF provides guidance on describing architectures in order to standardize this method of description Standardized architecture description approaches improve possibilities for architecture consistency and reuse An architecture description is a representation of: a current or future point in time, a defined “domain” in terms of its component parts, what those parts do, how the parts relate to each other, and the rules and constraints under which the parts function DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework DoD Architecture Framework DoD Architecture Framework is partitioned into two volumes and a deskbook Volume I provides definitions, guidelines, and related background material Volume II contains descriptions and examples/templates for each of the 26 products The Deskbook provides supplementary information to Framework users All three available on Internet at http://www.aitcnet.org/dodfw/ DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework DoD Architecture Framework DoDAF supports development of interoperating and interacting architectures DoDAF defines three related views of an architecture and products describing each of these views Operational View Systems View Technical Standards View DoD Architecture Framework Overview October 27, 2004

DoDAF Operational View DoD Architecture Framework Operational View (OV) is description of tasks and activities, operational elements, and information exchanges required to accomplish DoD missions OV contains graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes OV defines types of information exchanged, frequency of exchange, which tasks and activities are supported by the information exchanges, and nature of information exchanges DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework DoDAF Systems View Systems View (SV) is set of graphical and textual products that describes systems and interconnections providing for, or supporting, DoD functions SV associates systems resources to the Operational View These system resources support operational activities and facilitate exchange of information among operational nodes DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework DoDAF Technical View Technical View (TV) is minimal set of rules governing arrangement, interaction, and interdependence of system parts or elements TV provides technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed TV includes collection of technical standards, implementation conventions, standards options, rules, and criteria organized into profiles that govern systems and systems elements for a given architecture DoD Architecture Framework Overview October 27, 2004

Relationship Between DODAF Views One Architecture, multiple views or perspectives DoD Architecture Framework Overview October 27, 2004

DoDAF Products – All Views and Operational View Applicable Architecture View Product Reference DoDAF Product Essential or Supporting All Views AV-1 Overview and Summary Information Essential AV-2 Integrated Dictionary Operational OV-1 High-Level Operational Concept Graphic OV-2 Operational Node Connectivity Description OV-3 Operational Information Exchange Matrix OV-4 Command Relationships Chart Supporting OV-5 Activity Model OV-6a Operational Rules Model OV-6b Operational State Transition Description OV-6c Operational Event/Trace Description OV-7 Logical Data Model DoD Architecture Framework Overview October 27, 2004

C4ISR Architecture Framework Example In order to demonstrate examples of the contents of some of the DoD Architecture Framework products, assume that we will analyze the application domain for a Border and Coastline Surveillance System (BCSS) that should provide aerial coastline and border surveillance and reporting for the United States Border Patrol and Drug Enforcement Agency DoD Architecture Framework Overview October 27, 2004

Overview and Summary Information Product (AV-1) The Overview and Summary Information Product (AV-1) of the DoD Architecture Framework is used to document the Identification, Purpose, Scope, Intended Users, and Context of the system or system-of-systems that is being described. DoD Architecture Framework Overview October 27, 2004

Overview and Summary Information Product (AV-1) for BCSS Identification – The BCSS is to be developed for the Department of Homeland Security to meet the BCSS mission roles. Purpose – The BCSS will employ autonomous, long-endurance drone aircraft to patrol both land and water border regions in order to detect unauthorized incursions and notify ground personnel. Scope – The BCSS development project will develop, demonstrate, integrate, deliver, and maintain the air vehicle, ground station, mission planning, and logistics functionalities that comprise BCSS. DoD Architecture Framework Overview October 27, 2004

Overview and Summary Information Product (AV-1) for BCSS Intended Users – BCSS will be used by the U.S. Border Patrol and the Drug Enforcement Agency to monitor the borders and coastal waters to detect possible unauthorized incursions into the United States and to notify authorities to investigate these incursions. Context – BCSS is to be a system that employs an autonomous, long-endurance drone aircraft capable of integration into civilian airspace and of sharing surveillance data with other aircraft as well as with its mission monitoring station. DoD Architecture Framework Overview October 27, 2004

Integrated Dictionary Product (AV-2) The Integrated Dictionary Product (AV-2) of the DoD Architecture Framework is to define terms used in the given architecture AV-2 consists of textual descriptions in form of glossary, repository of architecture data, their taxonomies, and their metadata (data about architecture data) AV-2 enables set of architecture products to stand alone, allowing them to be read and understood with minimal reference to outside resources DoD Architecture Framework Overview October 27, 2004

High-Level Concept Graphic Product (OV-1) The High-Level Concept Graphic Product (OV-1) of the DoD Architecture Framework is used to depict a high-level graphical description of the proposed system and its internal and external interdependencies. OV-1 serves as a facilitating diagram for explaining the system elements and interfaces and for showing the system’s role as an element of the encompassing system-of-systems. DoD Architecture Framework Overview October 27, 2004

High-Level Concept Graphic Product (OV-1) for BCSS DoD Architecture Framework Overview October 27, 2004

Operational Node Connectivity Description Product (OV-2) The Operational Node Connectivity Description Product (OV-2) of the DoD Architecture Framework is used to depict the operational nodes and elements of the architecture, the needlines between them, and the characteristics of the information exchanged. OV-2 serves as a facilitating diagram for further defining the interfaces and information to be exchanged and for showing the system’s role as an element of the encompassing system-of-systems OV-2 is frequently done at both the system-of-systems and system levels. DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework System-of-Systems Operational Node Connectivity Product (OV-2) for BCSS DoD Architecture Framework Overview October 27, 2004

System-Level Operational Node Connectivity Product (OV-2) for BCSS - Flight control - Mission track BCSS - Surveillance - Status reporting Aircraft BCSS Mission Planning Node - A/C deconfliction Route Planning Mission Validation Node - Subsystems - Control commands diagnostics - A/C status - Diagnostic commands - Contact reports - Diagnostic status Mission Plans Mission Updates - Mission updates - Power-up/power-down sequencing commands - A/C monitoring BCSS Ground BCSS - A/C maintenance - Mission monitoring - Ground station Station Support - Contact reporting maintenance - Contingency handling Node Node - Operator training - A/C status - Ground station status - Training scenario - Control commands commands - A/C status - Contact reports - Mission updates BCSS Simulation Node - A/C simulation DoD Architecture Framework Overview October 27, 2004

Operational Information Exchange Matrix (OV-3) The Operational Information Exchange Matrix (OV-3) of the DoD Architecture Framework details information exchanges and identifies who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur OV-3 identifies information elements and relevant attributes of information exchange and associates the exchange to the producing and consuming operational nodes and activities and to the needline that the exchange satisfies DoD Architecture Framework Overview October 27, 2004

Operational Information Exchange Matrix (OV-3) OV-3 contains the information in the following categories for each Information Element: Information Element Description Producer and Consumer Identification Nature of Transaction Performance Attributes Information Assurance Security DoD Architecture Framework Overview October 27, 2004

DoDAF Products – Systems View Applicable Architecture View Product Reference DoDAF Product Essential or Supporting Systems SV-1 System Interface Description Essential SV-2 Systems Communication Description Supporting SV-3 Systems2 Matrix SV-4 Systems Functionality Description SV-5 Operational Activity to System Function Traceability Matrix SV-6 System Information Exchange Matrix SV-7 System Performance Parameters Matrix SV-8 System Evolution Description SV-9 System Technology Forecast SV-10a System Rules Model SV-10b Systems State Transition Description SV-10c Systems Event/Trace Description SV-11 Physical Data Model DoD Architecture Framework Overview October 27, 2004

System Interface Description Product (SV-1) The System Interface Description Product (SV-1) of the DoD Architecture Framework is used to depict the assignments of systems and their interfaces to the nodes and needlines identified in the OV-2 diagram SV-1 serves to specify which interfaces correspond to which systems and contributes to the identification of other systems with which coordination must be established SV-1 is frequently done at both the system-of-systems and system levels DoD Architecture Framework Overview October 27, 2004

System-of-Systems Interface Description Product (SV-1) for BCSS DoD Architecture Framework Overview October 27, 2004

System-Level Interface Description Product (SV-1) for BCSS BCSS Mission Planning Node Route Planning Mission Validation Mission Distribution Files for mission plans and updates DoD Architecture Framework Overview October 27, 2004

DoDAF Products – Technical Standards View Applicable Architecture View Product Reference DoDAF Product Essential or Supporting Technical TV-1 Technical Standards Profile Essential TV-2 Standards Technology Forecast Supporting DoD Architecture Framework Overview October 27, 2004

Technical Standards Profile (TV-1) The Technical Standards Profile (TV-1) of the DoD Architecture Framework provides technical systems implementation standards upon which engineering specifications are based, common building block are established, and product lines are developed TV-1 consists of set of systems standards rules that govern system implementation and operation of that architecture including what hardware and software may be implemented and what system data formats may be used DoD Architecture Framework Overview October 27, 2004

Technical Standards Profile (TV-1) Template Example DoD Architecture Framework Overview October 27, 2004

DoD Architecture Framework Conclusion Our DoD customers are being instructed to describe their system architectures for milestone review meetings using DoDAF products Some Boeing programs are using DoDAF products in their documentation J-UCAS has an Architecture Description Document that uses DoDAF products to capture their system architecture Boeing systems engineers need to become familiar with developing and using the DoDAF products DoD Architecture Framework Overview October 27, 2004