Overview of DoDAF with Innoslate

Ask Us Questions!

LinkedIn Group:

Innoslate Users

@innoslate

President and Founder

Expert Systems Engineering Professionals

Certificate

Steve.dam@specinnovations.com

@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

Webinar Host

Agenda

• Why is DoDAF Important to DoD?

• How Can We Do Good Systems Engineering and Meet DoDAF Requirements?

• How Can MBSE Tools Specifically Support DoDAF?

• Live Demonstration

• Questions and Answers

Why Is DoDAF Important to DoD?

What Is DoDAF?The DoDAF provides a means to compare architectures

It enables this comparison by defining a set of views of an architecture (a.k.a. products)

In Version 1.5 and previously, these products were grouped into 4 views:

◦ Operational View◦ Technical Standards View◦ Systems and Services View◦ All-View

In Version 2.0 they added the◦ Capability View◦ Data and Information View◦ Program View◦ Services View (separate from Systems)

Architectural viewpoints are composed of data that has been organized to facilitate understanding

DoDAF 2.0 ModelsModel 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 Dictionary

Architecture data repository with definitions of all terms used throughout the architecture data and presentations

Cap

abili

ty V

iew

po

int

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 Taxonomy

A 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 Dependences Dependencies between planned capabilities and defines logical groupings of capabilities

CV-5 Capability to Organizational Development MappingThe 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

Dat

a an

d In

fo V

P

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

DIV-2 Logical Data Model

Documentation 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)

Model Name General Description

Op

erat

ion

al V

iew

po

int

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 Chart

Organizational, role, or other relationships among Organizations

OV-5a & b Operational 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 Model

One of three models used to describe activity (operational activity) -identifies business rules that constrain operations

OV-6b State Transition Description

One 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

Pro

ject

Vie

wp

oin

t 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

DoDAF 2.0 ModelsModel Name General Description

Serv

ices

Vie

wp

oin

t

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

Model Name General Description

Syst

ems

Vie

wp

oin

t

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-5aOperational Activity to Systems Function Traceability Matrix

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

SV-5b Operational 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

Stan

dar

ds

Vie

wp

oin

t

StdV-1 Standards Profile

Listing 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

Where Did DoDAF Come From?IBM research paper written entitled “Architecture of the IBM System/360” (1964)

IT Architect profession was announced by IBM (1992)

Started after MIL-STD-499 was cancelled (1995)

C4ISR Architecture Framework v. 1.0 essentially replaced it, but was not an official standard

DoDAF in DoD PolicyJCIDS provides the requirements for all new systems being acquired by the Department

DoDAF is an integral part of the JCIDS process

◦ Part of the primary documents developed during the process◦ ICD, CDD, CPD among others

◦ Also part of the Capabilities-Based Assessments

JointCapabilitiesIntegration &DevelopmentSystem (JCIDS)

Planning,Programming,Budgeting, &Execution(PPBE) Process

DefenseAcquisition System

Milestone Decision Authority (MDA)

Oversight

DoDD 5000 Series

CJCSI 3170.01

DEPSECDEF Oversight

VCJCS/JROC Oversight

Cross Walk Between JCIDS Documents and DoDAF

Note that additional DoDAF views can be requested by different organizations as part of their internal architecture governance process

◦ S - Sponsor

◦ P – Program Office

◦ NR KPP – Net Ready Key Performance Parameters (part of JCIDS documents)

See JCIDS Manual on Intelink for details

Bottomline: These requirements for DoDAF products are continuing to change, but right now if you don’t do the DoDAF views you don’t get any funding for “major” systems

How Can We Do Good Systems Engineering and Meet DoDAF Requirements?

What Are the DoDAF Views Really?The heart of the DoDAF Views is standard systems engineering products:

◦ Behavioral (e.g., OV-5b, OV-6, SV-4, SV-10)

◦ Structural (e.g., CV-4, OV-2, SV-1, SV-2)

◦ Data Models (DIV-1, DIV-2, DIV-3)

◦ Hierarchies (e.g., CV-2, OV-5a)

◦ Timelines (e.g., CV-3, CV-5, SV-8, PV-2)

◦ Interface Matrices (OV-3, SV-3, SV-6)

◦ Metrics (SV-7)

◦ Traceability Mapping (e.g., CV-5, CV-6, CV-7, SV-5)

Once we realize that we can use the same kind of diagram (i.e., an Action Diagram contains all the information in the behavioral products), then we can use our systems engineering techniques to produce them

Behavioral

Structural

Mapping

Hierarchies

