AIA e. Business and the Metadata Harmonization Project Ron Schuldt Lockheed Martin Enterprise Information Systems Co-Chair, AIA Electronic Enterprise Working Group GEIA Workshop September, 2002
Agenda • Identify the drivers that caused Aerospace Industries Association (AIA) Executive Committee members (CEOs) to put a priority on solving e-business interoperability issues • Describe the strategy they took • Describe an AIA-led project that is expected to yield cost reduction opportunities for companies that take advantage of the project’s recommendations Page 2
e. Business In AIA Charge from the AIA Executive Committee At its 14 March 2001 meeting, the AIA Executive Committee agreed to establish a corporate-level steering group to coordinate the various ebusiness activities currently underway at AIA and to establish clear policy defining what common ebusiness practices are and how they are to be implemented AIA Executive Action Report 6 -2001 DTD 23 March 2001 Page 3
e. BSG Membership Dual representation from each member company encouraged Business Focus (Functional VP) Technical Focus (CIO) AIA Member companies with e. BSG representatives • • AAI BAE Systems Boeing Exostar Goodrich General Dynamics Honeywell Lockheed Martin • • • MOOG Northrop Grumman Parker Aerospace Raytheon Rolls Royce Textron TRW United Technologies Vought Aircraft Page 4
Relationship to AIA Organization e. BIC Workgroups Board of Governors (Bo. G) Bo. G Executive Committee AIA President and CEO e. Business Steering Group “Focal Point” No e-Bus. activity L Committees & WG’s L L Committees & WG’s Councils Committees & WG’s Division No e. Bus. activity Division Committees & WG’s WG e. BIC Liaisons Committees & WG’s L Association Members Co-Chaired by Ron Schuldt L e. Business Integration Committee (e. BIC) WG WG WG Chaired by Tom Shelman, Northrop Grumman WG WG Chaired by Bill Bryant, Lockheed Martin Page 5
EB Interoperability Framework Industry-level interoperability enabled by common framework that defines scope and elements of the “Information Backbone” Business Applications (AIA Member Unique – Out of Scope for e-BSG) “Information Backbone” Business Process AIA Member Company Outreach & Policy Component Elements Registry & Repository Security Business Partner Trading Partner Profile Transport & Package Technical Environment (AIA Member Unique – Out of Scope for e-BSG) Modeled after eb. XML Architecture AIA ebusiness workgroups aligned with the Framework Page 6
AIA EEWG Summary AIA Electronic Enterprise Working Group (EEWG) Scope: The scope of the EEWG effort is transaction data and metadata about technical data that goes through the firewall in support of e-business. EEWG Leadership: Ron Schuldt, Lockheed Martin EIS, Co-Chair for 2 year term representing AIA Member companies (71 companies as of June 12, 2002). Term expires Dec 31, 2003 Angela Baker, LMI Aerospace, Co-Chair for 2 year term representing AIA Associate Member companies (134 companies as of June 12, 2002). Filling remainder of partial term – full 2 year term expires Dec 31, 2004 Bill Lewandowski, Vice President, Supplier Management, AIA Staff Major Projects: Harmonization of EDI (X 12) transactions used within aerospace – led by Tom Warner, Boeing Aerospace XML – conversion of the harmonized EDI transactions to XML – led by Tom Warner, Boeing Metadata Harmonization – assigned by e-BSG – led by Ron Schuldt, Lockheed Martin 7 Page
The Integration Problem & Goal Current Point-to-Point Approach --- n(n-1) Future UDEF Canonical Approach --- 2 n Global Canonical Standard 400 350 300 $$ 250 200 150 Savings 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Page 8
The Interoperability Challenge “According to Gartner Group, 35 -40% of all programming effort in a typical computing environment is devoted to developing and maintaining the extract and update programs whose only purpose is to transfer information between different databases. ” Quote from Ernst & Young Financial Analysis of “Enterprise Application Integration – Constellar and British Power Achieving Business Benefit” “Interoperability required the entire interfaces between applications to be standardized. Only 5% of the interface is a function of the middleware choice. The remaining 95% is a function of application semantics. ” Gartner Group Application Integration “Semantics” Messaging and Transport Services 95% 5% Page 9
An Integration Cost Illustration Total Services Spend Software: $1 million If integration software costs $1 million, implementation will cost $3 -5 million. (Gartner) Implementation: $3 -5 million Data integration: $2 -3. 3 million Data transformation: $1 -1. 7 million Two-thirds of the implementation cost involves data integration. Data transformation is one-third of the implementation cost. (AMR Research) Page 10
The Standards Problem Summarized Conflicting Overlaps EIA-836 Config Mgmt STEP (CAD) X 12/EDIFACT (EDI) 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> As result, many industries including aerospace are defining their metadata Page (tag name) XML standards necessary for e-business – too many standards 11
Small Sample of the “Other XML Standards” • • • HL 7 - Health Care http: //www. hl 7. org/ IFX - Interactive Financial Exchange http: //www. ifxforum. org/ FPML – Financial Products http: //www. fpml. org/ SWIFT – Business Messages based on EDIFACT (for International Trading Partners) http: //www. swift. com/index. cfm HR-XML – Human Resources and Benefits http: //www. hr-xml. org/channels/home. htm OAG – ERP and Middleware Vendors http: //www. openapplications. org/ Rosetta. Net – IT and Electronic Components Industry http: //www. rosettanet. org/rosettanet/Rooms/Display. Pages/Layout. Initial ACORD – XML for the Insurance Industry http: //www. acord. org/ XBRL – Business Reporting - Accounting http: //www. xbrl. org/ Tran. XML – Transportation XML http: //www. transentric. com/default 2. asp Page 12
Example Overlaps UDDI AIA Transactions - Universal Unique ID (UUID) - Globally unique - Supports many ID codes - 128 bit hexadecimal (8 char AN) UDDI EIA-836 - Organization ID - Supports many ID codes EIA 836 Collaboration » CAGE, DUNS, FSCM, etc. - ID length not specified AIA EDI - Originating Company ID Number - Supports many ID codes » CAGE, DUNS, FSCM, etc. - ID length (10 char AN) STEP Collaboration Example Overlaps • Supplier ID • Address • Part Number Page 13
Stds such as X 12 and EIA-836 Project Scope Metadata Harmonization Project Scope Harmonized Data Elements from X 12, EIA 836, STEP, UCC, etc. – “Components” Part Identification Address Standard Reusable Segments – “Subassemblies” Engineering Change Proposal Purchase Order Invoice Standard DTDs and Schema – “Assemblies” HTML PDF Other Vendor-unique web connections Create Islands of Unconnected Applications HTML PDF Other Standard Style Sheets for Browser Display Page 14
Metadata Harmonization Project Summary Description The Metadata Harmonization Project (MHP) is defining an Aerospace Process Standard that will enable companies in the industry to reduce the costs of integrating their systems with trading partners. The MHP is creating a data interchange matrix that was directed by the e-BSG. Business Problem Major Milestones • Standards used within AIA overlap • Difficult to understand what the standards contain without some form of comparison • Cost effective interoperability depends on adoption of standards • Substantial overhead dollars required to integrate heterogeneous systems • E-BSG assigned EEWG MHP – Aug 2001 • Phase 1 complete – Aug 2002 • E-BSG approval of Phase 2 – Sept 2002 • Support from Contivo for Phase 2 – Aug 2002 • Phase 2 EEWG complete – Nov 2003 Dependencies • AIA member company adoption of the MHP Process Standard • On going maintenance of matrix is dependent on the UDEF • Sufficient resources • Require effective marketing of the MHP products (i. e. , SMC Master Classes) Page 15
Metadata Harmonization Project Roadmap Transaction 2001 2002 2003 eb. XML Core Components Harmonized eb. XML Core Components Begin Logistics Trans AIA EDI IC -> AIA XML DTD AIA IC Harmonized EDI 4010 Trans Sets Aerospace XML DTDs for Harmonized EDI Trans Set (procurement) Industry Convergence To UBL? ? Integration UDEF Development UDEF V 1. 0 UDEF Updates (AIA-managed) Meta-Data Harmonization UDEF Transferred to Non-profit Collaboration Harmonized Meta-Data Phase 1. 0 Harmonized Meta-Data Phase 2. 0 836 Development 836 Ballot AP 203 AP 232 Part 28 -XML 836 XML Schema EIA-836 AP 233 PDM Not Confirmed ISO 10303 - STEP National/International Standard Increments AIA WG or Committee Adoption AIA e-BSG Adoption Page 16
Mapping Matrix Summary Sample Mapping Matrix Extract UDEF ID 3_6. 35. 8 ah. 3_10. 35. 8 UDEF Property Manufacturer UDEF Object UDEF Type of Property Enterprise UDEF Role or Type of Object Defense Logistics Assigned Identifier Enterprise NATO Assigned Identifier EIA-836 Name Definition EDI (X 12) Valid Values Name CAGE Code 5 A Commercial and Government alphanumeric Entity (CAGE). . . character DE 98 + DE 66/ Code M 4 NSCM Code A standard NATO supply code. . . D DE 98/ Code M 9 + DE 66/ Code 37 string Phase One Summary Phase Two Summary • Focus on four topics • Enterprise Identification • Document Identification • Product Identification • Asset Identification • Four standards – EIA-836, X 12, STEP, UCC • Goal – to understand the process and the necessary resources to proceed into second phase • Target completion – August 2002 • In planning stages • Include additional standards such as ATA Spec 2000 • Require support from tool • Require XMLization of the UDEF • Require UDEF transfer to non-profit • Require additional business process experts – especially contracting and inbound/outbound logistics • Target completion – November 2003 Page 17
The UDEF Summary Description The Universal Data Element Framework (UDEF) is a rules based metadata naming convention that greatly accelerates data integration for large data integration projects. Once a data element concept has been mapped to the UDEF, the data element can then be assigned a UDEF derived intelligent unique ID. Canonical Model Name Current Business Problem • • • Point-to-Point Interfaces are the Norm Mappings are Time Consuming Process Lack Consistent Naming Convention Lack Standard Data Names System Experts Often Retained to Support Interface Development Alias 1 Benefits of UDEF • • • Depending on complexity, the time and effort required to analyze and map any pair of systems reduces substantially (potentially by order of magnitude) as the number of systems to be integrated increases beyond three or four (break even point) UDEF IDs add computer sensible intelligence to the names of elements within any system – thereby reducing dependence on requiring the system expert for mapping the system to any other system UDEF is gaining momentum as an e-business standard – adopted by AIA, EIDX, and OAG – gaining interest by UCC, Comp. TIA, DISA, and Rosetta. Net Alias 2 Alias 3 . . . Alias n Universal ID = Map-to-UDEF Approach UDEF ID UDEF Name Page 18
The UDEF Naming Convention Complies with ISO 11179 Naming Convention and Supports eb. XML Data Element Object Class List Name Entity Document Enterprise Object Class Term Property Term Place Program 0. . . n qualifiers + 0. . n qualifiers + 1 or more reqd Product 1 reqd Property Object Class Process Person Asset Example Data Element Names Law-Rule Document Abstract Text Environment Enterprise Name Condition Product Price Amount Liability Product Scheduled Delivery Date Animal Engineering Design Process Cost Amount Plant Mineral + Property List Amount Code Date Time Graphic Identifier Indicator Measure Name Percent Picture Quantity Rate Text Time Value Names constructed follow the rules of English – modifiers precede the word they modify Page 19
Data Element Concept per ISO 11179 UDEF Maps Data Element Concept - definition “A concept that can be represented in the form of a data element, described independently of any particular representation” Page 20
UDEF Objects – For Context Entity Enterprise B Enterprise A Place Laws/Rules Program Product Environment Process Product Document Person Asset Resources Condition Page 21
Data Element Concepts of UDEF Any data of interest to the ENTERPRISE …. . E-Business Transactions • Request for Quote • Purchase Order • Advance Ship Notice • Invoice Technical Data • Tradeoff Studies • Specifications • Designs • ECPs • Software Logistics Data HR - Data • • Assignments Evaluations Salary Benefits • • Repair Transport FD/FI Inventory Process Data • • • Engineering Manufacturing Procurement Test Maintenance Operations Finance Data • General Ledger • Accts Payable • Accts Receive Program Data • Contracts • Schedules • Risk Scientific Data • Statics • Dynamics • Thermal Page 22
Example “Enterprise” Object Tree PERSON Configuration Management aq Assigned ar (5) Customer Visitor as at Patient au Project a Page 23
Example “Name” Property Tree NAME Country Type 1 Brand 2 (10) First Last 4 3 5 Classification Address Maiden 6 Medium 1 2 Postal 1 1 2 3 Fourth Fifth 4 5 7 8 Security 1 1 First Second Third Middle Classification Sixth 6 Storage 1 Page 24
How to Map to the 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 an intelligent UID based on the UDEF taxonomy that carries the UDEF inherited indexing scheme. For example <Customer. Person. Last. Name GUID=“as. 5_5. 10”> Page 25
Example Mappings CM Data Elements document-publication-date document-data-rights-expiration-date document-sheet-total-quantity document-sheet-size-code software-product-version-identifier product-part-identifier reference-document-revision-identifier enterprise-division-address-text program-name product-quantity enterprise-address-text Universal ID 2_5. 6 2_1. 2. 6. 6 2_1. 8. 11 2_1. 6. 4 p. 9_8. 8 9_5. 8 aj. 2_9. 8 3_2. 14 10_10 9_11 3_12. 14 Page 26
Additional Example Mappings X 12 & EDIFACT Data Elements country code invoice number- assigned by issuer purchase order type code postal code location qualifier location identifier contract effective date expiry date of import license item number - product item number - service price Universal ID e. 7_4 bd. 2_1. 35. 8 d. t. 2_33. 4 7_1. 10. 4 7_20. 33. 4 7_8. 4 e. 2_13. 6 a. be. 2_6. 6 9_8 f. 9_8 9_2. 1 Page 27
Goal - UDEF IDs Become Global Unique IDs (GUIDs) UDEF ID = eb. XML UID EIA-836 X 12 (EDI) 9_5. 8 Product Part Identifier Product/Service ID 9_9 Product Name Vendor A Product/Service Name y. 3_9 e. 2_8 f. g. 9_11 2_33. 4 Part No Entity (Supplier) Name Supplier Contract Document Identifier Component Product Quantity Buyer’s Contract Number Contract No Document Type Code Report Type Code Doc Type <Contract. Document. Identifier DOC: GUID=“e. 2_8”>123 abc</Contract. Document. Identifier> <Buyers. Contract. Number DOC: GUID=“e. 2_8”>123 abc</Buyers. Contract. Number> <Contract. No DOC: GUID=“e. 2_8”>123 abc</Contract. No> Benefit – GUIDs eliminate the baggage associated with changing names Page 28
Benefits of the UDEF • • Based on ISO 11179 and eb. XML standards Infinitely extensible UDEF IDs are language independent Built in indexing for all XML catalogs – Find entries more rapidly within large catalogs • Enable faster alignment between disparate legacy systems – even for close matches – Two hinge points (the object and the representation word) • • Reduce costs associated with interfacing systems within the business Provide foundation for standardized global XML namespace categories – – – – PER: GUID Person – all XML names with Person as the object PRD: GUID Product – all XML names with Product as the object ENP: GUID Enterprise – all XML names with Enterprise as the object PRC: GUID Process – all XML names with Process as the object PLC: GUID Place – all XML names with Place as the object PRG: GUID Program – all XML names with Program as the object etc Page 29
UDEF Concept of Operation Other Metadata Repositories Vendors with Canonical Models Interfaces to Legacy Systems Run Time Transformation Engines Internet Global UDEF Registry Interface Developers Design Time Data Modelers • Data Dictionary • Mapping Matrices • Std Data Models Content Administrators UDEF Based Metadata Registry/Repository Software Vendors With UDEF ID APIs UDEF Change Board Page 30
Global UDEF Registry REGISTRATION SERVICE Registered Name System A Contract DOCUMENT IDENTIFIER System B External Contract. Num Conceptual Contract. No Conceptual Contract_Number Registered Universal ID Physical e. 2_8 Physical Contract_No AIA, EIDX and AFEI will work with. org to establish this service Page 31
Questions ? ? ? Ron Schuldt – 303 -977 -1414 or ron. l. schuldt@lmco. com Page 32
Скачать презентацию AIA e Business and the Metadata Harmonization Project
6e4e2e81eb25ad8115f0670f121159ab.ppt