connecting people with information coi information exchange vocabulary (iev) development for further...

Connecting People With Information

COI Information Exchange Vocabulary (IEV) Development

For further information email OSD at: [email protected]

DoD Net-Centric Data Strategy (DS) and Community of Interest (COI) Training

2-Day Training Version 08.3

2

Purpose

• Discuss the Universal Core

• Discuss the importance and benefits of information exchange vocabularies (IEV)

• Suggest a repeatable development process for information exchange vocabularies

• Delineate best practices and development challenges

3

Outline

• Universal Core

• Information Exchange Vocabularies (IEV)– Need for and benefits of IEVs– IEV development process

• Best practices

• Challenges

4

Limiting Factors of Information Sharing

• Historically, Programs have defined their own vocabularies and information exchange schemas, limiting the amount of understandable information that can be shared

• Communities of Interest (COI) have helped by developing common vocabularies within the COI to enable increased information sharing, however, sharing information outside the COI is still a challenge

• The development of COI vocabularies have demonstrated that a common, minimal set of “words” span community vocabularies – agreeing to the definition of these words will help cross-community information sharing

Source: Following slides taken from DoD/DNI Universal Core Executive Briefing

5

To enable information sharing, a common baseline standard is needed

• The Universal Core is a joint DoD/IC effort to agree on a common baseline standard vocabulary to enable information exchange

• The Universal Core …– Is a reusable method and set of artifacts to improve the sharing of

information that are fundamental to most operational processes

– Provides a simple starting point for teams to extend as they respond to complex data sharing opportunities

– Reduces mediation / translation between systems for a small number of the most valuable operational concepts

6

Key Principles of Universal Core

• Build a strong foundation– Policy, Governance, Definition, and Test processes

• Build Joint from the start– DoD and IC communities

• Harmonize across communities• Standards based• Small core with the following attributes

– Suitability - include only a few critical objects– Simplicity - for widespread adoption– Extensibility - to meet individual community needs– Leveragability - of existing standards, tools, and expertise– Supportability - for long-term success

7

Universal Core Background

• DoD Directive 8320.01– Attempted to define a large data model for all DoD systems to adopt– Too difficult to harmonize, implement, and scale

• DoD Directive 8320.02– Define and implement interoperability around Communities of Interest– Success harmonizing across the community and streamlining

implementation• Cursor on Target

– Simple, small, and powerful exchange standard– Applied loose coupling strategy– Led to numerous implementations and real warfighter capabilities

• Universal Core– Leverages the harmonization success of Communities of Interest– Simplicity and power of Cursor on Target– Application of commercial and DoD/IC standards– Cross-community agreements

Sup

erse

ded

by

8

DoD and IC Universal Core Data Schema

Task/Mission

COIExtensions

Service / Organization Specific Extensions

Domain Common Cores

Universal Core

WhenWhere

Increased Agility 6

• A universal core data schema that enables information sharing– Ways to describe “when,

where” types of information

– Minimal set of terms in the core

– Agreed to by DoD and Intel community

– Appropriate use of open and Government standards

– Extensible by COIs and systems as needed

9

Governance ProcessSenior Enterprise Services Governance Group (SESGG)

• Oversee Joint Data Strategy and Enterprise Services Implementation– Define the required measurement and control mechanisms to ensure DoD-

wide and IC-wide implementation

– Identify and develop necessary policy changes, including measurement and control responsibilities, to ensure consistent implementation

– Establish oversight forums, as required, to enable the DoD CIO and DNI CIO to review implementation progress

• SESGG Membership– Mr. Mike Krieger, co-chair, DoD CIO– Mr. John Brantley, co-chair, ADNI CIO– Mr. Ron Bechtold, Army, – Mr. Brian Clingerman, Navy,– Mr. Kent Werner, AF– Mr. David Green, USMC– Ms. Bobbie Stempley, DISA– Mr. Mac Townsend, DIA– Mr. Dennis Wisnosky, BTA

10

Universal Core Harmonization, Governance, Policy, Test

• Four Working Groups, each containing participation from all the organizations that make up the SESGG

– Methodology - DNI and Navy lead the methodology for defining and evolving the universal core schema

