1. DoD Architectures and Systems Engineering Integration
EXTRACT
DoD Architectures and Systems Engineering Integration
NDIA 15th Annual Systems Engineering Conference
Mr. Walt Okon
Mr. David McDaniel (ctr)
October 2012

2. …
22 Oct 2012

3. DoDAF Evolution Plan DoDAF v1.5 1995 C4ISR F/W v1.0 v2.0 2003 2007
UDAF
v2.05
2003
2007
JCIDS & NR-KPP
Applicability beyond C4ISR
Use-based
Integrated Architecture
2009
2010
2012
2014
v2.01
v2.02
v2.03
DoDAF/DNDAF
v2.04
1997
2016
2013
Joint Interoperability
DoDAF v1.0
C4ISR F/W v2.0
Net-centricity and SoA
SvcV views
26 AV/OV/SV/TV views
Linked to I&S policies
CADM 2.0
Fit-for-purpose
Data-centric architecture
Improved models of systems, services, capabilities, rules, measures
DoDAF Meta Model (DM2) based on IDEAS
Urgent CRs
52  1 XSD
IDEAS Foundation v1.0 fixes
TECHEDITS
DM2 OWL
Federal Common Approach
DNDAF Security Views
MODEM – DM2 Harmonization (IDEAS Domain Level)
NATO NAF
Standardization, e.g.,
ISO
OMG
OASIS
UAF
Framework Objective:
Achieve a single integrated architecture framework for interoperability.
Achieve a US, Canada, and United Kingdom single framework with a common data meta-model
Achieve alignment with the US Government’s Common Approach to enterprise architecture
22 Oct 2012 3

4. Initiatives: Federal Government Common Approach
sub-architecture domains (6)
50 document artifacts
primary outcomes (4)
levels of scope (8)
basic elements of an EA program (8)
There are four primary outcomes that are enabled by the common approach to federal EA:  Service Delivery  Functional Integration  Resource Optimization  Authoritative Reference
There are eight levels of scope for implementing an architecture using the common approach:
 International
 National
 Federal
 Sector
 Agency
 Segment
 System
 Application
There are eight basic elements that must be present and be designed to work together in each agency EA program:  Governance  Principles  Method  Tools  Standards  Use  Reporting  Audit
There are six sub-architecture domains in the common approach to Federal EA:  Strategic  Business Services  Data and Information  Enabling Applications  Host Infrastructure  Security
There are six reference models in the common approach to Federal EA:  Performance Reference Model - PRM  Business Reference Model - BRM  Data Reference Model - DRM  Application Reference Model - ARM  Infrastructure Reference Model - IRM  Security Reference Model - SRM
reference models (6)
22 Oct 2012

5. …
22 Oct 2012

6. Convergence Approach for NAF: IDEAS Layered Approachü
1. Foundation (upper ontology)
Ontologic concepts and relationships
Commonly used patterns (e.g., resource flow, exchange)
Consensus concepts and relationships (e.g., person, organization, material)
2. Common patterns
3. Common architecture domain objects & relationships X X X X
Views for:
NATO “core” architecture views
specific to needs and policies of individual nations
NAF
views
national
views
national
views
national
views
22 Oct 2012 6

7. Fit For Purpose (FFP) Views
22 Oct 2012

8. Fit For Purpose (FFP) and Legacy Views
supported processes
views
JCIDS
DAS
DM2
Capabilities
Locations
OPS SE
IDEAS Ontology
Set theoretic
4-D mereotopologic
Performers
Rules
legacy
PPBE
Services
CPM
fit-for-purpose
(FFP)
Reification
Projects
Pedigree
Resource Flows
22 Oct 2012

9. DM2 Has Three Model Levels
Conceptual Data Model (CDM)
Concepts and concept relationships
Propositions and definitions validated by SMEs
Logical Data Model (LDM)
Reified and formalized relationships
This is where almost all DoDAF design and analysis work is done
Physical Exchange Specification (PES)
XML encoding of LDM
Auto-generated from the LDM
No need to look at (unless you are a tool programmer)
The DM2 has several levels, each of which is important to a particular viewer of Departmental processes.
A conceptual level or Conceptual Data Model (CDM) defines concepts and relationships between them
business language of the enterprise
normative across the six core processes
A logical level or Logical Data Model (LDM) formalizes the relationships in the CDM mathematically
A physical level or Physical Exchange Specification (PES)
adds required NCDS metadata for security and pedigree to the LDM
is generated from the LDM as a set of XSD’s, one schema per DoDAF-described Model
22 Oct 2012

10. Example FFP: OV-2 / SV-1 Hybrid
22 Oct 2012

11. Creating a FFP Model Use the DM2 Logical Data Model.
Create a new diagram. Drag DM2 elements onto the diagram.
Extend classes (including relationship classes) as needed.
Use the IDEAS Profile to generate XSD.
Develop narrative documentation.
Share XSD and documentation with your COI.
Tutorial at tutorial
22 Oct 2012

12. …
22 Oct 2012

