Open S-BPM: Goals and Architecture

Transcription

1 Open S-BPM: Goals and Architecture Albert Fleischmann Werner Schmidt Table of Content 1 Introduction Mission, Vision and Objectives Research and Development Areas Open S-BPM Architecture Architectural Framework Build-Time Architecture Run-Time Architecture Open-S-BPM Work Domains General Remarks Business Layer Application Layer Infrastructure layer Organization Participants Page 1 of 12

2 1 Introduction Subject-oriented business process management (S-BPM) is a new paradigm for business process management. In that paradigm processes are considered as structured communication between the parties involved in a process. Subjects are an abstract representation of the parties involved in a process. Subjects are behavior specifications. Subjects define in which sequence messages are received or sent and internal actions are executed. Subject-oriented process models must be embedded into an organizational and/or technical environment. This means subjects are assigned to actors. Actors execute the behavior defined in the assigned subject. A subject can be a human, a machine, a computer program or a mixture of all. This paradigm has many advantages. Only a few basic types of specification elements are required: Subjects, messages, send, receive and do. Additionally the specification can be put in complete sentences with Subject, Predicate and Object, as everybody is familiar with from natural language. In other words a process is specified by articulating who does what, with what? In order to foster spreading the idea and concept of this new BPM approach and to stimulate research on it we initiated the Open S-BPM project. 2 Mission, Vision and Objectives In our mission we have defined what would be missed if the project did not exist (external view). Mission: The Open S-BPM project aims for establishing a research platform around Subject-oriented Business Process Management. It offers a playground and tool box for researchers, educators and practitioners to (further) develop ideas, concepts and solutions in all areas of S-BPM. Adressees should become familiar with this new business process paradigm. This helps to make organizations more agile. The vision tells about the goal the project participants want to reach with that project in the long run (internal view): Vision: We have established S-BPM as a standard methodology with defined interfaces to combine various tools to enable agile Business Process Management in organizations acting in a highly concurrent world. Based on the mission and vision the following objectives of the Open-S-BPM project should be reached by 2015: Objectives: Change the mindset: From sequence to parallelism Reality: World is a concurrent system. Due to division of work actors need to interact in order to accomplish tasks Problem: Today world is percepted as a sequence of actions Page 2 of 12

3 Change: Make people see the world as it is parallel Create a set of methods and tools which can be combined in order to introduce agile BPM within organizations and across organizations Create an infrastructure to connect different workflow systems based on different philosophies (control flow oriented and communication based systems) 3 Research and Development Areas Reaching the objectives formulated in section 2 requires R&D efforts in various dimensions. Aspects to be worked on include but are not limited to the aspects shown in figure 1. Figure 1: Open S-BPM Research & Development Areas Those future R&D activities can be based on results already available and published in several books and papers. The most significant publications on the core of the methodology so far are listed below. A. Fleischmann, W. Schmidt, C. Stary, S. Obermeier, E. Börger; Subjektorientiertes Prozessmanagement, Hanser Verlag 2011; an English version of this book is going to be published in October 2012 by Springer Verlag A. Fleischmann C. Stary, Whom to talk to? A stakeholder perspective on business process development; Universal Access in the Information Society; International Journal; Springer Verlag ISSN A. Fleischmann, C. Stary, Key Features of Subject-Oriented Modeling and Organizational Deployment Tools, Universal Access in Human-Computer Interaction. Applications and Services, Lecture Notes in Computer Science, Springer Berlin/Heidelberg 2011, pp , Volume 6768 Many researchers, educators and practitioners already used the S-BPM methodology and overall approach for their work. Their experiences and contributions are mainly discussed at the S-BPM ONE conference series and were/are published in the conference proceedings as follows: Page 3 of 12