– Governance - AF leads the development of Governance structure and processes

– Test and Eval – JFCOM and Army lead the Test and Evaluation methodology and execution

– Policy - DIA and DoD lead the Policy definition

11

Universal Core Adoption Goals

• It is our goal that as Universal Core matures…

– Communities of Interest (and associated systems) will adopt UCore

– Systems that are in the process of implementing information exchange capabilities will adopt UCore

– In the future, DoD and IC systems that exchange Ucore elements (“when, where, and what”) will adopt UCore

12

Future Vision for Universal Core

• Federal Governance Model – Broaden impact of Universal Core to span DoD, IC, DoJ, DHS, State and Local

• Refine the processes to inform policy, governance, test and evaluation and implementation

• Accommodate requirements of new partner federal agencies

• Refine Universal Core syntax and semantics based on implementations and lessons learned

13

UCore V2.0 Vision, Scope and Governance

Development and

Configuration Management

(DoD, DoJ Lead)

Policy Implementation

(IC Lead)

Outreach and

Communications(DHS Lead)

Executive Steering Council (ESC)

(Rotating Chair between DoD, IC, DoJ, DHS and State/Local Representative)

DoD CIO Initial Chair

Business Case

Design / Build

PilotTest and Eval

Config Mgmt

14

Outline

• Universal Core

• Information Exchange Vocabularies (IEV)– Need for and benefits of IEVs– IEV development process

• Best practices

• Challenges

15

Illustration: “Secure the Building”

One reason Government Agencies and Military Services have trouble operating jointly is that they speak different languages.

• “Secure the Building!” What does it mean?

– Security Personnel: “Sweep the place for bugs”

– Navy: “Turn off the lights and lock the doors.”

– Army: “Surround the building, occupy, and control entry.” – Marines: “Call in close air support, assault with small team, neutralize

occupants, fortify and hold at all costs until properly relieved. SEMPER FI!”

– Air Force: “Take out a three-year lease with option to buy.”

16

Illustration: “Target”

• Targeting Community: An area designated for future firing

• Intel Community: A country, area, installation, agency, or person against which intelligence operations are directed

• DoD: an area, complex, installation, force, equipment, capability, function, or behavior identified for possible action to support the commander’s objectives, guidance, and intent

Others:• A performance goal or objective• Marksman: an object to be aimed at in shooting practice or contests• Fencing: the portion of a fencer’s body where a touch can be scored• Surveying: the sliding sight on a leveling rod• An interbank payment system for processing cross-border transfers in the

European Union• A short album released by the rock band Hoobastank in 2002• A large merchandise retailer in the United States

Terms are ambiguousTerms are ambiguous

17

Defining “Information Exchange Vocabulary”

Vocabulary:Represents agreements on the terms and definitions common to the COI, including data dictionaries. – DoD 8320.02-G

Information Exchange Vocabulary (IEV):The terms employed and understood by a particular COI that precisely define the syntax and semantics of information exchanges within that community

“[COIs] … must exchange information in pursuit of their shared goals, interests, missions, or business processes and therefore must have shared vocabulary for the information exchanges.”

– DoD 8320.02

“[COIs] … must exchange information in pursuit of their shared goals, interests, missions, or business processes and therefore must have shared vocabulary for the information exchanges.”

– DoD 8320.02

COI IEVs must support “shared goals, interests, missions, or business processes”– Data representations internal to individual systems are not under the

purview of the COI or its IEV

18

Information Exchange Vocabularies

XML Schema Definition(Specifies syntax & semantics for XML instance)

XML Instance(Provides actual message payload)

CORE SERVICES (DISCOVERY, MESSAGING, SECURITY)

Data Sourc

e

Publish

19

Information Exchange Vocabulary: The Schema

The schema specifies the syntax and semantics for the information exchanges

The schema specifies the syntax and semantics for the information exchanges

20

The instance provides an example of what actually goes across “the wire” and it complies with the schema

The instance provides an example of what actually goes across “the wire” and it complies with the schema

Information Exchange Vocabulary: The Instance

21

The Need for COI Information Exchange Vocabularies (IEVs)

