DoDAF 2.0 Meta Model (DM2) Briefing for the JAWG 18 November 2010 MR. DAVID MCDANIEL Silver Bullet Solutions, Inc. / Lockheed-Martin Corporation Under contract to the Architecture and Infrastructure Directorate Office of the DoD Deputy Chief Information Officer (703) 607-0482 Michael.Wayson@osd.mil

Outline of Presentation DoDAF Meta Model (DM2) pieces Formal ontologic foundation: International Defence Enterprise Architecture Specification (IDEAS) overview Why we used IDEAS – benefits Simplification Quality Expressiveness The Physical Exchange Specification (PES) Active Configuration Management GFI Resources The International Defence Enterprise Architecture Specification (IDEAS) foundation was developed over several years by an international group. It includes a formal ontology using type theory and mereotopology. The U.S. DoD Architecture Framework adopted IDEAS as a foundation for the meta model for the new DoDAF 2.0. The initial reason for adoption was simplification of the modeling via inheritance of foundation “common patterns.” But later, it was found the ontologic tools provided a basis for analysis of issues by the DoDAF 2.0 mete model working group; once the group understood the IDEAS foundation, it provided principled ways for the group to analyze problems. As the DoDAF 2.0 entered service in May 2009, it also started becoming apparent the IDEAS foundation would provide a basis for achieving essential goals of EA, namely, integration of EA models from many heterogeneous sources and analysis of the resultant integrated dataset for EA purposes. The very motivators for EA in the first place, e.g., enterprise interoperability assessment, detection and filling of capabilities gaps, avoidance of unintended capabilities redundancies, system-of-systems engineering, and so on, were seen to depend on just this sort of ability to integrate and cross-walk EA models. This paper describes DoDAF 2.0 meta model development and the different types of benefits of adoption of IDEAS. It also describes some of the challenges with community acceptance and training.

The DM2 Has Three Levels DIV-1 DIV-2 DIV-3 Conceptual Data Model (CDM) Logical Data Model (LDM) Reified and Formalized relationships DIV-1 DIV-2 (This is where almost all the design and analysis work is done) DIV-3 (Auto-generated from the LDM) Conceptual Data Model (CDM) Concepts and concept relationships 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 Physical Exchange Schema (PES) XML encoding of LDM

Conceptual Level is Simple anything can have Measures Condition Guidance is-performable-under Rule Activity Capability Standard Agreement constrains requires-ability-to-perform 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 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

IDEAS Overview

Top-Level Foundation 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] http://www.ideasgroup.org 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. http://www.ideasgroup.org or http://en.wikipedia.org/wiki/IDEAS_Group

DoDAF Domain Concepts are Specializations so they Inherit -- Enables reuse of common patterns Thing Type Individual Individual Type A&D So you take all the DM2 domain concepts and classify them into the IDEAS foundation classes.

All Associations are Typed -- so their meaning is mathematically defined Before-after Whole-part for Types Overlap for Types Before-after for Types Description and naming Instance-of-type Instance-of-powertype A&D Similarly, we type the associations by classifying them under their IDEAS foundation class.

Benefits of IDEAS for DoDAF 2 Preface: the general pattern of architecture data development and usage Benefits of IDEAS: Model quality and simplification Mathematical rigor Expressiveness

General Pattern of Architectural Description Usage Create architectural descriptions Create architectural descriptions Create architectural descriptions Use architectural descriptions Create architectural descriptions Create architectural descriptions Create architectural descriptions Create architectural description JCIDS PPBE DAS SE Ops Planning CPM

Heterogeneous Data and EA For example: Interoperability assessment Capability gaps and overlaps Capability evolution measures SoS, FoS Portfolio optimization Joint, multi-agency, coalition operations Analysis of alternatives The very reason for EA implies a need to look at data from multiple sources

