Presentation is loading. Please wait.

Presentation is loading. Please wait.

Connecting People With Information COI Information Exchange Vocabulary (IEV) Development For further information OSD at: DoD.

Similar presentations


Presentation on theme: "Connecting People With Information COI Information Exchange Vocabulary (IEV) Development For further information OSD at: DoD."— Presentation transcript:

1 Connecting People With Information COI Information Exchange Vocabulary (IEV) Development For further information email OSD at: COI_HelpDesk@osd.mil DoD Net-Centric Data Strategy (DS) and Community of Interest (COI) Training 2-Day Training Version 08.3

2 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 3 Outline Universal Core Information Exchange Vocabularies (IEV) –Need for and benefits of IEVs –IEV development process Best practices Challenges

4 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 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 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 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 Superseded by

8 8 DoD and IC Universal Core Data Schema Task/Mission COI Extensions Service / Organization Specific Extensions Domain Common Cores Universal Core When Where 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 9 Governance Process Senior 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 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 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 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 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 Pilot Test and Eval Config Mgmt

14 14 Outline Universal Core Information Exchange Vocabularies (IEV) –Need for and benefits of IEVs –IEV development process Best practices Challenges

15 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 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 ambiguous

17 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 18 Information Exchange Vocabularies XML Schema Definition (Specifies syntax & semantics for XML instance) XML Instance (Provides actual message payload) C ORE S ERVICES (D ISCOVERY, M ESSAGING, S ECURITY ) Data Source Publish

19 19 Information Exchange Vocabulary: The Schema The schema specifies the syntax and semantics for the information exchanges

20 20 The instance provides an example of what actually goes across “the wire” and it complies with the schema Information Exchange Vocabulary: The Instance

21 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 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 23 Drives Enables Development of IEVs: The methodology Data Needed Service Implementations START HERE START HERE START HERE Enables Community Information Exchange Vocabulary Capability Delivery Drives Info Sharing Need Drives Service Needed

24 24 Finding the Loose Coupler One system, Intersection is everything Two systems, much less is common Three systems, Intersection gets smaller More systems, intersection keeps shrinking Green & Purple can form a sub-schema Other Systems can have sub-schemas

25 25 Stakeholder ValidationDevelop Draft Products IEV Development Process IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders 1 Month 2 Months 1 Month To view details for each step Click Here Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

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

30 30 Backup Charts

31 31 History of the Universal Core Standards Principles Initial Strike COI IEV Strike Pilot Decide to adopt as a starting point for Universal Core Form Working Groups: –Policy –Governance –Test & Eval –Description Goal: Increased info sharing Senior Enterprise Services Governance Group (SESGG) Implementations to solve operational needs SESGG Forms Intelligence Community DoD TODAYFUTURE Strike COI Business Transformation 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 32 Stakeholder ValidationDevelop Draft Products Step 1: Determine Scope IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

33 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 34 Stakeholder ValidationDevelop Draft Products Step 2: Develop Draft IEV Products IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

35 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 36 IEV Development Process: What does a COI IEV typically look like? UML Class Diagrams Logical Data Model COI XML SchemaCOI 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 37 Sample Automatic Generation Process Develop UML Use-Case Auto Generate XSD - XML IEV HandbookDetermine Pilot Demonstration Class Relationship Diagram

38 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 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 “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 40 Common Artifacts: Conceptual Data Model Diagram(s) that depicts the classes and the relationships between those classes without including attributes of each class

41 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

42 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 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 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 Heading is measured with respect to true north. Measured in degrees (0 <= heading < 360 )

45 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 - 0.1 2001-12-17T09:30:47.0Z 2001-12-17T09:30:49.0Z - Nationwide AIS (NAIS) - 2001-12-17T09:30:47.0Z - 26.158 80.1835 - 270 4.0 - 182 - 0.0 https://www.notional-amrs.mil/MMSI/304244000 304244000 Message Classification Markings / Dissemination Controls Collector Conveyance Vessel Time, Location, Vector, Heading, & Rate of Turn

46 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 Discovery 2.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 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 Set Primary Category ObligationPage The Security elements enable the description of security classification and related fields SecurityMandatory27 Resource elements enable the description of maintenance and administration information TitleMandatory29 IdentifierMandatory31 CreatorMandatory32 PublisherOptional35 ContributorOptional38 DateOptional48 RightsOptional50 LanguageOptional52 TypeOptional53 SourceOptional54 The Summary Content elements enable the description of concepts and topics SubjectMandatory56 Geospatial Coverage Mandatory unless not Applicable 59 Temporal Coverage Mandatory unless not Applicable 68 Virtual CoverageOptional72 DescriptionOptional74 The Format elements enable the description of physical attributes of the asset FormatOptional76

48 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 49 Stakeholder ValidationDevelop Draft Products Step 3: Conduct DMWG Workshop IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

50 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 51 Stakeholder ValidationDevelop Draft Products Step 4: Stakeholder Validation IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

52 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 53 Stakeholder ValidationDevelop Draft Products Steps 5 & 6: Obtain Steering Committee and Executive Board Approval IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

54 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 55 Stakeholder ValidationDevelop Draft Products Step 7: Register IEV Artifacts IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Acronyms: DMWG := Data Management Working Group IEV := Information Exchange IEV SME := Subject Matter Expert

56 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 57 Stakeholder ValidationDevelop Draft Products IEV Approval & Registration Update Products Validate Products with Stakeholders Update Products Obtain COI Steering Committee Approval Update Official IEV Baseline Register IEV Develop Draft IEV Products Conduct DMWG Workshop yes no Are stakeholders’ requirements met? Products ready for approval? COI Steering Committee Obtain COI Executive Board Approval COI Executive Board Next spiral? yes No no Determine Scope Conduct DMWG Workshop Determine IEV Format Research Related IEV Efforts Identify SMEs & Data Modelers Develop Use Cases Identify Stakeholders Step 8: Decision to Support Additional Spirals Acronyms: DMWG := Data Management Working Group IEV := Information Exchange Vocabulary SME := Subject Matter Expert

58 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 59 Sample IEV Tools UML –SPARX Enterprise Architect  http://www.sparxsystems.com.au/ 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 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 http://www.sybase.com/products/modelingmetadata/powerdesigner XML –Altova XML Spy  http://www.altova.com/ http://www.altova.com/ –oXygen  http://www.oxygenxml.com/ http://www.oxygenxml.com/


Download ppt "Connecting People With Information COI Information Exchange Vocabulary (IEV) Development For further information OSD at: DoD."

Similar presentations


Ads by Google