powerpoint presentation (size=2.73mb)

© 2002 The MITRE Corporation. All rights reserved.

DoD Architecture Framework DoD Architecture Framework V 1.0 V 1.0

Dr. Fatma Dandashi

The MITRE Corporation

April 8, 2003

Ope

ratio

nal System

s

Technical

2 © 2002 The MITRE Corporation. All rights reserved.

Context and Relationship To This AudienceContext and Relationship To This Audience

Manufacturing Manufacturing (Hardware Parts)(Hardware Parts)

AP233AP233

Systems Systems EngineeringEngineering

Processes and Processes and Modeling StandardsModeling Standards

Mission Needs/Mission Needs/Information Interoperability Information Interoperability

RequirementsRequirements

Software Parts/Software Parts/InformationInformation

UML/XMIUML/XMI

Industry StandardsIndustry Standards

Ope

ratio

nal System

s

Technical

Systems of SystemsSystems of Systems(Software Intensive)(Software Intensive)


Architecture DefinedArchitecture 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.

ArchitectureArchitectureArchitectureArchitecture ==Structure ofStructure ofComponentsComponentsStructure ofStructure ofComponentsComponents

RelationshipsRelationshipsRelationshipsRelationshipsPrinciples &Principles &GuidelinesGuidelines

Principles &Principles &GuidelinesGuidelines++ ++


Why Architecture?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 RevolutionsParallel Revolutions

InformationRevolution

1985 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 …

• Widespread E-Commerce • Wideband Internet to Homes

• Apple Personal Computer

• Internet Goes ‘Public’

• Low Cost Cell Phone Service

• Windows95

• Windows98

• Windows2000/XP

U.S.Dept of Defense

1985 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 …

• 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 BeginsArchitecture Focus

• JFCOM Formed• C4ISR AF • JV2020

• TerrorismStrikes 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’


• Agency or battlefield must work together• 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 Need for Integrated Architecture Descriptive ProductsProducts


Policy and Guidance on Architecture – Policy and Guidance on Architecture – Mandate for ArchitecturesMandate 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 ArchitecturesDoD 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 Policy Enabled by Common Approach for Developing ArchitecturesDeveloping 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

10


Increased Emphasis on Meta-Data Increased Emphasis on Meta-Data StandardizationStandardization

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

11


DODAF Core Data ElementsDODAF Core Data Elements

Technologies

InformationData

Performance

Standards

Systems

Operational Activities

Systems Nodes

Operational Nodes

System Functions

Facilities,Locations,Units, and Platforms

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

12


* CADM is a database design for architecture data* Products convey relationship between architecture data elements

System Functions

Business (Organization) Nodes

Systems (Location) Nodes

Business Activities

Systems

Standards

Performance

Data Information

Technologies

CADM Schema of Product field contents

Activity Model

Systems Interface

Description

DODAF Product

DODAF Arch Data

Element

Core Architecture Data Model (CADM)Core Architecture Data Model (CADM)

13


DARS ArchitectureDARS Architecture

TCP/IP Port 1521

Tape back-up

Oracle 9.2Database

Server Tape back-up

OracleInternet

ApplicationServer

R2 w/ Oracle Portal

FIREWALL

Desktop withInternet ExplorerModeling Tools

(System Architect)

Desktop withInternet ExplorerModeling Tools

(SLATE)

Desktop withInternet Explorer

Modeling Tools (ROSE)

HTTP Port 443

Various Users, Various Users, Various Modeling ToolsVarious Modeling Tools

Architecture Data, Architecture Data, CADM SchemaCADM Schema

14


Benefits of Architecture Meta-Data Benefits of Architecture Meta-Data StandardizationStandardization

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

15


DistributedArchitecture 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

Joint Mission Areas

NEO JTF

NIMA

Targeting/BDA

AFTaskForce

Integratable architectures that exploit opportunities for

integrated, interoperable, and cost-effective capabilities

Developing a DoD Enterprise ArchitectureDeveloping a DoD Enterprise Architecture

Operational