Example: Assessment Pattern Create Side Use Side For example: Queries for disconnects, inconsistencies, … Specialized tools (e.g., cost / risk / performance / sustainment models, interoperability assessment) Process simulators (e.g., comms flow, workflow, Petri nets, state machines) Campaign, mission, engagement, etc. simulators All have high-sensitivity to mis-interpreted, erroneous, incomplete, incompatible, … data register Create architectural descriptions Submit for core process event Get and integrate relevant datasets For example: Capability solution proposal Acquisition milestone review Interoperability and supportability assessment checkpoints Budget cycle (PPBE, IRB, CPM) Ops Plan (contingency update cycle, actual) Analyze and assess Present Results for core process decisions

The Wide Range of EA Data Assets DM2 is the neutral format for Interchange Interoperability Layers (notional) XMI / MOF Conversant (e.g., UPDM / SysML) Analysis Software DM2 PES XSD neutral implementation EA / ITA Tools Authoritative Data Sources EA Domain Concepts Common Patterns 4D Mereology Set Theory Naming Pedigree M&S Tools EA DBMS’ Ontic Foundation Reporting Tools and Formats Federal, Coalition, and other EA exchanges

Semantic Precision for Heterogeneous Data Integration Human-interpretable only A spectrum of information sharing Human-interpretable but with a predictable organized arrangement More structure than structured text Named records (or tables or classes) that are some sort of container for named fields (or attributes or columns).  Associations and relationships, containers can point to information in other containers Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information.  Referential integrity, data validation, cardinality rules, etc. Applicable mathematics: Set or type theory Mereology Mereotopology 4 dimensionalism Predicate calculus Logics: modal, Kripke, … Rules, operators: Commutative, reflexive, transitive, … Member-of, subset-of, part-of, … Let's start generally:  "unstructured data", e.g., free text, might be considered one end of spectrum and math (numeric or symbolic) another.   But even so-called unstructured free text can have structure, e.g., the OMG RFP template.  Why do we do semi-structured text?  There's a step to understanding what we’re doing.  Why do we do databases?  There's another step. The shortcoming of databases is that they usually have little more semantic structure than structured text -- named records (or tables or classes if you wish) that are some sort of container for named fields (or attributes or columns).  Via associations and relationships, containers can point to information in other containers.  Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information.  I don't think there's much going on besides that.  As for referential integrity, data validation, cardinality rules, etc., it's handy to go back to the semi-structured analogy and see that they just tell you what parts of the form or template have to be filled in, with what choices, what the rules are for cross-references, etc. Math does a lot more.  Let's just talk about logical entailment in this email.  Given, "I have a headache", how do you entail, "I have pain", unless you have a categorization of headache as a type of pain?  You won't get that from unstructured or semi-structured text, or database structure or SQL.  It's "common sense" to you but computers have no more common sense than a light switch (or even a few million light switches). Let's make this more relevant to EA.  "F-16C has a speed capability of Mach x" ==> some F-16's have a speed capability of Mach x "F-16's can fly at least Mach y" ==> F-16C's can fly at least Mach y "Ship's Self Defense System can parse and generate TADIL-J messages" and "SSDS is-part-of all CVNs" ==> CVN's can parse and generate TADIL-J messages I could go on and on.  Without the "intelligence" to perform entailment, data integrations, queries, and analysis algorithms miss connections.  I cannot even remember all the EA data integration and analysis routines I've seen over the years that flopped for this reason -- it is a real problem.  I'd bet Ian has lotsa examples too.  The C4ISR community has problems with semantic imprecision too. My basic point is that we computer scientists think we're doing a lot with computers when we use databases but it's really just storage and retrieval with connections only for exactly matching pieces of information (e.g., "keys" or exactly matching strings).  Reasoning requires a lot more and entailment is an important part.  IDEAS supports entailment and other sorts of mathematical understanding of the data with membership (~ set theory) and 4D mereotopology (parts and boundaries).  It only seems academic at first because it's so fundamental in human reasoning that it's hard to see that computers don't have it at all and that they need it if we want to use them for something more than just storage and retrieval.  We have to encode it into them with formal methods like IDEAS. It's a hard question because it's related to many questions that have been going on for a long time about AI, the "meaning of meaning", semantics vs syntax, types, set theory, categories, mereonomy, etc. I think now that we've got some of the "accidental" problems (e.g., when I had to write assembly language on green tablets or when we couldn't even run RDBMS' because they were too slow) behind us in computer science, we can start chipping away at some of these "essential" questions now.  Depends on near-universal mathematics and science that all learn very similarly

