1. 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

2. 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).

3. 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.

4. 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

5. What Makes IDEAS Different ?
The BORO Methodology -
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

6. 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

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

8. 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.

9. 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.

10. 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”

11. 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.

12. Foundation Top Level

13. Foundation: Key Objects

14. Common Patterns: Whole-Part

15. Type Instance Pattern

16. Domain Patterns: Process Type

17. Domain Patterns: Agent Super-SubType

18. Domain Patterns: Information Element Whole-Part

19. Common Patterns: Naming

20. Common Patterns: Geopolitical Area

21. Common Patterns: Calendar Period

22. The BORO Process

23. 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

24. 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

25. 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

26. Project Plan

27. Project Plan

28. 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

29. 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

30. Additional Information
Wiki at
The IDEAS Group website is