1 DoD-CIO/ASD-NII Architecture & Interoperability Directorate Presentation to CAF January 22, 2008

1

DoD-CIO/ASD-NIIArchitecture &

Interoperability Directorate

Presentation to CAF

January 22, 2008

2

DoDAF 2.0 Overview andDoDAF 2.0 Overview and Architecture Federation Architecture Federation

PilotPilot

Alan GolombekAlan [email protected]@osd.mil

(703) 607-5257(703) 607-5257

3

High Level DoDAF Terminology

Views – Perspectives of architecture content:– Operational View = Requirements– Systems View = Implementations– Technical Standards View = Standards– All View = Summary Information

& Definitions

Products - Graphical, tabular, or textual representations of architecture data within the views

Architecture Description - A set of architectural data for the products in the 4 views.

This common foundation for development ensures the use of similar formats for displaying information enabling the integration, federation, comparison, and reusability of disparate architectures.

4

DoDAF Core Architecture Data Model (CADM) The CADM is the common foundation to ensure the

capture of consistent data and their relationships to enable the integration, federation, comparison, and reusability of architectures.

5

Key Policies Requiring DoDAF

Joint Staff CJCSI 3170.01F, 1 MAY 2007, “JOINT CAPABILITIES

INTEGRATION AND DEVELOPMENT SYSTEM”

CJCSM 3170.01C, 1 MAY 2007, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”

CJCSI 6212.01D, 8 MAR 2006, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS”

6

Key Policies Requiring DoDAF

Office of the Secretary of Defense DoD Directive 5000.1, 12 MAY 2003: “The Defense Acquisition System”

DoD Directive 5000.2, 12 MAY 2003: “Operation of the Defense Acquisition System”

DoD Directive 4630.5, 5 MAY 2004: “Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)”

DoD Directive 8115.01, 10 OCT 2005: “Information Technology Portfolio Management”

DRAFT DoD Instruction 8210: “Global Information Grid (GIG) Architecture Development, Maintenance, and Use”

7

DoDAF Evolution To Support “Fit For Purpose” Architecture

(Published in 2003)

(Published in 2007)

DoDAF 1.5• Addresses Net-Centricity • Volume III is CADM & Architecture Data Strategy• Addresses Architecture Federation• Baseline for DoDAF 2.0• Shifted away from DoDAF mandating a set of products

DoDAFDoDAF

2.02.0

(To Be Published)(Late 2008)

DoDAF 2.0• Cover Enterprise and Program Architecture• Emphasize Data versus Products• Tailored Presentation• AV-1 to capture federation metadata• Quality Support to Decision Processes• FEA & Allied/Coalition Support• Journal - Errata & Interim Releases

DoDAF 1.0• CADM Separate• Baseline For DoDAF 1.5• Removed Essential & Supporting Designations• Expanded audience to all of DoD

8

The following Net-Centric Concepts were presented and discussed to be included in DoDAF 1.5

1. Populate the Net-Centric Environment Represent what information and capabilities are being made available (as

services) to the NCE so they can be leveraged by others.

2. Utilize the Net-Centric Environment Represent what information and capabilities provided on the GIG will be

available to service consumers through service discovery and leveraged across the NCE.

3. Support the Unanticipated user Represents that 1) capabilities can scale to support both human and system

unanticipated users, and 2) the posting of information, data, applications and services to the NCE occur as soon as possible to enable multiple use.

4. Leverage COIs to promote Jointness Represents the utilization of COI specific interface specifications, taxonomies,

and common vocabulary to support interoperability in the NCE.

5. Support Shared Infrastructure Represents that the shared physical and services infrastructure (the EIE) is

identified and leveraged in the NCE.

Net-Centric Concepts addressed in DoDAF 1.5

9

…… …

NC Concept Populate the NCE

Characteristics

Services are used to provide information and capabilities to machine consumers on the NCE.

Attributes Service

Service Description

Component-ization

Service Consumers

Net-Centric Concept 1.0

Attribute 1.1

Primary target consumers and anticipated utilization in the NCE (leveragability value to the NCE) systems and organizations.

Service Consumers

Making a stove-piped application functions available as distinct distributable components. Represent building services/functionality to deliver value to the net vice building to a specific user group/need.

