DoDAF Overview Using Innoslate Webinar

Developed by

WEBINAR

The webinar will begin shortly.

Overview of DoD Architecture Framework (DoDAF) with

Innoslate

Interact with Us

Overview of DoDAF with Innoslate

LinkedIn Group:Innoslate Users

@innoslate

Presenter Profiles


President and Founder

Expert Systems Engineering Professionals Certificate

[email protected]@stevenhdam

Steven H. Dam, Ph.D., ESEP is the President and Founder of Systems and Proposal Engineering Company (SPEC Innovations), as well as one of our training instructors. He has been involved with research, experiments, operations analysis, software development, systems engineering and training for more than 40 years.

Participated in the development of C4ISR and the DoDAF

mailto:[email protected]

Our Agenda

1

2

3

4

5


6

What is the DoDAF Anyway?

What are the DoDAF Models

What’s the DoDAF Missing?

Live Demonstration

Questions and Answers

What Makes a ‘Good’ Methodology?


“The structure of components, their relationships, and the principles and

guidelines governing their design and evolution over time.” DoD Integrated

Architecture Panel, 1995

1 What is DoDAF Anyway?What is Architecture?


1 What is the DoDAF Anyway?DoDAF 1.5 Three Views


1 What is the DoDAF Anyway?Elements of an Architecture

• Operational Context in which to operate

• Mission to accomplish

• Requirements to decompose, maintain and evolve to accomplish Mission

• Relationships among Requirements

• Organizations and Roles to operate in Context and accomplish Mission

• Relationships among Organizations

• Behavior and Functions necessary to accomplish Mission and Tasks

• Relationships among Functions

• Data and Information from Analyses

• Constraints on Design and Execution

• The highest level of Design

• Decisions


1 What is the DoDAF Anyway?What does an architecture look like?

cc#2

3 times

cc#1

1

Serial FunctionAND

2

Function inConcurrency

3

Multi-exitFunction

IT

4

Function inIterate

IT

OR

OR

5

Function inSelect

Construct

6

Function 2 inSelect

Construct

OR

AND

7

Output Function

Data 1ExternalInput

Data 5

Data 2

Data 3

Data 4

ExternalOutput

0

Constructs

Function

1

Serial Function

Function

2

Function inConcurrency

Function

3

Multi-exitFunction

Function

4

Function inIterate

Function

5

Function inSelect Constr...

Function

6

Function 2 inSelect Constr...

Function

7

Output Function

Function


1 What is the DoDAF Anyway?What does an architecture look like?

Architecture Repository


1 What is the DoDAF Anyway?Framework Products


2 What are the DoDAF Models?DoDAF 2.0 Viewpoint Structure


2 What are the DoDAF Models?DoDAF 2.0 Viewpoint Structure

Model X View X

Data+

Model Y View Y

Data+

Model Z View Z

Data+

View N

View Z

View Y

View X

Viewpoint N

• All Viewpoint • Capability Viewpoint • Data and Information Viewpoint• Operational Viewpoint• Project Viewpoint• Services Viewpoint• Standards Viewpoint• Systems Viewpoint

Derived from text on DoDAF 2.02 PDF page 3http://cio-nii.defense.gov/sites/dodaf20/background.html “Products”

http://cio-nii.defense.gov/sites/dodaf20/background.html

http://cio-nii.defense.gov/sites/dodaf20/background.html


2 What are the DoDAF Models?DoDAF 2.0 Models

Model Name General Description

All VP

AV-1 Overview and Summary Information

Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects

AV-2 Integrated DictionaryArchitecture data repository with definitions of all terms used throughout the architecture data and presentations

Capability Viewpoint

CV-1 Vision

Overall vision for transformational endeavors, provides a strategic context for the capabilities described, and provides a high-level scope

CV-2 Capability TaxonomyA hierarchy of capabilities specifies all the capabilities that are referenced throughout one or more architectures

CV-3 Capability PhasingPlanned achievement of capability at different points in time or during specific periods of time