Simplification and Quality: Rigorously worked-out common patterns are reused Saved a lot of repetitive work – “ontologic free lunch” Concentration of rigor on common patterns results in higher quality and consistency throughout Model compactness -- DM2 is tiny compared to its predecessor by two orders of magnitude! Easier to learn -- a few hard concepts are easier to learn than thousands of conceptually intractable ones. Implementations get reuse too – same code, queries, … work for many datasets Super/Sub Type, e.g., F-15 is type of Fighter Whole Part, e.g., AEGIS radar is part-of the AEGIS ship Overlaps, particularly Interface Type, e.g., Asset data collection activities produce data for audit reporting Before-After, e.g., The collection task takes place before the posting and exploitation tasks

Simplification: Compare DM2’s Predecessor, a classic E-R model CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements! DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements – two-orders of magnitude smaller yet far more expressive

Enterprise Data Modeling -- Reconciliation and analysis method State of practice in data modeling: Noun and adjective analysis Similar to natural language written in a diagram Often laden with entrenched but obsolete technology considerations The fundamental concepts of Entity-Relationship and Class Models: predicate subject object Implicit, built-in, language features: predicate “has” (for attributes) Plural, singular notions (cardinality) Sufficiency and completeness notions (e.g., no-nulls) Make a table / class / attribute / field / enumeration / etc. for every noun encountered Really a structured document Joins and associations allow for flexible sub-documents Good for storing and retrieving information Lousy for automated computation upon Set theory – categories of things Meronymy – spatial relationships between things Tuples – ordered relationships between things Logic – deductive, monotonic, non-monotonic, … Inference – probabilistic, evidential, … Lexical semantics, mathematical linguistics, … Like all complex systems, made up of many pieces The pieces interact through data Originally, piece makers (engineers, programmers) worked pair-wise (e.g., at design meetings, telephone, test sites) to figure out the interaction – involved much human interaction With network “bus” architectures, easier to make interaction possible because the data is available But understandable only by much human interaction1 The number of pieces continues to grow2 The number that need to interact continues to grow3 The scope of data they would like to use continues to grow4 XML provides documentation with the data, but humans still have to read and understand it. e.g., Smart Ship, Integrated Bridge System, BMD Continuing C4I – Combat System integration, Joint systems, OA and CANES SoA componentization e.g., reference data such as ECDIS-N charts and GCCS-I3 use in Combat System