Componentization

Web Service Description including governance and extended description. Defines how an interface is built to the service. Defines multiple operations accessible as an interface. This would include SDF.

Service Description

Populate the NCE

A physical (service module) or virtual (access to an application) component of functionality.

Web Service

Characteristics

Represent what services are being made available to the NCE so they can be leveraged by others. Support the concepts of serviceand service provider. This refers to information and capabilities being offered to machines through the use of web-services (through any common, open, web-services technology i.e. SOAP, WSDL, REST, etc).

Web Services are used to provide information and capabilities to machine consumers on the NCE.


Attribute 1.1


Service Consumers


Componentization


Service Description

Populate the NCE


Web Service

Characteristics




Attribute 1.1


Service Consumers


Componentization


Service Description

Populate the NCE


Web Service

Characteristics




Attribute 1.1


Service Consumers


Componentization


Service Description

Populate the NCE


Web Service

Characteristics




Attribute 1.1


Service Consumers


Componentization


Service Description

Populate the NCE


Web Service

Characteristics




Attribute 1.1


Service Consumers


Componentization


Service Description

Populate the NCE


Web Service

Characteristics



1. Review Concept and attributes from Net-Centric Concepts workshop

2. Review architectural relevance of each attribute

3. Decompose attributes to Data Element level

Characteristics


Populate the NCE

Attribute 1.1

Service Consumers

Componentization

Service Description

o How does this “characteristic” impact the DoDAF 1.0 Architecture Products?

o How does this “characteristic” impact the CADM?o How does this “characteristic” impacts architectural

guidance

Impacts/ Recommended changes


Attributes

Web Service

Characteristics

Characteristics


Populate the NCE

Attribute 1.1

Service Consumers

Componentization

Service Description

o How does this “characteristic” impact the DoDAF 1.0 Architecture Products?

o How does this “characteristic” impact the CADM?o How does this “characteristic” impacts architectural

guidance

Impacts/ Recommended changes


Attributes

Web Service

Characteristics

Attribute 1.N:Data elements

5. Propose Net-Centric Guidance for DoDAF 1.5

4. Apply Data Elements to DoDAF 1.0 views and identify gaps

DoDAF 1.5 Development Process

10

Volume II Net-Centric Example

“5.4.3 Net-Centric Guidance for SV-4b

Augmented Product Purpose. In a net-centric architecture, the SV-4b is used to documentservice functionality that is exposed to the NCE, their respective grouping into service families,and their service specifications. It is the SV counterpart to OV-5. Although there is a correlationbetween OV-5 or business-process hierarchies and the service functional hierarchy of SV-4b, itneed not be a one-to-one mapping, hence, the need for the Operational Activity to ServicesTraceability Matrix (SV-5c), which provides that mapping.

Net-Centric Product Description. The SV-4a traditionally describes system functions andthe flow of system data between functions and correlated to SV-1 and SV-2 systems. In the NCE,the SV-4b should capture and depict how services are orchestrated together to deliverfunctionality associated with an operational need. In industry, this is often referred to ascomposeable applications.Services are a key means to share information and capabilities in the NCE and can becaptured in the SV-4b by relevant service groupings or families to assist in understanding how aset of services align with an operational domain or a system capability. The SV-4b alsodocuments the data flows between services and may represent external services, systems, orhumans that interact with the service. Multiple SV-4b products can be utilized to show deeperlevels of detail as system nodes are decomposed into service families which further decomposeinto services that consist of specific operations and data.In the NCE, services require robust and consistent descriptions to operate in the NCE whereservice capabilities are discoverable and able to be consumed in a scalable and flexible manner.The SV-4b should capture and depict information about each service that collectively representsthe service specification. A service specification should be provided for each service that is orwill be provided to the NCE. The service specification enables services to be documented in aconsistent manner, and the DoD-wide SST should be used to the extent possible for describingeach service. Regardless of the precise SST, the necessary minimum subset of information fromthe SST for each service must be captured in the SV-4b:- Interface Model Category includes information of the service specification that identifies the service and

enables service consumers to discover the service and determine the service’s suitability for their needs. It also provides assistance in the usage of the service, and includes service policies and the following types of attributes:

