Practical DoDAF Presentation to INCOSE WMA

© 2014 Systems and Proposal Engineering Company. All Rights Reserved

Practical DoDAF: Applying

MBSE to Cost Effectively

Develop Architectures

Presented by:

Steven H. Dam, Ph.D.

(571) 485-7805

[email protected]

October 2014


Presentation Overview What Is Architecture?

What is the DoD Architecture Framework (DoDAF)?

What do we mean by MBSE?

How does MBSE produce DoDAF models and

viewpoints?

How can we develop architectures more cost

effectively?

2


WHAT IS ARCHITECTURE?

“Architectures are a primary tool for enterprise-level systems

integration.”

DoD Architecture Framework, Version 1.0 (09 February 2004) Volume I, p. 1-5

3


All Kinds of Architectures• House/Building Architecture

• Information Architecture

• Enterprise Architecture

• Technical Architecture

• Logical Architecture

• Physical Architecture

• …

4

Architecture is perhaps one of the most abused words in the English language today


DoDAF Architecture Definition

• Architecture:

“The structure of components, their relationships, and

the principles and guidelines governing their design and

evolution over time.” DoD Integrated Architecture Panel, 1995

• DoDAF 1.5 defined three views:

– Operational

– Systems

– Technical Standards

5

“Integrated Architectures are a primary tool for

enterprise-level systems integration.”

DoD Architecture Framework, Version 1.0 (09 February 2004) Volume I, p. 1-5

From “Integrated DoD Architectures” brochure, available at http://www.dod.mil/c3i/org/cio/i3/AWG_Digital_Library/pdfdocs/brochure.pdf

What’s Missing?


A Practical Definition?• Architecture: “A fundamental and unifying

structure defined in terms of elements, information, interfaces, processes, constraints, and behaviors.”– This definition implies that we need many dimensions

(or schema) to completely describe the architecture, including risk, decisions, data, systems, components, organizations, functions, requirements, performance.

– This definition also implies that architecture forms the foundation for dynamic analysis.

6

This means that we need a way to define the dimensions and make sure they link together to

capture the information needed to describe and apply an architecture.


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

7


WHAT IS THE DOD ARCHITECTURE

FRAMEWORK?

8


What is the DoD Architecture

Framework?• 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)

9


Perspectives: Viewpoints That Fit-the-Purpose

10

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

DoDAF V 2.0 PDF p 106


Models, Views and Viewpoints

11

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


Building the Architecture from

“Viewpoints”Viewpoint A

View N

View Z

View Y

View X Viewpoint N

Viewpoint C

Viewpoint B

Viewpoint A

Architectural Description

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

Viewpoint N

View N

View Z

View Y

View X

Viewpoint B

View N

View Z

View Y

View X

12

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


DoDAF 2.0 ModelsModel Name General Description

All

VP

AV-1 Overview and Summary InformationDescribes 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

Cap

abili

ty V

iew

po

int

CV-1 VisionOverall 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-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 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)


DoDAF 2.0 ModelsModel Name General Description

Op

era

tio

nal

Vie

wp

oin

t

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 & 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 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 DescriptionOne 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 ModelModel Name General Description

Serv

ice

s V

iew

po

int

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


DoDAF 2.0 Models

16

Model Name General Description

Syst

em

s V

iew

po

int

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


Framework “Products”• Specific information content for products in each view

• They are expressed in graphical, textual, and tabular

form

• The specific products developed depend on the intended

use of the architecture

• Additional products are allowed if they improve

communication of the architecture

Presented by Mr. Truman Parmele at the DoD Architectures Conference February 24, 2004

17

“The Framework does not advocate the use of any one methodology (e.g., structured analysis vs. object orientation), or one notation over another (IDEF1X or ER notation) to complete this step, but products should contain the required information and relationships.”

DoD Architecture Framework, Version 1.5 (23 April 2007) Vol. II, p. 2-6


What does an architecture look

like?

18

• To some, it’s a collection of diagrams and documents:

cc#2

3 times

cc#1

1

Serial FunctionAND

2

Function in

Concurrency

3

Multi-exit

Function

IT

4

Function in

Iterate

IT

