Universal Data Element Framework UDEF Overview GEIA DHS

Universal Data Element Framework (UDEF) Overview GEIA – DHS Workshop Phoenix – April 11 -14, 2005 Ron Schuldt April 13, 2005

UDEF Background CALS ISG - Developed UDEF EIA - Applied UDEF in the late 80 s – early 90 s Industry Ron Schuldt (Chair) - Lockheed Martin Barbara Barman (Vice Chair) - Raytheon Rob Bryant - Dyn. Corp Ruey Chen - David Taylor Research Center Bob Hodges - Texas Instruments Neal Mc. Namara - Analysis & Technology Inc. Bud Orlando - TRW Madelyn van der Bokke - ASEC George Walther - Lockheed Martin in the mid 90 s and 2002 Industry Ron Schuldt (Chair) - Lockheed Martin Rick Lang - Texas Instruments Pam Stanfield - Lockheed Martin Gary O’Hara - Hughes Space and Comm Tony Di. Perna - Ericsson Communications Ken Mc. Tee - Texas Instruments Cindy Hauer - Mevatec Corp Fred Bahrs - CMstat Corporation Doug Drury - ITT Federal Services Lee Le. Clair - Texas Instruments Government Norma Kornwebel - PM JCALS Dinah Beres - NAWC Steve Waterbury - NASA Government Deborah Cornelius - US Army Missile Cmd C. H. Van. Landingham - NOAA Nat’l Wea Svc Today AFEI (formerly CALS ISG) holds the Intellectual Property Rights to the UDEF

UDEF Recent Background UDEF Global Host Request For Information (RFI) by AIA and AFEI – Oct 2003 • Sought candidate global non-profits interested in hosting the UDEF tree structures • Responsible for managing extensions to the trees and for conducting global UDEF training and promoting adoption of UDEF • RFI response submitted jointly by Comp. TIA, OAGi and Contivo – later backed away for variety of reasons but all three are still interested • Draft Agreement and Performance Specification developed Once Global Host is Selected (Agreement Signed) • Pilot will be conducted to demonstrate that UDEF helps reduce costs of developing interfaces • Once pilot is completed successfully and the Performance Spec requirements are satisfied, then the non-profit will be given approval to formally launch the UDEF Global Host

Problem – Global Perspective Each organization is attempting to set its own semantics standard Each must interface with organizations they do not control Elec Banks Chem Aero Do. D NASA Trans Organization DHS Other Ship Retail The problem is the lack of common semantics and schema between organizations

Problem – Supply Chain Perspective • Today’s reality… point-to-point solutions introduce excessive cost, complexity and time • Examples of gaps and/or inefficiencies: - Increasing number of unique portals adding cost to suppliers - Multiple, redundant, incompatible “portal systems” - Incompatibilities in information exchange contribute to delay, rework, and error • Excessive cost, complexity and time impeding supply chain agility Supply Chain Perspective Cost of a single interface ranges from $10 K to $1 M depending on scope and complexity ~ N (N-1) mapping problem & expense Industry Members Business Partners Contractor Government Customer Public Exchange OEM Tier-1 Supplier excessive cost, complexit y and time Commercial Customer n-Tier Supplier Logistics Provider

Problem – Internal Perspective Conflicting semantic overlaps between back-office systems OAGIS XBRL HR-XML Other XML Standards Legacy Data Though semantically equal, the following are 4 different XML tag names <PARTNUMBER>111 -222 -333</PARTNUMBER> <part. Number>111 -222 -333</part. Number> <Part. Number>111 -222 -333</Part. Number> <partnumber>111 -222 -333</partnumber>

The Impact on Integration To interface two or more applications either within the enterprise or between enterprises --- • Middleware vendors build and sell “adaptors” for interfaces between major commercial applications (i. e. , SAP - People. Soft) - As the version of a given application changes it typically drives the need for changes to the adaptors • Application interface developers (data architects) spend considerable time and effort analyzing the semantics of data that need to be exchanged between systems - Semantics analysis requires up to 35 -40% of the requirements and design-time phase labor cost of building a given interface - To minimize the semantics analysis effort typically requires support (availability) from the “experts” of each application since most applications are poorly documented