• Today, systems store and share data in conflicting and/or proprietary formats

• Data semantics are often embedded in code and databases

• Conflicting representations of the same information impedes semantic understanding

• This results in many transformations into other formats and a large amount of work to understand data meaning – Results in unnecessary inefficiencies

• COI information exchange vocabularies standardize syntax and semantics– Syntax = data structure– Semantics = data meaning

22

Benefits of IEVs

• Standardizes definitions for information exchanges

• Promotes interoperability and understandability through common semantics (i.e., meaning) and common syntax

• Breaks down communication barriers

• Decreases the amount of transformation/translation to other formats

• Provides a common representation for information exchanges

23

Drives

Enables

Development of IEVs: The methodology

Data Needed

Data Needed

Service Implementations

Service Implementations

STARTHERE

STARTHERE

STARTHERE

Enables

Community Information Exchange

Vocabulary

Community Information Exchange

Vocabulary

Capability Delivery

Capability Delivery

Drives

InfoSharing

Need

InfoSharing

Need

Drives

Service Needed

Service Needed

24

Finding the Loose Coupler

One system,Intersection is

everything

Two systems,much less is

common

Three systems,Intersectiongets smaller

More systems,intersection

keeps shrinking

Green & Purplecan form a

sub-schema

Other Systemscan have

sub-schemas

25

Stakeholder ValidationDevelop Draft Products

IEV Development Process

IEV Approval & Registration

UpdateProducts

ValidateProducts withStakeholders

UpdateProducts

ObtainCOI SteeringCommitteeApproval

Update OfficialIEV Baseline

Register IEV

Develop Draft IEV Products

ConductDMWG

Workshop

yes

yesno

Are stakeholders’requirements met?

Products ready for approval?

COI Steering

Committee

Obtain COI Executive

Board Approval

COIExecutive

Board

Next spiral?

yes

No

no

Determine ScopeConduct DMWG

Workshop

Determine IEV Format

Research RelatedIEV Efforts

Identify SMEs &Data Modelers

Develop Use Cases

IdentifyStakeholders

1 Month

2 Months

1 Month

1 Month

To view details for each stepClick Here

Acronyms:DMWG := Data Management Working GroupIEV := Information Exchange VocabularySME := Subject Matter Expert

26

Best Practices

• Goal is not consensus – the goal is to reach closure

• Limit IEV scope– Avoid the “Uber-model” or “vocabulary to rule them all” approach– Focus on clear, concise information needs– Anchor the IEV upon well-defined services and use cases– Recognize when the IEV is “good enough”

• Be mindful of your information producers and consumers– Limit the complexity of the model; strive for simplicity

“Things should be made as simple as possible, but no simpler.” – Albert Einstein– Remember: producers and consumers will map to your COI’s schema; try to make it

easy for them

• Implement the Universal Core with COI specific extensions– Align with other models where appropriate

Check the DoD Metadata Registry (MDR) for existing, reusable schemas Joint Publications, ISO Standards, W3C standards, Geography Markup Language, etc But do not force-fit square pegs into round holes

• Provide capability to express information pedigree (source, confidence, timeliness, impact, real/non-real, etc.)

27

Best Practices (cont’d)

• Ensure involvement of right subject matter expertise and involve engineers, developers, designers, and programmers as soon as possible

• Capture semantics not just structure– Document/comment schema elements– Constrain data types where appropriate– Provide units for quantitative information

• Develop and post real examples of XML instance documents– Provides example usage– Provides test data for development effort– Verifies that instances support scenarios and use-cases

• Document your naming conventions, assumptions, design decisions, and version control processes

• Set clear objectives for each Data Management Working Group meeting

28

Challenges

• Reaching “closure”

• Thinking in terms of a small-set of loosely coupled and service oriented terms

• Getting the right mix of stakeholders and ensuring their participation

• “Over standardization”– Standardization vs Innovation/Agility

• Leadership that guides the development of the vocab

29

Summary

• IEVs standardize semantics, improving interoperability within the COI

• Use the Universal Core as the starting point for your IEV and make COI-specific extensions– Universal Core includes minimal set of terms agreed upon by DoD and

