DoD Architecture Framework Overview

Alessio Mosto
May, 2004
Outline
DODAF Definitions and Purpose
DODAF Products
DODAF Documents Overview
Future Evolution of DODAF

Q&A
DoD Architecture Framework 1.0
The Department of Defense (DoD) Architecture Framework (DODAF)
Defines a common approach for describing, presenting, and comparing DoD enterprise architectures
Facilitates the use of common principles, assumptions and terminology

The principal objective is to
Ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multi-national boundaries
History of the Framework
DoD Policy
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
Architecture Definition
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 vs. Design
System Architecture is used to:
Make buy decisions
Discriminate between options
Discover the true requirements
Drive one or more systems to a common use or purpose

System Design is used to:
Develop system components
Build the system
Understand configuration changes as the system is modified
Enterprise competitive edge
An enterprise’ s competitive edge and ultimate success are enabled by its ability to rapidly respond to changing business strategies, governance, and technologies
The DoD environment spells this competitive edge as victory
The competitive edge translates into higher levels of customer satisfaction, shorter work cycles, and reductions in schedules, maintenance costs, and development time, all resulting in lower overall cost of ownership
Enterprise Architecture
Enterprise Architecture is the key facilitating ingredient providing a holistic view and a mechanism for enabling the design and development as well as the communication and understanding of the enterprise
The overarching goals of enterprise architecture are to manage the complexity of the enterprise, align business strategies and implementations, and facilitate rapid change in order to maintain business and technical advantages
Enterprise vs. System
System Architecture is like blueprints for a building

Enterprise Architecture is like urban planning
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. [TOGAF 8, OpenGroup]
Basic Principles – An Integrated Architecture with Three Views
DODAF Products – Graphic, Textual, and Tabular
DODAF Products
The DODAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture
The 26 DODAF views are designed to document the entire architecture, from requirements to implementation
DODAF Products – Views
The list of products is refined into four views:
All Views (AV): is the overarching information describing the architecture plans, scope, and definitions
Operational View (OV): focuses on the behaviours and functions describing the enterprise mission aspects
System View (SV): describes the system and applications supporting the mission functions
Technical Standards View (TV): describes the policies, standards and constraints
DODAF Products
DODAF Products
DODAF Products

DODAF Products – Essential
The current DODAF version indicates a subset of work products that should be developed at a minimum (essential)
AV-1: Overview and Summary Information
AV-2: Integrated Dictionary
OV-2: Operational Node Connectivity Description
OV-3: Operational Information Exchange Matrix
OV-5: Operational Activity Model
SV-1: System Interface Description
TV-1: Technical Standards Profile
AV-1 & AV-2
OV-2 -Operational Node Connectivity Description
OV-3 -Operational Information Exchange Matrix
Table Headers Specified in Framework:
Name of Operational Needline Supported (from OV-2)
Name of Information Exchange
Nature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?)
Purpose or Triggering Event
Information Source (ID of Producing Node Element, Owning Organization of Node, Name of Producing Activity, UJTL ID)
Information Destination (ID of Receiving Node Element, Owning Organization of Node, Name of Receiving Activity, UJTL ID)
Performance Requirements (Frequency, Timeliness, Throughput, Other)
Information Assurance Attributes (Classification Restrictions, Criticality/Priority, Integrity Checks Required, Assured Authorization to Send/Receive)
Threats (Physical, Electronic, Political/Economic)
Operational Environment (Weather, Terrain, Policy/Doctrine Constraints)
OV-5 -Operational Activity Model
SV-1 -System Interface Description
TV-1 -Technical Standards Profile
Problems
Conspicuously absent are the all-important business, financial, and technical analysis of alternatives -information needed to drive enterprise architectural decisions
DoD Architecture Framework
Volume I: Definitions, Guidelines , and Background
Covers value of architectures, measures, use in DoD processes
Volume II: Product Descriptions
Covers Structured Analysis and UML Representations
Deskbook: Architecture Guidance
Provides guidance on development, use, incorporating security into the architecture
Release Date -November 2003
Web Site:
aitc.aitcnet.org/dodaf/
Key Changes in Volume II
Guidance on developing architecture products using UML
Greater emphasis on architecture data underlying the architecture products
Future Evolution Areas
Define a DODAF Object Model to:
Validate and Clarify the information definitions provided by the DODAF
To capture the architecture data elements (object and relationships) described by DODAF
Use DODAF definitions to define an object model

Validate and Clarify the notation definitions intended by DODAF
Adjust the object and relationship definitions to include graphics (e.g., modeling notation) and/or formatting characteristics that are required to be common
Facilitate the common usage of such a model
Define an ontology: identify the generalizations / specializations (supertypes / subtypes) that are appropriate
Provide clear, concise descriptions for all the data elements
Future Evolution Areas (Cont’ d)
Benefits – A DODAF object model will:
Provide a common set of objects and relationship definitions (requirements) that can be used by tool vendors to supply software tools that support the development of DODAF-Compliant architectures

Provide a common set of objects and relationship definitions against which a standard interface can be defined to:
Enable the sharing of architecture model / products between different tools
Enable the implementation of a common repository for architecture data
Future Evolution Areas (Cont’ d)
Define a common ontology of architecture elements
Address baseline (current) and objective (target) architectures
Address use of architectures to measure mission effectiveness (capabilities and measures of effectiveness)
DODAF prospect
February 9, 2004. Department of Defense CIO John P. Stenbit approved Version 1.0 of the Department of Defense Architectural Framework (DODAF) for immediate use. All architectures developed or approved after December 1, 2003 must comply with the new framework. Architectures developed prior to that date must be converted upon any version updates

Not only for military mission and for DoD
Also for civilian enterprise
Q&A

References
Department of Defense Architecture Framework Working Group. DoD Architecture Framework Ver. 1.0. Washington, D.C.: Department of Defense, Nov. 2003 aitc.aitcnet.org/dodaf

DoD Architecture Framework Overview -Dr. Fatma Dandashi -October 2003 www.opengroup.org/public/member/ proceedings/q403/dandashi.pdf

Enterprise DoD Architecture Framework and the Motivational View -D.B. Robi -Open Forum, April 2004 www.stsc.hill.af.mil/crosstalk/2004/04/0404Robi.html
References
Leveraging DoD/C4ISR Architecture Framework Products for Developmental and Operational Testing -Annette Ensing (The MITRE Corporation) and LTC Phil Hallenbeck (USA Operational Test Command) -The Software Technology Conference, May 2002 www.stc-online.org/stc2002proceedings/ SpkrPDFS/ThrTracs/p728.pdf

DoD Architecture Framework and Software Architecture Workshop Report -March 2003 www.ichnet.org/DODAF%20SEI%20report.pdf

Breakout Session 10B Outbriefing -James Martin -Ground System Architectures Workshop, 2004 sunset.usc.edu/gsaw/gsaw2004/s14/10b_outbrief.pdf

Sotware Productivity Consortium www.software.org/
Thanks
Open Group
Open Group is an international vendor and technology-neutral consortium

TOGAF, The Open Group Architecture Framework, is an industry standard architecture framework that may be used freely by any organization wishing to develop an information systems architecture for use within that organization

Categories: News