4 S-BPM ONE 2009, Communications in Computer and Information Science 85, Springer Berlin Heidelberg; S-BPM ONE 2010, Communications in Computer and Information Science 138, Springer Berlin Heidelberg; S-BPM ONE 2011, Communications in Computer and Information Science 213, Springer Berlin Heidelberg; S-BPM ONE 2012, April 4.-5 in Vienna, Proceedings are going to appear in April Open S-BPM Architecture 4.1 Architectural Framework In order to structure the contributions in the Open-S-BPM project we use the ArchiMate language of the Open Group. ArchiMate is a modeling language that offers an integrated architectural approach that describes and visualizes the different architecture domains and their underlying relations and dependencies 1. The language consists of three core concepts: Passive structure elements Behaviour elements Active structure elements These three aspects have been inspired by natural language, where a sentence has a subject, a verb and an object. This means ArchiMate is close to S-BPM. The ArchiMate language defines three main layers, based on specialisations of the core concepts: The business layer offers products and services to external customers, which are realized by business processes performed by actors. The application layer supports the business layer with application services which are realized by applications. The technology layer offers infrastructure services needed to run applications, realized by computer and communication hardware and system software. The core concepts and layers deliver a framework with nine cells. In each of these cells certain architectural aspects can be projected. The following figure shows these nine cells and the positioning of the most important architectural domains. 1 ArchiMate 2.0 Specification, The Open Group, Reading Page 4 of 12

5 Figure 2: Positioning of Architectural Domains in the Framework Based on this general framework for architectural domains the various aspects of the open S-BPM projects are positioned. In BPM there are two super domains: Build-time covers all architectural aspects of defining processes as models Run-time covers all aspects of executing business processes. In the following sections these two super domains are considered in more detail. 4.2 Build-Time Architecture Figure 3 shows the various architectural domains required for the build-time of processes. Figure 3: Build-time Architectural Domains In the business layer we do have the following domains: The process models which have to be created or modified. The model descriptions are the data on which the activities defined in the behaviour column are performed. The behaviour cell in the business layer contains the specification of the processes used to define processes (Business Process Management). Questions to be answered here are: Which process roles are required? What are the tasks and in which sequence are the tasks performed in order to define and to implement a business process? Page 5 of 12

6 The active structure in the business layer defines the organizational roles in the business process management. Major question is which general roles are required in business process management e.g. process owner, subject owner. In the application layer the following domains support the business layer domains: In a repository process models are stored. During modeling activities existing processes or parts of them can be inserted in a new process. Different versions of process models can be retrieved and other functions which make it easier to manage complex process systems are provided. There must be a set of tools which makes it easy to describe and to implement processes. There must be also ways to evaluate whether a process model meets the requirements or the intentions for handling a business event. There should be tools which allow creating rapid prototypes in order to test process models. Tools must allow enhancing process models step by step until a productive workflow has been created. Processes for creating processes help to structure BPM work and tools ease up accomplishing BPM tasks, but at the end of the day work must be done by people. This means that an organizations must be established, which executes the processes for creating processes. For all the applications a corresponding infrastructure is required. This infrastructure, described on the technology layer, can be based on conventional communication and computer systems or on a cloud infrastructure. The type of preferred infrastructure significantly influences which technologies should be used for implementing applications. 4.3 Run-Time Architecture After creating a process model and its embedding into the corresponding organizational and IT environment an executable workflow is available. Process instances are created and executed. Figure 4 depicts the architectural domains for this run-time environment. Figure 4: Run-time Architectural Domains In the business layer the following domains must be covered: Process instances and the related business objects which represent the handling of the corresponding business event A company consists of a complex network of processes. In a global economy process networks cross the boundaries of companies Page 6 of 12

7 Instances of business processes are executed in a certain organizational environment and use corresponding software applications e.g. SAP modules. In the application layer the following domains support the business layer domain: The information about process instances is stored in databases. Because processes are executed across company borders information about the status of a process instance can be distributed over several databases. In a global world processes cross company borders. Business partners often use different workflow systems, which means that federations of workflow systems must be supported. This is a major aspect to be considered in the Open-S-BPM project (see section 6.4.). People involved in a process instance must have the necessary rights for using the workflow system and the incorporated software applications. For all the applications a corresponding infrastructure is required. This infrastructure, described on the technology layer, can be based on conventional communication and computer systems or on a cloud infrastructure. The type of preferred infrastructure significantly influences which technologies should be used for implementing applications. If a process crosses the boundaries of companies then also the technology may change. This means that in a single process different technologies may be used. 5 Open-S-BPM Work Domains 5.1 General Remarks In the following sections several work domains in the Open S-BPM project are described. At this point of time these descriptions still remain rough and incomplete 2, and the list of work domains itself is not complete too. There is room for new ideas which can be added during project progress. Further on it is not predefined which people or institutions can take care of which aspect. 5.2 Business Layer The build-time business layer is essential for business process management. For the success of business processes there must be clearly defined ways in which steps business processes are defined, validated and implemented. The following figure shows a framework for such business process management processes. In this framework six activity bundles are identified. During the creation of processes activities in each bundle are executed. The various bundles can be executed in any reasonable sequence, depending on the process status. Based on this framework some more precise process management processes can be derived. 2 There is only one aspect which we describe a little more detailed (see section 5.4) Page 7 of 12

