Towards Adaptive Interenterprise Systems Norbert Jastroch MET Communications, Bad Homburg, Germany
[email protected] Abstract Interenterprise operability appears to be of high complexity with regard to technology, organisation, and application. It poses many challenges to supporting ICT solutions, frequently resumed under the term interoperability. A number of application issues have been pointed out in the Enterprise Interoperability Research Roadmap of the European Commission. The optimal ‚organisational fit’ of ICT systems becomes a basic issue, as enterprise interoperability is always linked with business processes. And technological issues, in the end, put forward the question of software engineering, i.e. how to address the specifics of interenterprise processes by appropriate systems engineering approaches. This paper reflects on these issues and suggests to combine the concept of component based software engineering and the software product line approach, as a means to facilitate the engineering of adaptive interenterprise systems. We argue that such combination offers the potential of supporting interenterprise operability at a reasonable level of complexity, while keeping resulting systems adaptive and evolutionary.
1
Interenterprise collaboration
When in the late 1980s the German pharmaceutical industry started a project to automatize the exchange of orders between wholesalers and manufacturers, it turned out that three major problems had to be solved. First, a manifold of IT systems used by the participating firms was to connect technically. As the Internet was not yet there, this could be achieved by means of an intermediate data interchange service offering mailbox type store and forward functionality. Second, the business processes involved on the wholesale side (order submission) resp. the manufacturer side (order processing) were to be mapped. Basic to the solution of this issue became EDIFACT, a standard defining the structure and contents of (order) messages for electronic interchange, together with a unified product numbering established by the national industry bodies. Third, each participating firm had to take care for integrating this EDI application with their, mostly proprietary, processing systems. Applications like that – similar ones were introduced f.e. to the automotive industry – may be considered quite simple forerunners of what nowadays is dealt with in the field of ICT for networked enterprises. While now, some twenty years later, the problem of mere technical connection of IT systems has been overcome by the global Internet infrastructure, the space of concern of ICT supporting interenterprise collaboration has somewhat narrowed to the mapping of business processes and issues of systems interoperability. It is, however, widening at the same time, because applications much more complex than the one described above appear on the agenda. A well-known example is Computer Supported Cooperative Work (CSCW). Research into this subject, which comprises intraenterprise as well as interenterprise applications, has pointed out the need for specific approaches to the engineering of CSCW systems as compared to software engineering in general or the modelling of business processes and organizational structures. Prinz & Pankoke-Babatz [7] suggest continual requirements management to replace one-time requirements analysis in that context. Similar concepts can be found in [2] with the separation of run-time from development environments in the Interoperability Framework of the
ATHENA project. Sommerville [9] discusses the deployment-time and design-time configuration as two aspects of the engineering of software product lines. Such conceptual thinking implies that iterative development forms part of the engineering process. Picot et al [6] stress the need for iterative engineering of ICT systems as a consequence of the changing business environment, i.e. the transformation from functional organization of business activities towards process oriented operation. Interenterprise collaboration appears to be a prominent manifestation of this process orientation. While, thus, the need for ICT systems supporting business processes across enterprise networks is rising, design and engineering of such systems pose certain challenges that have to be addressed. The Enterprise Interoperability Research Roadmap of the European Commission [3] therefore names the creation of a science base for enterprise interoperability as one grand research challenge. From a systems engineering point of view, there are lots of issues with this, which can be roughly grouped into such of complexity and interoperability.
2
Complexity
The notion of complexity as used here goes back to W. Weaver [10], who took it as a situation which can neither be described in terms of cause and effect (because the number of variables involved is not small enough, 3 to 4), nor statistically (because it’s not made of a multitude of homogeneous, but heterogeneous elements). In inter-enterprise collaboration complexity arises from the business processes (and their mapping), and the semantics that need to be taken into account. The number and variation of business processes is such that their linking and mapping becomes a question of organizing complexity. And so does semantics, which is necessary to establish a common understandability of messages that control collaborative activities. For the engineering of business processes the concept of Business Process Management (BPM) has been established. It comprises standards, tools and technologies for the modelling and execution of processes. Yet even the modelling of just a single process turns out a complex problem. That’s why currently the concept of views gets widely accepted as a means to derive abstract information to control processes. Together with graphical visualization it forms part of most of the process modelling methodologies in place. A number of most prominent business process modelling methods have been discussed by Lippe et al [5], especially as to their ability to facilitate cross-organizational processes. Their findings can well be applied to interenterprise collaboration as this implies particular forms of cross-organizational processes. They suggest a three-level framework providing different levels of abstraction as to the business, technical and executable aspects of such processes, overlayed with different views such as private and collaboration-related. Modelling then is to be done on each of the different levels. The methods to apply may well differ, since in general one method does not fit on all levels. Thus, need is there to cake care for an appropriate mapping of the process models generated. It appears immediately that the task of modelling crossorganizational, and that implies interenterprise, collaboration then becomes one of significant complexity. Another source of complexity is semantics. The problem of the unified product code in the pharmaceutical order exchange system mentioned above is a most simple manifestation on the execution level. It shows up likewise on each level of abstraction of business processes. All
elements represented in respective process models, be it data, events, functions, activities, objects, features, etc. need to be semantically clearly defined. That’s where application domain modelling comes into the game and hence the great interest in ontologies. To make an interenterprise process executable in the end, it must be controlled by messages providing all relevant information in a way that unique interpretation is guaranteed. As long as this concerns isolated applications with limited functional extent, classical approaches are sufficient. An example is the concept of classes and sub-classes within objectoriented modelling approaches. However, in a general context of interenterprise collaboration the need for a more universal semantical foundation arises. A lot of work therefore has been and still is dedicated to establishing the basics of computational ontologies. Most frequently this is application domain specific. But even then semantic mapping and mediation is required so that organizational units in different enterprises can make use of it. With regard to the engineering of such systems, this adds to the functional scope to be dealt with. Semantic mapping requirements again raise complexity.
3
Interoperability
Interoperability in the context of enterprise applications is the ability of a system to work with other systems without special intervention by the user. The IEEE definition stresses explicitly the information flow aspect: Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. In the case of interenterprise collaboration this means seamless integration across organizational boundaries between dispersed operational units of a number of firms. The result are highly distributed system architectures. In particular, such systems need to be able to cope with change even after deployment during their run-time. Change happens to the supply network, distribution channels, design and development co-operation etc. Systems engineering is forced to offer effective approaches which enable adaptivity and coping with evolving business environments not only at design-time, but also during system run-time. The problem here, to a large extent, lies in the matching of the system development approach with that of designing system adaptability. The ATHENA project [2] showed that it poses significant problems to engineering when a top-down development approach based upon business process modelling shall be integrated with a bottom-up approach to adaptability based upon decentralized settings and following the autonomous computing concept. While these interoperability issues fall into the area of business and technical process modelling, there is another category rather on the level of execution. The ATHENA project [1] uses for that a further separation into application, data, and communication issues. Sommerville [9] resumes three types of incompatibility when discussing the problem of component interfaces within component-based software engineering: parameter incompatibility, operation incompatibility, and operation incompleteness. In fact these are issues fundamental to the design of systems which integrate components from different sources. This is the case in the ATHENA approach based upon the model-driven and adaptable interoperability framework suggested in [2]. And it is surely of high relevance when a Composition-Based Software Systems (CBSS) engineering approach is taken, which in general means to compose a system using COTSsoftware, legacy systems and service-oriented systems as components.
4
Engineering approaches
The issues of complexity and interoperability apply to systems engineering in general, but quite particularly to the engineering of interenterprise collaboration applications. Significant advancements come from the introduction of the new engineering paradigm of Service Oriented Architecture (SOA). Basically aiming at making systems as simple as reasonable, the SOA concept is considered a promising approach to reduce complexity while keeping systems interoperable. SOA as an architectural style of systems engineering can be resumed as follows: The concept of services replaces the concept of objects. Functions, comprising system service functions and those which are composed of lower-level functions, are defined as services. Services operate as components which are independent in the sense that one component must neither ‘know’ nor ‘care’ how others perform their function. Components are coupled through interfaces. System design has to make sure that interfaces deliver required input to a component, and provide results of the component’s service as output. At the architectural level it is irrelevant whether interfaces are local (part of the system) or remote (external to the system). They get invoked, and various interconnect schemes or protocols can be used for invocation, as can infrastructure components from within the system that are required to make the connection. Services may be performed within the application, or on a completely different system, e.g. in the global web. What can be achieved by applying SOA, are systems loosely coupled by interacting software agents, as He [4] put it. Loose coupling here means the reduction of artificial dependencies within a system to the minimum, while keeping real dependencies. In fact, if this was to be realized in an ideal way, it would lead to systems at a minimum level of complexity. However, there seems to be an inherent problem with emergent interoperability issues which has to be dealt with. As a major research undertaking focused on the networked business field,, the ATHENA project have set out for a comprehensive investigation of Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application. The following two sub-chapters are to briefly resume some of their findings as published in [1] and [2].
4.1
Model-driven design time development
The approach taken by the ATHENA project for the design-time development of interenterprise applications builds upon the Object Management Group®s concept of Model Driven Architecture, MDA® for system integration, which is being adapted to form a model driven development (MDD) approach to the design of (inter)-enterprise systems. It makes use of the MDA abstraction levels which are the computation independent model (CIM), the platform independent model (PIM), and the platform specific model (PSM) and relates these to respective levels of abstraction for enterprise systems, i.e. business context, software specification, and software realization models. Business context models are to be established by use of state-of-the-art business process modelling methods, such as ARIS-EPC, IEM, or Business Scenario Maps. With PIM4SOA the ATHENA project suggest a framework for a Platform Independent Model for Service-Oriented Architecture which can be used as an intermediary step for connecting business level enterprise models with platform specific models building upon web services, such as WSDL or WS-BPEL. PIM4SOA is based upon the Business Process Definition Metamodel (BPDM) of the OMG. It is designed to facilitate the exchange of business process specifications between modelling tools,
and between these tools and such at execution level. For a number of tools, one-way (f.e. ARIS-EPC to PIM4SOA) or two-way (f.e. PIM4SOA to/from WS-BPEL) transformations are described. The results on this field shown by the ATHENA project clearly underline the relevance of complexity issues. The space of concerns to deal with is quite large and multi-faceted even in the case of the development of an enterprise application that builds on SOA only for one single enterprise and for one application domain, f.e. manufacturing. There is no need for semantic mapping. In fact, when it comes to interenterprise collaboration of broader scope, be it with respect to the application domains, or the number of firms involved, it will immediately grow by orders of magnitude. Apparently additional requirements have to be taken into account, such as the mapping of business process models and related computational semantics. And soon will then arise the need for meta-modelling of business processes, of application domains, and of related computational semantics. This leaves much work still to do on f.i. standardization, reference architectures, and ontologies.
4.2
Adaptive run-time development
In chapter 3 interoperability issues have been grouped in two categories, those ones related to the modelling of business and technical processes, and those related to the system execution level. In order to ensure inter-enterprise operability for the whole life-cycle of an interenterprise application, it needs to be continually adapted to changing environments. This must be done on the architectural as well as the execution level. With regard to the architectural level, the MDA concept of the OMG offers the approach of architecture-driven modernization (ADM). The ATHENA project suggest to incorporate ADM into their model-driven and adaptive interoperability framework. The PIM4SOA meta-model provides a feasible starting point. Model transformation has to be taken into account eventually. Dealing with run-time adaptability at the execution level poses much more of a problem, though. The ATHENA project suggest an Autonomous Computing Framework (AACF) as a valid approach. Building blocks of it are agent-based computing architecture, active object flow framework, peer-to-peer business resource management framework, and active model execution platform. These are governed by an engineering methodology for autonomous computing. Basic to it are the concepts of multiagent systems and peer-to-peer computing architecture. They are considered complementary in facilitating the description of local system behaviour (agents), what can be used in the context of business process models, and dispersed resources management (peer-to-peer), what supports the handling of business objects, services, or documents. However, current state is that there are no methods available to integrate these two concepts, neither at the business context nor the execution level. So interoperability in the sense of run-time adaptability of interenterprise collaboration systems is rather more than less a problem to solve. Consequently, the same applies to the integration of model-driven development with adaptive interoperability approaches into an integrated systems engineering methodology.
5
Composite systems approach
With regard to systems for interenterprise collaboration, the observations made so far allow for the following interpretation. The level of integration of a system correlates with its level of complexity and inter-operability. The higher the level of coupling of services which form part of the system as components (representing the architectural model of system functionality), the higher is the complexity of the system on the one hand, and its interoperability on the other hand. However, when looking at the run-time adaptability of such a system, the correlation appears to turn upside down: The higher the level of coupling, the lower gets system runtime adaptability. In fact, this applies under the provision that the architectural style of a system builds upon the SOA paradigm. Services represent functional processes within the system, on the execution level they are encapsulated in components. Coupling is done by interfaces connecting the components. Tight coupling, i.e. all interfaces are designed for seamless, automated, and selforganizing operation, means high level of integration of the system. Loose coupling is understood as not necessarily seamless, automated, and self-organizing operation of only a part of all interfaces. Loosely coupled systems require much more of user intervention than tightly coupled (highly integrated) systems. Between loosely coupled and highly integrated systems lies a type of systems that may be captioned as composite systems. Connection between components is designed for seamless, automated, self-organizing operation wherever feasible. Such composite systems are expected to be of moderate complexity, while providing reasonable levels of inter-operability, in particular adaptability. The figure below illustrates the positioning of the three types of systems in the space of complexity, interoperability and adaptability.
The engineering of composite systems builds upon the general principles of Component-based software engineering (CBSE) as described in [14]. We suggest to extend the “Architectural design” step in the CBSE process described there by the introduction of the concept of the dynamic configuration pattern (DCP). Configuration and reconfiguration of components are
engineering steps within the software product lines approach to software reuse [14]. They can be employed at system design-time as well as system deployment-time. The deploymenttime configuration approach is used in the context of enterprise systems (f.e. ERP – Enterprise Resource Planning) in support of business processes. It offers a feasible way to achieve adaptability. With regard to interenterprise collaboration systems, DCP shall facilitate the development of adaptive composite systems with moderate complexity and reasonable interoperability. DCP aims at the composition of such systems by designing the configuration of components - the pattern – by introducing the feature of dynamic adaptability. To achieve this on architectural level, dynamic aspects are allocated to components and the composite system at design-time. Basic dynamic aspects of components are: Enter Leave (the system) Connect Disconnect (to/from a component) Basic dynamic aspects of the composite system are: Invoke Replace Discard (components) Integrate (several components to a new one) Split (one component into several new) While at design-time the other steps of the CBSE process remain unaffected, the DCP approach prepares the composite system for reconfiguration through modification of its structure, and the organization of its components. Hence, adaptability will be enhanced.
6
Conclusions for interenterprise systems
Advancements of the state-of-practice of the engineering of interenterprise collaboration systems are not be achieved easily. New paradigms, like service oriented architecture and model-driven development, while offering approaches which let expect considerable enhancements to systems engineering in many application domains, can provide answers to genuine issues related to interenterprise operability. In particular, system design towards run-time adaptability is a problem yet to solve. There is reason to expect that weaving composite systems by building on the combination of component based software engineering with software product line development, and incorporating the dynamic configuration pattern approach, offers a pragmatic methodology to the engineering of moderately coupled systems with high level of run-time adaptively. References ATHENA-IP, Model-Driven and Adaptive Interoperability Architectures - Specification of a Basic Architecture Reference Model, Public deliverable A6.1, March 2005, http://www.athena-ip.org ATHENA-IP, Model-Driven and Adaptive Interoperability Architectures - Model-driven and Adaptable Interop erability Framework, Public deliverable A6.3, July 2006, http://www.athena-ip.org European Commission, Enterprise Interoperability – A Concerted Research Roadmap for Shaping Business Networking in the Knowledge-based Economy, Luxembourg, 2006
H. He, What is Service-Oriented Architecture? September 2003, http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html S. Lippe, U. Greiner, A. Barros, “A Survey on State of the Art to Facilitate Modelling of Cross-Organisational Business Processes”, p. 7-22, in: XML4BPM 2005, Proceedings of the 2nd GI Workshop XML 4BPM -XML Interchange Formats for Business Process Management at 11th GI Conference BTW 2005, M. Nüttgens and J. Mendling (Eds.), Karlsruhe, March 2005, http://wi.wuwien.ac.at/home/mendling/XML4BPM2005/xml4bpm-2005-proceedings.pdf A. Picot, R. Reichwald, and R.T. Wigand, Die grenzenlose Unternehmung, 5th ed., Gabler, Wiesbaden, 2003 W. Prinz, U. Pankoke-Babatz, ,,Kooperative Arbeitspraxis in der Wissensgesellschaft. Technikeinsatz und Technikgestaltung am Beispiel des CSCW-Engineering“, in: Gespaltene Welt? Technikzugänge in der Wissensgesellschaft, M. Kerner (Ed.), Köln, 2006 P. Sochos, M. Riebisch, and I. Philippow, ,,The Feature-Architecture Mapping (FarM) Method for Feature-Oriented Development of Software Product Lines”, ecbs, 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06), 2006 I. Sommerville, Software Engineering, 8th ed., Pearson, München/Boston, 2007 W. Weaver, Science and Complexity, American Scientist, 36:536, 1948
