How Standards Address Interoperability Needs: An Industry View

1. How Standards Address Interoperability Needs: An Industry View Claus von RiegenDirector, Web Services Standards, SAP AG OASIS SymposiumMay 10 2006, San Francisco

2. Interoperability Imperative Role of Standards Challenges Towards Standardization Guidelines

3. Interoperability Imperative Role of Standards Challenges Towards Standardization Guidelines

4. Interoperability Imperative Digitalbroadcasting(audio/video) Technology industries have their individual interoperability requirements e.g. Mobile TV e.g.. IPTV, VoD, MP3 download Convergence of networks and services require interoperable solutions across domains InternetTechnology (Mobile)communi-cations e.g. VoIP

5. Interoperability Layers 1 • Technical Interoperability • Messages are exchanged securely and reliably from sending to receiving infrastructure • Receiving infrastructure is responsible for delivering the message payload to application • Semantic Interoperability • Application knows the business context to which the payload belongs • Payload is valid from an application perspective • Application successfully processes payload • Organizational Interoperability • Application notifies appropriate users that are responsible for verification and approval steps and tracks deadlines 2 3 2 Application Application Approve POs 3 Infrastructure Infrastructure 1 Verify invoices

6. Some Definitions1 • Interoperability • The ability of two or more networks, systems, devices, applications or components to exchange information between them and to use the information so exchanged. • Standard Interface • A technical description of certain generic requirements that a technical implementation of that interface must conform to – in order to produce the desired functionality. In the case of information interoperability, today’s generic requirements broadly speaking refer to two categories of information, namely (i) data formats and (ii) protocols. • Open Standard • Control: the evolution of the specification should be set in a transparent process open to all interested contributors; • Completeness: the technical requirements of the solution should be specified completely enough to guarantee full interoperability; • Compliance: there is a substantial standard-compliant offering promoted by proponents of the standard; • Cost: fair reasonable and non-discriminatory access is provided to intellectual property unavoidably used in implementation of the standard. 1Taken from the EICTA Interoperability Whitepaper

7. Interoperability Imperative Role of Standards Challenges Towards Standardization Guidelines

8. Technology Development Standards Development Ex-ante Ex-post Standardization vs. Technology Development Communication / Coordination De facto standards Proprietary standards De jure standards Proliferation of Standards Communities Competition Collaboration

9. Actors in Standardization Specifications Test cases IPR declarations Standards Body Technicalcontributions (may contain IPR) IPR declaration Implementation feedback Agree on common denominator Requirements Implementers Users Developers Product/Services Sales Conformance / Interoperability issues IP licensing Prototypes Products Conformance Claims

10. Phases in Standardization Need Initiator Core Group Standards Body Need Initiator Core Group Standards Body RequirementsIdentification Partnering Specification Development Initial Implement./ Testing Incremental Enhancemnt Final /Maint. DevelopmentPhase ImplementationPhase PreparationPhase Agreed / common design principles for reaching interoperability

11. Interoperability Imperative Role of Standards Challenges in Standardization Towards Standardization Guidelines

12. Challenges in Standardization Closed policies, processes, development groups Intellectual property encumbrances Challenges obtaining standards credentials Cooperation between communities – Lack of common design rules and content reuse CROSS-TOPICS Competition to create standards Large, complex, “all or nothing” standards Misuse of standards as a means to erect barriers to competition and trade Lack of rigor in standards development Lack of test specifications Domain specific terms, concepts, etc. Creating standards which don’t work together Late declaration of IPR Lack of standards clarity or awareness Implementation cost Unclear level of conformance Proprietary extensions that do not observe interoperability requirements DEVELOPMENT IMPLEMENTATION PREPARATORY

13. Interoperability Imperative Role of Standards Challenges in Standardization Towards Standardization Guidelines

14. Aspects of Standards Development Openness IPR Management Awareness Extensibility Standards Development Requirements Collection and Scoping Maintenance and Errata Management Common Design Principles Conformance Development Efficiency Prototyping & Interop Testing

15. Openness Closed policies, processes, development groups CROSS-TOPICS Standards BodyRec. 2:Standards bodies should provide fair and reasonable membership terms and conditions Competition to create standards Misuse of standards as a means to erect barriers to competition and trade DevelopersRec. 1: Early and clear commitment to openness DEVELOPMENT IMPLEMENTATION PREPARATORY