Syst

ems

Technical

Framework

DARS - Repository

CADM – Data ModelJoint

Mission Areas

AFTaskForce

Targeting& BDA

TacticalInternet

MilitaryService

NEO JTF

CC

NIMA

Global Information

Grid

ICNational

Theater

CJTF

Tactical

CC

TacticalInternet

Global Information

Grid

IC

MilitaryService

16


DoD Architecture FrameworkDoD 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

17


DoD Architecture FrameworkDoD 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/

18


Systems

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

Information Flow

OperationalNodes

Data Flow

Communications

Prescribes Technical Standards

TechnicalStandards 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

•W

hat N

eeds

to B

e

Done

•W

ho D

oes It

•In

form

atio

n Ex

chan

ges

Requ

ired

to G

et It

Done

Identifies Participant Relationships

And Information Needs

Operational View

X YX

Z

XY

Y

Relates Systems Capabilities to Operational Requirements

SystemsView

•Operational Capability

Requirements

Service Areas

•Sy

stem

s th

at S

uppo

rt

the

Activ

ities

and

Info

rmat

ion

Exch

ange

s

19


Basic Principles - Graphic, Textual, and Tabular Basic Principles - Graphic, Textual, and Tabular ProductsProducts

Operational

Syst

ems

Technical

Operational Concept Description (OV-1)

Node Connectivity Description (OV-2)

X YXZ

XY

Y

Systems InterfaceDescription (SV-1)

Activity Model (OV-5)

Information Exchange Matrix

(OV-3)

Activity to System Function (SV-5)

System Functionality Description (SV-4)

Organizational Relationships Chart (OV-4)

Systems Data Exchange Matrix (SV-6)

Operational Activity Sequence and Timing

Description (OV-6 a/b/c)

NODE A

Local Area Net

System 1 System 2

System 3 System 4

System 5

EXTERNALCONNECTION(OUTSIDE THENODES OF INTEREST)

CONNECTIONTO NODE B

CONNECTIONTO NODE B

CONNECTIONTO NODE C

Two-WayCommunicationsLinks

One-WayCommunicationsLink

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 SchemaSV-11

A B C

T1T2T3

NODESTIME

A B C

T1T2T3

NODESTIME

20


Systems Architecture Viewpoints*Systems Architecture Viewpoints*Relationship to DODAFRelationship 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 SchemaRelational 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

21


DoD Architecture Coordination

CouncilC4ISR

Architecture Working Group

C4ISR Architecture Framework Version 1.0

C4ISR Architecture Framework Version 2.0

June 1996

Dec 1997

C4ISR ITFIntegrated

Architectures Panel

Prior Community Experiences

DoD ArchitectureFramework

Version V 1.0

2002

OSDMandate

Feb 1998

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

Lead by: Directorate for Architectures and IntegrationOASD(C3I) Architecture

Framework Working Group

2003

22


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 ProductsDODAF Architecture Products

23


(Business Process)Operational Activity Model

AnalyzeMarket

Information Reports

Outputs

(Business Organization)Operational Node

Connectivity Description

HQ

FieldOffice

DPCenter

Phonee-mail

Phonee-mailT3 Line,Satellite

PhoneE-mail

Inputs

Systems Interface Description

System Node

InterfaceSystemSystem

Node

System

System

System Node

System

Technical Standards ProfileOperational Information

Exchange Matrix

Producing Node

Producing Activity

Receiving Node

Receiving Activity

InformationNeedline

Information Exchanged

Also Includes: Triggering EventDescription, ‘Properties’,

Performance, Security

Service Area Service Standard

Applications Software

Data Document XML 1.0Interchange Interchange

(Business Concept)High-Level Operational

Concept Graphic

Importer/Exporter/Broker

SAFE, LEGAL, OPEN TRADE

Carriers Goods

Overview and Summary

Integrated DictionaryDictionary allows capture of Arch

definitions, relationships, attributes, rules

Activity 1 Activity 2 Activity 3

Activity 4 Activity 5

Activity Hierarchy