- Service Name is a short descriptive name for the service to be provided andas it appears in the SV-1…”

Document service functionality that is exposed to the NCE

Capture and depict how services are

orchestrated together to deliver functionality

Services are a key means to share information and

capabilities in the NCE

Document data flows between

services

Service

Specifications

Service Specification Template

11

DoDAF v1.5 Volume II Changes

New Product Description and Reason for Addition

Architectural Elements

SV-4a Systems Functionality Description

Description: The SV-4a documents system functional hierarchies and system functions, and the system data flows between them.

Reason: This product applies the original v1.0 definition. The net-centric concepts have been applied to a new product to prevent overloading the original description.

Process Activity

System

SV-4b Services Functionality Description

Description: The SV-4b documents service functionality that is exposed to the Net-Centric Environment, their respective grouping into service families, and their service specifications.

Reason: This product was developed to capture the services functionality of an architecture.

Process Activity

SOA Operation

SOA Service

12




SV-5a Operational Activity to Systems Function Traceability Matrix

Description: The SV-5a depicts the mapping of operational activities to system functions and thus identifies the transformation of an operational need into a purposeful action performed by a system.

Reason: This product applies the original v1.0 definition. The different matrices have been broken out to provide clarity.

Process Activity

System

Operational Capability Task

System Function

System Function Traceability Matrix Element

SV-5b Operational Activity to Systems Traceability Matrix

Description: The SV-5b extends the SV-5a and depicts the mapping of capabilities to operational activities, operational activities to system functions, system functions to systems, and thus relates the capabilities to the systems that support them.

Reason: This product applies the original v1.0 definition. The different matrices have been broken out to provide clarity.

Process Activity

System


System Traceability Matrix Element

13




SV-5c Operational Activity to Service Traceability Matrix

Description: The SV-5c depicts the traceability and mapping of services to operational activities to assist in understanding which services support operational activities.

Reason: This product applies the net-centric concepts. The different matrices have been broken out to provide clarity.

Process Activity

System


Service Traceability Matrix Element

SOA Service

14

ArchitectureData Strategy

CADM 1.5

DATA

EVENT-TRIGGER

INFORMATION

OPERATIONAL-ACTIVITY

OPERATIONAL-NODE

PERFORMANCE

PHYSICAL-NODE

STANDARD

SYSTEM

SYSTEM-FUNCTION

TECHNOLOGY

FederationStrategy

State of DODArchitecting

Net-Centricity Sources

& Prioritization

Decision Support

Processes

Survey, SME interviews, Feedback

Workshop Inputs

Three Integrated Volumes

Volume I

Volume II

Volume III

15

DoDAF v1.5 Stakeholder Feedback

Operational Node

Relationship to NCOW RM

Relationship to FEAStrategic Goals

Alignment to JCIDS/JROC

Information Assurance/Security

Service Specification Template

Net-Centricity

Service Oriented Architecture

Net-Centric Examples

Architecture Tiers

Service Interfaces

Authoritative Sources

BPMN

Capability related concepts

Measurement concepts

SA and OO

Other FrameworksOther Frameworks

Service Description FrameworkService Description Framework UPDM

ABM/ASM

Program vs. Enterprise Architecture Content

16

Vision Statement for the DoDAF v2.0

To enable the development of architectures that are meaningful, useful, and relevant to the

DoD Requirements, Planning, Budgeting, Systems Engineering, and Acquisition decision

processes.

17

Definition for the DoD Architecture Framework

The DoD Architecture Framework is the structure for organizing architecture concepts, principles, assumptions, and terminology about operations and technology into meaningful patterns to satisfy specific DoD purposes.

18

DoDAF 2.0 Development

Management Structure

19

DoDAF 2.0 Development Organizational Structure

DoDAF Plenary

CIO Executive

Board

Method

Working

Group

BTA*

* Led and Staffed by Component Representatives

Development Development TeamTeam

SE WorkshopSE Workshop

DAS WorkshopDAS Workshop

JCIDS WorkshopJCIDS Workshop

PfM/CPM WorkshopPfM/CPM Workshop

PPBE WorkshopPPBE Workshop

Operations WorkshopOperations Workshop

Core