One Result of this practice -- data model “wars” C2 Core UCORE model MIEM Anti-Submarine Warfare (ASW) COI Blue Force Tracking (BFT) C2 Interoperability Group CBRN Coalition C2 Interoperabilty (Coal C2) Common Sensor GEOINT Standards COI (GWG COI) Global Force Management (GFM) GPS Based Positioning Navigation Timing Service Integrated Fires Joint Air and Missile Defense Joint Air Track (JAT) Joint Electronic Warfare Data Standardization Joint Targeting Intelligence (JTI) Maritime Domain Awareness Meteorology-Oceanography (METOC) Mine Warfare Symbology (SYM) Undersea Warfare XML (usw-xml) CNDE model Users of these different models believe their model is the best for many purposes, in many cases overlapping purposes. NIEM GML Sensor ML Transducer ML a smattering – see notes for short descriptions JC3IEDM (STANAG 5525) C2 Core – Command and Control Core – in development at JFCOM (again) UCORE – Universal Core -- https://ucore.gov/node/23 -- a simplified “digest” of structured data with metadata and a COI-specific “structured payload” for information exchange across DoJ, DHS, IC, and DoD MIEM – Maritime Information Exchange Model – relevant to MDA-related missions CNDE – Consolidated Net-centric Data Environment -- https://nesi.spawar.navy.mil/projects/jtm/ -- formerly the JTM data model and currently the model for CANES NIEM – National Information Exchange Model -- http://www.niem.gov – relevant to MDA-related missions GML -- Geography Markup Language -- http://www.opengeospatial.org/standards/gml Adopted by NGA as their standard for geospatial and imagery data dissemination. Sensor ML – Sensor Markup Language – Transducer ML – Transducer Markup Language -- JC3IEDM -- Joint Command, Control, and Consultation Information Exchange Model -- http://www.mip-site.org/ -- NATO standard for coalition C2 information exchange VMF – Variable Message Format – TADIL-J – Tactical Action Data and Information Link -- CoT – Cursor On Target -- http://cot.mitre.org/bin/view/CoT/ -- implemented by many smaller systems A “Common” Data Model Has Not Worked Mandating “common” is problematic: Ignored, e.g., DoD Data Admin policy and “Corporate Information Management” -- rescinded in favor of current “market-driven” strategy; SECNAVINST 5000.36, Or complied with at great cost in terms of $’s, rqmts-to-deploy time, and interoperability One size rarely fits all, e.g., normalization is good for transactions, bad for mining A rational basis for model determination seems better COI Name Mission Anti-Submarine Warfare (ASW) COI to implement ASW Data Strategies and Open Architecture principles in support of DoD and Navy goals. The ASW COI has data responsibilities related to the Battlespace Awareness, Command & Control, Force Application and Force Protection Domains within the Warfighter Mission Area (WMA). COIs with associated interests include MASINT, METOC, Mine Warfare and Maritime Domain Awareness. Data sharing and interoperability with US Coast Guard and coalition forces are key components of effective ASW warfighting. Blue Force Tracking (BFT) Develop and provide a BFT Information Exchange Standard that facilitates BFT across Joint and Allied/Coalition forces to effectively ensure that data is visible, accessible, trusted, understandable and in accordance with the DoD Net-Centric Data Strategy and Directive 8320.2. C2 Interoperability Group The mission of the Command and Control Interoperability Group (CIG) is to manage the US-JC3IEDM standard. The CIG will capture US requirements, and develop and maintain US extensions, a set of specifications, a common implementation, and other products in support of the US-JC3IEDM. In addition the CIG will interface with other C2 interoperability groups to identify common technical issues and develop common solutions, when possible. The CIG will assist in coordinating the interoperability of US C2ISR at the strategic, operational and tactical levels. CBRN Coalition C2 Interoperabilty (Coal C2) The aim of the Coalition C2 is to achieve international interoperability of Command and Control Information Systems (C2IS) at all levels from corps to the lowest appropriate level, in order to support multinational, combined and joint operations and the advancement of digitisation in the international arena, including NATO. The Army wants to comprehenvisely manage the development and growth of Coaliton C2 Interoperability efforts. Common Sensor To serve as the focal point for Common Sensor PED Development; National Signatures Program; Common Sensor PED Customer Outreach; Common Sensor Metadata, Product Standards, and Portal; Common Sensor policy; Common Sensor related issues pertaining to Electro-Optical, Radar, CBRNE, Radio-Frequency, Seismic, Acoustic, Magnetic, Infrasonic, Laser, SAR, Spectral, Thermal, Biometrics; Common Sensor Testing & Evaluation GEOINT Standards COI (GWG COI) The GWG supports the ITSC in the configuration management of GEOINT standards within the DISR. Additionally, the GWG provides a standards-focused forum that the NSG community can use as a means to exchange and communicate issues regarding GEOINT standards requirements, development, implementation, and conformance. The GWG recommends GEOINT standards for data, systems, and their interfaces to ensure interoperability with DoD and non-DoD systems. The GWG serves as a community-based forum to advocate for Information Technology (IT) standardization activities related to GEOINT. In this capacity, the GWG supports the Director of the National Geospatial-Intelligence Agency (NGA) in carrying out GEOINT functional manager responsibilities for standards. The GWG performs two major roles: 1) as a technical working group (TWG) of the ITSC, with all the responsibilities of an ITSC member and, 2) as a coordinating body for the GEOINT community to address all aspects of GEOINT standards. Through the GWG, community consensu Global Force Management (GFM) GFM is a process that enables insight into global availability of US forces, and provides a means to assess risks associated with proposed allocation, assignment and apportionment. GFM data will be transparent, universal and accessible on demand in a net centric environment.Global Force Management requires the implementation of a common force structure, for which there are three key elements. 1. A joint hierarchical way to organize force structure data for integration across Service-lines, known as the Force Structure Construct (FSC). 2. Force structure data that is rigorously specified via a GFM Information Exchange Data Model and its semantics unambiguously defined so that sophisticated computer programs can economically exploit it via the net-centric data strategy. 3. A common naming convention and data tagging technology, known as Enterprise Wide Identifiers (EWIDs), that must be accepted and used across DoD (including adoption by future Joint systems such as DRRS, DIMHRS, and Blue Force Tracker), with th GPS Based Positioning Navigation Timing Service - GPNTS To provide Positioning, Navigation and Timing (PNT) solutions to afloat combat systems. Integrated Fires Fires Knowledge Network (FKN) is for all Fire Support and Field Artillerymen no matter where their mission may take them. This site is dedicated to linking the operational forces to the Field Artillery Center and to each other while providing a One-Stop Shop for all Fire Support and Field Artillery professional knowledge. Joint Air and Missile Defense Develop a common vocabulary, based on required capabilities and associated functions, for defining Joint AMD-specific data that must be shared among Joint, Interagency and Multinational (JIM) AMD platforms in the execution of the AMD mission, as well as the data required to support future AMD capabilities. Provide a resource to the Air Defense and Missile Defense Namespace Managers to ensure that AMD-specific metadata stored in those Namespace repositories are consistent with the common AMD vocabulary and harmonized with associated metadata from within their respective Namespaces as well as other associated COI's supporting Namespaces within the DoD Registry. Enable the discovery, posting, and subscription to Air and Missile Defense-specific data by all organizations associated with the DoD in accordance with the DoD Network Centric Data Strategy. Joint Air Track (JAT) Develop the collaborative environment of users, data sources, and services that supports exposure of air track data. Joint Electronic Warfare Data Standardization To establish a collaborative effort to ensure mutual concurrence in the review, standardization, and formal registration of Joint Electronic Warfare data elements with the Defense Information Syatems Agency (DISA). Joint Targeting Intelligence (JTI) Joint targeting intelligence to support deliberate planning and ultimately execution. COI Products: Targeting tables in MIDB, Joint Targeting Database (JTDB), Joint Target Materials Program, Joint Targeting Toolbox (JTT), Military Targeting Committee (MTC), Joint Targeting Automation Steering Group (JTASG), Targeting Issues Working Group (TIWG), Combat Assessment Working Group (CAWG), DIAI 57-24, Schema sets for target folders, target lists etc. Maritime Domain Awareness MDA COI is a new initiative to standardize data for Maritime Domain Awareness. It is composed of a steering committee and four working groups. Tasks for the COI working groups are to: define/implement high level COI Capability Roadmap; synchronize COI products with JCIDS and Mission Areas; develop shared vocabulary in accordance with DoD Net-Centric Data Strategy; develop repeatable processes; and to facilitate service implementation. Meteorology-Oceanography (METOC) Improve the interoperability, standardization and usage of METOC data, products and value-added net-centric services for the Joint Warfighter. * Provide a dynamic, authoritative, collaborative forum for establishment of DoD standards associated with Joint METOC information and services. * Improve joint usage and availability of meteorological, oceanographic (METOC) and space environmental architectures. * Define standards for METOC data, algorithms & model applications, and associated METOC interfaces to the GIG. * Manage the METOC XML Namespace within the MDR and de-conflict XML components across the other community namespaces. * Identify and develop METOC COI-specific services that embody CES tenants. * Provide one authoritative venue for the standardization of Joint METOC data, products and services. COI Product: The Joint METOC Conceptual Data Model(JMCDM) is the foundation for METOC information, implemented through the JMBL interface (Joint METOC Broker Language) as the single, web-enabled request and re Mine Warfare provide a location for creation and sharing of data to be used in the Mine Warfare arena Symbology (SYM) To develop and maintain Joint Warfighting Symbology MIL-STD-2525, for interoperability among C2 systems. Undersea Warfare XML (usw-xml) Create\assemble a common XML vocabulary to facilitate the establishment of coherent battlespace visualization capabilities for network-centric undersea warfare. VMF (MS 6017) TADIL-J (MS 6016) Cursor On Target Like diverse languages, there is a high cost to learn

