Practical DoDAF Presentation to INCOSE WMA

© 2014 Systems and Proposal Engineering Company. All Rights Reserved
Practical DoDAF: Applying
MBSE to Cost Effectively
Develop Architectures
October 2014
Presented by:
Steven H. Dam, Ph.D.
(571) 485-7805
steven.dam
@specinnovations.com

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

“Architectures are a primary tool for enterprise-level systems
integration.”
DoD Architecture Framework, Version 1.0 (09 February 2004) Volume I, p. 1-5
WHAT IS ARCHITECTURE?
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
Viewpoint N
View N
View Z
View Y
View X
• All Viewpoint
• Capability Viewpoint
• Data and Information
Viewpoint
• Operational Viewpoint
• Project Viewpoint
• Services Viewpoint
• Standards Viewpoint
Derived from text on DoDAF 2.02 PDF page 3 • Systems Viewpoint
http://cio-nii.defense.gov/sites/dodaf20/background.html “Products”

Building the Architecture from
“Viewpoints”
Viewpoint A
View N
View Z
View Y
Architectural Description
View X Viewpoint N
Viewpoint C
Viewpoint B
Viewpoint A
Derived from text on DoDAF 2.02 PDF page 3
http://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

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 Dictionary
Architecture 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 Taxonomy
A hierarchy of capabilities specifies all the
capabilities that are referenced throughout one or
more architectures
CV-3 Capability Phasing
Planned 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 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 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)

DoDAF 2.0 Models
Operational Viewpoint
OV-1 High-Level Operational Concept Graphic
High-level graphical/textual description of
operational concept
OV-2 Operational Resource Flow Description Operational resource flow needlines
OV-3 Operational Resource Flow Matrix
Resource 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
(operational activity) -identifies business process
responses to events
OV-6c Event-Trace Description
(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

DoDAF 2.0 Model
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-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-8
Services Evolution
Description
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
identifies responses of a services to events
SvcV-10c Services Event-Trace Description
identifies service-specific refinements of critical sequences of
events described in the Operational Viewpoint

DoDAF 2.0 Models
16
Systems 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-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
responses of a system to events
SV-10c Systems Event-Trace Description
system-specific refinements of critical sequences of events described in
the Operational Viewpoint
Standards
Viewpoint
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

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?
• To some, it’s a collection of diagrams and
documents:
18
cc#2
3 times
cc#1
1
Serial Function
AND
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
External Data 1
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
“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)
• 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
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
Action Diagram = combined OV-5b/OV6c, SvcV-4/SvcV-10c, SV-4/SV-10c)
• 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

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
Create a classic block
diagram for SvcV-1/2
and SV-1/2…
• Highly expressive and model-based physical
modeling
• Drag/drop capable
• Add picture, special lines and backgrounds
31
… 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

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
36

How Can We Avoid Learning the “Lessons
Learned” Again?
• Developing and using a clear, simple
methodology
37
– Techniques (the theory)
– Process (the application)
– Tools (the hammer)
• Planning and replanning
• Training
– Train complete team
– Provide refresher training as needed

Techniques
• Provide the theoretical
38
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

Requirements Analysis
Functional Analysis
Synthesis
System Analysis
and Control
SV-8 SV-9
14. Provide Options
Processes
39
1. Capture and Analyze Related Artifacts
2. Identify Assumptions
AV-1
Draft 5. Develop the Operational Context Diagram
DIV-2
6. Develop Operational Scenarios
7. Derive Functional Behavior
8. Derive Assets
9. Allocate Actions to Assets
4. Capture Constraints
3. Identify Existing/Planned Systems
15. Conduct Trade-off Analyses
10. Prepare Interface Diagrams
SV-10
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
AV-1
AV-2
OV-1
OV-2
OV-3
OV-4
OV-5
OV-6
SV-1
SV-2
SV-3
SV-4
SV-6 SV-5
SV-7
StdV-1 StdV-2
DIV-3
DIV-1 CV-1
CV-2
CV-3
CV-4
CV-5
CV-6
CV-7
PV-2
PV-3
PV-1
CONOPS
Time

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
40
Database
Requirements
Analysis
Automatically
Generated
Diagrams
Simulation

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
41

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

Practical DoDAF Presentation to INCOSE WMA

More Related Content

What's hot

Viewers also liked

Similar to Practical DoDAF Presentation to INCOSE WMA

More from Elizabeth Steiner

Practical DoDAF Presentation to INCOSE WMA