Practical DoD Architecture Framework (DoDAF) with Innoslate

Developed by
WEBINAR
The webinar will begin shortly.
PracticalDoDArchitectureFramework
(DoDAF)withInnoslate

Interact with Us
LinkedIn Group:
Innoslate Users
@innoslate
Practical DoDAF with Innoslate

Presenter Profiles
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

OurAgenda
1
2
3
4
5
6
7
What is Architecture?
What is the DoD Architecture Framework?
What do we mean by MBSE?
Live Demonstration
Questions and Answers
How does MBSE produce DoDAF models and viewpoints?
How can we develop cost effective architectures?

• All Kinds of Architectures
• House/Building Architecture
• Information Architecture
• Enterprise Architecture
• Technical Architecture
• Logical Architecture
• Physical Architecture
• Etc.
What is Architecture?
Architecture is perhaps one of the most
abused words in the English language today

The DoDAF Definition
“The structure of components, their
relationships, and the principles and
guidelines governing their design and
evolution over time.” -DoD Integrated Architecture
Panel, 1995
Architecture Definitions
The Practical Definition
“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.
“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

• 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
Elements of an Architecture

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)
Perspectives: Viewpoints That Fit-the-Purpose
Architectural viewpoints are composed of data that has been organized to
facilitate understanding

Models, Views and Viewpoints
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 3
http://cio-nii.defense.gov/sites/dodaf20/background.html
11
“Products”

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 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
AllVP
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
CapabilityViewpoint
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
DataandInfoVP
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)
OperationalViewpoint
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
ProjectViewpoint
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 Models
ServicesViewpoint
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
functionality- identifies responses of a services to
events
SvcV-10c Services Event-Trace Description
functionality- identifies service-specific refinements of
critical sequences of events described in the
Operational Viewpoint
SystemsViewpoint
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
SV-5b Operational Activity to Systems Traceability Matrix
Mapping of systems back to capabilities or operational
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
identifies responses of a system to events
SV-10c Systems Event-Trace Description
identifies 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

• 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
Framework Products
“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

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
Data 1External
Input
Data 5
Data 2
Data 3
Data 4
External
Output
What does an architecture look like?
To some, it’s a collection of diagrams and documents
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?
To others, it’s a decision database
Architectur
e
Repository

“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
INCOSE’s MBSE Definition
• 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 = SE

• 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)
What Techniques are Being Used?
Make sure the technique you choose will provide a broad,
complete foundation for analysis and specification

• 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
Characteristics of a “Good” MBSE Technique

How Does MBSE Produce
DoDAF Models and Viewpoints?

• A fully dedicated DoDAF
Dashboard provides access
to all DoDAF products
• DM2 Statistics
• PES export
Have Easy Access to 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
Build One Diagram and Get Many DoDAF
Products
Action Diagram = combined OV-5b/OV6c, SvcV-4/SvcV-10c, SV-4/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
Or Use a Sequence Diagram for the
OV-6c/ SvcV-10c/SV-10c

•Classic data flow
modeling
•Drag and drop
•Sidebar enabled
•ICOM view also
available
And an IDEF0 Diagram for the
OV-5b/ SvcV-4/SV-4

Use Simulations for Analysis and
Verification
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.

• Highly expressive and model-based physical modeling
• Drag/drop capable
• Add picture, special lines and backgrounds
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…
… or add pictures and
special lines for
concept diagram
(OV-1)

•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
Use Traceability Diagrams to See Link between
Entities

• 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
Include Development of AV-1

•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
Interactive DoDAF matrices

How Can We Develop Cost
Effective Architectures?

• 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
Why Do a Lot of Our Architectures Become
“Shelfware?”

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

• 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
Techniques
LML provides a complete foundation for lifecycle
modeling and analysis

Processes
14. Provide Options
36
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-2
OV-3
OV-4
OV-5
OV-6
9. Allocate Actions to Assets
SV-1
SV-2
SV-3
SV-4
SV-5SV-6
SV-7
SV-8 SV-9
SV-10
StdV-1 StdV-2
AV-1
Draft
DIV-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
Application of
proven processes to
produce
architecture
documentation as a
natural output

• 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
Tools
Database
Requirements Analysis
Automatically Generated Diagrams
Simulation
Innoslate supports Architecture and the rest of the lifecycle

• 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
How Do We Determine the Appropriate
Mix of Technique, Process, and Tool(s)?

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

QuestionsandAnswers
Enter Your Question in the GoToWebinar Control Panel

NEXT WEBINAR
Model-Based Systems Engineering
Using SysML as an extension of LML
April 21

DoDAF 2.0 BOOK Available Now on Amazon!

Feel Free to Contact Us
10440 Balls Ford Road
Manassas, VA 20109
Specinnovations.com/blog
info@Innoslate.com
support@innoslate.com
571-485-7800
LinkedIn: Innoslate User Group
Twitter: @innoslate
innoslate.com
specinnovations.com
Thank you for Attending!

Practical DoD Architecture Framework (DoDAF) with Innoslate

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (17)

Similaire à Practical DoD Architecture Framework (DoDAF) with Innoslate

Similaire à Practical DoD Architecture Framework (DoDAF) with Innoslate (20)

Plus de Elizabeth Steiner

Plus de Elizabeth Steiner (13)

Dernier

Dernier (20)

Practical DoD Architecture Framework (DoDAF) with Innoslate

Notes de l'éditeur