Intel community

• Development should be service oriented and leadership driven– Focused on a small set of terms – Not consensus-based

• Development cycle should not take longer than 4 to 5 months

• Products should be registered in the DoD Metadata Registry (MDR)

IEVs improve interoperability and provide a shared understanding

IEVs improve interoperability and provide a shared understanding

30

Backup Charts

31

History of the Universal Core

Standards

Principles

InitialStrike COI

IEV

StrikePilot

Decide toadopt as a

startingpoint for

Universal Core

Form Working Groups:– Policy– Governance– Test & Eval– DescriptionGoal: Increased

info sharing

Senior Enterprise Services Governance Group (SESGG)Implementations to solve

operational needs

SESGGForms

IntelligenceCommunity

DoD

TODAY FUTUREStrike COI

BusinessTransformation

Air Force

CoT

JC3IEDM

Army

Air Ops COI

Air Force

JTM

Navy

CoT = Cursor on Target JC3IEDM = Joint C3 Information Exchange Data Model JTM = Joint Track Management

Harmonization across organizations is HARD Lightweight interoperability standards and leadership are required

Stakeholders need an Enterprise perspective

DoD

32


Step 1: Determine Scope


UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV

Develop DraftIEV Products

ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases



33

Step 1: Determine Scope

• Conduct a Workshop for the DMWG to:– Identify Stakeholders

Formally invite stakeholder organizations to participate Identify the key programs of record (systems) that are producers and

consumers of the data and get them involved early Identify organizations and POCs that will vote on key decisions within the

DMWG– Identify Subject Matter Experts (SME) and Data Modelers

SMEs should have breadth/depth of domain expertise Data modelers should have database, XML, UML, and programming

expertise– Determine IEV Format

Reference slides on IEV artifacts– Develop Use Cases

Use cases will steer the IEV development Use cases prevent scope creep and provide focus

– Research Related IEV Efforts Identify existing vocabularies that can be reused/leveraged Identify a IEV format and related standards

34


Step 2: Develop Draft IEV Products


UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV


ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases



35

Step 2: Develop Draft IEV Products

• Elements of a COI IEV might include:– Use case diagrams– Conceptual Data Model (Object Models)– Logical Data Model (Class Relationship Diagrams)– Data Element Listing– Data Dictionary– XML Schema Definition (XSD) Files– XML Instances– Technical Standards Listing– DoD Discovery Metadata Specification (DDMS) Profile– IEV Handbook

• It is important to emphasize that these are NOT required– Ultimately, your COI should decide which ones it is going to create– Remember: the goal of each is understandability

• The IEV provides a standardized framework for exposing COI data to various systems and users to perform monitoring, operations, analysis, or other activities

• Per DoDD 8320.02, the intent of IEV is to “…make data assets understandable [and]…reusable”

36

IEV Development Process: What does a COI IEV typically look like?

UML Class DiagramsLogical Data Model

COI XML Schema COI XML Instance

Conceptual Execution

Logical structure for

the XML schema

Structure for XML instance

documents

Sample XML tagged data

Source: Adopted from C2 SSA COI DMWG

37

Sample Automatic Generation Process

Develop UML Use-CaseAuto Generate XSD - XML

IEV HandbookDetermine Pilot Demonstration

Class Relationship Diagram

38

IEV Common Artifacts

• Use case diagrams– Graphical examples with supporting text that depict the intended uses of the IEV with specific activities and actors

included• Conceptual Data Model (Object Models)

– Diagram(s) that depict the classes and the relationships between those classes without including attributes of each class

• Logical Data Model (Class Relationship Diagrams)– The Conceptual Data Model with attributes included

• Data Element Listing– A simple quick reference list of all the data elements (without attributes) used within a COI's XML schemas. These

elements should directly map to the classes in the Conceptual Data Model. • Data Dictionary

– A document that lists and defines every data element, its attributes, and data type. It should closely map to the Logical Data Model.

• XML Schema Definition (XSD) Files– A set of components such as type definitions and element declarations that can be used to assess the validity of a

well-formed XML instance document• XML Instances