13. DoDAF meta-model for: DOTMLPF
temporality, behavior, scenarios, M&S, executable architectures
22 Oct 2012

14. DOTMLPF
Doctrine. In Joint Pub 1-02, Dictionary of Military and Associated Terms, “doctrine” is defined as “Fundamental principles by which the military forces or elements thereof guide their actions in support of national objectives. It is authoritative but requires judgment in application.”
The concept of judgment in application concerns decision-making. This cannot be precisely modeled except perhaps as rules affecting the applicability of other rules. The parts of doctrine that can be modeled are included in the Capabilities data group as follows:
Principles are modeled as rules.
Military forces and elements thereof are modeled as types of performers and assemblies of performers.
Actions are modeled as activities.
Thus, doctrine is contained in the specification of certain fundamental rules, activities, and performers and the relationships among them. These relationships are:
Each performer must be the performer of one or more activities.
Each activity must be performed by one or more performers.
Each rule may be a constraint on one or more activities.
Each activity may be constrained by one or more rules.
Thus, since the DM2 contains the entities and relationships listed above it contains the necessary and sufficient set of entities and relationships to permit the modeling of doctrine and a separate data group for doctrine is not required.
Organization. An organization is a specific real-world assemblage of people and other resources organized for an ongoing purpose. DM2 models organizations as a type of performer.
Defining an organization as an assemblage means that an organization has whole-part relationships. An organization may include other organizations. Each part of one organization may also be a part of other organizations. The following DM2 relationships are involved in the capability-based analysis of organization where each organization is a type of performer:
Each capability must be the result of one or more activities.
Each activity must be performed by one or more performers, where each performer must be a type of organization; therefore, each capability must be provided by one or more organizations.
Each organization must be the performer of one or more activities.
Training. Training is defined as an activity or set of activities to increase the capacity of one or more performers to perform one or more activities under specified conditions to specified standards of performance:
Each performer may be either an organization or a person in a role.
Each performer must be of one or more activities.
Each activity must be performed under one or more conditions.
Each activity must be completed to meet one or more standards.
Each standard must be specified by one or more measures.
Materiel. Materiel is a type of resource. Like organizations, materiel has whole-part relationships. Materiel may be a whole comprised of parts that are themselves materiel, and a materiel may be a part of other materiel.[AKB1] 
The following DM2 relationships are involved in the capability based analysis of materiel where each Materiel is a part of a Performer:
Each performer must be assigned to one or more organizations.
Each performer must be used by one or more persons in roles, and each person in a role must be a member of only one organization at any one time.
Each activity must be performed by one or more performers, and each performer must be either an organization or a person in a role.
Leadership and education. Joint Pub 1-02 does not define leadership. In the context of the DM2, leadership is defined as the ability to lead. Joint Pub 1-02 defines military education as the systematic instruction of individuals in subjects that will enhance their knowledge of the science and art of war. Thus, to a certain extent, leadership is a set of skills that can be taught as part of the science and art of war and a smaller set of skills that can be trained as activities that must be performed under specified conditions to meet specified standards.
Leadership is about judgment in application of doctrine. Leadership deals with decision-making, and it cannot be precisely modeled except perhaps as rules affecting the applicability of other rules.
Personnel. Personnel refer to persons in roles. Each person in a role is a type of performer.
The following DM2 relationships are involved in the capability based analysis of materiel where each person in a role is a type of performer:
Each person in a role must be assigned to only one organization at any one time.
Each person in a role may be the user of materiel.
Each materiel must be used by one or more persons in a role.
Each activity must be by one or more performers, where each performer must be either an organization or a person in a role using a materiel.
Each person in a role must be the performer of one or more activities.
Each rule may be a constraint on one or more persons in a role.
Facilities. A facility is a real property entity consisting of underlying land and one or more of the following: a building, a structure (including linear structures), a utility system, or pavement. This definition requires that facilities be firmly sited on or beneath the surface of the earth. Things such as tents, aircraft, and satellites that are not fixed to a location on or beneath the surface of the earth are a type of materiel. Facilities and their materiel are germane to capability-based analyses through these relationships:
Each facility may be the site of one or more performers and any materiel that is part-of the performer(s).
Each performer may be at only one facility or within a materiel enclosure at any one time.
Because a facility is an individual, it has a spatial and temporal extent.
An individual instance of materiel has a spatial and temporal extent in contrast to a type, which does not. Generally, architecture descriptions deal with types of materiel, not with specific individuals such as serial-numbered items of equipment. However, the DM2 does represent a performer at a location and, consequently, any materiel that is part of the performer would also be at the location.
 [AKB1]not a felicitous name… need to treat this in some way that lets me rewrite in English.
22 Oct 2012

15. Temporality, Behavior, Scenarios, M&S, Executable Architectures
22 Oct 2012