CV-4 Capability DependencesDependencies between planned capabilities and defines logical groupings of capabilities

CV-5Capability to Organizational Development Mapping

The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular Capability Phase

CV-6 Capability to Operational Activities Mapping

Mapping between the capabilities required and the operational activities that those capabilities support

CV-7 Capability to Services Mapping Mapping between capabilities and the services that these capabilities enable

Data and

Info

VP

DIV-1 Conceptual Data Model Required High level data concepts and their relationships

DIV-2 Logical Data ModelDocumentation of the data requirements and structural business process rules (In DoDAF V1.5, this was the OV-7)

DIV-3 Physical Data Model

Physical implementation of the Logical Data Model entities, e.g., message formats, file structures, physical schema (In DoDAF V1.5, this was the SV-11)




Operational Viewpoint

OV-1 High-Level Operational Concept GraphicHigh-level graphical/textual description of operational concept

OV-2 Operational Resource Flow Description Operational resource flow needlines

OV-3 Operational Resource Flow MatrixResource exchanged and the relevant attributes of that exchange

OV-4 Organizational Relationships ChartOrganizational, role, or other relationships among Organizations

OV-5a & bOperational Activity Decomposition Tree & Model

Capabilities, activities (operational activities), relationships among activities, inputs, and outputs; overlays can show cost, performers or other pertinent information

OV-6a Operational Rules ModelOne of three models used to describe activity (operational activity) -identifies business rules that constrain operations

OV-6b State Transition DescriptionOne of three models used to describe activity (operational activity) -identifies business process responses to events

OV-6c Event-Trace Description

One of three models used to describe activity (operational activity) -traces actions in a scenario or sequence of events

Project Viewpoint

PV-1 Project Portfolio Relationships

Organizational structures needed to manage a portfolio of projects and shows dependency relationships between the organizations and projects

PV-2 Project Timelines A timeline perspective on programs or projects, with the key milestones and interdependencies

PV-3 Project to Capability Mapping

Mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability




Services Viewpoint

SvcV-1 Services Interface Description Identification of services and service items and their interconnections

SvcV-2 Services Resource Flow Description Services and service items and their related resource flows

SvcV-3a Systems-Services Matrix Relationships among between systems and services in a given architecture

SvcV-3b Services-Services Matrix

Relationships among services in a given architecture; can be designed to show relationships of interest, e.g., service-type interfaces, planned vs. existing interfaces, etc.

SvcV-4 Services Functionality Description Functions performed by services and the service data flows among service functions (activities)

SvcV-5Operational Activity to Services Traceability Matrix

Mapping of services (activities) back to operational activities (activities)

SvcV-6 Services Resource Flow Matrix Provides details of service resource flow elements being exchanged between services and the attributes of that exchange

SvcV-7 Services Measures Matrix Measures (metrics) of Services View elements for the appropriate time frame(s)

SvcV-8Services EvolutionDescription

Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving current services to a future implementation

SvcV-9 Services Technology Forecast

Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture

SvcV-10a Services Rules Model

One of three models used to describe service functionality- identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation

SvcV-10b Services State Transition Description One of three models used to describe service functionality- identifies responses of a services to events

SvcV-10c Services Event-Trace Description

One of three models used to describe service functionality- identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint




Syste

ms Viewpoint

SV-1 Systems Interface Description Identification of systems and system items and their interconnections

SV-2 Systems Resource Flow Description Systems and system items and their related resource flows

SV-3 Systems-Systems Matrix

Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing interfaces, etc.

SV-4 Systems Functionality Description Functions (activities) performed by systems and the system data flows among system functions (activities)

SV-5a Operational Activity to Systems Function Traceability Matrix

Mapping of system functions (activities) back to operational activities (activities)

SV-5bOperational Activity to Systems Traceability Matrix

Mapping of systems back to capabilities or operational activities (activities)

SV-6 Systems Resource Flow Exchange Matrix Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange

SV-7 Systems Measures Matrix Measures (metrics) of Systems View elements for the appropriate time frame(s)