16. IPR Management Intellectual property encumbrances CROSS-TOPICS Standards BodyRec. 3: Standards bodies should provide clear IPR policies. Regarding IPR essential for the implementation of a (proposed) standard, standards developers need to be obligated in terms of • Disclosure • Licensing (either RAND or Royalty Free) Late declaration of IPR Implementation cost DEVELOPMENT IMPLEMENTATION PREPARATORY

17. Requirements Collection and Scoping CROSS-TOPICS Large, complex, “all or nothing” standards Creating standards which don’t work together Users / Developers / Standards Body Rec. 4: Standards development efforts should be scoped in a clear and narrow manner. Dependencies and relationships to other standards should clearly be indicated. DEVELOPMENT IMPLEMENTATION PREPARATORY

18. Common Design Principles Cooperation between communities – Lack of common design rules and content reuse Developers / Standards Body Rec. 5: Related standards efforts should adopt common design principles. • Protocols: (e.g. Web services protocols) need to be modular and extensible so that they can easily be composed with each other • Data Formats: industry-specific XML vocabularies need to adopt common naming and design rules (such as the concepts described in UN/CEFACT CCTS) in order to more easily identify semantic commonalities and differences Rec. 6: Avoid over-specification. Specifications should observe the scope of the standards development effort and implementation details that don’t support interoperability should be kept out of the standard. CROSS-TOPICS Domain specific terms, concepts, etc. DEVELOPMENT IMPLEMENTATION PREPARATORY

19. Efficiency CROSS-TOPICS Lack of rigor in standards development Standards Body Rec. 7: Standards bodies should provide an efficient development process that ensures a high level of quality for its deliverables. • Efficiency: Clear rules for issue resolution and decision-making by retaining the ability for minorities to voice their opinion. • Quality: Mechanisms that promote early prototype implementations, interoperability testing, and feedback collection provide a higher probability that a standard becomes mature earlier. • Evolution: Standards bodies should provide a means to enhance their development processes. DEVELOPMENT IMPLEMENTATION PREPARATORY

20. Prototype Development and Interoperability Testing CROSS-TOPICS Lack of test specifications Standards Body Rec. 8: Specify clear conformance requirements and test cases. Rec. 9: Make prototype implementations and interoperability testing part of the standards development. Without such a commitment, standards may evolve with only limited industry adoption and implementations with lacking interoperability. DEVELOPMENT IMPLEMENTATION PREPARATORY

21. Conformance CROSS-TOPICS Unclear level of conformance Standards Body Rec. 10: Choose the One Standard - One Test, Supplier’s Declaration of Conformity (1-1SDoC) approach as the common denominator for conformance statements Standards Implementer Rec. 11: Provide standards conformance statements by means of supplier self-declarations. DEVELOPMENT IMPLEMENTATION PREPARATORY

22. Maintenance and Feedback/Errata Management CROSS-TOPICS Lack of rigor in standards development Standards Body Rec. 12: Provide channels for implementation feedback and processes for issue resolution and errata development, particularly after ratification of a standard DEVELOPMENT IMPLEMENTATION PREPARATORY

23. Extensibility CROSS-TOPICS Standards Body Rec. 13: Standards should provide extensibility mechanisms. • A standard needs to clearly differentiate between mandatory and optional features. It is the mandatory features that define the minimal set every implementation needs to implement interoperably. • A standard should also provide appropriate extensibility mechanisms that implementations can use in order to employ the standard in specific contexts. Proprietary extensions that do not observe interoperability requirements Implementers Rec. 14: Extensions need to observe interoperability requirements. Interoperability can suffer if, for example, mandatory features are added. DEVELOPMENT IMPLEMENTATION PREPARATORY

24. Awareness Challenges obtaining standards credentials CROSS-TOPICS Standards Body Rec. 15: A standards body should establish liaisons to other organizations that develop standards upon the standards body relies. Rec. 16: A standards body should ensure that their deliverables are made easily available and well marketed. Lack of standards clarity or awareness DEVELOPMENT IMPLEMENTATION PREPARATORY

25. EICTA Activities regarding Interoperability • EICTA • is the European Industry Association for Information, Communications and Consumer Electronics Technology • promotes the collective interests of the information and communications technology and consumers electronics sector • has long advocated interoperability in various contexts • EICTA Interoperability Task Force set up in September 2003 • Produced generic “Interoperability White Paper” in 2004 • Need for interoperability • Open standards as the preferred means to meet this need • Activities to develop a complementary white paper on standardization started in 2005 • Goal is to develop a set of guidelines that address challenges identified in standardization • Focus on experience with standardization activities • This presentation outlines the scope of the new whitepaper • Thanks to Jochen Friedrich (IBM) for co-authoring the initial draft guidelines

26. Q&A