– XML documents that provide concrete examples of how to use the IEV and typify the messages that will be delivered to end consumers. These are derived from XSD files.

• Technical Standards Listing– A brief listing of any technical standards, external XSD schemas, or other data models that were incorporated within

the IEV• DoD Discovery Metadata Specification (DDMS) Profile

– Specifies the elements and definitions that your COI will use from the DDMS to aid content discovery.• IEV Handbook

– Capstone document that includes all IEV artifacts with descriptions and explains the assumptions, constraints, methodology, and design decisions that drove the IEV development effort

39

Common Artifacts: Use Case Diagrams

• Graphical examples with supporting text that depict the intended uses of the IEV with specific activities and actors included

class Class Model

Maritime Domain Awareness Services

Analyst Decision Maker

Associate Maritime Information

Prov ide Vessel Information Prov ide Cargo

Information

Prov ide People Information

Prov ide Conv eyance Information

«extend»

“Analyst is able to discover and access vessel, cargo, and people information that is visible, accessible, and understandable. Analyst then associates vessel, cargo, people information to produce new value-added information products.”

40

Common Artifacts: Conceptual Data Model

• Diagram(s) that depicts the classes and the relationships between those classes without including attributes of each classclass Class Model

TemporalObject

Conv eyance

Vessel

PeopleCargo

isA

isA

1

associatedWith

* ** *

associatedWith

*

41

Common Artifacts: Logical Data Model

• The Conceptual Data Model with attributes included

• Some classes may serve as placeholders in anticipation for subsequent spirals– For example, Cargo and

People

class Class Model

TemporalObject

- time: Time- location: Location- courseOverGround: int- speedOverGroundInKnots: int- rateOfTurn: int- trueHeading: int

Conveyance

- GUID: char- name: char- callSign: char- intendedDestination: char- estimatedTimeOfArrival: char

Vessel

- IMONumber: int- MMSI: int- officialNumber: int- hullNumber: int- flag: char- homePort: char- vesselLengthInMeters: int- grossTonnage: int- netTonnage: int- displacement: int

PeopleCargo

isA

isA

1

associatedWith

* ** *

associatedWith

*

42

Common Artifacts: Data Element Listing

• A simple quick reference list of all the data elements and complex/simple types used within a COI's XML schemas

• Listing should directly map to the Conceptual Data Model

• Diagram on the right was automatically generated from Altova XML Spy– Many of the modeling

tools provide a similar capability

43

Common Artifacts: Data Dictionary

• Document that contains a listing and description of each class, attribute, type, and relationship

• Diagram on the right was automatically generated from Altova XML Spy– Many of the

modeling tools provide a similar capability

44

Common Artifacts: XML Schema Definition (XSD) files

• An XML Schema is a set of components such as type definitions and element declarations that can be used to assess the validity of a well-formed XML instance document

<xsd:element name="heading"> <xsd:annotation> <xsd:documentation>Heading is measured with

respect to true north. Measured in degrees (0 <= heading < 360 )

</xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:decimal"> <xsd:fractionDigits value="1"/> <xsd:maxExclusive value="360"/> <xsd:minInclusive value="0"/> </xsd:restriction> </xsd:simpleType></xsd:element>

45

Common Artifacts: XML Instance Examples

• Derived from an XSD file (i.e., XML Schema)• Provide concrete examples of how to use the IEV and

typify the messages that will be delivered to end consumers

<?xml version="1.0" encoding="UTF-8" ?>  -<dmwg:Message xmlns:dmwg="http://some-dod-dhs-namespace.mil/" xmlns:ism="urn:us:gov:ic:ism:v2" ism:classification="U" ism:ownerProducer=“USA" ism:disseminationControls="FOUO"> <version>0.1</version> <timeOrigin>2001-12-17T09:30:47.0Z</timeOrigin> <timeReceipt>2001-12-17T09:30:49.0Z</timeReceipt> - <collector>

<DataSource>Nationwide AIS (NAIS) </DataSource> </collector>- <conveyance xsi:type="dmwg:Vessel">

- <time> <startTime>2001-12-17T09:30:47.0Z</startTime> <endTime>2001-12-17T09:30:47.0Z</endTime>