Management

Group

EA

Summit

Presentation

Working

Group

OUSD(P&RM)*

Data

Working

Group

ARMY*

20

Focused on DoD Decisions

M

C

E

P

FederatedFederatedArchitecturesArchitectures

FederatedFederatedArchitecturesArchitectures

E – EnterpriseM – Mission AreaC – DoD ComponentP - Program

DoD Core DoD Core Decision ProcessesDecision Processes

DoD Core DoD Core Decision ProcessesDecision Processes

PPBE/PfM

JCIDS

DOTLMPF

Acquisition

Systems Eng

Architecture IT Technology

GovernanceGovernanceLink Technology to ObjectivesInstitutionalize IT Best PracticesProtect digital assets

Cost ViewCapability View

SE ViewAcquisition

etc.

ArchitectureArchitectureViewsViews

ArchitectureArchitectureViewsViews

““Fit for Purpose”Fit for Purpose”

21


Development

Approach

22

Core Architecture Data Model

All View

Syst

ems/S

ervi

ces

Vie

w

Technical StandardsV

iew

Operational View

CADMCADM

2.02.0


All View

Syst

ems/S

ervi

ces

Vie

w

Technical StandardsV

iew

Operational View

DoDAFDoDAF

2.02.0

InitialInput

Derive

MODAFTOGAF

NAF

ASM UPDM CADM

DoDAF v2.0 Development Approach

Comments&

Stockholder FeedbackPlus

TechnicalWorkingGroup

Analysis

MethodGroup

DataGroup

PresentationGroup

Policy

FEA

GAO Assessment

Phase II: Synthesis

Net-Centricity

DoDAF 1.5


All View

Operational View

JournalJournal

2.02.0

BPMN SOA

BaselineRequirements

DAS Process JCIDS ProcessPfM/CPM Process Operations ProcessesPPBE Process SE Processes

Requirements Workshops Input

Phase I:RequirementsIdentification

Phase III:

Production

Data-Centric

VALIDATION

DOTMLPF

FederationSemantic InteroperabilityMediation

WorkshopsInterviewsSurveys

23

Workgroup Collaboration

Inter-dependencies based on cross process requirementsInter-dependencies based on cross process requirements

Data Method

Presentation

Content

Definitions &Relationships

Collection & Assembly

Display

Synchronization&

Harmonization

Query

Rules

24


Outline

25

DoD Architecture Framework Version 2.0VOLUME 1

Executive Summary (Same for all Volumes)Introduction, Overview, and Concepts1. Vision for DoDAF 2.0

1.1 Fit for Purpose Architecture1.2 Goals and Objectives

2. Framework and Journal Overview2.1 DoD Architecture Framework Defined2.2 Purpose and Scope

3. Domains of Architecture (Strategic, Capability, and Solution) 4. Principles of Federation

4.1 FEA & DoD Reference Models4.2 DoD Enterprise Architecture Overview

5. Customer Requirements5.1 Support of Key Processes 5.2 The Program Tier5.3 The Enterprise Tiers (Component, Mission Area, and Department)

6. Methodologies6.1 Methodology Based Approach to Architecture6.2 System – Component, Package, Deployment Diagrams

7. Presentation7.1 DoDAF Notional Structure7.2 Generated Views (Reports)

8. Data Focus8.1 CADM8.2 Exchange Standard: XML Schema Definitions (XSDs)

9. Process Performance Engineering & Metrics 9.1 Performance Engineering in Process Improvement9.2 Metrics for Use in Testing Process Improvement

10. Analytics10.1 Modeling and Simulation10.2 Executable Architectures

11. Architecture Planning11.1 Organizing the Architecture Effort11.2 Architecture Management

12. Governance13. CM (Not Instantiated Architectures)

13.1 CCB13.2 CADM (DoD Architecture Data Model)13.3 Generic Process Models13.4 DoDAF13.5 Journal

VOLUME 21. Operations Architecture

1.1 Capabilities/Metrics

1.2 Process

1.3 Information Flow

1.4 Data Descriptions

1.5 Roles

2. Technology Architecture

2.1 Systems, Applications, Services, Interfaces

2.2 Infrastructure (Networks, CES, Computing, Spectrum)

