195 TMBP: A Transactional Metamodel for Business Process Modeling Based on Organizational Structure Aspects Lucinéia Heloisa Thom1, Cirano Iochpe1, Bernhard Mitschang2 1Institute of Informatics, Federal University of Rio Grande do Su, Av. Bento Gonçalves, 9500, 90610 Porto Alegre, Brazil {lucineia, iochpe}@inf.ufrgs 2Institute for Parallel and Distributed Systems , University of Stuttgart, Universitätstrasse 38, 70569, Stuttgart, Germany Abstract: Business processes executed in organization are automated through a workflow system. Currently, there are several metamodels for business process and workflow process modelling. However, the limitations of these metamodels are twofold: First, the use of organizational structure aspects is limited and second they don’t support business (sub)process patterns based on organizational structure aspects. These limitations may restrict the accuracy, efficiency, and productivity of the workflow project. This paper addresses the Transactional Metamodel of Business Processes (TMBP). TMBP links organizational structure aspects with business (sub)process and makes it feasible to create business (sub)process from the reuse of business (sub)process patterns based on organizational structure aspects. An additional feature of TMBP supports the generation of business subprocess patterns through the Business Process Execution Language for Web Services (BPEL4WS). 1 Introduction Any organization should be modelled according to the business process1 it must perform. Therefore, first the business process must be defined and after this the organization must be modelled to best operate it. To model an organization involves the assignment of values to a set of organizational structural aspects2 (OSA) concerning the business process executed by the organization. Modern organizations have performance demands related at least to both the execution time and resource consumption of their business process. Within this context, the workflow technology has shown to be very effective, mainly in the business process automation. In workflow systems, a business process is automated through a workflow process. A workflow process uses a workflow process metamodel to represent all singularities of a business process needed for its automation. 1 A business process is as a partial order of tasks, where each of these tasks contributes in a stage of the process. A business sub-process is a process integrated to as well as controlled by another business process. 2 E.g., scalar chain, the work coordination mechanism and the decision-making structure [1]. Proceedings of the CAiSE'05 Forum - O. Belo, J. Eder, J. Falcão e Cunha, O. Pastor (Eds.) © Faculdade de Engenharia da Universidade do Porto, Portugal 2005 - ISBN 972-752-078-2 196 Lucineia Heloisa Thom, Cirano Iochpe, Bernhard Mitschang Recently, different consortia including the Business Process Management Initiative (BPMI) as well as the Workflow Management Coalition (WfMC), the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) proposed metamodels for business process and workflow process modelling. However, their submodels for OSA representation show limited power of expression. This fact restricts whole workflow project accuracy since the workflow process may not represent the real business process as it is executed in the organization. The lack of a business process metamodel linking business (sub)process with OSA was one of the major motivations for the development of the Transactional Metamodel of Business Processes (TMBP) proposed in this paper. TMBP is an extension of the Transactional Model of the Workflow Processes – TMWP [2] with support to OSA. It can be employed as a metamodel for business process modelling from the reuse of business (sub)process patterns based on OSA. This should improve not only the quality but also the performance of whole workflow project. The rest of the paper is structured as follow. Section 2 describes TMBP and Section 3 addresses conclusions and research directions. 2 A Transactional Metamdel for Business Process Modelling (TMBP) TMBP is described through the Unified Modelling Language (UML) notation [3]. We opted for UML because it provides a wide range of modelling resources, such as class diagram, use case diagram and activities with actions diagram [4] required to represent all singularities of TMBP. Accordingly, the metamodel is a package composed of five subpackages: PBusinessProcess, POrganizational, PResource, PRouting and PCatalogue (see Figure 1). Transactional Model of Business Process (TMBP) POrganizational PResource PCatalog PBusinessProcess PRouting Fig. 1. Transactional metamodel of business process 2.1 Organizational Package Roles (as illustrates Figure 2) can be differentiated between functional (e.g., to formulate rules; to review and approve documents) and organizational roles (e.g., manager, director, president of a company) [5]. An organizational role is linked with 197 actor (task performer). Additionally, it is associated with organizational unit (e.g., department, division). Nevertheless, it is a generalization of functional role. A functional role is associated with skill (e.g., to know how to program in Java) and competence (e.g., may sign orders > than $ 20.000). An organization is an aggregate of organizational units. Each organizational unit may be related to other organizational units. The cardinality (0,*)- (0,*) in the auto-relationship in the OrganizationalUnit class is feasible, hence it express multi-dimensional organizations (e.g., matrix-structures). Finally, every organizational unit has a set of OSA. Actor Organization StructuralAspect subordinated of 0..* 0.. * 0..* 0..* 0..* OrganizationalRole OrganizationalUnit 0..* 0..* 0..* Competence Functional 0..* 0..* Skill 0..* 0.. * Fig. 2. Organizational package 2.2 Resource Package A resource (see Figure 3) is an artifact required for a task execution. It can be: a tool (e.g., word processor, printer) or an or an item type of some item type (e.g., document). Depending on its type an item can have a more complex structure (class SructuredItemType in Figure 3). In this case it is recursively composed of sub- items ņ e.g., an environment process composed of several documents (sub.itens). Resource Tool ItemType StructuredItemType Fig. 3. Resource package 2.3 Routing Package Routing along particular branches determines which task needs to be performed and in which order. There are several proposals concerning routings between tasks/activities (e.g. [6], [7], [2]). We apply the Wil van der Aalst workflow patterns in the TMBP Routing Workflow patterns [6]. Due to space limitation in this paper we don’t present all UML diagrams concerning the routings proposed by Aalst. A detailed explanation can be found in [8]). 198 Lucineia Heloisa Thom, Cirano Iochpe, Bernhard Mitschang 2.4 Business Process Package In Figure 4 each business process transforms an item type from an initial state into a final state. Transformations may be decomposed in smaller transformations, where each of them corresponds to a change in the item state. When there are no more transformations to be performed, the item reaches its final state and the organization reaches the aim of its business. Each business subprocess can involve several business transactions, hence also several actors. However, the set of organizational structure aspects (obtained through the OrganizationalUnit class) and their values should remain constant in the business subprocess. A business subprocess can involve one or more organizational units if their structural aspects do not vary. Each business subprocess has only one responsible. The abstract class subflow is just a modelling structure. Due to its possible high complexity, a business process can be recursively decomposed in to business subprocess, up to the business transaction level. Under the organization’s point of view, a business transaction is the smallest business process unit of work. Each business transaction is responsible for one of the item transformations. A business transaction can be decomposed in to a partial order of atomic tasks and its whole execution is under the responsibility of a single actor. Nevertheless, a business transaction can receive as inputs several resources to be used in task executions. Additionally, it is a generalization of task. A task is a description of a piece of work that forms one logical step within a process. It can be a simple task or a supertask (a composition of simple tasks). BusinessProcess work item ItemType (from PResource) 0..* 1 Actor Subflow (from POrganizational) 1 responsible 0..* SubProcess BusinessTransaction inputs 0..* 0..* 0..* responsible 0..* Resource OrganizationalUnit (from PResource) (from POrganizational) Task Skill SimpleTaskType (from POrganizational) 0..* 0..* 0..1 0..* Routing 0..1 next SimpleTask SuperTask (fro m PRo uting ) 0..* msg 0..1 0..* previous Manual Automatic Fig. 4. Business process package 199 2.5 Catalogue Package Catalogue package (see Figure 5) describes the classes used by a catalogue manager in the selection of the best design pattern from a catalogue of business suprocess patterns (The patterns are available in [9]), as basis to model a certain business process. The selection concerns the identification of a set of parameters obtained from TMBP, such as: kind of business subprocess, value of OSA (obtained via OrganizationalUnit class and its associated classes) on which this business subprocess depends and kind of work item (ItemType class) used in the business subprocess. Note that the set of parameters may vary according to the kind of business subprocess. After this, a catalogue builder adapts the selected pattern to the specific workflow model being developed. For each business transaction it must include: the work item manipulated, the input resources its internal tasks use, the actor responsible for tasks execution and the partial order among them. requires SubProcess <> (from PBusinessProcess) generates PatternCatalog 0..* responsible requires 0..* <> <> OrganizationalUnit CatalogManager CatalogBuilder (f ro m POrgani za ti ona l) Fig. 5. Catalog package 3 Conclusions and Future Work This paper presented a transactional metamodel for business process modelling based on OSA. With the metamodel we expect to provide a bridge between OSA and business (sub)process, minimizing the complexity of business process modelling and at the same time improving the efficiency and quality of it. Furthermore, through business pattern reuse, we expect to increase the productivity within the workflow modelling process. Due to space limitation, in this this paper we don’t present in details the TMBP methodology for business process modelling. Information about is in [10]. The methodology is composed by tree steps: (1) creation of business process models based on TMBP. The task of this step is the creation of business process models as described in section 2.5. 200 Lucineia Heloisa Thom, Cirano Iochpe, Bernhard Mitschang (2) automatic generation of BPEL4WS processes corresponding to the business process models defined in step 1. Explanation about why we decided by BPEL4WS in favor of other languages as well as an example of a TMBP business process described as BPEL4WS process can be found in [10]. We developed some mapping rules between the business process patterns represented through activity with action diagram from UML and BPEL4WS. This rules are also presented in [10]. (3) execution of BPEL4WS process through workflow engine. This Step is still under research. As future work we consider to extend TMBP with process decomposition aspects in order to better identify to which organizational aspects different parts of the business process are related to. E.g., technology dependent subprocess versus informational subprocess. Additionally, investigate deeper the way patterns should be represented as well as stored, and queried in the pattern catalogue as well as to look for adequate inference engines that can answer queries to the catalogue with minimum human interference. Furthermore, we are looking forward to validate TMBP in real case studies. References 1. Davis, M. R.; Weckler, D. A. A Practical Guide To Organization Design. Boston: Crisp Publications, 1996. 2. Grefen, P.; Pernici, B.; Sànchez, G. Database Support for Workflow Mangement: The WIDE Project. Boston: Kluwer Academic, 1999. 3. Fowler, M.; Scott, K. UML Distilled: a brief guide to the standard object modelling language. 2nd ed. Reading: Addison-Wesley, 2000. 185 p. 4. Object Management Group. UML 2.0 Superstructure Specification. OMG. Final Adopted Especification, Aug. 2003. Available at: . Visited on Oct. 2004. 5. Neumann, Gustaf; Strembeck, Mark. A Scenario-driven Role Engineering Process for Functional RBAC Roles. 2002. Available at: . Visited on Nov. 2004. 6. Aalst, W. van der et al. Et al. Advanced Workflow Patterns. In: International Conference On Cooperative Information Systems, COOPIS, 7., 2000. Proceedings… Berlin: Springer- Verlag, 2000. p. 18-29. (Lecture Notes in Computer Science, v. 1901). 7. Workflow Management Coalition. Terminology &Glossary. Bruxelas, Feb. 1999. 65p. Available at: . Visited on Nov. 2004. 8. Thom, Lucineia H. TMPB: A Transactional Model for Business Processes Modeling With Support To Organizational Structure Aspects. Porto Alegre: PPGC-UFRGS. 2004. (Technical Report). 9. Thom, L.H.; Iochpe, C. identifying Patterns Workflow Design Relying on Organizational structure Aspects. In: International Conference On Enterprise Information Systems, 5., 2003, Angers. 6., 2004. Proceedings… Porto (Portugal): ICEIS, 2004. 10. Thom, Lucineia; Iochpe, Cirano, Mitschang, Bernhard. Improving the Workflow Project Quality Via Business Process Patterns Based on Organizational Structure Aspects. Proc. of the 1st GI Workshop XML4BPM 2005 - XML for Business Process Management at BTW 2005, Karlsruhe Germany, March 2005.