Some DODAF Architecture ProductsSome DODAF Architecture Products

24


NodeA

NodeB


NodeC

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 graphicaldescription of the operational concept of interest

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

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

To External

Node

STATEVECTOR

From External

Node

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

Operational Activity Model

OperationalProcess 1

Outputs

Inputs

OperationalProcess 2

Information

Information

Inputs

Operational activities, information inputs and outputs, conditions

25


Data Flow Among System Functions

SystemFunction 1

SystemFunction 2

ExternalSource

Data Flow 1

Data Flow 2

Data Repository

System Nodes,Systems, Links

Systems Interface Description SV-1

Communication Pathways and Networks, Configuration Detail

Station Base

SystemA

SystemB

SystemC

Systems Communications Description SV-2

Systems Functionality Description SV-4Capability Evolution and

Migration

Cap 1Cap 2

Cap 3Cap 4

V 1.0 V2.0

Systems Evolution Description SV-8

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 Systems View Captures Systems, Functions Performed, Data, and Network LayoutPerformed, Data, and Network Layout

Describes planned systems evolution over time

26


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 ElementsGreen indicates system product Data Element

Technical Architecture Profile (TV-1) 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

27


RECOMMENDED USES OF ARCHITECTURE: 1 2 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 11 1 2

Planning, Programming, Budgeting Process

PPBS

Capability Based Analysis for IT Investment Decisions

Modernization Planning (including AoAs)

Requirements Generation Process

Determining Mission Needs and Identifying Deficiencies

CONOPS & TTP

Acquisition Process

Program Definition and Risk Reduction

Approval to Begin a New Acquisition Program

Interoperability/Integration of C4ISR Systems

Acquisition Strategy and Source Selection

Cost, Schedule, and Performance Risk Management

Operational and Developmental Test & Evaluation

Systems Engineering (Design & Development)

Operations Planning & Execution

Exercise Planning & Execution

Organizational Design

= Product info is highly applicable = Info is often or partially applicable blank = Info is usually not applicable

Life-Cycle Support & Integrated Digital Environment

BPR / FPI

Operations (Assessment, Planning, Execution, …)

APPLICABLE ARCHITECTURE PRODUCTSAll-

ViewTech View (TV)

Portfolio Management

Technology Insertion / Evolution

System View (SV)Operational View (OV)

Requirements generation

process

Products needed in Requirements

Analysis

Matrix of Products According to UseMatrix of Products According to Use

28


Matrix of Products According to UseMatrix 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

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

Requires tighter integration between staffs, operational, and acquisition communities

29


DODAF Products and UML RepresentationDODAF Products and UML Representation

Applicable View

Framework Product

Framework Product Name UML Diagram

All Views AV-1Overview and Summary

InformationNone: Produced from domain knowledge, diagram and element

annotations

All Views AV-2 Integrated Dictionary None: Produced from diagram and element annotations

Operational OV-1High-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-2Operational Node

Connectivity Description

Collaboration Diagrams for operational/ organizational nodes

Operational OV-3Operational Information

Exchange Matrix

None: Produced from Collaboration or Sequence Diagram messages (OV-2 collaboration messages)+ additional adornments (e.g., IA attribute)

Operational OV-4Organizational

Relationships ChartClass 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 ModelNone: 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-6bOperational State

Transition DescriptionUML Statechart Diagrams

Operational OV-6cOperational Event-Trace

DescriptionUML Sequence Diagrams

Operational OV-7 Logical Data Model Class Diagrams

30



Applicable View Framework Product


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

31





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

32





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

33


US CustomsService

ArchitectureProducts

GSAEnterprise

ArchitectureFramework

TreasuryEnterprise


Architecture

Framework V1.0

ICArchitecture

Products

FederalEnterprise


Homeland

Security

Architecture

Products

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


OPERATIONALINFORMATIONELEMENT

DESCRIPTION MEDIA SIZE UNITS

NAME/IDENTIFIERDEFINITION DIGITAL,VOICE,TEXT,IMAGE,ETC.

