and outlook on future research issues. 2 Basic Concepts In this section we introduce the core concepts needed to implement our management approach for SoA-based application systems. 2.1. Workflow Technology Workflow management systems (WfMS) are used to model and control business processes (workflows). Workflow schemas are the results of workflow modelling and the basis of the control of a business process. A workflow schema describes a workflow under different perspectives, e.g. functional, informational and operational, using the language of the workflow management system [JB96]. In order to create flexible business processes in the sense that modifications like changes of the process sequence or the insertion or omission of sub processes can be made quickly and efficiently, the component-oriented approach shall be applied on workflow management: Workflow schema parts (so called process components) are assembled to a workflow schema as a complete description of the business process. For further details we refer to similar approaches presented by [MCH03], [Aa99] and [Ac04]. 2.2. Component-based Application Development In the previous chapter, we briefly mentioned how to build flexible processes and control them using workflow technology. If the tasks in a process should be executed by software, the software application has to be as flexible as the processes. Applications built of loosely coupled components offer this flexibility. According to [Ac02], a component “consists of different (software) artefacts. It is reusable, self-contained and marketable, provides services through well-defined interfaces, hides its implementation and can be deployed in configurations unknown at the time of [its] development.” To connect and control loosely coupled components, workflow technology, in particular WfMSs are well-suited following the principle of a strict distinction between control and execution of business processes. If a sub process of a business process is supported or executed by a software component, the WfMS invokes the previously determined software component via its interface, provides it with required input parameters and - if so - receives the results of the execution in order to transfer them to following organisational resources. Binding software components to process components of a WfMS-controlled business process abolishes the restrictions for flexible process design 210 and changes that are related to conventional IT applications. As an additional prerequisite to flexible applications, only the selection of variants of a component but not their modification can be allowed [RR03]. Variants of a component differ slightly in particular characteristics such as functionality or interfaces. If only similar components are available opposed to a perfectly suitable component, these should not be adapted to a special usage in an application. Instead of that, a new variant of the component has to be produced and used in the planned application [GO05]. Software components as well as process components must be specified in an unified way and stored in a component catalogue. A unified specification framework was proposed by [Ac02]. 2.3. Service-oriented Architecture (SoA) There are a lot of definitions of the term software architecture, e.g. [BCK03], [Fo02]. For our purpose we prefer the comprehensive definition of Krafzig, Banke and Slama [KBS05]: “A software architecture is a set of statements that describe software components and assign the functionality of the system to these components. It describes the technical structure, constraints and characteristics of the components and the interfaces between them. The architecture is the blueprint for the system and therefore the implicit high level plan for its construction”. A Service-oriented Architecture (SoA) is a specific software architecture based on services as fundamental elements for integrating and developing applications, e.g. [KBS05], [Pa03], [Ba03]. Services are specific software components. They are welldefined, self-contained and encapsulate high-level business functionality. Services communicate with each other by sending and receiving messages. Services can adopt different roles. When acting as a service provider a service publishes its interfaces that can be invoked by other services that play the role of a service requestor. A SoA is characterised by the loosely coupling of the services involved. This means that services can be replaced by other services at runtime. A SoA supports location transparency. This means that services should have their definitions and location information stored in a repository and be accessible by a variety of clients that could locate and invoke the services irrespective of their location [Pa03]. To enable agile applications and processes a SoA aims at reducing complexity. This is achieved by the loosely coupling of the involved services and the decoupling of the technologies used at provider and requestor sides [KBS05]. As a consequence, a SoA shifts the focus from technical to business requirements. From a business perspective, SoA-based processes and application systems have the potential to achieve significant cost saving due to the reduction of maintenance costs and the fact that a SoA can bee seen as an enabling framework for BPO (Business Process Outsourcing) ([BMS04], [Be05], [SBM04]). However, it is not possible to eliminate technological dependencies at all because an appropriate infrastructure (e.g. enterprise service bus) is still required. Furthermore, standardisation is a key success factor and there are still open issues in this field. 211 Based on the results of a functional business process decomposition as part of an in- depth business process analysis in most cases it is possible to derive process components, which are composed to a complete business process and can be mapped onto software components later on (e.g. services as an integral part of a SoA). Figure 1 shows the result of the decomposition of a generic credit process. The credit process was decomposed into the sub processes “loan request”, “credit assessment”, “servicing” and “workout”. In our example, the sub process “credit assessment” is decomposed again. Results of this decomposition are the sub processes “internal rating”, “external rating” and “decision”, which itself can be decomposed. A further step of decomposition of the sub process “internal rating” leads to the activities “evaluate documents”, “evaluate employment” and “evaluate income”. Process Components: A