Some real-world and costly results of this practice Cost and project risk Developers and integrators must learn multiple proprietary “languages” Need to build many translators Over promised ability of “translation hubs” Context, interdependent, and value-dependent translations Operational impact E.g., from “lossy” translations, mis-translations, … Difficulty in transitioning new technologies, e.g., automated processing tools Prohibits or impedes scaling and cross-domain integration and data sharing Impedes Net-Centricity / OA / SoA due to need for much human interaction Only unanticipated users of the same “language” can understand your data The costs and risks – both project and operational -- are usually underestimated

Reconciling Using IDEAS Analysis Technique: BORO1 Agreed-upon principles that provide a principled basis for issue analysis Example decision process time Example BORO analysis diagram Dave Copy and Send Ian Copy DD, copy 1 Flow process Send part Dave’s Document, Original Receive part Dave’s Document, Copy 1, in flow state DD, copy 1 1. Business Objects Reference Ontology, http://www.boroprogram.org/ or http://en.wikipedia.org/wiki/BORO_Method

Improved ability for analysis: Mathematical Foundation

Type Theory Math Examples Flip over – not time to brief

Mereotopologic Math Examples Overlaps, spatial relationships (mereotopology) Behaviors -- Sequences, before-after (4D mereotopology) Flip over – not time to brief