RANGELIMITS

FEET,LITERS,INCHES,ETC.

OPERATIONALELEMENT &ACTIVITY


IDENTIFIEROF

PRODUCINGOE

PRODUCINGACTIVITY

IDENTIFIEROF

CONSUMINGOE

CONSUMINGACTIVITY

INFORMATIONSOURCE

INFORMATIONSOURCE

INFORMATIONDESTINATION


FREQUENCY,TIMELINESS,THROUGHPUT

SECURITYINTEROPER-

ABILITYREQUIREMENTS

INFORMATION EXCHANGE

ATTRIBUTES


ATTRIBUTES

INFORMATIONDESCRIPTION


Operational Information Exchange Matrix

NODE A

System Interface Description

NODE B

NODE C

SYSTEM2

SYSTEM1

EXTERNALCONNECTION

SYSTEM1

COMMS Interfa

ce

COMM

S Inter

face

COMMS InterfaceOne-way SATCOM Interface

SYSTEM2

SYSTEM3

SYSTEM1

SYSTEM4

Technical Architecture ProfileActivity 3NodeA

NodeB


NodeC


• Information Description

• Name/Identifier

• Definition• Media

• Size

• Units• Information Exchange

Attributes

• Frequency,

Timeliness,

Throughput• Security

• Interoperability

Requirements

• Information Source

• Information Destination


OperationalNode Connectivity

Description Activity Model

SERVICE AREA SERVICE STANDARDSupport ApplicationsWeb Applications Internet Explorer Version 4.X or better

Netscape Version 3.X or betterData Management Business Data

StandardsData Universal Numbering System (DUNS)

ZIP Code DirectoryCongressional District Identifier

ISO 3166: ISO 3166-1 (1Ocober 1997) and ISO 3166-2 (15 December 1998) (Codesfor the Representation of Names of Countries and Their Subdivisions)

U.S. State Codes and Territory CodesCatalogue for Federal Domestic Assistance ProgramElectronic Grants Data Elements

Data Interchange DocumentInterchange

XML 1.0, W3C Recommendation, 10 February 1998, Rec-xml-19980210 (ExtensibleMarkup Language)

HTML 4.0 Specification, W3C Recommendation revised 24-apr-1998, Rec-html40-19980424 (Hypertext Markup Language)ANSI ASC X12 (Electronic Data Interchange)

Communications World Wide WebServices

IETF RFC-2616 Hypertext Transfer Protocol – HTTP/1.1, June 1999

Electronic Mail IETF Standard 10/RFC-821/RFC-1869/RFC-1870 Simple Mail Transfer Protocol(SMTP) Service Extensions, November 1995

IETF Standard 11/RFC-822/RFC-1049 Standard for the Format of ARPA InternetText Messages, 13 August 1982

IETF RFCs 2045-2049 Multipurpose Internet Mail Extensions (MIME), November1996

34


NATO’s

Architecture

Framework

Taiwan’s

Architecture

Australia’s

Architecture

Framework

Sweden’s

Architecture

Framework

UK’s

Architecture

Framework

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

US CustomsService

ArchitectureProducts

GSAEnterprise


TreasuryEnterprise


Architecture

Framework V1.0

ICArchitecture

Products

FederalEnterprise


Homeland

Security

Architecture

Products


OPERATIONALINFORMATIONELEMENT

DESCRIPTION MEDIA SIZE UNITS

NAME/IDENTIFIERDEFINITION DIGITAL,VOICE,TEXT,IMAGE,ETC.

RANGELIMITS

FEET,LITERS,INCHES,ETC.



IDENTIFIEROF

PRODUCINGOE

PRODUCINGACTIVITY

IDENTIFIEROF

CONSUMINGOE

CONSUMINGACTIVITY

INFORMATIONSOURCE

INFORMATIONSOURCE



FREQUENCY,TIMELINESS,THROUGHPUT

SECURITYINTEROPER-

ABILITYREQUIREMENTS


ATTRIBUTES


ATTRIBUTES



