1. Why XMI Will Not Work as the Data Exchange Standard for the DoD EA COI
Dave McDaniel
28 March 2011

2. The LDM is more complicated than the PES
Lay of DoDAF Land
Model specifications (AV-1  SV-10c)
Intent was to specify using data dictionary terms
Too much legacy committee language was preserved
Estimate 75% of the terminology is undefined and inconsistent
DM2
Conceptual Data Model is a one-slide ppt and a handful of definitions
Logical Data Model is in Sparx EA UML tool but modified to be an IDEAS tool
Physical Exchange Specification is automatically generated from the LDM
It is just the LDM in XML
The DM2 is related to the 52 DoDAF models via a matrix of the ~250 data elements = ~15,000 matrix cells
The LDM is more complicated than the PES

3. Conceptual Level of DM2 is Simple
anything can have Measures
Condition
Guidance
is-performable-under
Rule
Activity
Capability
Standard
Agreement
constrains
requires-ability-to-perform
Backup slide has term definitions
has
consumes-and-produces
is-performed-by
is-realized-by
Project
achieves-desired-effect (a state of a resource)
is-the-goal-of
Resource
describes-something
Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.
Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.
Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received.
Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.
Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose.
System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.
Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture.
Service: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The capabilities accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents.
Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.
Condition: The state of an environment or situation in which a Performer performs.
Desired Effect: A desired state of a Resource.
Measure: The magnitude of some attribute of an individual.
Location: A point or extent in space that may be referred to physically or logically.
Guidance: An authoritative statement intended to lead or steer the execution of actions.
Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action.
Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in.
Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
Project: A temporary endeavor undertaken to create Resources or Desired Effects.
Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties.
Information
Not shown but implied by the IDEAS Foundation:
Everything is 4-D and so has temporal parts, i.e., states
Everything has parts
Everything has subtypes
Materiel
Performer
Data
System
Organization
is-at
Location
GeoPolitical
Service
PersonRole
is-part-of

4. DoDAF 2 Conceptual Data Model Terms
Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.
Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.
Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received.
Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.
Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose.
System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.
Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture.
Service: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The capabilities accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents.
Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.
Condition: The state of an environment or situation in which a Performer performs.
Desired Effect: A desired state of a Resource.
Measure: The magnitude of some attribute of an individual.
Location: A point or extent in space that may be referred to physically or logically.
Guidance: An authoritative statement intended to lead or steer the execution of actions.
Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action.
Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in.
Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
Project: A temporary endeavor undertaken to create Resources or Desired Effects.
Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties.

5. The LDM is Where IDEAS Comes In
Because of IDEAS there are ~250 total data elements
CADM had ~16,000! (Yes, sixteen thousand) And did less
But, … with IDEAS, things can be combined in many interesting, sometimes surprising, sometimes complex ways
The hardest part of learning DM2 is IDEAS

6. PES is a dumbed-down XML encoding of the LDM
PES sample
Has been implemented by Vicense. SBSI can generate PES easily.

7. XMI
Specific to UML software engineering tools – 5 out of 50 identified by the A&I team – 10%
Most architecture tools we have identified are not UML
There will probably never be a business case for them to implement XMI
In many cases it is not even possible because they are not software engineering tools
Very complicated – has taken years for a very limited set of like-functioned tools to exchange
OMG represents a sliver of the tools and standards relevant to architectures
An IEEE, INCOSE, or ISO standard would be broader

8. XMI sample

9. COTS Tools Identified
Tool Name
Vendor
OPNET
CORE
ViTech
Naval Simulation System - 4 Aces
METRON
InterChange
Trident Systems
Enterprise Elements
Artisan
Atego
Magic Draw
No Magic
Enterprise Architect
Sparx
Corporate Modeler
Casewise
planningIT
alfabet
MEGA Suite for DoDAF
Mega
Troux Standards
Troux Technologies
Rational System Architect
IBM
Rhapsody
Metastorm ProVision
Metastorm
QEA (QualiWare Enterprise Architecture)
QualiWare
Salamander MOOD
Salamander
Abacus
Avolution
PowerDesigner
Sybase
BiZZdesign Architect
BiZZdesign
MDWorkbench
Sodius
ARIS
Software AG
MAP Suite
Intelligile Corporation
UDEF Explorer
Knotion Consulting
System Architecture Management Utility (SAMU)
Atoll Technologies
Envision VIP
Future Tech Systems
EVA Netmodeler
Promis
NetViz CA
Rochade
ASG Software Solutions
R2EAsults
In2itive
iServer
orbussoftware
Architecture Engine
Rividium
PBO180
Eagle Optimization
Does not address “GOTS” tools specific to core processes

