view slides

Claus von RiegenDirector, Web Services Standards, SAP AG

OASIS SymposiumMay 10 2006, San Francisco

How Standards Address Interoperability Needs: An Industry View

Challenges

Towards Standardization Guidelines

Interoperability Imperative

Role of Standards

SAP AG 2006, How Standards Address Interoperability Needs / C. v. Riegen / 4


InternetTechnology

Digitalbroadcasting(audio/video)

(Mobile)communi-

cations

e.g.. IPTV, VoD, MP3 download

e.g. VoIP

e.g. Mobile TV

Convergence of networks and services require interoperable solutions across domains

Technology industries have their individual interoperability requirements


Application

Interoperability Layers

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

Infrastructure

ApprovePOs

Verifyinvoices

Application

Infrastructure1

2

3

1

2

3


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

Challenges



Role of Standards


Standardization vs. Technology Development

Collaboration Com

petit

ion

Standards Development

Ex-ante

Technology Development

Ex-post

Proliferation of Standards Communities

De jure standardsDe facto standards

Communication / Coordination

Proprietary standards


Actors in Standardization

Developers Implementers Users

Standards BodyTechnical

contributions (may contain

IPR) IPR declaration

SpecificationsTest casesIPR declarations

Requirements

Product/Services

Sales

Conformance /Interoperability

issues

IP licensingPrototypes Products

Conformance Claims

Implementation feedback

Agree on commondenominator


Phases in Standardization

RequirementsIdentification

Partnering Specification Development

Initial Implement./

Testing

Incremental Enhancemnt

Final /Maint.

PreparationPhase

DevelopmentPhase

ImplementationPhase

Agreed / common design principles for reaching interoperability

Need Initiator Core Group Standards BodyNeed Initiator Core Group Standards BodyNeed Initiator Core Group Standards Body

Challenges in Standardization



Role of Standards



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

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

PREPARATORY DEVELOPMENT IMPLEMENTATION




Role of Standards


Aspects of Standards Development

Standards Development

Requirements Collection and

Scoping

Openness

Prototyping & Interop Testing

Maintenance and Errata

Management

AwarenessIPR

Management

Common Design

Principles

Development Efficiency

Conformance

Extensibility


Openness

Competition to create standards

Misuse of standards as a means to erect barriers to competition and trade

Closed policies, processes, development groups CROSS-TOPICS


DevelopersRec. 1: Early and clear commitment to openness

Standards BodyRec. 2: Standards bodies should provide fair and reasonable membership terms and conditions


IPR Management

Late declaration of IPR Implementation cost

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)


Requirements Collection and Scoping

Large, complex, “all or nothing” standards

Creating standards which don’t work together

CROSS-TOPICS


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.


Common Design Principles

Domain specific terms, concepts, etc.

Cooperation between communities – Lack of common design rules and content reuse

CROSS-TOPICS


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.


Efficiency



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.

CROSS-TOPICS


Prototype Development and Interoperability Testing

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.

CROSS-TOPICS


Conformance

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.

CROSS-TOPICS


Maintenance and Feedback/Errata Management



Standards Body Rec. 12: Provide channels for implementation feedback and processes for issue resolution and errata development, particularly after ratification of a standard

CROSS-TOPICS


Extensibility

Proprietary extensions that do not observe interoperability requirements


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.

Implementers Rec. 14: Extensions need to observe interoperability requirements. Interoperability can suffer if, for example, mandatory features are added.

CROSS-TOPICS


Awareness

Lack of standards clarity or awareness

Challenges obtaining standards credentials


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.

CROSS-TOPICS


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


Q&A

view slides

Documents