Operational Information Exchange Matrix

NODE A

System Interface Description

NODE B

NODE C

SYSTEM2

SYSTEM1

EXTERNALCONNECTION

SYSTEM1

COMMS Interfa

ce

COMMS In

terfac

e

COMMS InterfaceOne-way SATCOM Interface

SYSTEM2

SYSTEM3

SYSTEM1

SYSTEM4

Technical Architecture ProfileActivity 3NodeA

NodeB


NodeC


• Information Description• Name/Identifier

• Definition• Media

• Size

• Units• Information Exchange

Attributes

• Frequency,Timeliness,

Throughput• Security

• Interoperability

Requirements• Information Source

• Information Destination


OperationalNode Connectivity

Description Activity Model

SERVICE AREA SERVICE STANDARDSupport ApplicationsWeb Applications Internet Explorer Version 4.X or better

Netscape Version 3.X or betterData Management Business Data

StandardsData Universal Numbering System (DUNS)

ZIP Code DirectoryCongressional District IdentifierISO 3166: ISO 3166-1 (1Ocober 1997) and ISO 3166-2 (15 December 1998) (Codesfor the Representation of Names of Countries and Their Subdivisions)U.S. State Codes and Territory CodesCatalogue for Federal Domestic Assistance ProgramElectronic Grants Data Elements

Data Interchange DocumentInterchange

XML 1.0, W3C Recommendation, 10 February 1998, Rec-xml-19980210 (ExtensibleMarkup Language)HTML 4.0 Specification, W3C Recommendation revised 24-apr-1998, Rec-html40-19980424 (Hypertext Markup Language)ANSI ASC X12 (Electronic Data Interchange)

Communications World Wide WebServices

IETF RFC-2616 Hypertext Transfer Protocol – HTTP/1.1, June 1999

Electronic Mail IETF Standard 10/RFC-821/RFC-1869/RFC-1870 Simple Mail Transfer Protocol(SMTP) Service Extensions, November 1995IETF Standard 11/RFC-822/RFC-1049 Standard for the Format of ARPA InternetText Messages, 13 August 1982IETF RFCs 2045-2049 Multipurpose Internet Mail Extensions (MIME), November1996

35


DODAF V 1.0 - SummaryDODAF 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

36


Contact InformationContact 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/

37


Backup SlidesBackup Slides

38


Operational Node Connectivity Description (OV-2)Operational Node Connectivity Description (OV-2)

: Node A

: Node B

: Node C

: External Source

: External Destination

Performs:Activity 1Activity 2

Performs:Activity 3

Performs:Activity 2Activity 3

Nee

dlin

e 2

2: Information Type Y

Needline 1

3: Information Type X

Needline 34: Information Type W

Needline 4

1: Information Type Z

39


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

Needline Identifier

Information Exchange Identifier

Info

rmat

ion

Ele

men

t N

ame

An

d Id

enti

fier

Co

nte

nt

Des

crip

tio

n

Mis

sio

n /

Sce

nar

io U

JTL

o

r M

ET

L

Lan

gu

age

Acc

ura

cy

Tra

nsa

ctio

n T

ype

Tri

gg

erin

g E

ven

t

Inte

rop

erab

ility

Lev

el

Sen

din

g O

p N

od

e N

ame

An

d Id

enti

fier

Sen

din

g O

p A

ctiv

ity

Nam

e A

nd

Iden

tifi

er

Rec

eivi

ng

Op

No

de

Nam

e A

nd

Iden

tifi

er

Rec

eivi

ng

Op

Act

ivit

y N

ame

An

d Id

enti

fier

Nature of Transaction

Information Description Producer Consumer

Needline Identifier

Information

Exchange Identifier

Per

iod

icit

y

Tim

elin

ess

Ava

ilab

ility

Co

nfi

den

tial

ity

Dis

sem

inat

ion

Co

ntr

ol

Info

rmat

ion

Cri

tica

lity

Inte

gri

ty

Acc

ou

nta

bili

ty

Pro

tect

ion