Some Math Sources National Center for Ontologic Research (NCOR), http://ontology.buffalo.edu/smith/ Direct Model-Theoretic Semantics for OWL 2, http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/ Vocabulary Interpretations Object Property Expressions Data Ranges Class Expressions Satisfaction in an Interpretation Class Expression Axioms Object Property Expression Axioms Data Property Expression Axioms Datatype Definitions Keys Assertions Ontologies Models

Examples of Improved Expressive Power Reification levels not the naïve, OV=requirements, SV/TV=solutions Representation pattern Capabilities and Desired Effects Information Pedigree Services, Agreements, and Rules Metrics

Design Reification and Requirements Traceability describes describes describes Thing describes describes Pedigree (requirements) Pedigree (requirements) Pedigree (requirements) Pedigree (requirements) Architectural Description Pedigree (requirements) Architectural Description Architectural Description Architectural Description Architectural Description Rules Rules A&D Successive refinement of the Architectural description. For any phase, it is traceable to the prior (pedigree). The prior phase becomes the rules that constrain the activities of the next performer – adherence to requirements baseline. They’re all aiming at the same future Thing, just describing it in more detail and in different ways as you go along. Rules constrain Rules constrain Rules constrain constrain constrain Worker Technician Engineer Architect Executive Strategic Op Rqmt TLR SLR A-Spec B-Spec C-Specs CBA ICD AoA Perf Spec CDD CPD IOC time

Capabilities and Desired Effects Desired Effect = state of some resource + desired by somebody, e.g., State of enemy becomes neutral State of disastered peoples becomes healthy Takes getting used to thinking 4-dimensionally but most users have had an “aha” moment and seen great power in thinking so 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.