8 List of open issues on the business layer: Figure 5: Build/Design Process for Processes Consulting methodology based on the Business Process Management framework Change management concepts for introducing S-BPM 5.3 Application Layer Figure 6 gives an overview of the possible application components which can (should) be developed in the open S-BPM project. Figure 6: S-BPM Tools for Build/Design and Execution Time Page 8 of 12

9 Analysis and Optimization o Tools to support analysis of qualitative process data (goals, risks etc.) o Tools to analyze data collected during execution (see there) o Tools to simulate process execution with numerous instances (efficiency) o Calculation of required resources in order to meet constraints (time, cost) o Avoid bottlenecks, find sunshine paths o. Modeling o Specification in the large Hierarchical process networks Meshed process networks. o Specification in the small Subject interaction diagram and subject behavior diagram Modeling by restriction Subject phase matrix Modeling table Modeling game.. o o Tools to describe business objects Structure, elements, views, layouts o Validation o Tools for static evaluation of process models (e.g. dead locks) o Tools for dynamic evaluation: Checking whether a process model meets the functional requirements (effectivity) o Execute the model in a IT-supported role play o Embodying o Integrate user and organization data to use them in execution and simulation IT-Integration o Application Integration Integration of applications and services (backend and frontend), called during execution Wrapping of existing applications with a service subject o. Execution o Workflow Engine Interprets model data at runtime and controls the processing of process instances Based on Abstract State Machines o Application Embedded Execution Executable code is derived from a process model. This code can be embedded in an application Page 9 of 12

10 o Workflow engine embodiment in Enterprise infrastructures (e.g. jbpm). Monitoring o Collecting execution data (instance data) in order to investigate an existing process (see Analysis & Optimization): o Periodic offline analysis o Real time analysis with Complex Event Processing o Preparing and delivering management information (alerts, ad hoc and periodic reports) Infrastructure o Cloud-based operation o Mixed use of components: Cloud and non-cloud o Impact on the component integration o Process and business object templates in the cloud o Combination of S-BPM and Business by Design o Mobile Devices o 5.4 Infrastructure layer In a global economy with a complex division of work processes cross company borders and connect business partners with each other. Often times each partner uses its own workflow system. As a consequence there must be ways to connect processes and workflow systems of different organizations. Process interfaces between must cover static (structure of exchanged data) and dynamic aspects (communication sequences). A first proposal for solving that problem has been developed under the name of jcpex! in the Theseus research project sponsored by the German government. Figure 7 depicts the basic concept of how jcpex! connects heterogenous networks of workflow systems with a so-called behavioural interface. Figure 7: Behavioural Interface to connect heterogenous Workflow Systems Page 10 of 12

11 6 Organization The Open S-BPM project is initiated by the Institute of Innovative Process Management e.v. (I2PM) The Open S-BPM project is organized in a subject-oriented way: The related parties communicate with each other. This communication is maintained by the project initiator and a steering committee as facilitators. The owner of a project describes his/her project in a summary: Content and interfaces to other projects. The owners of projects with interfaces to other components/projects communicate with each other defining their technical interfaces. The steering board releases technical interfaces specifications. Figure 8: Communication of Open S-BPM Participants 7 Participants Currently following parties intend to participate in the Open S-BPM project: TU Darmstadt: Static process validation University of Applied Sciences Deggendorf: New type of editor: Subject Phase Matrix University of Linz: Editor for process design combined with modeling table Page 11 of 12

12 Workflow engine based on the ASM specification KIT Karlsruhe Extending modeling concepts: Layered Behaviour University of Applied Sciences Ingolstadt Subject-oriented business controlling Page 12 of 12