(T

ype

Nam

e,

Du

rati

on

, Dat

e)

Cla

ssif

icat

ion

Cla

ssif

icat

ion

Cav

eat

Performance Attributes

Information Assurance Security

40


Organizational Relationships Chart (OV-4)Organizational Relationships Chart (OV-4)

Third Level Organization D

Third Level Organization C

Second Level Organization A

CommandsCommands

Working Group

Coordinates

Second Level Organization B

Top Level Organization

Commands

Coordinates

Commands

41


Operational Activity Model (OV-5)Operational Activity Model (OV-5)

Node C

Node A

Node B

Activity 2

External Activity 1

Activity 1

Flow1

Flow 2

External Activity 2

Node D

Activity 3

Flow 3

Flow 4

Conducts

Conducts

ConductsConducts

Conducts

42


Operational Activity Model (OV-5)Operational Activity Model (OV-5)

Activity 1.1Flow 1

Activity 1.3

Activity 2.1

Activity 1.2

Flow 2

Activity 2.2

Activity 3

Flow 4

Flow 3

ExternalDestination

Node DNode CNode BNode AExternalSource

43


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

State 2State 1 Event[ Guard Condition ] / Action

44


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

: Op Node A : Op Node B : Op Node C

Message 1Time 1

Message 2Time 2

{formula relating Time 1 to Time 2}

Message 3

Time n

Time 3 Message 4

Message 5Time 4


Message 6

Message 7

Message 8

45


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

Entity 2 Name

Attribute 1 NameAttribute 2 Name...

Entity 3 Name


Entity 1 Name


Relationship Name

Entity 4 Name


46


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

Interface 2

Node A

System 1

System 5

Node B

System 1

System 3

Node C

System 1

System 4Node1

External Connection

Sys Func LSys Func M Interface 1

Interface 4

Sys Func N

Sys Func LSys Func M

Sys Func HSys Func ISys Func J

Interface 5

Key Interface 3

47


Systems-Systems Matrix (SV-3)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).

SYSTEM1

SYSTEM2

SYSTEM3

SYSTEM4

SYSTEM5

SYSTEM6

SYSTEM7

SYSTEM8

SYSTEM9

SYSTEM10

SYSTEM 1

SYSTEM 2SYSTEM 3SYSTEM 4

SYSTEM 5

SYSTEM 6SYSTEM 7

SYSTEM 10

SYSTEM 8

SYSTEM 9

48


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

User Type A

Systems Use Case 2User Type B

Systems Use Case 1

User Type CSystems Use Case 3

49


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

Systems Use Case 1

Package 3Package 2

implemented byimplemented by

Class 1(from Package 2)

Package 1

implemented by


uses


uses


uses

uses

50


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

: Class 1

: Class 2

: Class 4

1 : External Source

2 : External Source

1 : External Sink

2 : External Sink

: Class 3 : Data Repository

2:

Data Flow 2

3:

Data Flow 3

4:

Data Flow 4

6:

Data Flow 6

8:

Data Flow 8

7:

Data Flow 7

1:

Data Flow 1

5:

Data Flow 5

9:

Data Flow 9

10: Data Flow 10

51


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

1

1.1

1.1.1

1.1.1.1

1.1.1.2

1.1.1.3

1.1.2

1.1.2.1

1.1.2.2

1.1.2.3

1.1.3

1.1.3.1

1.1.3.2

1.1.3.3

1.1.3.4

3.11

3.11

.3

3.12

3.12

.1

3.12

.2

3.12

.3

3.13

3.14

3.14

.1

3.14

.2

3.14

.3

3.14

.4

3.15

3.16

3.17

3.17

.1System Functions

..

..

Operational Activities

X

XX

X

X

X

XX

X

X

X

X

XX

X

OV-5 High Level Operational Capability

SV

-1/2

Sys

tem

s

Ope

ratio

nal C

apab

ility

a

Ope

ratio

nal C

apab

ility

b

Ope

ratio

nal C

apab

ility

c

Ope

ratio

nal C

apab

ility

