Proposal for a Revised Technical Framework for UN/CEFACT

1. Proposal for aRevised Technical Framework for UN/CEFACT

2. Requirements Revised Technical Framework Proposal

3. The current market • Surveys, analysis and experience suggests: • Many established communities not using UN/CEFACT standards consistently • Situation is too fragmented to change • Then and now… • UN/EDIFACT = single SDO (UN/CEFACT) • XML = many SDOs (W3C, OASIS, ISO, IEC, GS1) • UN/CEFACT is not the sole arbiter of XML standards for eBusiness • No ‘one’ canonical standard will work

4. What Standard(s) Can We Achieve? • One Standard to Rule them All • Centralized • Global agreement • Is my invoice everyone’s invoice? Or • Islands of standardization • Foundational semantics • Satisfying different communities of use • Using specific EDI or XML formats • Transform between different formats • Needs coordination

5. The Options Before Us • Fragmented Standards • Who wins? • Coordinated Standards • Common semantics • Federated approach • One Standard • Who decides? • What do they decide? • When do they decide?

6. The opportunity for UN/CEFACT • Someone needs to facilitate the interoperability between these communities. • UN/CEFACT can have that role • Standardize what can be agreed, to improve interoperability • ‘core’ processes, structures, components and data types (including code lists). • Allow communities to re-use these in their environments.

7. The role for UN/CEFACT • A forum for coordinating a framework for interoperability for trade facilitation and eBusiness • Ensure everything is done, but … • Not to do everything • Facilitators not owners • Support disparate community implementations • Build bridges not walls How do we do this?

8. Restructure what we have • Agree on what the ‘end game’ should be: • What an effective framework for UN/CEFACT deliverables would look like. • Plan how to reach the ‘end game’ • Who does what • Stop doing things that don’t fit this plan • Manage the completion of these projects • Get the right resources • Manage expectations • Communicate value

9. Interoperability Revised Technical Framework Proposal

10. summary • (proposed) Revised Technical Framework: • Standardize on semantics not syntax or formats • UN/CEFACT ‘core’ semantics establish foundation for interoperability • Communities of use create their own implementations • Process, components, structures, documents and syntax • Statement of conformance • Registry of conformant specifications published by UN/CEFACT • UN/CEFACT is a facilitator of interoperability between communities • Impact on programme of work: • UN/CEFACT projects will develop… • Profiles for business processes • Business requirements, rules and semantics • Published as Deliverables for Information • Recommendation for use of standards • Communities of use develop … • Implementation profiles • business requirements, rules and semantics and syntax

11. Framework for Interoperability • For us its all about information exchange • The ability of two or more systems or components to exchange information and to use the information that has been exchanged • Requires mutual agreement on several levels

12. Interoperabilitylevels Political Context Legal Interoperability Legislative Alignment Organizational Interoperability Organization/Process Alignment Semantic Interoperability Semantic Alignment Technical Interoperability Interaction & Transport

13. Facilitating Interoperability in Trade Requirements for Trade Facilitation Requirements for Interoperability Political Context Trade Agreements International Laws Legal Interoperability WTO/UN recommendations Legislative Alignment Organizational Interoperability Trade Facilitation Recommendations Organization/Process Alignment agreed business processes Semantic Interoperability agreed components Semantic Alignment agreed documents Technical Interoperability agreed syntax Interaction & Transport agreed messaging protocol

14. The role for UN/CEFACT Requirements for Trade Facilitation Requirements for Interoperability Political Context Trade Agreements International Laws Legal Interoperability WTO/UN recommendations Legislative Alignment Organizational Interoperability Trade Facilitation Recommendations UNECE Recommendations Generic reference models for business processes Organization/Process Alignment ‘core’ business processes Generic semantic data models Semantic Interoperability ‘core’ components Generic semantic data structure models Semantic Alignment ‘core’ structures Technical Interoperability EDIFACT and XML expressions Of the models EDIFACT and XML Interaction & Transport messaging protocols

