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

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

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

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.

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

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

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

XMI sample

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

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

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

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

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

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

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

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