</time>- <location locationAttribute="isAtLocation">

<latitude>26.158</latitude> <longitude>80.1835</longitude>

</location>- <vector>

<courseOverGround>270</courseOverGround> <speedOverGround>4.0</speedOverGround>

</vector>- <trueHeading>

<heading>182</heading> </trueHeading>- <rateOfTurn>

<rate>0.0</rate> </rateOfTurn> <UID>https://www.notional-amrs.mil/MMSI/304244000</UID> <mmsi>304244000</mmsi>

</conveyance> </dmwg:Message>

Message

Classification Markings /Dissemination Controls

Collector

Conveyance

Vessel

Time, Location,Vector, Heading, & Rate of Turn

46

Common Artifacts: Technical Standards Listing

• A brief listing of any technical standards, external XSD schemas, or other data models that were incorporated within the IEV

• Examples:

Technical Sandards Listing– AIS GUIDLINES

– IALA Guidline No. 1028 on the Automatic Identification System (AIS) Volume 1, Part 1 Operational Issues (Edition 1.3, December 2004) provided the developers a ‘one-stop’ information source for both operational and technical aspects of the AIS.

1. DDMS 1.0– Department of Defense Discovery Metadata Specification (DDMS) 1.0 (September 29, 2003)

provided elements to aid Content Discovery2. UML 1.1

– This standard was adopted for the UML Use-cases, Logical Data Models, and Conceptual Data Models

3. XML 1.0– This standard was adopted for the XML Schema Definitions (XSD) and XML Instance Documents

4. Intelligence Community Information Security Markings (ICISM V 2.0)– This is an Intelligence Community XML standard that was adopted to specify handling instructions

and provide information security markings on information assets.

….

47

Common Artifacts: DoD Discovery Metadata Specification (DDMS) mapping profile

• Some elements of the DDMS are mandatory while others are optional

• DDMS profile specifies the elements and definitions that your COI will use from the DDMS to aid content discovery

Core Layer Category SetPrimary

CategoryObligation Page

The Security elements enable the description of security classification

and related fieldsSecurity Mandatory 27

Resource elements enable the description of maintenance and

administration information

Title Mandatory 29

Identifier Mandatory 31

Creator Mandatory 32

Publisher Optional 35

Contributor Optional 38

Date Optional 48

Rights Optional 50

Language Optional 52

Type Optional 53

Source Optional 54

The Summary Content elements enable the description of concepts

and topics

Subject Mandatory 56

Geospatial Coverage

Mandatory unless not Applicable

59

Temporal Coverage

Mandatory unless not Applicable

68

Virtual Coverage Optional 72

Description Optional 74

The Format elements enable the description of physical attributes of

the assetFormat Optional 76

48

Common Artifacts: IEV Handbook

• Capstone document that includes all IEV artifacts (with descriptions) and explains the assumptions, constraints, methodology, and design decisions that drove the IEV development effort

• Capture the set of assumptions/constraints that the DMWG will operate upon throughout the IEV development process

– Many may only apply for a given spiral– Some may apply across several spirals– This should be one of the first artifacts developed; this is a living list

Do not include it within the IEV Handbook as an afterthought– Provides a set of inputs that will influence what is produced

Garbage in, garbage out– These should be evaluated and revised often throughout the IEV development process

and vetted with COI Working Groups and Leadership

• A description of your methodology is important because it describes your development approach and should articulate a repeatable process

• It is always a best practice to document the design alternatives that your DMWG considered throughout the IEV development process

– Be sure to document your rationale for the choices you made– Document (but don’t necessarily release) any unresolved design conflicts or contentions

49


Step 3: Conduct DMWG Workshop


UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV


ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases



50

Step 3: Conduct DMWG Workshops

• Conduct multiple DMWG Stakeholder Workshops– Meet at least once a month to maintain momentum– Get involvement from each stakeholder– Emphasize meeting purpose and expectations of stakeholders – Expect several iterations before delivery– Deliver initial IEV after 3-4 months

Achieve DMWG consensus or Elevate any issues to Steering Committee for guidance