Representation Pattern Links: Information and Data (in the DIV’s) with the Things being described, e.g,. Imagery Formatted data Messages One level of reification to another – describing the same Thing Architectural descriptions to the Thing that has the architecture* * Consistent with ISO/IEC 42010 / IEEE Std 1471-2000

Information Pedigree Model Workflow model, e.g., Open Provenance Model (provenance = linked together pedigrees) ~ Activity model (OV-5 + 6c) D Requirement in the DoD Net-Centric Data Strategy (NCDS) Similar to Open Provenance Model Describes the workflow that led to the production of the information Pedigree is the immediate link – provenance further back in the production chain Activities, Performers, Performer states, resources used, rules abided by, measures conformed to

Service Descriptions From OASIS SoA RAF, Figure 27, “Service Description” 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.

Service Descriptions as Modeled in DM2 This means a Service Description can have all the structure of an Architectural Description, e.g., Activities Before-After Rules Conditions Data structures Locations Dependencies Etc. Continuing work with OASIS and OMG (SoAML) on fine structure, e.g., for: Reification process for agreement for establishment of Execution Context for Joint Action

“Fit for Purpose” Architecture Descriptions Based on DM2, the architectural description can support desired presentations for multiple purposes. The Physical Exchange Specification (PES) supports this Working on governance for FFPs in the DoD EA COI

The PES schema is auto-generated from the Logical Data Model The PES has three parts: Reference to the IDEAS and DM2 structures The data Indicators of what DoDAF Models (AV-DIV) this data pertains to DoDAF models (52) DM2 elements (~ 300) (see Data Dictionary to read entire matrix) Legend: “n” = Necessary data for this DoDAF model “o” = Optional “f” = Foundational Blank = cannot be included in this DoDAF model

Active Configuration Management NSA AF DoN Army Marine Corps DISA DISA DISA FAC – Voting – 23* votes DoD CIO JFCOM STRATCOM JCS J6 DCMO USD(I) P&R AT&L Monitors and redirects DNI CIO Monthly reports and new baseline decision briefs DoDAF-DM WG – Collaborative – Agreed-upon business rules enable analysis of different opinions Framework Groups OMG / INCOSE / NDIA MODAF / NAF / TOGAF FEA / FSAM Core Process Stakeholders CJCSI revs AT&L SoSE & Acq Reform Combatant Command architectures CPM Governance PA&E Framework & Ontology Groups OMG / INCOSE / NDIA IDEAS / NAF UCORE Enterprise Vocabularies ~ 300 members Meets weekly Vendors EA/ITA Tool M&S Data Analysis Repository Data Integration Data Exchange Pilots Early Adopters Federation COI Coordination Groups DoD MDR WG DoD COI Forum To join, go to DoDAF 2 website and select the DoDAF-DM2 WG

Resources DoDAF-DM2 WG Collaboration site Reference material IDEAS Bibliography Oracle and SQL Server DDL scripts Physical Exchange Specification (PES) XML generation queries DM2 in OWL

Summary The basic structure of DoDAF / DM2 is holding up well. Refinements by the community are making it simpler, clearer, and more responsive to DoD’s needs. Pilots and early adopters – Government and vendors are very helpful. The GFI database scripts and PES queries are speeding adoption of DoDAF 2. Core process dataset requirements should lead to the end of “checklist architectures”.

Points of Contact Michael Wayson Michael.Wayson@osd.mil (703) 607-0482 Shelton Lee Shelton.Lee@lmco.com (703) 916-7340 David McDaniel David.McDaniel@SilverBulletInc.com (619) 253-9040 It is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience. If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts. There are six steps is the DoDAF methodology: 1-Determine the intended use of the architecture 2- Determine the scope of the architecture 3- Determine data required to support architecture development 4- Collect, organize, correlate and store data 5- Conduct analysis in support of architecture objectives 6- Document results Managers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed.

Questions

Backup

Diagram and XML Examples are Available!

CIO Governance Framework