“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)

Updated Plan

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

“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)

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

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

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

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

A “sausage grinder”

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”

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)