Abstract
New legal settings, the need for improved quality of service, and technological advances increase the pressure on public administrations to cooperate in order to modernize and innovate procedures. Thus, the automation of cross-organisational processes is a clear objective. But due to the traditional independence of administrations, as well as the need to minimize modifications of internal systems, a loose coupling rather than tight system integration is desired. In this vein, a method is required that enables public administrations to create comprehensive interfaces they can publish to collaboration partners. This chapter presents the concept for a Business Interoperability Interface that describes the externally visible behaviour of administrations and supports the design and execution of loosely coupled, cross-organisational processes. Requirements for this interface are derived from the Europol-Eurojust collaboration, and the development and application of the Business Interoperability Interface are illustrated with the same scenario.
TopIntroduction
Needed: Automated But Loosely Coupled Collaboration Between
Public Administrations
Due to the increasing heterogeneity and dynamics of the European Union, more and more Public Administrations (PA) within Europe are challenged to work together and to adapt continuously to rapid technological changes. New legal settings, modernization, the need for improved quality of service, the search for competitive advantages and innovations as well as rapid technological advances create a new dynamic and complex administration environment, which requires flexibility and mobility from European public administrations. For these reasons, different governments have to cooperate in order to modernize and innovate public administrations. To avoid redundant manual work, to increase speed of process execution as well as process transparency, the IT systems of different PA should support the execution of joint, collaborative processes.
Nonetheless, due to the traditional independence of different administrations and differences in regulations, it is unrealistic to expect a tight integration of PA and their technical systems. Thus, the objective should rather be a loose coupling of organisational systems that requires only minor changes of internal systems but still supports the automation of cross-organisational processes. An analysis of related work reveals that current E-Government interoperability frameworks focus on the descriptive rather than the constructive aspects of interoperability, e.g. by providing standards and technical recommendations for selected aspects of IT system development. They only offer limited support when it comes to methods for systematically implementing cross-organisational processes (CBP), e.g. by providing a procedure model or an architecture of how to put the various standards involved in a CBP together (cp. Schmidt et al., 2007).
This raises the necessity for extending existing interoperability frameworks regarding constructive aspects that support the design and implementation of CBP in the public sector. Descriptive aspects define, for example, which specific E-Government data specifications, interfaces, process models or open standards ought to be used in different local, regional and international public administrations. Constructive aspects describe on a more generic level the methods to be applied for creating interoperable software systems of public administrations. While the descriptive aspects focus on static elements, e.g. a certain standard needed for the collaboration of two public administrations on the national level, the constructive aspects aim at the dynamics of establishing interoperable information systems, e.g. the various steps necessary to develop such a system. Note that we presume the existence of mechanisms to ensure syntax compatibility among the collaborating Public Administrations, e.g. the mapping of heterogeneous language formats is not in the scope of this work.
Key Terms in this Chapter
Interoperability Architecture: An Interoperability Architecture describes the overall structure of an interoperable software system from a high level perspective. It describes the components comprised in the system and their relationships as well as the principles and guidelines governing their design and evolution over time.
Interoperable Software System: An interoperable software system consists of loosely coupled software components which might be heterogeneous and owned by different jurisdictions. A predefined and agreed-upon method for the description of the system elements allows implementing the interactions between the components as intended by their owners.
Private Process: A private process is a Business Process which is designed for internal purposes; its elements are private in the sense that they are not public to other organisations unless declared to be so.
Business Interoperability Interface: The Business Interoperability Interface of one organisation represents the sum of all public and global process models it must publish to partners to enable a cross-organisational process with them. To enable both design and execution of cross-organisational processes, these models should cover the relevant enterprise dimensions and should be represented in a conceptual, technical and code level.
Global Process: A global process describes the interactions between two or more organisations from a neutral perspective, capturing all allowed interactions between all partners.
Public Process: The public process of party A contains those parts of the private processes needed by its collaboration partners (e.g. party B and C) to understand how they can interact with party A. It is an interface to the outside-world which extracts only that kind of information which is necessary for the interaction with one or more potential partners. Unlike statically interfaces it describes not only the operations offered by an organisation but also the sequence in which operations are executed.
Business Process: A Business process is a sequence of activities executed to reach a business objective.