What SE Techniques Are Being Used?• Viewgraph engineering (Number 1, unfortunately!)

• Model-Based Systems Engineering (MBSE)o Structured Analysis with and without real-time extensions

o Integration DEFinition (IDEF)

o Unified/Systems Modeling Language (UML/SysML)

o Business Process Model and Notation (BPMN)

o Lifecycle Modeling Language (LML)

Make sure the technique you choose will provide a broad, complete foundation for analysis and specification

INCOSE’s MBSE Definition“Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” From INCOSE Model Based Systems Engineering (MBSE) Initiative presentation at INCOSE IS 2007

• Some have equated MBSE to a specific technique (SysML)

• But MBSE has been around for a long, long time

• At INCOSE International Workshop 2014 I saw a viewgraph that said:

MBSE = SEIn implementing MBSE, it is assumed that you will be using a modern

database tool to create and store the models

Characteristics of a “Good” MBSE Tool

• Provides both ontology and visualization• Interactive models, not just drawings with a database

(e.g., Visio)

• Various visualizations from database

• Simulation (discrete event and Monte Carlo) at least to verify the models

• Document authoring and reviewing

• Report creation from database

How Can MBSE Tools Specifically Support DoDAF?

Have Easy Access to DoDAF Products•A fully dedicated DoDAF Dashboard provides access to all DoDAF products

•DM2 Statistics

•PES export

Build One Diagram to Automatically Produce Many DoDAF Products

• Highly expressive and model-based functional modeling (sequencing and data flow, with allocation and resource modeling explicit)

• Drag/drop capable

• Executable in both Discrete Event and Monte Carlo simulators

Action Diagram = combined OV-5b/OV6c, SvcV-4/SvcV-10c, SV-4/SV-10c

Or Use a Sequence Diagram for the OV-6c/ SvcV-10c/SV-10c

• Functional sequencing only

• Another view from the database, not a separate “drawing”

• Can generate from Action Diagram or be used to generate an Action Diagram

• Also, drag and drop capable, with sidebar for information on entities

And an IDEF0 Diagram for the OV-5b/ SvcV-4/SV-4

•Classic data flow modeling

•Drag and drop

•Sidebar enabled

• ICOM view also available

Use Simulations for Analysis and Verification

Monte Carlo resultDiscrete Event result

Essential for verification of the models to ensure that you have not designed in bottlenecks or other errors that may only be detected later in the lifecycle

Then Build the Physical Model for the OV-1, SvcV-1 & 2, and SV-1 & 2

• Highly expressive

• Model-based physical modeling

• Drag/drop capable

• Add picture, special lines and backgrounds

Create a classic block

diagram for SvcV-1/2 and

SV-1/2…

… or add pictures and

special lines for concept

diagram

(OV-1)

Use Traceability Diagrams to See Link between Entities

•Shows how a single entity (database object) is related to the rest of the system

•Drag and drop new entities and create relationships right from the diagram

•Sidebar enabled

Include Development of AV-1

• Enables complete architecture study management

• Uses new Document View

• Trace findings to other aspects of the database

• Can provide requirements for tracing to other entities

• Link to Risk and Decision entities

Interactive DoDAF matrices

Easy to use matrices for: ◦CV-4, CV-5, CV-6, CV-7◦PV-1, PV-3◦SvcV-3a, SvcV-3b, SvcV-5, SvcV-7

◦SV-3, SV-5a, SV-5b, SV-7

Practical DoDAF with Innoslate

Summary1. Practical DoDAF means using MBSE techniques, processes and tools to develop the DoDAF

models

2. Use common language (technique & DoDAF terms)

3. Apply a process that works for your situation (architecture usually needs middle-out)

4. Use comprehensive tools to capture the information and produce DoDAF products

Questions and Answers

DoDAF Training

DoDAF 101 – Introduction to DoDAF

DoDAF 301 – Executive Overview of DoDAF

DoDAF 401 – Developing Executable Architectures using DoDAF

DoDAF 501 – Developing Integrated, Executable Architectures

DoDAF 515 – Developing Concepts of Operations (CONOPS)

DoDAF 601 – Developing Executable Architectures using DoDAF and Systems Engineering

DoDAF 701 – DoDAF Contract Kickoff Workshop

DoDAF 717 – DoDAF Workshops

Visit https://www.specinnovations.com/training/dodaf-training/

Buy the book at Barnes & Noble

(www.barnesandnoble.com)

Next Webinar

Move Past Spreadsheets with Modern Requirements Management

Tuesday, September 12th at 2:30pm EST