2.3 Standards (DISR, profiles)

2.4 Data Exchange

3. Net-Centric Architecture Description

3.1 Net-Centric Perspective

3.2 Backward Compatibility with Legacy Architectures

3.3 Point to Point Connections

3.4 Support for SOA

VOLUME 31. DODAF Metamodel

APPENDICIES (Applies to all 3 Volumes):

A. GLOSSARY

B. ACRONYMS

C. REFERENCES

D. TRANSITION FROM DODAF V1.0/1.5 TO V2.0

VOLUME 1 (cont)

14. Relationships to Other Frameworks14.1 MODAF (Copy from NAF Executive Summary)14.2 NAF (Copy from NAF Executive Summary)14.3 TOGAF14.4 Zachman

26

DoDAF (Notional Structure)DoDAF v2.0 Perspective Views

Users, Planners, Process Owners, Program Managers, Portfolio & Mission Area Managers

Information Designers, Administrators, Systems Engineers

System Analysts, Architects and Software Engineers

Contracting Administrators, Budget Analysts, Operators, Administrators, Managers, and T&E Directors

Operations Architecture

Technology Architecture

Activity View (OV5)

Conceptual View Software Engineering View

Computing Infrastructure View(SV1)

Nodes View (OV2)

Process View (OV6b)

Information View (OV3)

Communications View(SV2)

Locations View (OV2)

Acquisition View

Logical View(OV7)

Applications View

