1. “New” things Discussed in London
Detailed planning for 4/08 demo
Backtrack rehersals, setups, …
“Military Utility”
Ops planning and data exchange scenario
Useful results from exchange (ideas on later slide)
Documentation
Op Concept Doc AU started
Model description
Methodology (Data TWG could use too)
Training on implementing data exchange (e.g., for federates, vendors)

2. Updated Plan

3. “As-is”
We need to document how the Coalition Ops Planning scenario would be done today
Manual? (paper, , faxes, phone calls, meetings, …)
Discovery of issues in the field (on-the-job interoperability)

4. “To-Be” Military Utility Scenario
Visualization Environment
Decision Environment
“To-Be” Military Utility Scenario
Relational DB Query Environment
SQL Query
OWL/RDFS DB Data Mining Environment
RDFS Database
IDEAS Data Exchange Format (RDFS)

5. IDEAS OCD Current structure: Mostly TBS/TBD CAPABILITY IDENTIFICATION
DEFINITION AND REFERENCE DOCUMENT
SOLUTION INDEPENDENT CAPABILITY NEEDS
EXISTING COALITION PLANNING SYSTEM
SYSTEM SOLUTION DESCRIPTION
Mostly TBS/TBD

6. IDEAS Model (prelim) Sections for each layer: Within each: Foundation
Common Patterns
Domain
Within each:
For each package/diagram:
Narrative description, diagram walkthru and items of special note
Standard data dictionary information
Examples

7. IDEAS Methodology (prelim)
How IDEAS differs from other methodologies
BORO overview
“Sausage grinders”:
Walk thru diagram
Examples

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

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

10. A “sausage grinder”

11. IDEAS Usage Guide OWL/RDFS Specification
Walk thru
Special notes
Examples
Guidance from experimentation on:
Generation from tools and databases
Ingestion into tools and databases
Querying and “data mining”

12. SBSI Current Tasking At end of GFY06, expending labor at ~$25K/mo
Currently ~$35K/mo due to ramp up on DoDAF 2 (DEV-T, CMG, TWG)
Annual -> ~$420K
~$150K DoDAF
~$270K IDEAS + travel (=UK+SWE+FL+?=~$20K)