16. DM2 is founded on 4D ontology
Four dimensionalist -- xyzt
Extensional -- physical existence is the criterion for identity
Signs and representations are separated from referents
Mathematics:
Type theory ~ Set theory
Mereology (wholes and parts)
4D Mereotopology (spatio-temporal relations)
Then domain concepts inherit several important properties. None of these foundation properties are unusual; they are all used in reasoning everyday:
Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent.
Types, sets of things.
Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework.
Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure.
Temporal whole-part; e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity).
Super-subtype; e.g., a type of system or service, capability, materiel, organization, or condition.
Interface; e.g., an overlap between two things.
[1]
Three types of Things: Types (which are like sets), Tuples (ordered relationships), and Individuals (not persons, but Things that have spatial and temporal extent – spatio-temporal extent.)
mereology is a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology. or 16
22 Oct 2012

17. Maritime Interdiction / ISR “National Critical Contact of Interest”
Example OV-1
Maritime Interdiction / ISR
“National Critical Contact of Interest”
FORCEnet
E-2
P-3
Nat’l CCOI
CVN
DDG
SH-60
C2 Data
FORCEnet
Data Link
Electronic Emission Detection
Shipping Lanes
SSN
SSGN
22 Oct 2012

18. Maritime Interdiction / ISR Scenario “Critical Contact of Interest Surveillance and Prosecution” OV-6c Sequences
Command/Control
Nat'l Assets
SSN
CVN
DDG
SH-60/UAV
E-2
P-3
CCOI report
Voice report / OPTASK revision
Track ID Change
Intel report
Control Message
Launch/Control Message/Imagery
Command Message
Command and Control
Intel Report
Various
Voice /SIPRNET /GCCS-M
Link-11/16
Link-11 / SIPRNET
Voice
Voice / GCCS-M/ SIPRNET
BYG-1
ISIS
SSDS
GCCS-M
AEGIS
HAWKLINK
E2-C2
P3-C2
Control / Track Message
22 Oct 2012

19. DoDAF and SE Documents and Artifacts
22 Oct 2012

20. DoDAF Artifacts Overlaid on “V”
Operations & Support
Life-Cycle Sustainment … RD
ISR
ISR
FOC
Capability Validation (OT)
CBA
Full-Rate Production & Deployment RD
M&S
identify
ITR
VAL
IOC
System Validation (OT)
ICD
ASR
MSA
LRIP
PCA
define
CPD
MS-A
MS-C
SRR
SFR
Prototyping
System Verification
(DT)
PRR
FCA
represent
VER
REQM
MS-B
System Design
Subsystem Verification
(DT)
CDD
Acquisition Model Decisions & Milestones
Capabilities Based Assessment (CBA)
Material Solutions Analysis (MSA)
Technology Development (TD)
Engineering & Manufacturing Development (E&MD)
System Engineering Technical Reviews
Initial Technical Review (ITR)
Alternative System Review (ASR)
System Requirements Reviews (SRR)
System Functional Reviews (SFR)
Preliminary Design Reviews (PDR)
Critical Design Reviews (CDR)
Test Readiness Review (TRR)
Production Readiness Review (PRR)
In-Service Review (ISR)
Functional Configuration Audit (FCA)
Physical Configuration Audit (PCA)
JCIDS Documents
Initial Capabilities Doc (ICD)
Capabilities Design Doc (CDD)
Capabilities Production Doc (CPD)
Typical Systems Engineering Work Products
Performance Specification / System Requirements Document (SRD) / Technical Requirements Document (TRD) / System Segment Specification (SSS)
System Design Document (SDD) / System Segment Design Document (SSDD)
Software Requirements Specification (SwRS)
Software Design Document (SwDD)
Interface Requirements Specification (IRS)
Interface Control Document (ICD) / Interface Design Document (IDD)
Data Base Design Document (DBDD)
Test and Evaluation Master Plan (TEMP)
CMMI Process Areas
Requirements Development (RD)
Requirements Management (REQM)
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
PDR
specify
TRR
Component Design
Component Verification
configure PI
CDR
VER TS
instantiated
Build
Unit Test
22 Oct 2012

21. Notional Systems Engineering Documents with embedded DoDAF artifacts
System Specification (SSS, SDS, SDD, etc.)
Functional Description – SV-4
Performance Specification – SV-7
Interfaces – SV-1, high-level SV-2 and 6
Standards to Comply – StdVs mapped to SV’s
Components – SV-1
Interface Specification (IRS, ICD, etc.) – SV-2 and 6, possibly linked to DIV-2 and 3
22 Oct 2012

22. Elements of Quality Architecture
Single Architecture Framework
Policy, Direction, Guidance
Exchange
Architecture Tools
Certified Architects
Enabling efficient and effective acquisition of hardware, software and services used by DoD and Partners in mission performance.
Unified Architecture Framework
22 Oct 2012 22 22

23. Summary DoDAF is foundational to Federal Government and NATO
FFP + DM2 enables more sophisticated modeling than legacy views
DoDAF’s model for reification supports many life-cycle models, including SE “V”
The DoDAF Meta Model (DM2) was designed to allow modeling beyond the legacy views
DoDAF artifacts, SE documents, and artifacts should be complimentary
22 Oct 2012

24. …
22 Oct 2012