10. UPDM Team and PES Fatma Dandashi has opposed PES since 2007
The OMG slide (see next) conflates PES with the “monster matrix”
In v2.00 the MM was used in generating the 52 XSDs
Since 2.01 (March 2010), this is no longer the case. UPDM team was very happy with this change
Using the DoDAF Conformance levels briefed to the FAC (and planned for v2.03), UPDM 2.0 will initially claim Level 2 conformance (DM2 LDM)
Level 3 (PES), however, can be tested with everyday XML schema validators

11. UPDM DoDAF 2.0 and PES Slide
DoD has a vision of federated architectures that are linked together
Exchange of DoDAF models with DoD is via the PES
PES:-Physical Exchange Specification, XML based file format
Based on DM2 data dictionary mapping, defines all the elements that appear in all the views:- Approx 15,000 cells
Federated/Integrated
Joint Architectures
Federation/Integration
Methodology
Useful
Analytical
Information
PPBE
JCIDS
Investment
Reviews
Acquisition
Decision
Support
Tools,
Repositories,
and Registries 11

12. DoDAF-DM2 Conformance (proposed change for v2.03)
Level 1 -- Conceptually conformant
Uses DoDAF terms and aliases (from DM2 CDM) to categorize its concepts
DoDAF views (AV-1 thru DIV-3) have correct information according to “monster matrix”).  For example,
An OV-2 with radios would be non-conformant
An OV-4 with Tank parts would be non-conformant
Fit-For-Purpose (FFP) would have to be conformant with whatever the FFP model specifier said, e.g., a “FFP-1" view for which the originator specified the model as Services mapping to Capabilities should have Services and Capabilities and the relationship but shouldn't have unrelated info
Level 2 -- Logically conformant
Level 1 + adheres to terms and relationships from DM2 LDM and aliases
Level 3 -- Physically conformant
Level 2 + expressed as DoDAF – DM2 PES that can be consumed by others
Level 4 -- Semantically conformant
Level 3 + IDEAS semantics are correct 12

13. Why does UPDM team have problem with PES if it’s just an XML version of the LDM?
It’s testable
Generating PES is a lot easier than ingesting it
The Government hasn’t emphasized that option
The OMG slide shows the general use case for data exchange
Authoring / development tools  analysis tools, i.e., authoring tools only need to generate
If a UML authoring tool exchange is needed for some use case, use XMI, not PES
The Government has alluded to XMI being the standard for DoDAF
This is unrealistic because UML tools are not the one-size-fits-all tool for every architecture project -- FFP
Not in the overall interest of the architecture program
Interfaces to core process authoritative data sources, e.g., DITPR
Interfaces to core process tools, e.g., EISP, JACAE, JCPAT-E
Data exchange based on IDEAS, MODEM, and CUDEAM
Dr. Dandashi continues her 3-year opposition to PES in the meetings
If Dave McDaniel is not present, she will spin the UPDM team

14. What are the UPDM PES Problems?
Don’t know
There are only 6 PES Change Requests before the DoDAF-DM2 Working Group out of ~250 CRs
None are high priority
The UPDM team has been a member of the WG for over two years
They can turn in CR’s via web or
They have turned in many CR’s on the DoDAF and LDM
~75, of which ~50 were resolved in 2.01 and 2.02
None on PES
Upon receipt of the white paper, the established procedure would be to parse issues into the CR system for peer review and work by the WG and then Component review via the FAC

15. Conclusion PES is not a CADM-type problem
PES is just a way to exchange DM2 data via XML
DM2 is the only solid part of DoDAF 2.0
The DoDAF model descriptions have massive quality problems which will be a drag on CA-Federal
Using DM2 is the only hope of fixing them
XMI cannot be the one-size-fits-all standard for architecture data exchange
Most tools cannot support
Recommend proposing to vendor’s list and at vendor’s day to get non-UML tool reactions
Most ADS cannot import or export to
If a commercial standard is desired, recommend work with IEEE, INCOSE, ISO, IDEAS, and NATO
The UPDM white paper should be peer reviewed by the WG
WRT UPDM team, recommend Government:
Request PES generation only
Make sure they understand limits of XMI for Government architecture purposes

16. Compare XMI Pro’s Con’s PES Pro’s Con’s Commercial
UPDM tools (5) implement
Con’s
90% of architect tools won’t / can’t implement
Won’t interface to GOTS tools and ADS’
Was originally designed as a CASE tool not a tool to support the 6 core processes
PES
Pro’s
Matches DM2 exactly
A DM2 database can import and export easily
IDEAS  MODEM and CUDEAM interoperable
Was designed specifically to support the 6 core processes
Any tool or database can implement once they relate to DM2
Con’s
Government developed