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).
Any organization should be modelled according to the business process 1 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 aspects 2 (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].
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.
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).
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 actor (task performer). Additionally, it is 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.
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 subitems e.g., an environment process composed of several documents (sub.itens).
StructuredItemType ItemType Fig. 3. Resource 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]).
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).
Catalogue package (see 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.
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.
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.