SV-8 Systems Evolution Description Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation

SV-9 Systems Technology Forecast

Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture

SV-10a Systems Rules Model

One of three models used to describe system functionality— identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation

SV-10b Systems State Transition Description One of three models used to describe system functionality— identifies responses of a system to events

SV-10c Systems Event-Trace Description

One of three models used to describe system functionality— identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint

Standards

Viewpoint

StdV-1 Standards ProfileListing of standards that apply to solution elements in a given architecture

StdV-2 Standards Forecast

Description of emerging standards and potential impact on current solution elements, within a set of time frames


3 What’s the DoDAF Missing?

The Framework provides a methodology for developing architectures

MYTH


Question: What is missing from DoDAF 2.0?

3 What’s the DoDAF Missing?

Q

AAnswer: A detailed methodology. The techniques, processes, and tools that you use to develop architectures.


4 What Makes a Good Methodology?How Do We Determine the Appropriate Mix of Technique, Process, and Tool(s)?

1. Choose the technique(s) you want to use first (get the theory right)

2. Identify tools that support the technique3. Obtain/develop your process4. Optimize all three … don’t be afraid to use a

different technique, tool or process if one doesn’t work

5. Work with your customer to make sure that whatever you produce is what they want


4 What Makes a Good Methodology?What Techniques are Used?

• Viewgraph engineering• Model-Based Systems Engineering (MBSE)

• Structured Analysis with and without real-time extensions• Integration DEFinition (IDEF)• Unified/Systems Modeling Language (UML/SysML)• Business Process Model and Notation (BPMN)• Lifecycle Modeling Language (LML)

Make sure the technique you choose will provide a

broad, complete foundation for analysis

and specification

Overview of DoDAF with Innoslate 21

• Simple, easy to understand

• Complete• Produces DoDAF

products as a by-product

4 What Makes a Good Methodology?Characteristics of a “Good” MBSE Process

PV-2PV-3

PV-1

14. Provide Options

5. Develop the Operational Context Diagram

15. Conduct Trade-off Analyses

6. Develop Operational Scenarios

1. Capture and Analyze Related Artifacts

4. Capture Constraints

3. Identify Existing/Planned Systems

2. Identify Assumptions

7. Derive Functional Behavior

8. Derive Assets

10. Prepare Interface Diagrams

12. Perform Dynamic Analysis

11. Define Resources, Error Detection & Recovery13. Develop Operational Demonstration Master Plan

16. Generate Operational and System Architecture Graphics, Briefings and Reports

Requirements Analysis

Functional Analysis

Synthesis

System Analysis and Control

AV-1

AV-2

OV-1OV-2

OV-3

OV-4

OV-5

OV-6

9. Allocate Actions to AssetsSV-1

SV-2SV-3

SV-4

SV-5SV-6

SV-7

SV-8 SV-9

SV-10

StdV-1 StdV-2

AV-1Draft DIV-2

DIV-3

DIV-1 CV-1CV-2

CV-3

CV-4

CV-5CV-6

CV-7

CONOPS

Time


4 What Makes a Good Methodology?Characteristics of a “Good” MBSE Tool

1. Interactive models, not just drawings with a database (e.g., Visio)

2. Simulation (discrete event and Monte Carlo) to verify the models

3. Ontology + Visualization4. Various visualizations from database5. Report creation from database

Overview DoDAF with Innoslate

Live Demonstration

Questions and Answers:

Enter Your Question in the GoToWebinar Control Panel


NEXT WEBINAR

November 13th

Overview DoDAF with Innoslate

DoDAF 2.0 BOOK


Feel Free to Contact Us

10440 Balls Ford Road Manassas, VA 20109

Specinnovations.com/blogInnoslate.com/blog

[email protected]@innoslate.com

571-485-7800

LinkedIn: Innoslate User GroupTwitter: @innoslate

innoslate.comspecinnovations.com

Thank you for Attending!

DoDAF Overview Using Innoslate Webinar

Engineering

Transcript of DoDAF Overview Using Innoslate Webinar