Enterprise integration projects link or merge artifacts across many functions, processes and management levels in a company or government agency. In the absence of methods generic enough to cover the diverse range of enterprise integration projects and adaptable enough to support specific projects effectively, integration services promise to constitute a suitable “middle layer”. Since patterns and reference models could serve as such a middle layer, existing work in the fields of patterns in computer science and reference modeling in information systems engineering is analyzed. In a bottom-up manner, alignment, derivation, binding and merge are proposed as fundamental patterns for enterprise integration. Integration services are identified as integration tasks associated with these base patterns. Such integration services are clustered into enterprise integration patterns that serve as fragments for composing a context and project type specific enterprise integration project. Two case studies illustrate the concept and gain initial validation insights.
Top1. Introduction
In contrast to “small” projects that do only affect a specific function, process, or management level, enterprise integration (EI) projects link or merge artifacts across many functions, processes or management levels in a company or government agency. EI projects affect business artifacts like business functions, responsibilities, information objects/information flows, services/outputs, etc., as well as IS/IT artifacts like software components/interfaces, data structures/data flows, access rights on software/data assets, etc. In contrast to Hohpe and Woolf (2003), we do not restrict EI to technical integration. Instead, our understanding of EI is focusing on business integration like:
- •
M&A: In a merger or acquisition, most company structures are affected. Product programs, organizational units, business processes, software systems and most company data have to be consolidated.
- •
Inter-organizational integration: When services are to be integrated that go beyond company boundaries, not only software components and data structures are affected, but also responsibilities and business processes have to be adapted.
- •
Outsourcing: Only rarely selected system functionalities, data, process steps and governance activities can be carved out without affecting all kinds of artifacts “business-to-IT”.
- •
Consolidation: Similar to out-/in-sourcing, it is usually not possible to consolidate two (or more) platforms, software systems, data models, processes, organizational units or product catalogues without incurring multiple amendments in structures that are directly or indirectly affected.
- •
Alignment: In particular if business and IT structures are to be aligned, the range of affected artifacts is large, and changes can hardly be kept “local” if the transformation aims at significant impact.
EI projects cannot be planned and implemented intuitively. For their support, methods are needed that define the various project activities, a procedure model, respective activity results, project roles and responsibilities, and an underlying meta model that guarantees the consistency of all intermediate and final results. The method engineering (ME) discipline is concerned with the processes of constructing, adapting and implementing methods for the design of information systems (Brinkkemper, 1996). According to Brinkkemper, a method is “[…] an approach to perform a systems development project, based on a specific way of thinking, consisting of directions and rules, structured in a systematic way in development activities with corresponding development products” (Brinkkemper, 1996). Such methods can be denoted as generic methods, as they are not restricted to solve only one specific problem, but rather address a class of (similar) problems.
EI projects represent a large diversity of problems and approaches. In order to be applicable for EI support, generic methods need to be adapted to the specific characteristics of the problem situation. This issue has been addressed in the ME discipline by proposing different construction processes for the development of so called situational methods (e.g., Brinkkemper, 1996; Karlsson & Ågerfalk, 2004; Ralyté & Rolland, 2001; Tolvanen, 1998). In order to provide a conceptual structure for these approaches, Bucher et al. (2007) and Bucher and Winter (2008), suggest to differentiate situational method configuration and situational method composition. The distinguishing mark of situational method configuration is the adaptation of a so called base method against the background of a specific problem situation (Bucher et al., 2007). By contrast, the fundamental idea of situational method composition is the selection and orchestration of method fragments with respect to the specifics of a problem situation (Bucher et al., 2007). Unlike situational method configuration, the composition process is not aimed at configuring one single base method, but at combining and aggregating several method fragments in order to establish new constructional results. Situational method composition is widely used and discussed in detail in the scientific literature (e.g., Becker, Knackstedt, Pfeiffer & Janiesch, 2007).