People View (Organization Chart (OV4)

Services View(SV1 / SV4)Roles

Cost View

Strategic View

Physical View* (SV11)

Software Distribution View*Standards View

(TV1 / TV2)

Traceability View

Rules View (OV6a)

Events View (OV6c)

Performance View

System Engineering View

Information Assurance View

Data View (OV7 / SV11)

Net Ops Management View

Net-Centric Views

* Implementer Responsibility

DRAFT

27

DoDAF (Notional Architecture Content)DoDAF v 2.0 Derivation of Architecture

Users, Planners, Process Owners, Program Managers, Portfolio, & Mission Area Managers Information Designers, Administrators, Engineers, Developers System Analysts, Architects and Software Engineers Contract Administrators,

Budget Analyst, Operators, T& E Directors, etc. (Examples & Others)

High Level Context and Architecture Boundaries

Data Dictionary

Operations Architecture (Requirements)

Technology Architecture (Solutions)

Activities Conceptual

Nodes Logical

Processes Physical

Information Functions

Locations Engineering

People (Organization Chart) Distribution

Roles Infrastructure

Cost Communications

Strategies Services

Traceability Systems

Rules Standards

Events Technical Performance/Metric

Operational Performance Metrics Role

Information Assurance

Data

NetOps Management

Generated

Presentation

Examples

•SE

• Acquisition

• JCIDS

• Capability

• Cost

DRAFT

28


Spiral Development

Spiral Approach - DoDAF 2.0 Requirements Delivered by Phase

10% of all Requirements

High PrioritySimpleObvious ValueLow Risk

• Draft Conceptual Model• DoDAF 2.0 Outline• Volumes I-III initial write-up

35% of all Requirements Fulfilled

High PrioritySimpleObvious Value

• Draft Logical Model w/Rqts Workshop Data• Presentation Artifacts; Methods Content• Refined Volumes I-III spiral write-ups


Fulfilled *

Finalized• Volumes I-III• Journal


Fulfilled• Conceptual and Logical Data Model• Presentation Artifacts• Methods Content • New Potential Views• Refined Volumes I-III write-ups• Initial v2.0 Journal

Spiral 1

Spiral 2Spiral 3

Spiral 4

* Includes requirements that require revisit or further interviews

30

Plenary11 Dec

2ndQTR 08

4th

QTR 07

OctAug DecNovSepJun Jul Jan

DoDAFKick OffMeeting7 Jun

SPIRAL I18 Jan

JCIDS WS11-12 Jul

Notional DoDAF v2.0 Development Schedule

Phase IIPhase II

Phase IPhase I

1st

QTR 08

Opns WSDAS WS

Jan

CIO EBCoord

Meeting28 Jun

CMGOutbrief19 Jul

EASummit7 Aug

SE WS17 Oct

TWGKickoff25 Sep

Weekly TWG Meetings

DEV-TKickoff2 Jun

Bi-Weekly DEV-T Meetings

CMGOutbrief30 Aug

CMGOutbrief27 Sep

All TWG6 Dec

31

EA Summit

23 Jan 08

2nd

QTR 083rd

QTR 08

Feb AugJun OctSepJulAprMar May

PfM WSPPBE WS

Feb 08

Nov

EA Conf14-19 Apr

SPIRAL II4 Apr 08

SPIRAL III27 Jun 08

SPIRAL IV12 Sep 08

Notional DoDAF v2.0 Development Schedule (cont)

DoD CIOApproval

Post to

DARS

Phase IIPhase II

Phase IPhase I

Phase IIIPhase III

Plenary1 Apr

4th

QTR 08

32

Points of Contact OSD

– Brian Wilczynski [email protected] 703-607-0252– Alan Golombek [email protected] 703-607-5257– Walt Okon [email protected] 703-607-0502– Michael Wayson [email protected] 703-607-0482– Scott Badger [email protected] 703-

607-0556– Mike McFarren [email protected] 703-489-2286

CADM– Francisco Loaiza [email protected] 703-845-6876– Forest Snyder [email protected] 703-602-6365

REQUIREMENTS BASELINE– Charles Thornburg [email protected] 703-412-7937– Hilda Pineda [email protected] 703-

902-4509 SOO

– Tracy LaRochelle [email protected] 703-916-7453 SCHEDULE

– Craig Cromwell [email protected] 703-916-7456– Tracy LaRochelle [email protected] 703-916-7453

DARS– Bruce Dunn [email protected] 732-

427-3674 DEV-T LEAD

– Craig Cromwell [email protected] 703-916-7456 DEV-T SECRETARIAT

– Tracy LaRochelle [email protected] 703-916-7453

mailto:[email protected]





33

What the Operator Sees Today

34

What the Operator Expects to See

35

FederationStrategy

FederationStrategy

DARS

MILDEP COCOM AGENCY

•CADM•DoDAF•NCOW RM

DoD EAReference Models

DA

TA

DA

TA

RE

QT

S.

RE

QT

S.

DoD Decision ProcessesDoD Decision Processes

COI yCOI yCOI xCOI x

Reporting (OMB, GAO, etc)Reporting (OMB, GAO, etc)

A Federation of Data Producers

•COI = Community of Interest•CADM = Core Architecture Data Model•DoDAF = DoD Architecture Framework•NCOW RM – Net-Centric Operations & Warfare Reference Model

36

Architecture Federation

Working Draft Pre-decisional

- Completed - In Process - Planned

DoD Architecture Federation (Notional)

MISSION

AREA

DEPT

GIG Architectural VisionGIG Architectural Vision

DoD EARMs

NCOWRM

COMPONENT

PROGRAM

JCAJCABEA4.1

COMMSCOMMS

TAMD

(ES, IA, CI)

Business Warfighter DefenseIntelligence

Enterprise Information Environment

WIN-T

ARMY NAVY AIR FORCE

OSEA

COCOMS &

Agencies

JTRSJTRSJTF HQ

GLOBAL C2GLOBAL C2

TSATTSATDCGS – A

NECCNECC

LandWarNet

GIG CapabilityIncrements DISR

JDDA

IA Componentof the GIG

DON EA Coordination

Board

METOCMETOC HRM EAHRM EA

USMCUSMC EA EffortsEA EffortsMCASE MAGTAFMCASE MAGTAF

FORCEnetFORCEnet

GCSS USMCGCSS USMC

CAC2SCAC2S

NMCINMCIDJC2DJC2

Navy ERPNavy ERP

GCCS MGCCS M

GLOBAL C2GLOBAL C2

JC2JC2

AENIA

LIAALIAA C2 Constellation

Discovery and Information Sharing

•What is Available?

•Who Owns the Content?

•Where is it Located?

•What is the Current Status?

•What Tool was it Developed in?

•What Level of Detail?

37

DoD EA Federation Strategy Completed

Available on DARS Website: https://dars1.army.mil/IER/index.jsp

38

GIG Architecture Enterprise Services in Use

DARSFederated Catalog

NCES FederatedSearch Client

Title

C2C Architecture

C2C Architecture

C2C Architecture

C2C Architecture

Other Federated Catalogs

Other Federated Catalogs

Federated EACatalogs

SearchResults

Creator

AFC2ISRC

STRATCOM

Hanscom

AFC2ISRC

Identifier (URL)

https://dars1.army.mil

https://dars1.army.mil

http://hanscom.af.mil

https://langley.af.mil

39 - Completed - In Process

- Planned

DoD Architecture Federation

MISSION

AREA

DEPT

GIG Architectural VisionGIG Architectural Vision

DoD EARMs

NCOWRM

COMPONENT

PROGRAM

JCAJCABEA4.1

COMMSCOMMS

TAMD

(ES, IA, CI)

Business Warfighter DefenseIntelligence

Enterprise Information Environment

WIN-T

ARMYARMY NAVY AIR FORCE

OSEA

COCOMS/ Agencies

JTRSJTRS

JTF HQ

GLOBAL C2GLOBAL C2

TSATTSATDCGS – ADCGS – ANECCNECC

LandWarNet

GIG CapabilityIncrements DISR

JDDA

IA Componentof the GIG

DON EA Coordination Board

METOCMETOC HRM EAHRM EA

USMCUSMC EA EffortsEA EffortsMCASE MAGTAFMCASE MAGTAF

FORCEnetFORCEnet

GCSS USMCGCSS USMC

CAC2SCAC2S

NMCINMCIDJC2DJC2

Navy ERPNavy ERP

GCCS MGCCS M

GLOBAL C2GLOBAL C2

JC2JC2

AENIA

LIAALIAA C2 Constellation

DoD EA Federation Pilot

Participants:

BTA USTRANSCOM Army

DARS Marine Corps Navy

Air Force Joint Staff – J6I

Participants:

BTA USTRANSCOM Army

DARS Marine Corps Navy

Air Force Joint Staff – J6I

Objectives: Develop a Component value

proposition to test through architecture federation (Use Case)

Use Registration and Discovery services (GAES)

Federate the items in the “Table” Graphic (minimum)

Validate federation process and tools (technical)

Validate usefulness of federation (use cases)

Issue federation implementation guidance

40

DoD EA Federation Pilot Use Cases BTA/USTRANSCOM/Marine Corps:

– Federate the BEA with JDDA and Marine Corps Logistic architectures and register in DARS to gain visibility into “end to end” logistics process

Army:– Create a “knowledge base” through architecture federation for Army

communities.– Test tools and concepts through federation, i.e. social networking

(ontology development, semantic indexing,) architecture data analysis, UPDM applicability

Air Force: – Establish interface and search capability between DARS and AFARS.

Demonstrate search capability

Navy:– Implement and use procedures outlined in the GIG Enterprise

Architecture Federation Strategy and DARS CONOPS to create a repeatable federation process

Joint Staff/J6I:– Identify interface points and alignment between Mission Area-level

architectures to obtain enable a horizontal view across mission areas and drill down to Program level.

DARS:– Develop registration template for AV-1 and DDMS metadata

41

DoD EA Federation Pilot Schedule

September – October 2007– Acquire resources to conduct pilots– Develop Use Cases

November 2007 – February 2008– Conduct Pilots– Analyze results– Submit findings and lessons learned– Initial Pilot Demonstrations to FJAWG

March – April 2008– Prepare Demonstrations– Demonstrate Architecture Federation at EA Conference– Conduct Panel Discussion at EA Conference:

Architecture Federation (General) Architecture Federation Pilot Findings

42

Points of Contact

OSD: DoDAF & Architecture Federation– Brian Wilczynski [email protected] 703-607-5257– Walt Okon [email protected] 703-607-0502– Alan Golombek [email protected] 703-607-5727– Michael Wayson [email protected] 703-607-0482– Scott Badger [email protected] 703-607-0556

DARS– Bruce Dunn [email protected] 732-427-3674– Tracy LaRochelle [email protected] 703-916-

7453

Documents

1 DoD-CIO/ASD-NII Architecture & Interoperability Directorate Presentation to CAF January 22, 2008