An important goal of any Service-oriented Architecture (SOA) is to increase the flexibility of IT-supported business processes. In particular, it should be possible to quickly implement new business processes and business services, and to flexibly adapt the corresponding IT applications to changing business needs. In addition, it is crucial to adequately cope with changes in the SOA environment itself. Examples of such changes include modifications of IT services or business objects that are used by IT-supported business processes.

Due to the insufficient interaction between domain experts and system engineers, usually a large gap between business needs on the one hand and information systems on the other hand exists. SOA offers promising perspectives to reduce this gap by aligning services with business requirements in a better way (Business-IT Alignment). Generally, integrated lifecycle support of processes, services, and data objects at both business and technical level constitutes a big challenge for SOA. In practice, no comprehensive information is maintained about these artifacts and their relations to technical implementations. This lack of documentation, in turn, causes severe maintenance problems. For example, when a service (or particular service version) is shut down it cannot be immediately determined, which processes or applications are affected. This makes it difficult to preserve system consistency and to guarantee for the absence of system errors. For instance, a process implementation might crash if the service it uses was shut down or a process might be blocked if actor assignments cannot be resolved.

The variety of services and processes existing in different versions and variants as well as their concurrent use have resulted in high operation and maintenance costs. Services that are not used anymore should therefore be removed in order to avoid and reduce these costs. This, in turn, requires information about the multiple dependencies that exists between the different service versions and their consumers.

In the ENPROSO (Enhanced Process Management through Service Orientation) project we target at high consistency between business requirements on the one hand and their IT-based implementation in process-aware information systems on the other hand. In this context service orientation enables the use of different service versions by numerous processes and consumers respectively. This, in turn, results in a complex network of relationships (see Fig. 1) that need to be controlled.

The contributions the ENPROSO project targets at are manifold: First, ENPROSO defines basic concepts for realizing a repository that covers all aspects of a SOA (cf. Fig. 2). In particular, it shall maintain different versions of processes, services and data objects at both business and technical level. Additionally, this repository shall maintain comprehensive information relation to the whole lifecycle of processes and services as well as to the many relation-ships existing between the numerous artifacts.

Second, in ENPROSO we are developing a multi-layer modeling method to implement process-aware and service-oriented information systems in a consistent and maintainable way (cf. Fig. 3). All model layers cover process aspects like control flow, data objects, business rules, business services, and organizational model at different levels of granularity. The first layer starts with the business perspective and its models, which are then refined towards a technical implementation at the IT level. In particular, process or service changes have to be approved by domain experts or business units, before they are technically realized by the IT department on a specific platform. One challenge is to map activities from the business level to those at the technical level and vise versa as well as to maintain these relationships. For ex-ample, when adding, deleting or modifying activities within a business process model, this adoptions should be easy mappable to the corresponding workflow implementation. Note that such mapping is by far not trivial since workflow specification are usually more fine granular than business process models, and there is no 1:1 mapping between business activities and workflow activities in general.

Generally, it is a complex task to identify the relations between business process activities and corresponding technical activities in the IT-implementation. Therefore, a traceable documentation of dependencies is fundamental for closing the gap between business process models and their corresponding IT-implementation. Particular challenges are to maintain such depen-dencies and to guarantee the consistency between the different model layers.