Briefing to DoDAF 2.0 Development Team TBD 2007 The International Defence Enterprise Architecture Specification (IDEAS) for exchange Group IDEAS Briefing to DoDAF 2.0 Development Team TBD 2007

Purpose To deliver a unified specification for the exchange of military architectures between coalition partners Need to understand: Each others’ capability and functionality How to interface with coalition systems The main purpose of IDEAS is to support coalition military operations planning. The ability to exchange architectures between countries enables better understanding of each others capabilities, communications mechanisms and standard procedures. Sharing of standard operating procedures and doctrine Þ enables better understanding and more efficient joint operations. Sharing of systems information Þ allows for better orchestration of sensors and effects across the coalition. Change management Þ allows for better forward planning. Identification of system options Þ allows for selection of best capability, and reduction in redundancy and start-up effort. Identification of network configuration Þ means there is less re-work and less opportunity for gaps in understanding between the nations Assessment of Relative Performance Þ allowing simulation of capability prior to operational commitment. Force Structures Sharing of standard operating procedures and doctrine. Each nation has its own operating procedures, which are usually represented in process models (e.g. a DoDAF OV-5 Product). An ability to share these processes between partner nations enables better understanding and more efficient joint operations. Sharing of systems information. The nations generally use different communications systems, weapon systems and platforms. An ability to share technical information (within classification limits) enables better understanding of how partner nations' systems communicate and function. This allows for better orchestration of sensors and effects across the coalition. Change management. The procurement cycles in each of the nations are generally not coordinated with each other. Ability to share future systems information amongst partner nations allows for better forward planning. Identification of system options. In planning a coalition operation, it is useful for the planner to have an accurate picture of each nation's capability contribution. This allows for selection of best capability, and reduction in redundancy and start-up effort. Identification of network configuration. It is important for each nation to have an understanding of the comms laydown for an operation. An ability to provide each nation with the same understanding of the comms structure means there is less re-work and less opportunity for gaps in understanding between the nations Assessment of Relative Performance. IDEAS will enable exchange of complete Enterprise Architecture models, potentially allowing simulation of capability prior to operational commitment. Force Structures. Coalition nations will be able to share organisational structures and orders of battle with partners (again, subject to issues of security classification).

Scope The scope is four nation (plus NATO as observers) and covers MODAF (UK), DoDAF (USA), DNDAF (Canada) and the Australian Defence Architecture Framework. The initial scope for exchange is the architectural data required to support coalition operations planning – Systems – communications systems, networks, software applications, etc. Communications links between systems Information specifications – the types of information (and their security classifications) that the comms architecture will handle Platforms & facilities. System & operational functions (activities) People & organizations Architecture meta-data – who owns it, who was the architect, name, version, description, etc.

How is IDEAS Different ? DoD’s IT history is littered with grand plans for data integration Failures due to insufficient stakeholder engagement – i.e. attempting to “foist” a data architecture on unwilling parties Failures due to inadequate analysis techniques – usually based on process modelling Failures due to inability to properly compare different sources of information Failures due to “DoD-Centric” approach ignoring coalition partners IDEAS is different because: It does not seek to impose a particular terminology, way of working, or data architecture on the users and stakeholders It brings in the opportunity for international coalition interoperability It fosters a “view from nowhere” approach – soft systems practitioners will be familiar with this idea It is strongly founded in set theory, allowing it to provide a more accurate representation of real-world

What Makes IDEAS Different ? The BORO Methodology - http://www.boroprogram.org/ Provides a precise, mathematical approach to comparing information Very easy to understand, and stakeholders readily commit to use the methodology Guaranteed to produce a correct representation, and is fully transparent at every stage – stakeholders are involved so buy-in is kept all the way through Set Theory Traditional data modelling is generally not founded in mathematic principles IDEAS uses formal set theoretic tools to accurately represent the structure of real-world concepts The Naming Pattern Once the analysis is complete, the terminology used by the stakeholders is mapped back onto the resulting model Enables stakeholders to continue working with their own terminology Allows seamless integration of legacy systems Incremental Experimentation “Design a little, test a little” Won’t end up with an infeasible specification

Experimentation First experiment, exchange architecture data regarding the processes, agents, information flows, and sequences of activities (OV-5, 6c) involved in Battlefield Human Casualty Management. Using Canadian doctrine document as “test data” Want to show “value added” military utility, e.g., Inconsistencies in processes, sequence, timing, event triggers, information flow and reporting, … Knowing ahead of time could lead to adjustments or just understanding so there won’t be surprises during execution

Coalition Operations Pre-Deployment Exchange Experimentation SA XML Import (Update logic) EE XML Export (ALL) Telelogic System Architect® SQL Query RDFS Database IDEAS Data Exchange Format (RDFS) IDEAS RDFS Generate Parse *Many tools TBD; ones shown are notional