• Stakeholders should include:– Representatives from the other COI working groups (e.g., Pilot and

Implementation working groups)– Representatives from the participating Programs of Record– Representatives from other COIs collaborating with or interested in

your IEV– Domain Subject Matter Experts– Technical Subject Matter Experts– Data producers and data consumers

• Appoint a Secretary for each meeting

51


Step 4: Stakeholder Validation


UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV


ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases



52

Step 4: Stakeholder Validation

• May want to provide forms for official feedback• Avoid letting SMEs walk away without sharing their

recommendations• Incorporate recommendations, modifications, and

updates in a timely manner• Publish products on the DMWG collaboration portal for

further review• Perform 1-2 week validation spirals

– Strive for concurrence between all voting organizations – May want to develop IEV validation “Rules of Engagement”

(e.g., 2/3 majority vote)• Present finalized products to the Steering Committee for

approval

53


Steps 5 & 6: Obtain Steering Committee and Executive Board Approval


UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV


ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases



54

• COI Steering Committee Validation– Deliver initial IEV products as soon as possible

– Generate a formal letter

– Identify programs of record that have needs met by IEV

– Document organizational concurrence and/or non-concurrence• After being coordinated through the COI Steering Committee,

propose that the COI Executive Board sign out a memo to senior level addressees. For example:– Under Secretary Of Defense (Acquisition, Technology, & Logistics)– Under Secretary Of Defense (Intelligence)– Vice Chairman Of The Joint Chiefs Of Staff– Under Secretary Of Defense (Comptroller)– Director, Program Analysis And Evaluation– Department Of Defense Chief Information Officer

Steps 5 & 6: Obtain Steering Committee and Executive Board Approval

55


Step 7: Register IEV Artifacts


UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV


ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases


Acronyms:DMWG := Data Management Working GroupIEV := Information Exchange IEVSME := Subject Matter Expert

56

Step 7: Register IEV Artifacts (DoD Metadata Registry)

Purpose: visibility and re-use, not standardization through mandate!

http://metadata.dod.mil

• “One Stop” Publish, Subscribe and Manage capabilities for Reusable Structural Metadata Components – Over 180,000 components (schema, stylesheet etc) registered – Includes translation logic for mediation & taxonomies – Over 8000 Registered Users (DoD, IC, DHS, NASA, NATO, etc.)– Supports > 900 Programs of Record > over 700 government orgs

organizations– Unclassified, Secret and Top Secret instances operating

• Run Time support available – Web Services – ebXML Registry capabilities

• User feedback driven– Online user-to-developer– DoD Metadata Working Group

57



UpdateProducts


UpdateProducts


Update OfficialIEV

Baseline

RegisterIEV


ConductDMWG

Workshop

yes

yesno



COI Steering

Committee


Board Approval

COIExecutive

Board

Next spiral?

yes

No

no


Workshop

DetermineIEV Format



Develop Use Cases


Step 8: Decision to Support Additional SpiralsAcronyms:DMWG := Data Management Working GroupIEV := Information Exchange VocabularySME := Subject Matter Expert

58

Step 8: Decision to Support Additional Spirals

• Are there additional services that would benefit the community? Can the IEV currently support those services?

• Subsequent IEV spirals should follow the same process– Well-defined scope and focus

– Lightweight IEV

– Stakeholder involvement

– Frequent iterations

– IEV approval

• If there is no intent to launch additional spirals, you will need to determine if your DMWG is going to perform Operations and Maintenance (O&M) on the IEV or transition those functions to another entity

59

Sample IEV Tools

• UML– SPARX Enterprise Architect

http://www.sparxsystems.com.au/ Does UML-to-XML and XML-to-UML conversions

– IBM Rational Software Architect http://www-306.ibm.com/software/awdtools/architect/swarchitect/index.html Does UML-to-XML conversions

– Sybase PowerDesigner http://www.sybase.com/products/modelingmetadata/powerdesigner

• XML– Altova XML Spy

http://www.altova.com/

– oXygen http://www.oxygenxml.com/

connecting people with information coi information exchange vocabulary (iev) development for further...

Documents

sharing of information

understandable information

crosscommunity information

information exchange

increased information

small core

community vocabularies

information email osd