The Goal Reduce Requirements and Design-Time Phase Semantics Analysis Time and Cost Current Point-to-Point Approach --- n(n-1) Global Semantics Standard Approach --- 2 n Global Semantics Standard 400 350 $$ 300 250 200 Savings 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Derived XML Schema Requirements XML Schema “Structure” Requirements • All new XML Schema used or built by an organization must conform to W 3 C XML and XML Schema specifications » http: //w 3. org/TR/2004/REC-xml 11 -20040204/ » http: //w 3. org/XML/Schema#dev • Adopt global naming convention standard – ISO/IEC 11179 -5 » http: //isotc. iso. ch/livelink/fetch/2000/2489/Ittf_Home/Publicly. Available. Standards. htm • Adopt United Nations XML schema naming and design rules » http: //www. disa. org/cefact-groups/atg/downloads/index. cfm XML Schema “Payload” Requirements • Adopt global set of basic data representation terms and their definitions – e. g. , Amount, Date, Name, Quantity » Tables 8 -1 and 8 -3 in United Nations Core Components Technical Specification (CCTS) – ISO 15000 -5 • Adopt global and industry XML schema “payload” standards whenever possible before building organization unique XML schema – see example list on next slide

Example “Payload” Standards • OAGIS – Open Applications Group http: //www. openapplications. org/ » Participants - ERP and middleware vendors and end users » Example payloads – RFQ, purchase order, invoice, bill of material • HL 7 - Health Care http: //www. hl 7. org/ » Participants – health care providers across the globe » Example payload – health records • ACORD – XML for the Insurance Industry http: //www. acord. org/ » Participants – insurance providers across the globe » Example payload – insurance claim • XBRL – Business Reporting - Accounting http: //www. xbrl. org/ » Participants – accounting firms across the globe » Example payload – financial reports to SEC • EIA-836 – Configuration Management Data Exchange and Interoperability http: //63. 249. 145. 5/836/default. htm » Participants – Do. D and aerospace and defense industry (AIA and GEIA) » Example payload – engineering change

Derived XML Schema Requirements XML Schema “Infrastructure Support” Requirements • Organization adopted and internally developed XML schema must be easily discovered for reuse – requires a centralized registry/repository • Use Universal Data Element Framework (UDEF) as means to index the points of intersection between various XML schema “payloads” and XML instances AND to improve data interoperability. UDEF directly supports and enhances an organization’s metadata management strategy.

XML Schema “Standards” Architecture XML Schema “Infrastructure Support” Standards Cross Standard Semantics and Metadata Alignment – UDEF*, RDF, OWL XML Schema “Payload” Standards Organization Specific Implementation Conventions (subsets & extensions) OAGIS ACORD XBRL HL 7 EIA-836* PLCS …. Others XML Schema “Structure” Standards ISO/IEC 11179 -5, eb. XML CCTS, UN Naming and Design Rules W 3 C – XML, XML Schema * Not quite ready for full adoption

UDEF – Similar to Dewey Decimal System The Dewey Decimal Classification or DDC was invented in 1876 by a young American librarian, Melvil Dewey. 1. Divided human knowledge into ten major Classes 2. Subdivided these classes into ten Divisions 3. Division subdivided into ten Sections. 4. These sections subdivided, etc How to classify a book on Radio Short Waves 10 Main Classes 000 Generalities 100 Philosophy 200 Religion 300 Social Sciences 400 Languages 500 Science 600 Applied science 700 Arts 800 Literature 900 History 500 Natural sciences 510 Mathematics 520 Astronomy 530 Physics 540 Chemistry 550 Earth sciences 560 Paleontology 570 Life sciences 580 Botany 590 Zoology 530 Physics 531 Solid mechanics 532 Fluid mechanics 533 Gas mechanics 534 Sound 535 Light 536 Heat 537 Electricity 538 Magnetism 539 Modern physics 537. 5342 537. 5343 Electronics Radio waves Long waves Short waves

UDEF – Scope Transactions – Structured Data • Purchase Orders • Purchase Order Changes • Purchase Order Acknowledgements • Purchase Order Change Acknowledgements • Invoices • Remittance Advice • Request for Quote Response • Shipping Schedule • Etc. Heavily influenced by finance and procurement functions and ERP type applications Relevant open standards – X 12, EDIFACT, eb. XML, OAGIS, Rosetta. Net Collaboration – Unstructured Data • Mission Requirements • Concept of Operations • Specifications • Product Designs • Engineering Change Proposals • Trade-off Studies • Test Reports • Meeting Minutes • Plans • Schedules • Presentations • Etc. Heavily influenced by engineering, manufacturing and program management functions and PDM/Document Management type applications Relevant open standards – STEP, PLCS, EIA-836 UDEF transcends the transaction and collaboration worlds

