A Model for the Classification of Interorganisational Standards
Ulrich M. Löwer
Institute for Information, Organisation and Management Ludwig-Maximilians-Universität München
Ludwigstraße 28 VG 80539 München loewer@bwl.uni-muenchen.de
Abstract: Interorganisational standards are an important requirement for loosely coupled interorganisational relationships such as supply chain networks. The many different standardisation efforts, however, make this field quite confusing. This work thus proposes a model called ‘interorganisational specifications stack’, which serves for the classification of the different efforts. An analysis reveals many interconnections between the different specifications. The work suggests considering these interconnections in future research on such standards.
1 Introduction
Today’s supply chain networks rely on concepts such as ‘build-to-order’, ‘capable-to- promise’, and ‘efficient consumer response’. If all of these concepts were specifically modelled for each IO relationship, connecting many partners and switching between them would be prohibitively expensive. The main vision in IO standards is thus to standardise the interfaces between firms in order to enable loosely coupled IO relationships. While often discussed standardisation efforts such as the Web Services or Semantic Web initiatives already aim to provide such standards, they offer only very fundamental technologies. They do not model business-related facts, which are needed for the loose coupling of firms. Fortunately, there are many different initiatives on the way, which aim to standardise such business semantics. The sheer number of these initiatives, however, makes this field quite confusing and difficult to understand [KNL03]. The main goal of this work is to propose a model for the classification of the many initiatives and their standards. This work focuses on standard development organisations (SDOs) that try to establish IO specifications as standards. It thus defines this term in section 2 and discusses its characteristics. The third section proposes and explains a framework, which serves for the classification of the many different IO standards available. Section 4 then presents an application of this framework and discusses the many interrelations between the different standards. A final section concludes this paper.
2 Interorganisational Standards
As the term ‘interorganisational standards’ is not widely used yet, I propose the following definition: Interorganisational standards are broadly adopted specifications that formally define or support business-related semantics and processes, which are made accessible to other organisations’ information systems, usually via Web-based technologies.If such a specification is not yet broadly adopted, I will speak of a (Web- based) interorganisational (IO) specification. [He03] lists several aspects a comprehensive IO standard would have to specify unambiguously: Time quantities and currencies, physical places, goods and services, organisations and individual roles, business processes, agreements and contracts. Most of these aspects are not stable, but subject to frequent change. Jacucci et al. claim that formalisation of (inter- )organisational domains will never come to full closure because of the unpredictable side-effects of human action [Ja03]. Such semantic change demands permanent
‘reparation’ of formal specifications [Fr91]. It would be inefficient to cover all aspects of business semantics within one specification, as it would be changing almost permanently, leading to instability and confusion. Accordingly, a modular approach seems to be superior, with a set of specifications each focused on a certain topic. There are many frameworks available, which aim to classify different IO specifications [ADH03; CS04; Go03; HWT01; Ja03].
3 The Interorganisational Specification Stack
On the basis of the Business Internet Consortium Framework [HWT01], I propose to use the IO specification stack as depicted in Figure 1, which offers a good compromise between detail and clarity. The lowest layer is the network transport layer. It consists of all technologies commonly used for Internet connections, such as TCP/IP and HTTP.
XML and several related technical standards such as XML Schema Definition (XSD) form the next layer. Messaging specifications serve for the exchange of XML-based messages between the information systems of business partners. While SOAP is broadly accepted as a messaging specification for different kinds of applications, it lacks security mechanisms. ebMS augments SOAP with security and adds further mechanisms needed for the business-specific use of SOAP. The description layer offers specifications for the machine-readable description of the IO interfaces. Again, WSDL is a generic specification, while ebCPPA also includes business aspects. Discovery comprises specifications for building central registries to make it easier to find business partners.
Although UDDI is one of the basic Web Services specifications, here it differs from SOAP and WSDL, as it includes business-specific semantics and is maintained by OASIS. As these specifications focus on technical aspects of IO information systems, I will further subsume them under the term ‘technical IO specifications’. The next layers are divided into two halves. Specifications concerned with business semantics are on the left and those concerned with business processes are on the right in Figure 1. Both modelling business semantics and business processes can be quite complex [He03;
He96; vAK03]. Modelling both in different specifications is thus an appropriate approach to keeping these complexities separate.
Network Transport Core XML Standards
Messaging Business Semantics
Format Definition Business Process Format Definition Specialized Business
Semantics Specialized Business Processes
Discovery Description Universal Business
Semantics Universal Business Processes Trading Partner Agreements
Hardware, TCP/IP, HTTP, SMTP, ITU T X.509, …
XML, DTD, Relax NG, XSD, … ebMS, SOAP
IEEE, IETF, ITU, W3C, … OASIS, W3C OASIS, W3C
ebCPPA, WSDL OASIS, W3C
ebRMI/RS, UDDI OASIS
ebCCTS, UML,
(OWL, RDF) OASIS, OMG, UN/CEFACT,
(W3C) ebCCTS, EAN.UCC,
EDIFACT, UBL OASIS, UCC, UN/CEFACT,
VICS
RN Dictionaries RosettaNet
Exemplary specifications Exemplary SDOs
ebCPPA, TPIR OASIS, RosettaNet
TechnicalUniversalSectoral
ebBPSS, BPEL, UML CPFR RN PIPs
Figure 1: Interorganisational Specifications Stack
Moreover, I distinguish three layers of business semantics and process specifications.
The lowest layer comprises formats of how to define business semantics and processes.
Today almost all business-related specifications rely on UML (e.g., RosettaNet PIPs or UN/CEFACT’s ebCCTS). While UML is a universal approach to modelling almost any kind of information system, specifications such as Resource Description Framework (RDF) and Web Ontology Language (OWL) offer ways of formally describing the semantics of entities and their relationships that computers can automatically interpret.
Similarly, the Business Process Execution Language (BPEL) and the Business Process Specification Schema (ebBPSS) offer concepts and elements for defining business processes that information systems can automatically execute. None of these specifications, however, provides readily defined semantics and processes, only the methods for doing so. Specifications on the next layer comprise actual business semantics and processes that IO scenarios can directly draw on. For instance, the EAN.UCC system globally defines unique numbers for the identification of products.
CPFR is an industry-independent specification for collaborative forecasting developed by Voluntary Interindustry Commerce Standards (VICS). However, such universal business semantics and processes cannot usually meet all the requirements of a particular application domain. As a result, industries often develop specialised specifications based on the universal ones. For example, RosettaNet’s collaborative forecasting Partner Interface Processes (PIPs) are based on CPFR, but customised to the needs of the electronics industry. If there are no universal specifications for a certain scenario needed in an industry, then SDOs usually develop specialised specifications, which can be transferred to other industries later. RosettaNet follows this approach, as it is a leader in developing IO business processes, but is also open for other industries to adopt them.
The last element of the IO specifications stack is the definition of formal trading partner agreements. In the ideal case, such a trading partner agreement (TPA) comprises all technical, organisational and legal details and can be processed automatically by the IO information systems of the partners involved. Further complexity is added by the fact that such agreements also have to consider the details of the specifications used on the other layers, as the on-top position in Figure 1 indicates. Several SDOs use TPA
specifications in their architecture to support automatic discovery, negotiation and agreement via IO standards too (e.g., ebCPPA). However, the high complexity and the many different specifications used for IO scenarios will leave many issues unresolved until this vision is achieved on a broader scale. If this succeeds, autonomic software agents could play an increasing role in dynamic supply chain networks [CD00]. To differentiate between the specifications that can be generally applied and specifications developed for a certain industry, I will call the former ‘universal IO specifications’ and the latter ‘sector IO specifications’ (see Figure 1).
4 Classification of Interorganisational Standards
The many different standard development organisations (SDOs) with similar visions and unclear status confuse potential users and even experts in the field [KNL03]. It appears to be a hopeless task to capture and classify all existing SDOs and their specifications without missing some out. While OASIS offers an almost complete overview of XML- based specifications, it is still an unstructured list [OA04]. Based on this, I have compiled a list of the most relevant SDOs for IO specifications. This only includes SDOs developing specifications meeting the definition of IO specifications as presented in section 2. I have analysed the respective specifications using the stack in Figure 1. In a first step, I identified which elements of the stack are covered by a certain specification.
As it has become obvious that there are many interrelations between the specifications, I also analyzed the specifications for the use of others in a second step. Both steps result in the table published online in [Lö05]. The analysis reveals strong interconnections between the specifications. It is possible to combine them in many different ways, often not explicated in the specifications or supporting documents. For example, RosettaNet uses specifications from eight other SDOs, while CEFACT’s specifications are used by ten other SDOs. In general, the sectoral SDOs often rely on the technical/universal specification, while these are also highly interconnected. Two noticeable exceptions are RosettaNet and SWIFT. API’s PIDX and CIDX’s Chem eStandards use the messaging infrastructure of RosettaNet and some RosettaNet concepts for their semantics and process definitions too. As the dominant specifications in the financial industry, SWIFT standards are indirectly used in almost any industry. RosettaNet started to integrate them into its specifications for financial processes, while ISO approved them as ISO 20022.
As all these IO standards are highly interwoven with the day-to-day business of the user firms, it is generally difficult to isolate their direct benefits [Ni94]. Moreover, it is important to distinguish between the different types of standards before comparing their potential benefits. The IO specification stack as proposed in section 3 seems to be a useful framework to do so.
5 Conclusion
This paper proposes a model to classify the many different efforts to standardise IO specifications. The IO specifications stack is discussed in more detail and illustrated with several examples. It also serves as a framework for an analysis of many different SDOs
working on IO specifications. The analysis reveals that many specifications are highly interconnected and should thus be compared and discusses only after clarifying their relations to each other. The proposed framework proved to be useful for this task, but clearly offers potential for further application and refinement in future research.
References
[ADH03] Albrecht, C.C.; Dean, D.L.; Hansen, J.V.: Market Place and Technology Standards for B2B-E-Commerce: Progress and Challenges. In (King, J.L.; Lyytinen, K. Hrsg.):
Workshop on Standard Making: A Critical Research Frontier for Information Systems, Seattle, WA, 2003; pp. 188-209.
[CS04] Chari, K.; Seshadri, S.: Demystifying Integration. Communications of the ACM (47:7) 2004; pp. 59-63.
[CD00] Choi, T.Y.; Dooley, K.J.; Rungtusanatham, M.: Supply Networks and Complex Adaptive Systems: Control versus Emergence. Journal of Operations Management (19:3) 2000; pp. 351-366.
[Fr91] Franck, E.: Künstliche Intelligenz – Eine grundlagentheoretische Diskussion der Einsatzmöglichkeiten und –grenzen. Mohr, Tübingen, 1991.
[Go03] Gosain, S.: Realizing the Vision for Web Services: Strategies for Dealing with Imperfect Standards. In (King, J.L.; Lyytinen, K. Hrsg.): Workshop on Standard Making: A Critical Research Frontier for Information Systems, Seattle, WA, 2003; pp. 10-29.
[HWT01] He, J.; Wenzel, P.; Thomasma, T.: High-Level Conceptual Model for B2B Integration.
Business Internet Consortium, 2001.
[He03] Hepp, M.: Güterklassifikation als semantisches Standardisierungsproblem Gabler, Wiesbaden, 2003.
[He96] Hess, T.: Entwurf betrieblicher Prozesse – Grundlagen – Bestehende Methoden – Neue Ansätze Deutscher Universitäts-Verlag, Wiesbaden, 1996.
[Ja03] Jacucci, E.; Grisot, M.; Aanestad, M.; Hanseth, O.: Reflexive Standardization – Interpreting Side-Effects and Escalation in Standard-Making. In (King, J.L.; Lyytinen, K. Hrsg.): Workshop on Standard Making: A Critical Research Frontier for Information Systems, Seattle, WA, 2003; pp. 147-160.
[JZ03] Jain, H.; Zhao, H.: A Conceptual Model for Comparative Analysis of Standardization of Vertical Industry Languages. In (King, J.L.; Lyytinen, K. Hrsg.): Workshop on Standard Making: A Critical Research Frontier for Information Systems, Seattle, WA, 2003; pp.
210-221.
[KNL03] Kotinurmi, P.; Nurmilaakso, J.-M.; Laesvuori, H.: Standardization of XML-Based E- Business Frameworks. In (King, J.L.; Lyytinen, K. Hrsg.): Workshop on Standard Making: A Critical Research Frontier for Information Systems, Seattle, WA, 2003; pp.
135-146.
[Lö05] Löwer, U.M.: Classification of Interorganisational Standards, published online:
http://www.iom.bwl.uni-muenchen.de/~loewer/interorgstaclass.html, 2005.
[Ni94] Niggl, J.: Die Entstehung von Electronic Data Interchange Standards. Gabler, Wiesbaden, 1994.
[OA04] OASIS: Cover Pages: XML Applications and Initiatives. 2004.
[vAK03] van der Aalst, W.; Kumar, A.: XML-Based Schema Definition for Support of Interorganizational Workflow. Information Systems Research (14:1) 2003; pp 23-46.