Methodology The work has begun with the development of a formal ontology to specify the data exchange semantics. IDEAS is a formal, higher-order, 4D (see four dimensionalism) ontology. It is extensional, using physical existance as its criterion for identity. In practical terms, this means the ontology is well suited to managing change over time and identifying elements with a degree of precision that is not possible using names alone. The ontology is being built using the BORO Methodology which has proven useful for the multi-disciplinary team working on IDEAS. BORO forces the ontology developer to consider each concept in terms of its physical extent. This means there can be no argument about names or meaning - something either exists or it doesn't. The BORO method also deals with classes and relationships by tracing them back to their members (classes) or ends (relationships). The W3C Resource Description Framework and Web Ontology Language (XML) will be the format used for data exchange. A demonstration of multinational interoperability is scheduled for September 2007, based on exchanging process models for casualty tracking.

Methodology and Approach A foundation ontology based on set and meronymy theory Membership Spatio-temporal overlap Domain ontology that is a specialization from the foundation E.g., Agent, Process, Information Element Reified relationships, e.g., whole-part for functional decomposition, overlap for input/output Use of Business Objects Reference Ontology (BORO) methodology to clarify concepts All concepts traced to real spatio-temporal examples Participants continued to: use UML as modeling language, profiled to IDEAS derive model from agreed operational constructs provide complete semantics Participants will fully document all aspects of the model and methodology for the IDEAS capability Participants will experiment with data exchange as they progress to ensure a model that can be implemented The foundation forces rigor and enables “ontologic free lunch” wherein a pattern, once developed, is reusable for other domain representations.

IDEAS Structure Provides a common semantic foundation for multiple uses The common foundation enables interoperability across domains and applications All traces back up to IDEAS, so also offers possibility of international interoperability Data sources act as requirements on the ontology, feeding up the stack into the areas of stronger governance – “standardisation by adoption”

high-level patterns (upper ontology) common objects (agreed taxonomy) Structure Layered approach Starting from first principles to ensure common understanding at the most fundamental level Reaching down to country-specific definitions whose meaning may need to be understood by other nations fundamental concepts: classes, instances, properties foundation high-level patterns (upper ontology) commonly used relationships: whole-part, sequence, etc. common objects (agreed taxonomy) internationally accepted terms: person, organization, materiel, etc. national extension national extension national extension national extension terminology specific to nations that which may be useful to other nations - e.g. Bowman, Bradley FV, etc.

Foundation Top Level

Foundation: Key Objects

Common Patterns: Whole-Part

Type Instance Pattern

Domain Patterns: Process Type

Domain Patterns: Agent Super-SubType

Domain Patterns: Information Element Whole-Part

Common Patterns: Naming

Common Patterns: Geopolitical Area

Common Patterns: Calendar Period

The BORO Process

Data Analysis Steps The BORO Analysis breaks down the data into its fundamental elements These are then re-assembled under the appropriate ontological pattern Finally, the names used by the original systems / parties are re-assigned to achieve seamless interoperability

The Naming Pattern The ontology itself is concerned with the nature of things Relies on the only thing that is irrefutable, the physical extent of something It is useful to ignore names when developing the ontology, as they carry too much baggage and confusion – people tend to cling onto names of things rather than trying to work out if things are the same or not Once the semantic de-confliction is done, the names can be re-assigned, in context of their owners – and this is how interoperability is achieved

IDEAS Model Status Foundation well defined Namespace pattern at initial definition Still need to finalise patterns for Overlap/Event, Time and Tuple Type Data being defined/incorporated/clarified Common Objects well defined Mapping of national terms to IDEAS terms has progressed facilitated by the namespace pattern Need to define who owns the namespace for each organisation/nation Top level IDEAS context diagram created and described Identified that a common upper level taxonomy will need to be defined for a number of areas of operational data likely to be exchanged via the IDEAS model

Project Plan

Project Plan

Exercise Concept Identify a scenario where exchange of architecture planning data across the Coalition aids: Planning for interoperability, e.g., processes, organizations, and/or systems Identification of interoperability issues before they happen in a real operation Better synchronization of forces in real operations

Side Benefits DoDAF 2.0 requirement for a standard dictionary to support DoD architectures Could provide ideas for “DoDAF ontology” Could leverage the IDEAS model to provide the top level of the ontology Interest in ontology is developing all over Govt. BORO methodology could be looked at by the Methods TWG as a way to systematically derive OV-7

Additional Information Wiki at http://en.wikipedia.org/wiki/IDEAS_Group The IDEAS Group website is http://www.ideasgroup.org

www.ideasgroup.org