UDEF Built on Standards An Instantiation of ISO 11179 -5 Naming Convention and Supports eb. XML UDEF Object Class List • Entity • Document • Enterprise • Place • Program • Product • Process • Person • Asset • Law-Rule • Environment • Condition • Liability • Animal • Plant • Mineral ISO 11179 -5 Naming Convention Data Element Name Object Class Term 0. . . n qualifiers + 1 or more required Object Class + Property Term 0. . n qualifiers + 1 required Property Example UDEF-Based Data Element Names Document Abstract Text Enterprise Name Product Price Amount Product Scheduled Delivery Date Engineering Design Process Cost Amount eb. XML Property List • Amount • Code • Date Time • Graphic • Identifier • Indicator • Measure • Name • Percent • Picture • Quantity • Rate • Text • Time • Value • Sound • Video UDEF names follow the rules of English – qualifiers precede the word they modify

ISO/IEC 11179 – Data Element Concept Object Class Property Representation Data Element Concept UDEF Maps Data Element Concepts Data Element Core Data Element Value Domain Application Data Element

Creating UDEF IDs UDEF Trees 16 Object Class Trees 0 Entity 1 Asset 2 Document 18 Property Trees … t Order a Work b c Change Technical 1 Amount 1 Region d Purchase 4 … Code … 33 Type … … 66 Defined … Purchase Order Document_Type Code has UDEF ID = d. t. 2_33. 4 See http: //www. udef. org/

Example Mappings Organizations cannot avoid multiple data standards ** Need global semantics standard ** PDM Sys A PDM Sys B Part No Part Num OAGIS 7. 1 Rosetta. Net Item. X Proprietary. Product. Identifier 9_9. 35. 8 X 12 (EDI) EDIFACT Product/Service ID Item Number STEP AP 203 x. CBL Product ID Part. ID UDEF Universal Identifier Product(9)_Manufacturer(9). Assigned (35). Identifier(8) N (N-1) mapping effort instead becomes a 2 N mapping effort

Mapping Concepts to UDEF 1. Identify the applicable UDEF property word that characterizes the dominant attribute (property) of the data element concept. For example, Name, Identifier, Date, etc. 2. Identify the dominant UDEF object word that the dominant property (selected in step 1) is describing. For example, Person_Name, Product_Identifier, Document_Date, etc. 3. By reviewing the UDEF tree for the selected property identified in step 1, identify applicable qualifiers that are necessary to unambiguously describe the property word term. For example, Last Name 4. By reviewing the UDEF tree for the selected object identified in step 2, identify applicable qualifiers that are necessary to unambiguously describe the object word term. For example, Customer Person 5. Concatenate the object term and the property term to create a UDEF naming convention compliant name where it is recognized that the name may seem artificially long. For example, Customer Person_Last Name 6. Derive a structured ID based on the UDEF taxonomy that carries the UDEF inherited indexing scheme. For example <Customer. Person. Last. Name GUID=“as. 5_5. 10”>

DHS Typical Example Data Element Concept Name United States Passport Number UDEF ID 1. Object Type or Role Object Class Property Type Property Identify the applicable UDEF property word that characterizes the dominant attribute (property) of the data element concept. For example, Name, Identifier, Date, etc.

DHS Typical Example Data Element Concept Name United States Passport Number UDEF ID Object Type or Role Object Class Property Type Property Identifier 2. Identify the dominant UDEF object word that the dominant property (selected in step 1) is describing. For example, Person_Name, Product_Identifier, Document_Date, etc.

DHS Typical Example Data Element Concept Name United States Passport Number UDEF ID Object Type or Role Object Class Document 3. Property Type Property Identifier By reviewing the UDEF tree for the selected property identified in step 1, identify applicable qualifiers that are necessary to unambiguously describe the property word term. For example, Last Name

DHS Typical Example Data Element Concept Name United States Passport Number UDEF ID Object Type or Role Object Class Document 4. Property Type State Department Government Assigned Property Identifier By reviewing the UDEF tree for the selected object identified in step 2, identify applicable qualifiers that are necessary to unambiguously describe the object word term. For example, Customer Person

DHS Typical Example Data Element Concept Name United States Passport Number UDEF ID Object Type or Role United States Passport 5. Object Class Document Property Type State Department Government Assigned Property Identifier Concatenate the object term and the property term to create a UDEF naming convention compliant name where it is recognized that the name may seem artificially long. For example, Customer Person_Last Name

DHS Typical Example Data Element Concept Name United States Passport Number UDEF ID a. ck. 2_2. 13. 35. 8 6. Object Type or Role United States Passport Object Class Document Property Type State Department Government Assigned Property Identifier Derive a structured ID based on the UDEF taxonomy that carries the UDEF inherited indexing scheme. For example <Customer. Person. Last. Name GUID=“as. 5_5. 10”>