d

Ope

ratio

nal C

apab

ility

e

Ope

ratio

nal C

apab

ility

f

Ope

ratio

nal C

apab

ility

g

System 1

System 2

System 3

System 4

System 5

System 6

52


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

Interface Identification

Data Exchange

IdentificationData Exchange Identification Nature of Transaction

Systems Interface

Name and Identifier

Systems Data

Exchange Name and Identifier

Content Descripti

on

Format Type

Media Type

Data Standar

d

Units of

Measurement

Accuracy

Transaction Type

Triggering

Event

Interoperability Level

53


Systems Data Exchange Matrix (SV-6) Cont’dSystems 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

Confidentia

lity

Disseminati

on Contr

ol

Criticality

Integrity

Non-Repudiation Produ

cer

Non-Repudiation Consu

mer

Protection

(Type Name, Duratio

n, Date)

Classification

Classification Caveat

Release-

ability

Security Standard

54


Performance Parameters Matrix (SV-7)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 NameTime0 (Baseline) Time1 Timen (Objective)

Performance Thresholds/Measures

Hardware Element 2

55


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

LEGACYMAINFRAME

SYSTEM

FEDERATEDDISTRIBUTED

SYSTEM

CLIENT/SERVERPLATFORMS, LAN, &MIDDLEWARE INSTALLED

SEGMENT 1 APPLICATIONS& UNIQUE DATA CONVERTEDTO CLIENT/SERVER

SEGMENT 2 APPLICATIONS& UNIQUE DATA CONVERTEDTO CLIENT/SERVER

SEGMENT 3 APPLICATIONS,& UNIQUE DATA CONVERTEDTO CLIENT/SERVER

COMMON DATA CONVERTEDTO SHARED DATA SERVER

NEW FUNCTION 1 &UNIQUE DATA IMPLEMENTEDON CLIENT SERVER (& INTEGRATED WITH COMMON DATA ON MAINFRAME)

NEW FUNCTION 2 &UNIQUE DATA IMPLEMENTEDON CLIENT SERVER (& INTEGRATED WITH COMMON DATA ON MAINFRAME)

V1.0

V1.1

V1.2

V1.3

V1.4

V2.0

+6 MO. +12 MO. +18 MO. +24 MO. +36 MO. +48 MO. +60 MO.

56


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

TECHNOLOGYCATEGORY

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 LinuxE-mail on wireless PDAs commonplace

Application Platform

Data Management Oracle 9i availableMySQL (Open Source DBMS) available

Operating System Next MS Windows desktop upgrade expectedNext Red Hat Linux major release expected

Next MS Windows server upgrade expected

Physical Environment Intel IA-64 becomes standard processor for desktopsInitial 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 desktopsConventional 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

57


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

State 2State 1 Event[ Guard Condition ] / Action

: Systems Node A : Systems Node B : Systems Node C

Message 1Time 1

Message 2Time 2


Message 3

Time n

Time 3 Message 4

Message 5Time 4


Message 6

Message 7

Message 8

58


Physical Schema (SV-11)Physical Schema (SV-11)

Entity 2 Name


Entity 3 Name


Entity 1 Name


Relationship Name

Entity 4 Name


59


DODAF UML Extensions 1/2DODAF 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)

60


DODAF UML Extensions 2/2DODAF 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.

61


Volume I: Definitions and GuidelinesVolume I: Definitions and Guidelines

Purpose – Guidance on– Value of architectures – Architecture measures– Framework overview and the six-step process

Audience – Decision makers– Managers

62


Volume II: Product DescriptionVolume 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

63



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

64



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

65



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

66


Deskbook: Architecture GuidanceDeskbook: Architecture Guidance

Purpose: provide supplementary guidance on– Developing architectures– Using architectures– Incorporating Security into architectures

Audience – Managers– Architects– Engineers

67


Key Changes in Volume IKey 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)

68


Key Changes in Volume IIKey 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

69


Deskbook (New Volume)Deskbook (New Volume)Supplementary Material – Topics Included 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