# Presentation: 562922

## DoD Architecture Framework V 1.0 

**Dr. Fatma Dandashi**
- The MITRE Corporation** **
- April 8, 2003

** **

## Context and Relationship To This Audience

**Context and Relationship To This Audience**

**Manufacturing (Hardware Parts)****AP233**

**Systems Engineering****Processes and Modeling Standards**

**Mission Needs/****Information Interoperability Requirements**

**Software Parts/****Information****UML/XMI**

**Industry Standards**

**Systems of Systems****(Software Intensive)**

## Architecture Defined

**Architecture**
** ****	**"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 Description**
- Graphical, tabular or textual representations of the architecture
**Architecture Discipline**
- A discipline for developing and analyzing an architecture in terms of its processes, components, and their relationships and rules.

**Architecture**

**=**

**Structure of**
**Components**

**Relationships**

**Principles &**
**Guidelines**

**+**

**+**

## Why Architecture?

**Architecture is about structure and relationships**
- Making things fit together and work together well
**Architecture is about Categories to identify and clarify, facilitate reuse, eliminate redundant efforts**

**Economy Demands**** **

**  ****Things Fit Together And Work Well With Minimal Investment, **
**  ****Taking Advantage Of Reuse, And **
**-  Eliminating Unnecessary Redundant Efforts**

## Parallel Revolutions

***Information***
***Revolution***

** ****Widespread E-Commerce **
** ****Wideband Internet to Homes**

** ****Apple****  Personal Computer **

** ****Internet****  Goes ‘Public’**

** ****Low Cost Cell****  Phone Service**

** ****Windows**
**95**

** ****Windows**
**98**

** ****Windows**
**2000/XP**

***U.S.***
***Dept of Defense***

** ****PPBS Process Changes?**
** ****Capabilities-Based Acquisition?**
** ...****???**

** *****Goldwater-Nichols *****Act**

** ****DARPA Focuses on***** Infotech***

** ****Strategic Defense Initiative**

** ****Joint Force in ****  Gulf War**

** ****JV2010 – Integrated****  Defense Strategy**

** ****Joint Staff Begins**
**Architecture Focus**

** ****JFCOM Formed**
** ****C4ISR AF **
** ****JV2020**

** ****Terrorism**
**Strikes US**
**(9/11)**

** ****Dept of Homeland Security**
** ****DOD 5000 Acquisition****  Reformed**
** ****DoDAF Version 1 *****Required***
** ****DAB Reviews JMA**
** ****CJSCI 3170 (Draft)**

*** ******Clinger-Cohen***** Act**

** ****Digital Wireless****  Phones Introduced**

** ****End of the Soviet Empire **
** ‘****Fall of the Wall’**

## Need for Integrated Architecture Descriptive Products

**Must integrate many business processes, data flows, much infrastructure**
**Need a description and structure of how to work together**
**Need integrated set of products to capture relationships for understanding and analysis**
**Need to assess dependencies and impacts**

_**Systems of Systems**_

_**Agency**_

_**Cross Agency**_

**- Must have architecture,****  To document/ analyze ****  interfaces**
**- Assess impacts and ****  dependencies**

**- How agency achieves mission,****- what are priorities**
**- Use architecture for how****  sharing, intertwined processes,****  communications occur**
**- Assess impacts and dependencies**

**- Use reference models to identify****  similar functions, efforts, ****  potential joint work;**
** ****Use architecture for how****  sharing, intertwined processes,**
**  ****communications occur**

**Need for Integrated Architecture Descriptive Products**

## Policy and Guidance on Architecture  – Mandate for Architectures

**Information Technology Management Reform Act (ITMRA)/Clinger-Cohen Act. (1996)**
-  Mandates that Chief Information Officers of Executive Agencies are responsible for “developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the executive agency “.

**Executive Order 13011: Federal Information Technology**** (1996).  **
- Executive Agencies shall appoint a Chief Information Officer and “shall refocus information technology management to support directly their strategic missions, implement an investment review process that drives budget formulation and execution for information systems, and rethink and restructure the way they perform their functions before investing in information technology to support that work.”

**Chief Information Officer of the Department of Defense.****  **
- Review and provide recommendations to the Secretary of Defense on Department of Defense budget requests for information technology and national security systems.

## DoD Policy on Using Architectures

- DoDD 4630.5, Interoperability and Supportability of Information Technology (IT) and National Security Systems, January 11, 2002
- DoDI 4630.8, Interoperability and Supportability of Information Technology (IT) and National Security Systems, May 2, 2002
- DoDD 8000.1, Management of DoD Information Resources and Information Technology, February 27, 2002
- DoDD 8100.01, Global Information Grid Overarching Policy, September 19, 2002
- DoDI 5000.2, Operations of the Defense Acquisition System, draft October 2002
- CJCSI 3170.01C, Joint Capabilities Integration and Development System, draft 2003 (Replacement for Requirements Generations System)

**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

## Policy Enabled by Common Approach for Developing Architectures

**DoD Architecture Framework (DODAF)**

**Common approach for developing an architecture description**

**Core Architecture Data Model (CADM)**

**Common data model for architecture data**

**DoD Architecture Repository System (DARS)**

**Common repository for storing and retrieving architecture data **

***DoD Guidance on Developing Architectures***

## Increased Emphasis on Meta-Data Standardization

**Each DODAF product description**
-  Information Element Definition Table
-  CADM Support
**Core Architecture Data Model (CADM)**
- Build Architectures IAW CADM
**DoD Architecture Data Repository (DARS)**
-  CADM compliant data repository
-  Hosts accredited DoD architecture information

## DODAF Core Data Elements

- Facilities,
- Locations,
- Units, and
- Platforms

**DODAF Product data Elements, CADM Model, & Basis for DARS Schema**

## Core Architecture Data Model (CADM)

***  Products convey relationship****   between architecture data****   elements**

**CADM Schema **
**of Product field contents**

**Activity Model**

**Systems Interface Description**

**DODAF Product**

**DODAF Arch Data Element**

**Core Architecture Data Model (CADM)**

## DARS Architecture

**TCP/IP Port 1521**

**Tape back-up**

**Oracle 9.2**
**Database**
**Server**

**Tape back-up**

**Oracle**
**Internet**
**Application**
**Server**
**R2 w/ Oracle Portal**

**FIREWALL**

**Desktop with**
**Internet Explorer****Modeling Tools**** (System Architect)**

**Desktop with**
**Internet Explorer**
**Modeling Tools (SLATE)**

**Desktop with**
**Internet Explorer****Modeling Tools (ROSE)**

**HTTP Port 443**

**Various Users, ****Various Modeling Tools**

**Architecture Data, ****CADM Schema**

## Benefits of Architecture Meta-Data Standardization

- Reuse of data
- Consistency that facilitates integration
- Flexibility in partitioning of data from different points of view
- Ability to use automated architecture and modeling tools interchangeably
- Better support for analysis and decision-making

- Increased emphasis on development of *integrated architectures*
- De-emphasis of an architecture product-by-product approach

## Developing a DoD Enterprise Architecture

***Distributed***
***Architecture Development***

***in accordance with***

***Results in ...***

**  ****Assures that architectures ****    are integratable across the ****    community**
**  ****Establishes threads that tie ****    the architecture views ****    together**
**  ****Provides the basis for an ****    audit trail that relates ****    systems to measures of ****    mission effectiveness**

**Joint **
**Mission**
** ****Areas**

**NEO JTF**

**Targeting/BDA**

**AF**
**Task**
**Force**

**  ****Integratable architectures that exploit opportunities for integrated, interoperable, and cost-effective capabilities**

**Developing a DoD Enterprise Architecture**

**Joint Mission Areas**

**AF**
**Task**
**Force**

**Targeting**
**& BDA**

**Tactical**
**Internet**

**Military**
**Service**

**NEO JTF**

**CC**

**NIMA**

**Global Information Grid**

**IC**

**National**

**Theater**

**CJTF**

**Tactical**

**Tactical**
**Internet**

**Global Information Grid**

**IC**

**Military**
**Service**

## DoD Architecture Framework

**The Department of Defense (DoD) Architecture Framework (DODAF)**
- Defines a standard approach for describing, presenting, and integrating DoD architectures
**The principal objective of the Framework is to **
- Ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multi-national boundaries

## DoD Architecture Framework

**DoD Architecture Framework**

**DODAF is partitioned into **
- Volume I: Definitions, guidelines, and background material
- Designed for managers
- Volume II: Descriptions of products
- Designed for architects and engineers
- Deskbook: Supplementary material (How to)
- guidance on architecture development and use
- Designed for engineers
**Expected Release – June 2003**
**Available on the Web**
- http://flrc.mitre.org/dodfw/

## Basic Principles - An Integrated Architecture with Three Views

***Systems***

**Basic Principles - An Integrated Architecture with Three Views**

***Information Flow***

***Operational***
***Nodes***

***Data Flow***

***Communications***

- Prescribes Technical Standards

**Technical**
**Standards View**

***Standards***

***Services***

***Activities/***
***Tasks***

- Specific Capabilities Required  to SatisfyInformation Exchanges

- Technical Criteria GoverningInteroperable Implementation/Procurement of the SelectedSystem Capabilities

- Basic Technology Supportability
- New Technical Capabilities

- What Needs to Be Done
- Who Does It
- Information Exchanges Required to Get It Done

- Identifies Participant
- Relationships
- And Information Needs

**Operational **
**View**

- Relates Systems Capabilities to
-  Operational Requirements

**Systems**
**View**

- Operational Capability Requirements

***Service Areas***

- Systems that Support the Activities and Information Exchanges

## Basic Principles - Graphic, Textual, and Tabular Products

**Operational Concept Description (OV-1)**

**Activity Model (OV-5)**

**Information Exchange Matrix (OV-3)**

**System Functionality Description (SV-4)**

**Systems Data Exchange Matrix (SV-6)**

**Operational Activity Sequence and Timing Description (OV-6 a/b/c)**

**Systems Communications Description (SV-2)**

**System - System Matrix (SV-3)**

**Systems Technology Forecast (SV-9)**

**Standards Technology Forecast (SV-9)**

**Technical Architecture Profile (TV-1)**

**Systems Performance Parameters Matrix (SV-7)**

**Logical Data Model (OV-7)**

**Systems Functionality Sequence and Timing Description (SV-10  a/b/c)**

**Systems Evolution Description (SV-8)**

**Physical Schema**
**SV-11**

## Systems Architecture Viewpoints*Relationship to DODAF

- ISO standard ISO/IEC 10746-1: Reference Model – Open Distributed Processing (RM-ODP)

| RM-ODP View Points | Expresses | DoD Framework products | DoD Framework UML Products |
| --- | --- | --- | --- |
| Enterprise Viewpoint | Business activities supported by the system | IDEF0 Diagrams | Use Cases, Use Case Diagrams and related Diagrams |
| Computational Viewpoint | Logical decomposition of the system as a set of class objects/subsystems | Data Flow Diagrams | Classes, Class Diagrams, and related Diagrams |
|  | Threads of control, which carry out the computation elements | Statecharts | Statechart & Activity Diagrams, Sequence Diagrams |
| Engineering Viewpoint | Mechanisms to support distribution of functionality | Physical Distribution | Component and Deployment Diagrams |
| Information Viewpoint | Data managed by the system | Data Models, Physical Data SchemaRelational Databases | Sequence and Collaboration diagrams, Class Diagrams, OO DBs |
| Technology Viewpoint | The system and its environment that focuses on the choice of technology in that system. | Matrices | Technology standards and properties attached to systems and subsystems |

## Evolution of the Framework & Timeline Road Map

**DoD Architecture **
**Coordination **
**Council**

***C4ISR Architecture ***
***Framework ***
***Version 2.0***

***June 1996***

***Dec 1997***

**C4ISR ITF**
**Integrated Architectures**
** ****Panel**

**Prior Community Experiences**

**DoD Architecture**
**Framework**
**Version V 1.0**

***2002***

***OSD***
***Mandate***

***Feb 1998***

**Evolution of the Framework & ****Timeline Road Map**

**Lead by: Directorate for Architectures and Integration**
**OASD(C3I) **

**       ****Architecture**
**       ****Framework**
**       ****Working Group**

***2003***

## DODAF Architecture Products

| Applicable View | Framework Product | Framework Product Name |
| --- | --- | --- |
| All Views | AV-1 | Overview and Summary Information |
| All Views | AV-2 | Integrated Dictionary |
| Operational | OV-1 | High-Level Operational Concept Graphic |
| Operational | OV-2 | Operational Node Connectivity Description |
| Operational | OV-3 | Operational Information Exchange Matrix |
| Operational | OV-4 | Organizational Relationships Chart |
| Operational | OV-5 | Operational Activity Model |
| Operational | OV-6a, b, c | Operational Activity Sequence and Timing Descriptions |
| Operational | OV-7 | Logical Data Model |
| Systems | SV-1 | Systems Interface Description |
| Systems | SV-2 | Systems Communications Description |
| Systems | SV-3 | Systems-Systems Matrix |
| Systems | SV-4 | Systems Functionality Description |
| Systems | SV-5 | Operational Activity to Systems Function Traceability Matrix |
| Systems | SV-6 | Systems Data Exchange Matrix |
| Systems | SV-7 | Systems Performance Parameters Matrix |
| Systems | SV-8 | Systems Evolution Description |
| Systems | SV-9 | Systems Technology Forecast |
| Systems | SV-10a, b, c | Systems Functionality Sequence and Timing Descriptions |
| Systems | SV-11 | Physical Schema |
| Technical | TV-1 | Technical Standards Profile |
| Technical | TV-2 | Technical Standards Forecast |

**DODAF Architecture Products**

## Some DODAF Architecture Products

**(Business Process)**
_**Operational Activity **__**Model**_** **

**Analyze**
**Market**

**Information**

**Reports**

**Outputs**

**(Business Organization)**
**Operational Node Connectivity Description **

**HQ**

**Field**
**Office**

**DP**
**Center**

**Phone**
**e-mail**

**Phone**
**e-mail**
**T3 Line,**
**Satellite**

**Phone**
**E-mail**

**Inputs**

_**Systems Interface Description**_

**System **
**Node**

**Interface**

**System**

**System **
**Node**

**System**

**System**

**System **
**Node**

**System**

_**Technical Standards Profile**_

_**Operational Information Exchange **__**Matrix**_** **

**Producing **
**Node**

**Producing **
**Activity**

**Receiving **
**Node**

**Receiving **
**Activity**

**Information**
**Needline**

**Information **
**Exchanged**

**Also Includes: ****Triggering Event**
**Description, ‘Properties’,**
**Performance, Security**

**Service Area      Service       Standard**

**Applications Software**

**Data               Document     XML 1.0**
**Interchange  Interchange**

**(Business Concept)**
_**High-Level Operational Concept **__**Graphic**_

**Importer/Exporter/**
**Broker**

**SAFE, LEGAL, OPEN TRADE**

**Carriers**

**Goods**

_**Overview and Summary**_

_**Integrated Dictionary**_**Dictionary allows capture of Arch definitions, relationships, attributes, rules**

**Some DODAF Architecture Products**

## Operational View Captures Critical Mission Relationships and Information Exchanges

**Node**

**A**

**Node**

**B**

- Activity 1 Activity 2

**Node**

**C**

- Activity 3

- Activity 2Activity 3

- Information Description
- Name/Identifier
- Definition
- Media
- Size
- Units
- Information Exchange Attributes
- Frequency, Timeliness,     Throughput
- Security
- Interoperability Requirements
- Information Source
- Information Destination

- Information Exchange 1

**High-Level Operational**
**Concept Description**

**Operational **
**Node Connectivity **
**Description**

**Operational Information**
**Exchange Matrix**

- High-level graphical
- description of the
- operational concept
- of interest

- Operational nodes,
- activities performed at
- each node, node-to-node
- relationships, and
- information needlines

- Summary of Information exchanged between nodes with  attributes, such as security, timeliness

- To
- External
- Node

- From
- External
- Node

**Operational View Captures Critical Mission Relationships and Information Exchanges**

**Operational Activity Model**

- Operational
- activities, information inputs and outputs, conditions

## Systems View Captures Systems, Functions Performed, Data, and Network Layout

**Systems Functionality Description SV-4**

- Can include systems,
- H/W & S/W Items, Interfaces (conceptual),
- System Functions

- Can include systems,
- communications nodes,
- networks, paths,
- Links forming path, protocols supported

- Includes data sources
- and sinks, repositories,
- data flows between
- system functions

**Systems View Captures Systems, Functions Performed, Data, and Network Layout**

- Describes planned systems evolution over time

## Technical Architecture Profile (TV-1) 

_**Dictionary Content**_

**Reference Model Name**

**Service Area Name**

**Service Name**

**Standard Name**

**System Name**

**System Hardware/****Software Item Name**

**Communications System Name**

**Communications Link Name**

_**Relationships in Dictionary**_

**Orange indicates Technical Architecture Elements**

**Green indicates system product Data Element**

**Technical Architecture Profile (TV-1) **

**Reference Model**
**Service Area**
**Service**
**Standard**
**System**
**System Hardware/Software Item**
**Communications System**
**Communications Link**
**Systems Data Exchange**
**System Function**
**Physical Schema Model**

**Systems Data Exchange**

**Physical Schema Model**

**System Function**

## Matrix of Products According to Use

**Requirements generation process**

**Products needed in Requirements Analysis**

**Matrix of Products According to Use**

## Matrix of Products According to Use

**Purpose **
- Provide guidance on which architecture products are applicable to various uses of architecture
**Emphasis and expectation**
- Architecture data underlying the products will be used to support the DoD core processes
- List of uses is not comprehensive but rather a summary of uses supporting DoD core processes

- Increased emphasis on development of integrated architectures and de-emphasis of an architecture product-by-product approach

- Requires tighter integration between staffs, operational, and acquisition communities

## DODAF Products and UML Representation

| Applicable View | Framework Product | Framework Product Name | UML Diagram |
| --- | --- | --- | --- |
| All Views | AV-1 | Overview and Summary Information | None: Produced from domain knowledge, diagram and element annotations |
| All Views | AV-2 | Integrated Dictionary | None: Produced from diagram and element annotations |
| Operational | OV-1 | High-Level Operational Concept Graphic | None: but may be produced via Use Case Diagrams, one for each use or mission Produced from domain knowledge |
| Operational | OV-2 | Operational Node Connectivity Description | Collaboration Diagrams for operational/ organizational nodes  |
| Operational | OV-3 | Operational Information Exchange Matrix | None: Produced from Collaboration or Sequence Diagram messages (OV-2 collaboration messages)+ additional adornments (e.g., IA attribute) |
| Operational | OV-4 | Organizational Relationships Chart | Class Diagrams, maps to OV-5 use case actors |
| Operational | OV-5 | Operational Activity Model | Use case Diagrams+ Activity Diagrams (to show threads)+ Sequence Diagrams (OV-6c) and StateChart Diagrams (OV-6b) |
| Operational | OV-6a | Operational Rules Model | None: Produced from pre- and post- conditions on OV-5 use cases, or derived from StateChart Diagrams supporting OV-5 and OV-7 diagram and element adornments |
| Operational | OV-6b | Operational State Transition Description | UML Statechart Diagrams |
| Operational | OV-6c | Operational Event-Trace Description | UML Sequence Diagrams |
| Operational | OV-7 | Logical Data Model | Class Diagrams |

## DODAF Products and UML Representation

| Applicable View | Framework Product | Framework Product Name | UML Diagram |
| --- | --- | --- | --- |
| Systems | SV-1 | Systems Interface Description |    Deployment Diagrams+ Component Diagrams for Intra-nodal and Intra-system version of SV-1 |
| Systems | SV-2 | Systems Communications Description |    Deployment Diagrams+ Component Diagrams for Intra-nodal and Intra-system version of SV-2 |
| Systems | SV-3 | Systems-Systems Matrix | None: Produced from SV-1/2 diagram and element adornments |
| Systems | SV-4 | Systems Functionality Description | Use Case Diagrams+ Class Diagrams (with operations)+ Collaboration Diagrams (to show data flows or exchanges) |
| Systems | SV-5 | Operational Activity to Systems Function Traceability Matrix | None: Produced from OV-5 & SV-4 diagram and element annotations.  information may be derived from operational sequence diagrams that are refined into system sequence diagrams |
| Systems | SV-6 | Systems Data Exchange Matrix | None: Produced from SV-1, SV-2, & SV-4 diagram and element annotations.  information may be derived from system sequence diagrams |

## DODAF Products and UML Representation

| Applicable View | Framework Product | Framework Product Name | UML Diagram |
| --- | --- | --- | --- |
| Systems | SV-7 | Systems Performance Parameters Matrix | None: Produced from SV-1, SV-2, & SV-4 diagram and element annotations |
| Systems | SV-8 | Systems Evolution Description | None: Domain Knowledge, and Framework Systems View Products |
| Systems | SV-9 | Systems Technology Forecast | None: Domain knowledge, Technology Knowledge, and Framework Systems View Products |
| Systems | SV-10a | Systems Rules Model | None: Produced from SV-4, SV-11 diagram and element annotations and constraints, or derived from StateChart Diagrams supporting SV-4 |
| Systems | SV-10b | Systems State Transition Description  | UML Statechart Diagrams |
| Systems | SV-10c | Systems Event-Trace Description | UML Sequence Diagrams |
| Systems | SV-11 | Physical Schema | Class Diagrams |

## DODAF Products and UML Representation

| Applicable View | Framework Product | Framework Product Name | UML Diagram |
| --- | --- | --- | --- |
| Technical | TV-1 | Technical Standards Profile | None: Produced from system elements and applicable Technical standards |
| Technical | TV-2 | Technical Standards Forecast | None: Produced from system elements and applicable Technical standards |

## Other Agencies Building The Same Sets Of Comparable Products And Data Elements

**Other Agencies Building The Same Sets ****Of Comparable Products And Data Elements**

## Other Countries Building Similar Sets Of Comparable Products And Data Elements

**Other Countries Building Similar Sets Of Comparable Products And Data Elements**

## DODAF V 1.0 - Summary

**DoD Issuances provide “teeth” for the architecture process**
**DoD Architecture Framework**
- Emphasis on developing and using architectures to support Department’s major processes
- Acquisition (5000),
- Requirements (3170),
- Budget processes
- Interoperability
- Model-Driven analysis based on a data-centric approach

## Contact Information

**Owner of the Architecture Framework:**
- OASD(C3I)/DoD CIO,
- The Directorate for Architectures and Integration
**Government Lead:  **
- Truman Parmele 703-607-0502
**Support for the Framework:**
- Fatma Dandashi   -  Mitre                 703-883-7914
- Huei-Wan Ang      -  Mitre                 703-883-6701
- Patsy McGrady     -  ACS-Defense   757-229-7887
**Available on the Web**
- http://flrc.mitre.org/dodfw/

## Backup Slides

## Operational Node Connectivity Description (OV-2)

## Operational Information Exchange Matrix (OV-3)

## Organizational Relationships Chart (OV-4)

## Operational Activity Model (OV-5)

## Operational Activity Model (OV-5)

## The Operational State Transition Description (OV-6b)

## The Operational Event-Trace Description (OV-6c)

## Logical Data Model (OV-7)

## Systems Interface Description (SV-1 & 2)

## Systems-Systems Matrix (SV-3)

**Interface characteristics:**
- Status (e.g., existing, planned, potential, de-activated)
- Purpose (e.g., C2, intelligence, logistics)
- Classification level (e.g., Secret, TS/SCI)
- Means (e.g., Joint Worldwide Intelligence Communications System, SIPRNet).

## Systems Functionality Description (SV-4)Use Case Diagram – 1/3

## Systems Functionality Description (SV-4)Class Diagram – 2/3

## Systems Functionality Description (SV-4)Collaboration Diagram – 3/3

## Operational Activity to Systems Function Traceability Matrix (SV-5)

## Systems Data Exchange Matrix (SV-6)

| Interface Identification | Data Exchange Identification | Data Exchange Identification |  |  |  |  |  | Nature of Transaction |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Systems Interface Name and Identifier | Systems Data Exchange Name and Identifier | Content Description | Format Type | Media Type | Data Standard | Units of Measurement | Accuracy | Transaction Type | Triggering Event | Interoperability Level |

## Systems Data Exchange Matrix (SV-6) Cont’d

| Producer |  | Consumer |  | Performance Attributes |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Sending System Name and Identifier | Sending System Function Name and Identifier | Receiving System Name and Identifier | Receiving System Function Name and Identifier | Periodicity | Timeliness | Throughput | Size |

| Information Assurance |  |  |  |  |  |  |  | Security |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Access Control | Availability | Confidentiality | Dissemination Control | Criticality | Integrity | Non-Repudiation Producer | Non-Repudiation Consumer | Protection (Type Name, Duration, Date) | Classification | Classification Caveat | Release-ability | Security Standard |

## Performance Parameters Matrix (SV-7)

***Hardware Element 1***

-       Maintainability

-       Availability

-       System Initialization Time

-       Data Transfer Rate

-       Program Restart Time

***S/W Element 1 / H/W Element 1***

-       Data Capacity (e.g., throughput or # of input types)

-       Automatic Processing Responses (by input type, # processed/unit time)

-       Operator Interaction Response Times (by type)

-       Effectiveness

-       Availability

-       Mean Time Between S/W Failures

-       Organic Training

***S/W Element 2 / H/W Element 1***

**System Name**

- Time

- 0

-  (Baseline)

- Time

- 1

- Time

- n

-  (Objective)

**Performance Thresholds/Measures**

***Hardware Element 2***

## Systems Evolution Description (SV-8)

***LEGACY***

***MAINFRAME***

***SYSTEM***

***FEDERATED***

***DISTRIBUTED***

***SYSTEM***

- CLIENT/SERVER

- PLATFORMS, LAN, &

- MIDDLEWARE INSTALLED

- SEGMENT 1 APPLICATIONS

- & UNIQUE DATA CONVERTED

- TO CLIENT/SERVER

- SEGMENT 2 APPLICATIONS

- & UNIQUE DATA CONVERTED

- TO CLIENT/SERVER

- SEGMENT 3 APPLICATIONS,

- & UNIQUE DATA CONVERTED

- TO CLIENT/SERVER

- COMMON DATA CONVERTED

- TO SHARED DATA SERVER

- NEW FUNCTION 1 &

- UNIQUE DATA IMPLEMENTED

- ON CLIENT SERVER (& INTEGRATED WITH

- COMMON DATA ON MAINFRAME)

- NEW FUNCTION 2 &

- UNIQUE DATA IMPLEMENTED

- ON CLIENT SERVER (& INTEGRATED WITH

- COMMON DATA ON MAINFRAME)

***V***

***1.0***

***V***

***1.1***

***V***

***1.2***

***V***

***1.3***

***V***

***1.4***

***V***

***2.0***

- +6 MO.

- +12 MO.

- +18 MO.

- +24 MO.

- +36 MO.

- +48 MO.

- +60 MO.

## Systems Technology Forecast (SV-9)

| TRM
TECHNOLOGY
CATEGORY | TECHNOLOGY FORECASTS |  |  |
| --- | --- | --- | --- |
|  | SHORT TERM
(0-6 Months) | MID TERM
(6-12 Months) | LONG TERM
(12-18 Months) |
| Application Software |  |  |  |
| Support Applications | Microsoft Office 2000 available (for Windows 2000)  | Microsoft Office 2000 stable enough for full scale implementation | Microsoft Office available for Linux
E-mail on wireless PDAs commonplace |
| Application Platform |  |  |  |
| Data Management | Oracle 9i available
MySQL (Open Source DBMS) available |  |  |
| Operating System |  | Next MS Windows desktop upgrade expected
Next Red Hat Linux major release expected | Next MS Windows server upgrade expected |
| Physical Environment |  |  | Intel IA-64 becomes standard processor for desktops
Initial use of quantum computing technologies |
| External Environment |  |  |  |
| User Interface  |  | Thin screen CRT monitors for PC desktops become price competitive | Thin screen LED monitors become price competitive for desktops
Conventional CRT technology monitors for desktops become obsolete |
| Persistent Storage | 5G PCMCIA type 2 card available |  | Disk storage capacity doubles again |
| Networks |  | Cable modem service available for most telecommuting staff | Fiber optic connections available for most telecommuting staff |

## Systems Functionality Sequence and Timing Descriptions (SV-10)

## Physical Schema (SV-11)

## DODAF UML Extensions 1/2

**Currently, the UML specification ties the deployment diagram to choices of hardware and software, and thus forces the use of deployment diagrams as implementation level descriptors of the technology**
**For the DODAF, nodes in a deployment diagram are associated with systems which are in turn associated with operational activities (use cases)**

## DODAF UML Extensions 2/2

**Need to assign or associate systems which may consist of combinations of hardware and software (stereotyped components), to physical locations (stereotyped deployment nodes), to organizations (actors, roles) responsible for conducting the operational activities, and to operational activities (use cases), *****without having to develop class diagrams***** as use case realizations that compose components. **
**Solution: The above relationships from organizations (actors), to operational activities (use cases), to systems (components), to systems nodes (deployment nodes) should be specified and maintained by the UML and UML modeling tools, without forcing the architect to realize use cases in class diagrams that detail system behavior.  The use case model element should have a direct *****residing-contained***** relationship with a component.  Actors should have a *****supported-by***** relationship with a component.**

## Volume I: Definitions and Guidelines

**Purpose – Guidance on**
- Value of architectures
- Architecture measures
- Framework overview and the six-step process
**Audience **
- Decision makers
- Managers

## Volume II: Product Description

**Purpose**
- Definition, description, and intended use for each Framework product
- Description of product and architecture data element relationships
- Description of corresponding CADM entities and relationships

## Volume II: Product Description

**Audience for Volume II:**
- For the manager, product definition and purpose section:
- Provide a brief overview of architecture products,
- Describe level of effort involved in developing each product,
- Describe potential uses of architecture products
- Allow assessment of products needed to support decisions

## Volume II: Product Description

**Audience for Volume II (cont’d)**
- For the architect and engineering team, a detailed description, and architecture data element definitions section:
- Allow identification of products to be included in the architecture based on architecture’s intended use
- Facilitate determination of architecture data needs
- Allow identification of  sources for the architecture data
- Allow analysis and comparison of the data gathered
- Facilitate composition of data into architecture products

## Volume II: Product Description

**Audience for Volume II (cont’d)**
- For the architecture data modelers, tool developers, and engineers, a CADM entities and relationships section:
- Facilitate implementation of a CADM compliant architecture Modeling tool
- Facilitate implementation of a CADM compliant architecture data repository

## Deskbook: Architecture Guidance

**Purpose: provide supplementary guidance on**
- Developing architectures
- Using architectures
- Incorporating Security into architectures
**Audience **
- Managers
- Architects
- Engineers

## Key Changes in Volume I

**Overview of DoD and Federal policies concerning architectures**
**Information on the value of architectures, architecture measures, and use of architectures to support DoD processes**
**Introduction to DoD Architecture Repository System (DARS)**

## Key Changes in Volume II

**Data element definitions internally consistent across products**
**Greater emphasis on architecture data underlying the architecture products**
- Data element tables and element attribute definitions
- CADM section and corresponding entities
**Guidance on developing architecture products using UML**
**Section on product and data element interrelationships**
**Technical View is re-titled the Technical Standards View. The acronym remains TV**

## Deskbook (New Volume)Supplementary Material – Topics Included 

**An example architecture using two different approaches (Structured Analysis and Object Orientation)**
**Some techniques for using architecture information to support DoD processes.  These include:**
- Navy’s Mission Capability Package analysis approach
- Air Force’s Task Force capability-based analysis
- OASD(C3I)/J6 Key Interface process for addressing interoperability at interfaces
- Key Interface Profiles for addressing interoperability at interfaces
- Architecture input to C4I Support Plans
**Guidance on using architectures in the Capital Planning Process**
**Architecture Perspective on Net-centric Operations and Warfare (NCOW)**
**Guidance on security (information assurance) issues with respect to architecture**
**The Role of Humans in Architectures **
**General information on automated tools**