UDEF Use with XML • UDEF derived intelligent ID is the “key” to systems integration • Mapping to UDEF is a rules-based approach to determine semantic equivalence Two different systems with need to exchange purchase order data System A (x. CBL 3. x Format) UDEF Name Purchase Order Document_Identifier UDEF ID = d. t. 2_8 System B (OAGIS 7. x Format) • Optional UDEF IDs applied only when aligning ANY two systems for the first time (design time) – stored as an alias within each system - Non-intrusive – does not require change to data element names • Leverage the UDEF Web Service to generate a gap analysis report http: //xml. eidx. org: 8080/udef/servlet/Udef. Report 1

Possible DHS-Do. J UDEF Example UDEF-Based Common Vocabulary Person Identifier 5_8 Person Last Name 5_5. 10 Person First Name 5_4. 10 Person Birth Date 5_51. 6 Person Birth City Name 5_2. 10 Local Police – Suspect Role Local Police – Criminal Role Suspect Id aw. 5_3. 13. 35. 8 Criminal Id av. 5_3. 13. 35. 8 Suspect Name aw. 5_5. 10 & aw. 5_4. 10 Criminal Name av. 5_5. 10 & av. 5_4. 10 Suspect Date of Birth aw. 5_51. 6 Criminal Date of Birth av. 5_51. 6 Suspect City of Birth aw. 5_2. 10 Criminal City of Birth av. 5_2. 10

A Metadata Managed Architecture Interfaces to Back-Office Systems Run Time EAI Vendors with Canonical Models UDEF-Indexed Metadata Registries Transformation Engines Internet Std Schema Global UDEF Registry Use Matrices Design Time Interface Developers • Data Dictionary Extend Matrices • Mapping Matrices • Std XML Schema Build/Extend Schema UDEF-Indexed Data Modelers Metadata Registry/Repository And Apps Developers Centralized metadata registry/repository • Enables reuse to reduce costs • Encourages standardization Software Vendors with UDEF ID APIs UDEF Change Board Web Public

Sample Scenarios and Benefits Sample Scenarios Sample Benefits Application developer uses metadata repository and UDEF IDs to discover a data model containing 60% of the data for the new application Data model reuse – time and cost reduction Helps enable a corporate-wide common vocabulary Interface developer uses metadata Interface reuse – time and cost reduction repository and UDEF IDs to discover 35% of fields already mapped between two applications CEO wants to know state-by-state breakdown how many dollars in last fiscal year went to suppliers for a single program Provide answer in 4 hours rather than 5 days Interface developer uses automated tools that have been UDEF enabled to help build Java code that directly feeds the run-time EAI translation tool Reduce time and cost to automatically develop Java code from 4 hours to 1 hour A new supplier uses Rosetta. Net rather than the industry standard x. CBL. The semantic mapping based on UDEF is provided to the supplier Reduce the supplier’s time and cost to complete the mapping.

Do. D End-to-End Procurement Mapping • AIA effort by Raytheon, Lockheed Martin and Northrop Grumman based on actual Do. D procurement of a Raytheon spare part • Mapped all fields in five documents plus Central Contractor Registration to both the UDEF and to OAGIS 8. 0 XML standard – RFQ, Response to RFQ, Purchase Order, DD 250, Invoice • DD 250 includes the 16 fields required to support UID

UDEF Example Mappings Examples From Do. D Purchase Order Mapped to UDEF and OAGIS 8. 0 UDEF Name UDEF ID Sys. Name DPASPriority OAGIS XML Path Name Purchase Order Document Government Assigned Priority Code Purchase. Order/Header/Priority d. t. 2_1. 4. 31. 4 Date. Of. Order Purchase Order Document Date Purchase. Order/Header/Document. Date. Time d. t. 2_6 Issued. By. DODAAC Buyer Enterprise Defense Logistics Agency Assigned Identifier q. 3_6. 35. 8 Purchase. Order/Header/Parties/ Sold. To. Party/Party. ID/ID • UDEF names are unambiguous • UDEF names cross-referenced and indexed by UDEF IDs to a table would allow interfaces to be built without being dependent on availability of the “system expert”

Summary – Key Points • Adopt Key Global XML Schema Standards – especially … - ISO/IEC 11179 -5 “Naming and Identification Principles for Data Elements” - ISO 15000 -5 Core Components Technical Specification (especially Tables 8 -1 and 8 -3) • Work together to promote and adopt the UDEF – an Instantiation of ISO/IEC 11179 -5 and ISO 15000 -5 CCTS Table 8 -1 and 8 -3

For Additional Information ISO/IEC 11179 – Specification and standardization of data elements http: //isotc. iso. ch/livelink/fetch/2000/2489/Ittf_Home/Publicly. Available. Standards. ht m UDEF. ORG Web Site http: //www. udef. org/ Ron Schuldt – 303 -977 -1414 or ron. l. schuldt@lmco. com