OR

OR

5

Function in

Select

Construct

6

Function 2 in

Select

Construct

OR

AND

7

Output Function

Data 1External

Input

Data 5

Data 2

Data 3

Data 4

External

Output

0

Constructs

Function

1

Serial Function

Function

2

Function in

Concurrency

Function

3

Multi-exit

Function

Function

4

Function in

Iterate

Function

5

Function in

Select Constr...

Function

6

Function 2 in

Select Constr...

Function

7

Output Function

Function


What does an architecture look

like?

19

• To others it’s a decision database:

Architecture Repository


WHAT DO WE MEAN BY

MBSE?

20


INCOSE’s MBSE Definition

• Some have equated MBSE to a specific

technique (e.g., SysML)

• But MBSE has been around for a long,

long time

• Recently (IW 2014) I saw a viewgraph that

said: MBSE = SE

21

“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


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)

22

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


Characteristics of a “Good”

MBSE Technique• Interactive models, not just drawings with

a database (e.g., Visio)

• Simulation (discrete event and Monte

Carlo) to verify the models

• Ontology + Visualization

• Various visualizations from database

• Report creation from database

23


HOW DOES MBSE PRODUCE

DODAF MODELS AND

VIEWPOINTS?

24


Tools That Support DoDAF

• A number of tool have support for DoDAF

today

• Some support a specific technique, others

claim to be “technique or methodology”

independent

• Select a technique, tool and process that

make it easy for you to apply “good”

MBSE characteristics

25


Have Easy Access to DoDAF

Products• e.g., a

dedicated DoDAF Dashboard provides access to all DoDAF products

• DM2 Statistics

• PES export

26

DM2 = DoDAF MetaModel 2.0


Build One Diagram and Get 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

27

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

28


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

29


Use Simulations for Analysis and

Verification

30

Monte Carlo result

Discrete Event result

Note the simulator is compatible with the Action and

Sequence Diagrams. Do not try to simulate IDEF0s –

they are non-executable diagrams.


Then Build the Physical Model for

the OV-1, SvcV-1 & 2, and SV-1 & 2

• Highly expressive and model-based physical

modeling

• Drag/drop capable

• Add picture, special lines and backgrounds31

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

32


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

33


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

34


HOW CAN WE DEVELOP

ARCHITECTURES MORE COST

EFFECTIVELY?

35


36

Why Do a Lot of Our Architectures Become

“Shelfware?”

• No clear relationship to mission or design

• Done in the abstract … users not involved

• Focus on “To-Be” without understanding the “As-Is”

• No way to develop a real transition plan

• No internal governance process

• “Paper” architectures, not living models

• Lack of complete traceability … all elements, not just requirements


37

How Can We Avoid Learning the “Lessons

Learned” Again?

• Developing and using a clear, simple methodology

– Techniques (the theory)

– Process (the application)

– Tools (the hammer)

• Planning and replanning

• Training

– Train complete team

– Provide refresher training as needed


38

Techniques

• Provide the theoretical

underpinnings for the

architecture development

or system design

• Provides a set of “bins” to capture

information

• Provides standards for communicating

the information, usually in graphical

form


14. Provide Options

Processes

39

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 & Recovery

13. 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-1

OV-2OV-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

PV-2PV-3

PV-1

CONOPS

Time


40

Tools• Enhance efficiency of

the architect/system

engineer

• Capture the information

required by standards

• Enforce consistency

by applying standards

• Make generation of

products and reports

much easier

Database

Requirements Analysis

Automatically Generated Diagrams

Simulation


41

How Do We Determine the Appropriate Mix

of Technique, Process, and Tool(s)?

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

• Identify tools that support the technique

• Obtain/develop your process

• Optimize all three … don’t be afraid to use a different technique, tool or process if one doesn’t work

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


Summary

• Practical DoDAF means using MBSE

techniques, processes and tools to

develop the DoDAF models

– Use common language (technique & DoDAF

terms)

– Apply a process that works for your situation

(architecture usually needs middle-out)

– Use comprehensive tools to capture the

information and produce DoDAF products

42

Documents

Practical DoDAF Presentation to INCOSE WMA