15. UN/CEFACT Publications Interoperability Framework Requirements for Trade Facilitation • [ODP] UN/CEFACT deliverables for information • Deliverables that support how one or more Business Standards and/or Recommendations shall be implemented Political Context Trade Agreements International Laws Legal Interoperability WTO/UN recommendations Legislative Alignment Organizational Interoperability Trade Facilitation Recommendations Organization/Process Alignment ‘core’ business processes Semantic Interoperability ‘core’ components Semantic Alignment ‘core’ structures EDIFACT and XML expressions Technical Interoperability Interaction & Transport messaging protocols

16. Defining the ‘core’ 1. Union of all usages (A,B,C,D,E,F,G) • Everything everyone wants: • complex to understand • complex to maintain (harmonize) • enables compliance of legacy/current solutions • compliance does not ensure interoperability G community community E F A B C D community 2. Designed set (A,C,F,Z) • What we think everyone needs: • creates yet another standard • challenges compliance of legacy/current solutions • compliance ensures interoperability commuity A F C Z

17. Defining the ‘core’ 3. Intersection of all usages (F) • What everyone uses: • simple to understand • easier to maintain • encourages compliance of legacy/current solutions • compliance ensures (limited) interoperability F can evolve towards 4. Intersection of common usage (B,C,F,G) • What many use: • still simple to understand • harder to maintain (harmonize) • enables compliance to subsets by legacy/current solutions • compliance does not ensure interoperability G C F B

18. The Core Interoperable Foundation Library Requirements for Trade Facilitation Core Interoperable Foundation Library Trade Agreements Published in International Laws WTO/UN recommendations Trade Facilitation Recommendations ‘core’ business processes Based on standard repository schema ‘core’ components ‘core’ structures syntax expressions of models messaging protocols XML EDIFACT

19. communities of use… • Trading environments around specific: • business domains, • industry groups, • governments, • regions, • technologies or • commercial service models • Communities contain smaller communities • No organization exists in only one community • members overlap • communities form webs not hierarchies • They are identified by context • requirements defined by business rules • May support disparate implementations by members

20. communities specify their ownimplementation guides • Business processes • Establish context of use • Document requirements • Invoice, Freight Invoice, Utility Invoice, Bill, etc, etc. • Process determines function NOT name of document • Business rules (incl. code lists) • “In cases when invoices are issued in other currencies than the national currency of the seller, the seller may be required to provide information about the VAT total amount in his national currency.” • Syntax • EDIFACT, X12, ASN.1, XML • Formats • XML vocabularies (UBL, GS1, OAGi, XBRL, ISO20022)

21. creating a ‘core’ semantic referencefor eBusiness ‘core’ ‘community of use’ business processes Used in components and code lists Used in structures Used in syntax expressions Used in

22. Communities define ‘common’ Insurance community G Insurance community ‘common’ to the insurance community (B,F,G) F A B Insurance community CBRA community G Customs community E F ‘common’ to the CBRA community (F,G,C) C Single window community Procurement community Procurement community F B C ‘common’ to the procurement community (B,F,C) D Procurement community

23. communities may have different implementations Governance Communities Implementations UN/CEFACT Conformance to core semantics Conformance to community semantics Agriculture Domain Cross Border Agriculture domain Core Interoperable Foundation Library

24. assurances of conformity • Communities issue statements of self conformance • no certification • It is assumed that the industry will police itself and that most communities will determine that it is in their own best interests to make truthful and accurate claims. • Sample: • “This specification is in conformity to the UN/CEFACT Core Interoperable Foundation Library in that it uses the following generic components… • All new components introduced in this specification are defined in reference to these generic components and are consistent with them.”     

25. registry of community specifications European Commission Joinup Registry IMS Global Learning Consortium IVI Consortium Community Specifications

26. ISO 20022 Registry

27. Towards Sustainable Collaboration Contributing to Global Trade

28. International Supply Chain Reference Model

29. Services supporting Global Supply Chain Communities ARIBA GS/1 PROCUREMENT INTTRA GTNexus LOGISTICS SUPPLIER BUYER Korean Single Window Malaysian Single Window REGULATORY HSBC STANDARD CHARTERED FINANCIAL Information sharing based on foundation of UN/CEFACT semantics