Modelling planning processes with TALMOD
The Agent Lab Modelling Language to enable the analysis, redesign and improvement of and
the development of agent-based simulation and support systems for complex business processes
Master thesis Technology Management (TBW) University of Groningen, The Netherlands Faculty of Management and Organization
Specialization: Information Technology / ‘extra 5th year’
September 2004 – June 2005
Student: Cees de Snoo StudentNo: 1152785
Supervisors: dr. N.B. Szirbik
drs. S. Sibum
dr. W.M.C. van Wezel prof.dr.ir. J.C. Wortmann
Research group: The Agent Laboratory – University of Groningen
All rights reserved. No part of this thesis may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the author.
The human mind plans the way, but the LORD directs the steps.
Bible, Proverbs 16: 9.
PREFACE
A well-known Chinese proverb goes: ‘a picture says more than thousand words.’ Over all centuries, people have tried to express themselves with the help of all kinds of figures, diagrams, models, et cetera.
In business, many modellers are still busy to investigate appropriate ways to represent and depict complex phenomena from reality.
In this thesis a ‘new’ modelling tool to model complex business processes is proposed and explained: The Agent Lab Modelling Language (TALMOD). I immediately want to admit that this language is one of hundreds, probably thousands attempts to get grip on these processes that are often difficult to understand, to represent and to manage. TALMOD has its own advantages and disadvantages, strengths and weaknesses. Nevertheless, I wish that TALMOD will be useful for many people, especially for business analysts and information system developers.
I am convinced that humans will never be able to represent, understand and manage all business process aspects completely. Human beings form namely a crucial part of these processes. Humans perform activities while playing different roles. Interactions between these roles and humans are very complicated, I experienced. Human behaviour is too complex and versatile to be fully understood, represented and predicted. The ambition and goals of modellers should be directed in another way.
I hope this thesis, and TALMOD in particular, will show the uniqueness of humans and their behaviour, and the complexity and difficulty to represent this behaviour.
With this thesis I round off my graduate project at The Agent Laboratory, University of Groningen. I would like to thank the lab members Michael Heemskerk, Gijs Roest, Nick Szirbik and also Boyana Petkova for their support, the sociable environment, competitive ping-pong contests, nice lunches, et cetera. I thank my supervisors Nick Szirbik, Simon Sibum and Wout van Wezel for their stimulating criticisms during the project. I thank Hans Wortmann for the opportunity to do this project. Thanks to many others which have been, consciously or unconsciously, be of importance to fulfil this project.
Finally, I would like to thank God, my Lord. Being totally dependent on Him, I have been able to do this project: He always provided me with all I needed. He directed my steps and He will do that for ever.
Cees de Snoo
Groningen, June 27, 2005
Some guidelines for the reader
The main part of this thesis exists of an article that, in a reviewed form, will be submitted for publication in the international journal Information systems. This article shortly describes the main reasons to develop an agent-oriented modelling language for the representation of complex business processes. It also introduces the research at The Agent Laboratory and the main aspects of the modelling language TALMOD.
Several appendixes are attached, which can be seen as separate documents that explain TALMOD in a further way. A manual ‘Modelling with TALMOD’ and several examples are given in appendixes 1 and 2.
The third appendix elaborates some special difficulties regarding business process modelling. Appendix 4 gives a comparison between TALMOD and some other famous modelling languages. We also apply some modelling frameworks on TALMOD. A bibliography can be found in appendix 5. Appendix 6 exists of a glossary that can be helpful during the study of other parts of this thesis.
THESIS ARTICLE
Modelling business processes with TALMOD
Cees de Snoo
Faculty of Management and Organization, University of Groningen P.O. Box 800, 9700 AV Groningen, The Netherlands
c.de.snoo@rug.nl
Abstract
Due to the complex and dynamic nature of organizations, carefully developed models are necessary for business analysis and for the design of correct business support tools.
Currently, both information system oriented and business process oriented modelling languages are available to easy the modelling project. Unfortunately, only a few attempts to merge both schools exist, like the business extensions of UML and YAWL. However, these languages do not sufficiently take into account the importance of agents, roles and interactions. Interactions are temporarily ordered sets of activities perceived and performed by agents in a process. Agents are actors that play one or more roles, and will often have a lack of process knowledge and conflicting process views.
In this article, we give a brief overview of recent trends in business process modelling as well as information system development. We introduce the research at The Agent Laboratory and present a new agent oriented modelling language, TALMOD, which is able to support business analysis, redesign and simulation as well as the development of agent-based software systems. TALMOD is an extension to and a ‘union’ of two existing modelling languages: UML and Petri nets.
Key words: Modelling, business analysis, agent-theory, UML, Petri nets, TALMOD
1. Introduction
Loosely coupled business processes within and between organizations, flexibility, mass customization, outsourcing, and overall IT-support are some of the main characteristics of today’s enterprises. Supply chain management is the relatively new term that is used to describe models and methods to manage such current business dynamics, especially focusing on the interactions between different departments and enterprises (Stadler, 2002). As a consequence of these features, humans in organizations increasingly rely on software systems for everyday activities. However, modern software systems exhibit characteristics that make them very different from the software systems to which we are accustomed (Zambonelli, 2003). Today’s software systems become more and more pro-active, pushing the activities in the organization’s business processes. The shift from workflow management systems to business process management systems (Van der Aalst, 2004a) and the rapid advance of agent oriented software
systems (Odell, 2005a; Giorgini, 2004) can be seen as the most obvious examples of this tendency. In addition, the increasing informational visibility, for instance brought by ERP systems, is changing organizational control and the way people collaborate in and between organizations. Ultimately, these trends change the behaviour of people, and also the structure and dynamics of organizations. Unfortunately, these aspects are not yet properly investigated (Szirbik, 2005).
The Agent Laboratory at the University of Groningen researches these issues from a multi- disciplinary point of view. One of the first projects contains the development of an agent oriented modelling language, based on existing languages like UML and Petri nets, that is able to support business analysis, redesign and simulation as well as the development of agent-based software systems. Our background motives and ideas, as well as our modelling approach and the modelling language TALMOD itself are extensively described in this paper.
We first shortly present some reasons and methods for business or enterprise modelling (section 2). Recent trends in business modelling and information system development are discussed in section 3 respectively section 4. These sections encompass also a brief description of UML and Petri nets. We use these languages to develop a ‘joined’ extension to them, called The Agent Lab modelling language (TALMOD). The need of a merge between business process and information systems modelling is explained in section 5. Some other attempts to realize this via extended and new modelling languages are presented together with a brief overview of some main shortcomings of these tries in section 6.
TALMOD is introduced in section 7 and is described in detail in the sections 8 to 10. Each of the four kinds of diagrams to model complex, distributed business processes is explained: the agent- role diagram, role-interaction diagram, static structure diagram and the process or ‘local behaviour description’ diagrams. Finally, an overview about the strengths and weaknesses of the current version of TALMOD is given in section 11. We end with a conclusion.
2. Enterprise modelling
Due to the complex and dynamic nature of organizations, carefully developed models are necessary for the understanding and analysis of their behaviour and for the design of new support tools (Giaglis, 2001). A model is an abstract representation of reality that excludes much of the world’s infinite detail. The purpose of a model is to reduce the complexity of understanding a phenomenon by eliminating the detail that does not influence its relevant behaviour. Selecting bounds for the phenomena to be modelled depends on the uses to which the model will be put (Curtis, 1992). Therefore, a model highlights certain aspects of the phenomenon being described, and it disguises other aspects (Kusters, 2005). Models enable to filter out the irrelevant complexities of the real world, so that efforts can be directed toward the most important parts of the system under study (Vernadat, 1996).
Shortly, a model reveals what its designer believes is important in understanding and treating the phenomena modelled (Curtis, 1992). This finality, i.e. the goal of the modeller, has a direct influence on the modelling method definition (Vernadat, 1996).
Modelling has always been at the core of both business process analysis and information systems development (Giaglis, 2001). Management and computer science researchers are interested in improving the understanding of organizations and their processes, facilitating process analysis
and design and supporting process management. The topic is also of great practical importance to industry as an aid to design organizational structures, processes and IT infrastructure that achieve business goals in an efficient and flexible way (Koubarakis, 2002). Furthermore, models can be used as a communicative tool for human actors playing different roles in the business processes (Kusters, 2005; White, 2004; Dietz, 2003; Eriksson, 2000). The design of a model can be also instructive in itself: a by-product of the modelling exercise is that it often quickly reveals anomalies, inconsistencies, inefficiencies and opportunities for improvement (Koubarakis, 2002).
The field of modelling businesses and organizations is also called enterprise modelling (Kusters, 2005; Eriksson, 2000; Marshall, 2000; Vernadat, 1996). The objective of enterprise modelling is not to fully describe all aspects of an enterprise. This would be useless, nearly impossible, and certainly endless. Moreover, during the enterprise modelling exercise, one has to keep in mind the inherent complexity and dynamic nature of the enterprise, and make sure that once the model has been obtained, it is still a valid representation of the current reality because things modelled first might have changed in the meantime (Vernadat, 1996).
Some of the main motivations for enterprise modelling are:
• managing system complexity,
• enhance the understanding of the way in which a business is organized,
• enabling regular management activities, i.e. monitoring, control and planning, but also change management,
• capitalization of enterprise knowledge and know-how, and last but not least
• design, implementation, use and continuous improvement of information systems (Kusters, 2005; Vernadat, 1996).
Vernadat (1996) defines an enterprise model as “a consistent set of special purpose and complementary models describing various facets of an enterprise to satisfy some purpose of some business users.” This definition emphasizes several points:
• an enterprise model serves a goal for a business user,
• an enterprise model may be composed of sub models,
• the sub models have special purposes, and
• the set of models should be consistent (Kusters, 2005).
We should keep these criteria in mind when we define our modelling language TALMOD (sections 7 to 10) and come back to these points in section 11.
A wide range of model types exists that can be used to describe aspects of an enterprise. We can for instance mention descriptive, formal, programming and analytical models, each having their own purposes and own requirements regarding to the preciseness of their syntax and semantics.
Furthermore, modellers differ on how they intend their models to be. Take for example business processes into consideration. Prescriptive modelling implies the process should be performed in a particular way. Descriptive modelling attempts to determine the actual processes used to get work done in an organization. A third perspective is offered by proscriptive models, which delineate behaviour that is not allowed (Curtis, 1992).
TALMOD can be characterized as a modelling language that enables the development of descriptive, analytical models. The initial focus is on the representation of the current business situation. After analysis, redesign can be done by creating more formal and prescriptive models.
Vernadat (1996) provides us with a graphical representation of the basic steps in the enterprise modelling process (fig. 1). The feedback loop to business process engineering via continuous improvement is emphasized, suggesting that, as we already noted, the enterprise modelling process is a never-ending process. Several steps will be discussed in coming sections.
Figure 1. Basics steps of the enterprise modelling process (Vernadat, 1996: 86).
Finally, Kusters and Wortmann (2005) make some useful remarks about conflicting goals regarding enterprise modelling. As we already stated, the requirements for enterprise models depend on the purpose of the model. However, consider properties such as simplicity and completeness. Most people would agree that models should be as simple as possible. Similarly, many people would agree that a good model should be complete, i.e. cover as many as possible aspects and situations of reality. Unfortunately, if a model becomes richer and more complete, it usually becomes less simple and transparent.
More important is the criticism that enterprise models are often too detailed for the intended purpose. Engineers tend to think that more details can always be added, which, however, is often leading to information overload for business analysts. Business analysts the other way around tend to think that alternatives and exceptions can be neglected in the models, although in information systems design the thing that matters most is exactly that of handling exceptions (Kusters, 2005). We come back to these issues in section 11 where we also discuss the interrelated term coherence, as defined by Szirbik and Wagner (2001).
3. Business process and workflow modelling
Enterprise modelling is driven by business process modelling (Vernadat, 1996). Business processes represent the flow of control of things happening in the enterprise. They show up in management policies, operating and administrative procedures, manufacturing processes, flows of documents, and the like. The modelling of business processes often starts with capturing high- level activities and then drilling down to lower levels of detail within separate diagrams (White, 2004).
Business process modelling is studied now more than a decade ago, and a variety of products are available to support this, based on different process languages (Weske, 2004). It is stated that the absence of a universal organizational ‘theory’ and accompanying standard business process modelling concepts explains and even justifies the major differences in business process modelling languages (Van der Aalst, 2005). Lim et al. (1997) distinguish five orientations or approaches to which the modelling of business processes can be designated:
1. Activity oriented approach – representing the main activities and the relationships between activities and entities as well as resources that are required to perform these activities.
2. Agent oriented approach – especially useful when the interactions between human actors and human-machine actors are to be modelled.
3. Resource oriented approach – representing the logistic behaviour of individual work centres.
4. Goal oriented approach – based on the idea that each business process needs to attain a certain business goal.
5. Organization oriented approach – defining the enterprise structure roughly from a management point of view.
Most modelling languages are a product of a combination of these approaches. However, an explicit and so-called interaction oriented approach does not exist, although the agent oriented approach approximates it the best. In our research, we use an interaction oriented approach with an emphasis on agents and roles. We want to figure out if an interaction can be viewed as a stand- alone, independent object abstracted and separated from the agents and roles involved in this interaction. Such an object should be suitable for analysis, reuse and probably automation.
Section 3.1 contains some more arguments for an interaction oriented approach.
Our modelling language is strongly based on existing theory about business process and workflow modelling. Therefore, in this section we successively discuss process modelling, workflow modelling as a specialization of process modelling, and business process management as an extension of workflow management. Next, we shortly introduce the Petri net modelling language. This section is ended with a short discussion about current needs and shortcomings in business process modelling. As a kind of solution, we briefly introduce the agent oriented business process modelling approach.
3.1. Process modelling
Process modelling languages and representations usually should present one or more different perspectives. Lim et al. (1997) mention the next perspectives (they call them ‘conditions’ that business process models should meet):
• Functional – ‘what’ has to be done.
• Behavioural – ‘when’ something has to be done.
• Informational – what are the ‘informational entities used/produced’.
• Organizational – ‘who’ (which agents) has to do something.
• Operational – ‘how’ is something achieved.
• Interaction – how are members ‘informed about work’ (Lim, 1997; Kusters, 2005; Curtis, 1992).
Compared with the five business process modelling approaches mentioned earlier in this section, we see some overlapping. For instance, a modelling language having an agent oriented approach will pay most attention to the organizational perspective.
The sixth perspective is called ‘interaction’, suggesting that a process modelling language should take communication, interaction and negotiation aspects between actors, either human or artificial, into account. We agree with that and propose an even stronger emphasis on this condition. It has not only to do with ‘information about work’ but more fundamentally with communication, negotiation, collaboration, cooperation and coordination. Although many business processes are automated and supported by artificial systems, humans are still important and indispensable.
Because of the specialized skills of human actors, they are more and more dependent on each other. Well-functioning interaction processes therefore are of great importance for a business. It is this conviction that brings us to argue for an interaction and agent oriented approach to business process modelling (see also De Snoo, 2005).
Anyhow, in short, a good process model should allow representation of “what is going to be done, who is going to do it, when and where it will be done, how and why it will be done, and who is dependent on its being done” (Curtis, 1992).
Although there is not widespread consensus on the constructs that collectively form the essential basis of a process model, the following list includes the most frequently mentioned (based on:
Kusters, 2005; Dietz, 2003; Eriksson, 2000; Lim, 1997; Curtis, 1992).
• Agent – an actor (human or machine) who executes activities.
• Role – a coherent set of process elements to be assigned to an agent as a unit of functional responsibility.
• Activity – the primary building blocks of a process, being an embodiment of work to be done.
• Flow – a link between activities mutually and between an activity and an ‘external’
process.
• Artefact – a product created or modified by the enactment of a process element.
• Resource – a source used in the process (physical, abstract or informational).
• Goal – a purpose of the process, or the outcome the process is trying to achieve.
• Rule – a statement that define or constrain some aspect of the process.
It is interesting to note that Curtis already in 1992 elaborates about the important issue of agents and roles.
“A single agent can perform multiple roles (e.g., designer, reviewer, coder), and a single role may be performed by multiple agents. A process can now be further elaborated as one or more agents acting in defined roles to enact the process steps (i.e. activities). Typically, process steps either manipulate an artefact or coordinate dependencies with other agents involved in the same or a related process. Consequently, process steps should be planned as part of a defined process, assigned to a role, allocated resources, and monitored” (Curtis, 1992).
We adopted this view on process modelling as a basis for our modelling language, but we call the process steps ‘activities’.
3.2. Workflow modelling and Business Process Management
Business processes that are executed regularly, that have few foreseeable exceptions and that can be easily represented and implemented as a fixed order of activities can be modelled as a workflow (Van der Aalst, 2005; Georgakopoulos, 1995). The Workflow Management Coalition (WfMC) defines a workflow as: ‘the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules’ (WfMC, 1999). In this definition, it is emphasized that the artefacts are passed from and to participants, thus multiple agents. However, a workflow description can also be used to represent a sequence of activities executed by a single agent.
In the last decades, workflow management systems have become a popular tool to support and automate some business processes (Fischer, 2005; Liu, 2003). A workflow management system is a generic software tool that allows for the definition, execution, registration, and control of business processes or workflows (Van der Aalst, 2004c). At the moment, many vendors are offering a workflow management system. This shows that the software industry recognizes the potential of workflow management tools (Verbeek, 2004).
We need to describe some characteristics of workflows and workflow modelling, because our research follows some guidelines from this field.
The fundamental property of a workflow process is that it is case-based (Verbeek, 2004). This means that every piece of work is executed for a specific case, also called a workflow instance.
Examples of cases are an insurance claim, a tax declaration, a customer complaint, an order, and the design of a production plan (Van der Aalst, 2004c).
A typical example of a process that is not case-based, and hence not a workflow process, is a production process such as the assembly of bicycles. The task of putting a tire on a wheel is (generally) independent of the specific bicycle for which the wheel will be used. Note that the production of bicycles to order can be considered as a workflow process (Verbeek, 2004).
Today’s workflow processes become more and more complex, especially because they often span more than one organization (inter-organizational workflow processes). If the part of the workflow process in one organization fails, then it might have a serious effects on the other organizations involved (Verbeek, 2004).
This risk of current workflow management systems calls for a shift in the approach to business processes. This shift has been recognized in the advance of business process management tools.
Business Process Management (BPM) includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes (BPMI, 2005).
BPM can be considered as an extension of classical workflow management systems and approaches. Many people consider business process management to be the ‘next step’ after the workflow wave of the 1990s (Van der Aalst, 2004a).
In comparison to workflow management, business process management also focuses on diagnosis, flexibility, goal driven process design, and human-centric processes (Weske, 2004). However, also BPM tools cannot deal with non-predefined business processes, unpredictable interactions and completely independent and autonomous participants (agents) having each their own, local view on the process. Therefore, our research at TAL does not have in mind to reinvent a new workflow management system. On the contrary, the ‘stringent’ process view developed in the workflow research community should be extended to a more flexible, agent oriented direction.
To explain the advantages of modelling processes like workflows, we will describe a modelling language that is perfectly suitable for modelling workflows: the almost half a century old Petri net notation. According to Salimifard and Wright (2001) several modelling techniques can be applied to workflow modelling, but Petri nets are the only formal technique suitable to be used for both structural modelling and a wide range of qualitative and quantitative analysis.
3.3. Petri nets
Petri nets are graphical and mathematical modelling tools developed to represent and analyze the behaviour of concurrent and parallel processes and systems. Petri nets were first proposed in Carl Adam Petri’s doctoral dissertation in 1962 for the analysis of concurrent computer systems, and have been applied since then to a wide range of problems (Liu 2002, Salimifard, 2001).
Petri nets are based on a very simple, abstract representation of a process in terms of a bipartite directed graph made of two types of nodes, respectively called places (represented by a circle) and transitions (represented by vertical bars) and connected by directed arcs. The progress of the process, i.e. the behaviour of the system, is modelled by tokens (i.e. marks) flowing from place to place via the firing of transitions. When a transition is fired, it consumes tokens in its input places and produces tokens in its output places. Each transition is connected with at least one input place and one output place. The state of the process is defined by the marking of places, i.e. the number of tokens in each place (Van der Aalst, 2004c; Vernadat, 1996).
The popularity of Petri nets for the analysis and design of complex dynamic processes and systems can be explained by its advantages: the ability to model systems graphically, the clear representation of conflicts, parallelism and synchronization, and the ability to model qualitative as well as quantitative properties (Vernadat, 1996). The graphical nature of Petri nets makes them self-documenting and a powerful design tool, which facilitates visual communication between several people. On the other hand, Petri nets are based on a strong mathematical formalism, which makes it possible to set up mathematical models describing the behaviour of the system.
Moreover, validation of a Petri net model can be carried out using Petri net analysis techniques (Salimifard, 2001).
Coloured Petri nets (CPNs) are one of the most well-known classes of high-level Petri nets developed to overcome some problems to use basic Petri nets for enterprise modelling (Liu, 2002;
Giaglis, 2001). CPNs can be used to model business processes of an enterprise: tokens represent objects (data and/or materials), each one being characterized by its data type (i.e. its colour), and transitions represent processes or activities. The algorithm of an activity can be modelled as a procedure attached to the transition. A logical predicate can be specified on some transitions for the modelling of conditions constraining the execution of an activity (Vernadat, 1996).
While modelling with Petri nets is common, the idea of programming with Petri nets has not been widely accepted yet. However, especially when it comes to concurrent and distributed processes, e.g. multi-agent systems, the advantages of Petri nets are obvious (Cabac, 2005).
Cabac et al. (2005) uses Petri nets to model interaction protocols between different agents. We propose to use elements of the Petri net notation (symbols and partly semantics) to easy the modelling of processes. Particularly the simple ‘agreement’ of alternation between transition (i.e.
activity in UML) and place (i.e. ‘wait state’ in UML) will be important. This main feature has
been neglected in YAWL (Van der Aalst, 2005), one of the newest workflow modelling languages (see also section 6.4).
3.4. Discussion: an agent oriented alternative
Workflow modelling as well as BPM lack some important notions regarding the modelling of the behaviour of processes. Less attention is paid to the agent or actor perspective. A clear representation of agents and roles involved in the process is missing. In addition, the discussed business process modelling approaches assumes (nearly) full acquaintance with the processes, i.e.
a full understanding of the activities, the sequence of them, the division of tasks over actors and/or roles, the interaction protocols, etc. However, processes are fundamentally not knowable in detail, beforehand as well as during the process execution. Furthermore, people have several and often mutually exclusive views on the same process. There are also hidden agendas, hidden goals, and hidden activities, conscious as well as unconscious. By the way, many similar activities performed by human actors will be nonetheless executed in different ways. A planner creating a production schedule can start with the assignment of employees while a colleague creating the same plan can prefer to start with the division of orders to the machines. It is questionable if it really makes sense to model all such kinds of little differences and alternatives during the process modelling exercise.
In conclusion, if business process modelling only enables the modelling of standard, beforehand and for everyone knowable, and ‘automatable’ activities, its impact and usability will be very limited. Therefore, the modelling language and also the accompanying process simulation and support software should contain elements to model these important aspects.
A good alternative to deal with current business process modelling requirements can be found in the multiagent theory that is founded in the science discipline of artificial intelligence.
The agent approach enables the modelling and support of a slightly known process, conflicting process views and complex actor interactions. All participating active entities are agents. The interaction patterns between the various agents in the system do not have to be described completely or beforehand. In an agent based system, each agent has a given behaviour and the overall agent community will achieve its goals via the concerted actions of the agents (Szirbik, 2001; Szirbik, 2005). Because of the many advantages of this agent approach, we developed a modelling language based on existing workflow modelling languages that takes the just mentioned issues into account. Our agent based modelling language, however, is also based on the object-oriented modelling approach, which will be discussed now.
4. Information systems modelling and UML
Many differences can be pointed between the characteristics of the first computer applications and present-day applications, even refrained from the differences with respect to software design development, improvement, and impact (Zambonelli, 2003; Iivari, 2000; Iivari, 1998). Since the 1980s, the object-orientation concept has been evolved from both a programming language and an analysis (modelling) perspective. Compared to the more traditional, function-oriented software engineering approaches a number of advantages of the object-oriented approach are stated. First,
Secondly, the focus on structuring the problem rather than solving it with any particular solution and the smoother transition from requirements analysis to design to code are mentioned. Other advantages would be the more flexible systems that are easier to adapt and change, and the promotion of reusability (Van Vliet, 2000).
The object-oriented approach is a very powerful and universal modelling tool, although it is based on only one modelling construct: the object. Objects are uniquely identified, have a state and behaviour. They represent abstract or concrete things. The main characteristic of the approach is encapsulation: joining function modelling and information modelling into one unified paradigm. The whole model is defined as a set of communicating objects (Vernadat, 1996).
In terms of business modelling, the main advantages of the object-oriented approach are property inheritance mechanisms and reusability of models and model constructs. However, the object- oriented approach is originally not meant to model businesses and processes. As Vernadat says:
“the object-oriented approach emphasizes the concept of object while enterprise modelling emphasizes the concept of process” (Vernadat, 1996). Also other familiar concepts for business users such as goals, products, and resources are not present in the object-oriented paradigm and must therefore be defined as specific object classes (Eriksson, 2000; Marshall, 2000).
4.1. UML
Since its introduction in January 1997 by the three amigos Grady Booch, James Rumbaugh and Ivar Jacobson, the Unified Modelling Language (UML) has quickly become the standard modelling language for object-oriented software development (Roques, 2004; Fowler 2004).
UML is a language for specifying, constructing, visualizing, and documenting the artefacts of a software-intensive system (OMG, 2003). According to the official introduction of UML on OMG’s website, UML defines twelve types of diagrams, divided into three categories: four diagram types represent static application structure; five represent different aspects of dynamic behaviour; and three represent ways you can organize and manage your application modules (Siegel, 2005):
• structural diagrams – class diagram, object diagram, component diagram, and deployment diagram.
• behaviour diagrams – use case diagram, sequence diagram, collaboration diagram, activity diagram, and state chart diagram.
• model management diagrams – packages, subsystems, and models (OMG, 2005).
Some of the UML diagrams are explicitly intended for modelling business processes also, from which the activity diagrams form the most important one (Dumas, 2001).
UML is currently being upgraded to a new major version, namely UML 2.0. Being a multi- purpose language, UML 2.0 offers a variety of notations for capturing different aspects of software structure and behaviour (Wohed, 2005). Because the UML 2.0 specification is not ready at the moment, we cannot summarize and evaluate the most modern UML’s possibilities to model business processes. Therefore, we base our judgement about modelling business processes with UML chiefly on two trials to model businesses with UML 1.x, proposed by Eriksson and Penker (2000) respectively Marshall (2000).
The model management diagrams are in literature often left out, for example in the official description of the latest official version of UML (1.5) (OMG, 2005; OMG, 2003). The component and deployment diagram are seldom used in business modelling, so we still have seven diagrams. Eriksson and Penker (2000) give the following description of them:
• Class diagram – describes the structure of a system. The structure is built from classes and relationships, such as associations, aggregations, and generalizations. Classes can represent and structure information, products, documents, or organizations.
• Object diagram – expresses possible object combinations of a specific class diagram.
• Statechart diagram – expresses possible states of a class (or a system) and shows also what triggers the change from one state to another.
• Activity diagram – describes activities and actions taking place in a system.
• Sequence diagram – shows one or several sequences of messages sent among a set of objects.
• Collaboration diagram – describes a complete collaboration among a set of objects.
• Use-case diagram – illustrates the relationships between use cases. Each use case, typically defined in plain text, describes a part of the total system functionality.
4.2. Business modelling with UML
Eriksson and Penker (2000) mention some reasons to use object-oriented techniques to describe a business. They call the next advantages:
• Similar concepts. A business can be described in terms of processes that achieve goals by collaborating with different types of resource objects. Rules define conditions and constraints as to how the processes and resources may relate to each other and how they may behave.
• Well-proven established techniques. Object-oriented modelling and programming has proven that it can handle large and complex systems. A number of patterns are available for modelling businesses.
• Standard notation. Business modelling methods and techniques are in need of a standard notation. The tools are already there (viz. UML), and these tools can be adapted and used to describe the business models.
• Short learning curve. Using object-oriented techniques and notation will decrease the gap between the business modellers and information system modellers and architects.
• New and easier way to view an organization. The traditional way of describing and viewing an organization does not show much of how the business is performed. Object- oriented techniques can easily show modern business processes, as well as the traditional organizational structure.
The Eriksson and Penker-extension to UML has been called by Scott W. Ambler a ‘marriage between proven business modelling concepts and the techniques of the UML’ (Eriksson, 2000).
However, probably the major disadvantage to UML is its size and complexity. Many model constructs, each having its own semantics, notation, and usage rules leads to an enormous barrier that business modellers have to take before they can become familiar with this modelling language. Moreover, the number of diagrams and the focus on system development instead of giving the opportunity to analysis and model a business without implicitly taking always into
account any system, makes this language in our opinion unsuitable for and little accepted by the business modelling community. Although some efforts are taken to combine UML and workflow modelling languages, no real breakthrough has been realised until now (Wohed, 2005; Eshuis, 2003; Dumas, 2001).
We will not evaluate several business extensions to UML (see e.g., Marshall, 2000; Eriksson, 2000) and compare them with our language TALMOD in detail here; we will elaborate on this issue in future research.
4.3. Discussion: again an agent oriented alternative
During the last decade, more and more computer as well as business analysts indicated the shortcomings of the object-oriented approach (see e.g., Jennings, 2000; Zambonelli, 2003; Ferber, 2004). As an alternative, the agent oriented approach was quickly rising (Tveit, 2001). Yoav Shoham is seen as the first scientist using the agent-concept; his most famous article ‘Agent- Oriented Programming’ was published in 1993. The agent-concept as ‘one who is authorized to act for or in the place of another’ (Merriam Webster’s Dictionary) exists of course already many centuries.
The agent oriented approach has been used by many disciplines, like artificial intelligence, computer science, organization and management science, sociology, economics, philosophy and psychology (Weiss, 1999). Wooldridge (1999) defines an agent as ‘an encapsulated computer system that is situated in some environment and that is capable of flexible, autonomous action in that environment in order to meet its design objectives’. However, many scientists, and we agree, view humans, organizations, etc. also as agents (De Snoo, 2005; Wagner, 2003; Ferber, 1999).
Nevertheless, there will be always fundamental differences between humans and artificial agents, at least with respect to responsibility and liability (Dietz, 2003).
Summarizing, the agent concept seems to be very suitable, both regarding the ‘new’ requirements from software engineering, like flexibility and reusability, and from business modelling like process- and human-orientation (Klügl, 2002). We discussed and argued for an organization- centered agent-based perspective on businesses in our previous work, having a specific focus on planning process modelling (De Snoo, 2005).
5. A ‘union’ between business process and information system modelling
Now we have discussed two important modelling approaches and have argued for an agent oriented approach, we want to benefit from lessons learned.
Historically, business process models developed by business people have been technically separated from the process representations required by systems designed to support, implement and execute those processes. In this way, there was a need to translate the original business process models to the information system models manually (White, 2004). Such translations are subject to errors and make it difficult for the process owners, the business analysts and the IT- specialists to discuss the same process from different points of view. However, business process design and information technology development are more or less natural partners, and their relationship can be defined as a recursive pattern (Giaglis, 2001).
How can we bridge the gap between business models and system models and between business or process modelling and information systems development? Important insights like the focus on actors and roles, distributed and complex processes and the ability to model static as well as dynamic aspects should then be taken into account (Odeh, 2003).
As we have seen, the advantages of Petri nets lie in their inherent concurrency, whereas UML is a powerful modelling language that is well accepted and widely spread. Both – UML and Petri nets – can contribute to the construction of large distributed and/or concurrent systems (Cabac, 2005).
A productive and intelligent ‘merge’ of the information systems models with the business models is meant to mirror, support and even automate the business (Odeh, 2003). However, as we also have seen, models are and can be used for many purposes. Therefore, we search a modelling language, that can be used for business processes analysis on the one hand and information system development on the other, between which a certain form of translation and conversion is possible.
6. Existing joining attempts
Several modelling scientists have tried to realize a merge between business process modelling and information system modelling, sometimes also by adopting the agent concept. Most of them have tried to incorporate the concept in existing languages (Odell, 2005a; Giorgini, 2004; De Lara, 2003; Wagner, 2003; Odell, 2000). We briefly discuss some of these languages and indicate the main shortcomings of them. For a more extensive analysis of these languages, see De Snoo (2005).
6.1. Agent UML (AUML)
Odell et al. (2000) propose an agent-based extension to the standard UML, called Agent-UML (AUML). The AUML-extension is remained limited to some subsets of UML, viz. interaction protocols, role modelling and class diagrams. An approach for defining semantics for AUML agent interaction protocol diagrams using Petri net code structures is described by Cabac et al.
(2005). Tveit remarks that AUML has been submitted to the UML standardization committee as a proposal for inclusion in the forthcoming UML 2.0 (Tveit, 2001).
AUML’s general philosophy is ‘when it makes sense to reuse/extend portions of UML, then do it;
when it doesn't make sense to use UML, use something else or create something new’. Although AUML pays some attention to agents and roles, the diagrams representing these roles and their accompanying activities are ‘at the threshold of human readability’ (Odell, 2000). However, we adopted from AUML the idea to use life lines, or swim lanes, to indicate which activities a role is performing in the course of time.
6.2. AORml
Wagner developed an agent oriented approach to the conceptual modelling of organizational information systems, called Agent–Object-Relationship (AOR) modelling (Wagner, 2003;
Relationship (ER) meta-model and the Relational Database (RDB) model (Tveit, 2001). AORml has been developed because neither ER modelling nor UML would provide any means to account for the deontic aspects of an information system, while such deontic concepts (like commitments and claims with respect to external agents, and right and duties with internal agents) would be essential for understanding and controlling interaction between agents and other systems (the social context). There are two basic types of AOR models: external and internal ones. An external AOR model adopts the perspective of an external observer who is observing the (prototypical) agents and their interactions in the problem domain under consideration (the ‘global view’). In an internal AOR model, the internal (first-person) view of a particular agent to be modelled (the
‘local view’) is adopted. However, these diagrams are really insufficient when you want to represent the complexity of multiple, probably conflicting views. Each agent has its own local view that is not known by other agents. The development of only two diagrams is obviously too little. The strength of AORml is the clear set of ontological principles that the modelling language is based on. An important disadvantage of AORml is the enormous amount of slightly different symbols, mainly caused by the many variations of dotted, semi-dotted and closed lines.
Furthermore, AORml currently does not include the concept of activities.
6.3. DEMO
DEMO has been developed as a result of a deep dissatisfaction with current ways of thinking about information systems and business processes (Dumay, 2005; Dietz, 2001; Dietz 2003).
According to the DEMO developers does existing modelling languages and tools fail to provide assistance in articulating what is essential and what is invariant about business processes. Like in our view, they argue for a focus on communication and interaction. DEMO is an acronym that has had several different meanings during the last two decades; currently it is an abbreviation of
‘Design & Engineering Methodology for Organizations’ (Dumay, 2005). It is a theory about and methodology for the construction and the operation of organizations that is rooted in the Communicative Action Paradigm, or also called the Language Action Perspective, regarding human communication and action. In this theory, the working principle of an organization consists of the entering into and the complying with commitments between human beings, where authority, responsibility and competence play an important role (Dumay, 2005).
DEMO is grounded on the concept of the ‘actor role’, defined as an amount of authority to perform particular acts (Van Reijswoud, 1998). An actor is a subject fulfilling an actor role. An organization consists of recurrent patterns of communication and action between actors playing several roles. Important notions in these patterns like responsibility, delegation and authorization are included in the DEMO syntax. However, DEMO is meant to model processes on a very high level: little attention is paid to activities and alternative work flows. Nevertheless, their strive to model communication patterns motivates us to continue our focus on agent interactions.
6.4. YAWL
Based on a meticulous analysis of existing workflow management systems and workflow languages, Van der Aalst et al. propose a new workflow language: YAWL, an acronym for ‘Yet Another Workflow Language’ (Van der Aalst, 2005). YAWL is strongly based on Petri net modelling, but extended with additional features to facilitate the modelling of complex
workflows. YAWL has its own formal semantics and consists of only a few symbols. However, it is claimed to be able to represent most of all workflow patterns, i.e. recurring interactions. An overview of workflow patterns can be found in (Van der Aalst, 2003).
YAWL is explicitly meant to support the development of workflow systems (Van der Aalst, 2004b) and can be classified as an activity oriented approach, cf. section 3. It does currently not pay much attention to the agent, resource and goal perspective, unfortunately. Moreover, the YAWL semantics are not totally clear. Places are replaced by ‘conditions’, but a compulsory alternation of activities and condition is lacking. As a consequence, the state of a system cannot be easily recognized, because the exact location of the tokens cannot be depicted.
6.5. BPMN
Related to the Workflow Management Coalition (WfMC) and the Object Management Group (OMG) a group of commercial enterprises united in the Business Process Management Initiative (BPMI) is developing the Business Process Modelling Notation (BPMN). The BPMN 1.0 specification was released to the public in May 2004 (BPMI, 2005). BPMN is a modelling language that has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. The primary goal of the BPMN effort was to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes (White, 2004). Due to the size and power of the collaborating founders of BPMN, this notation will have an enormous impact on the acceptance and use of other (new) business process oriented modelling languages. BPMN already has been adopted by the UML group (BPMI, 2005).
Like with YAWL and many business process oriented languages, BPMN misses the link between the modelling of static and dynamic aspects of the process. Furthermore, these languages presume full process knowledge, or even omniscience. However, as we all know, in today’s dynamic business environments many aspects of processes are not known or even knowable before a process is executed.
This list of research into modelling languages is far from complete. However, it shows some different points of view and indicate some ‘grey areas’. In the next section, we present our research and introduce our alternative modelling language TALMOD.
7. The Agent Lab Modelling Language (TALMOD)
Starting in September 2004, The Agent Laboratory (TAL) at the University of Groningen has been involved in the development of agent oriented business tools from an interdisciplinary, but mainly organizational and management point of view. We will briefly introduce here our background ideas. We believe that an architecture of distributed heterogeneous applications that interact in a coordinated way is easier to maintain and extend than current enterprise information system architectures (Zambonelli, 2003). Furthermore, we believe that such an architecture is a more natural match to the network-centric model of computing and to today’s network-centric
architectures have great potential in the support of and automation and optimization of business processes (Gilbert, 2000; Gazendam, 1998). In such an architecture, an enterprise information system would consist of a collection of expert agents that have knowledge and skill in narrow domains. The overall functionality of the system is implemented by the coordinated activities of the individual agents (Wagner, 2003; Szirbik, 2003). Finally, as can be concluded from the previous sections, we believe that an agent oriented approach is a natural match to business process modelling and that the success of an enterprise information system strongly depends on its ability to match the structure and scope of the business processes it is supporting.
We want to develop an open platform that is able to support collections of heterogeneous agents and a collection of tools that allow us to develop agents efficiently from (business process) models. Since their development in the 80’s, multi-agent systems, an important emphasis has been put on the agent side. Less attention has been given to the more organizational aspects (Ferber, 2004). Therefore, we will focus on interaction and coordination between the agents and will not focus on the decision making processes that must occur within the agent. Many alternatives exist for the implementation of the internal decision making processes (rule-based systems, BDI agents, etc), each with its strengths and weaknesses (Ferber, 1999; Weiss, 1999).
Following Wagner (2003) and Dietz (2003), we view business processes as social interaction processes emerging from the behaviour and the communication patterns of the participating agents (see also Van den Broek, 2001; Szirbik, 2001; Katzenstein, 2000).
Summarizing, we will develop a modelling language for agent oriented analysis and design, tools to automatically create (skeleton) code from these models and an open platform on which these agents can be executed. Humans can be actively involved in the development phase as well as during the use of the support software.
In this article, we present the modelling language developed in TAL. The language is explicitly based on UML as well as on Petri nets and can be seen as a union between them. TALMOD is suitable to model complex processes.
Parallel to the development of TALMOD we have been busy with the development of the so- called ‘Tupos’ framework. Tupos is ancient Greek meaning ‘prescribed form, model to be imitated’ or ‘archetype, pattern, model’. Tupos is all about models and patterns: it is the software implementation of the TALMOD language. The framework is meant as a basic software architecture for the implementation of the TALMOD diagrams. The Tupos framework will be described in a separate paper and is therefore not explained in this article.
Because planning belongs to the most difficult business processes (Van Wezel, 2001a; Van Wezel, 2001b; Jorna, 1996), we have taken planning processes as a basis case example during the development of the language. In this way, we use the modelling of planning processes as a benchmark to, more or less, proof the usability of our modelling language.
Planning has long been approached as a well-defined problem of a single stakeholder. However, many planning problems are not owned by the planner only, but also by other employees like suppliers, engineers, managers and operational co-workers. A planning problem therefore can be considered as a problem in which various stakeholders negotiate to find a solution, and collectively explore other ways than the conventional ways to solve problems. We can approach this situation from a paradigm that the various stakeholders may have objectives, constraints and degrees of freedom that the planner simply cannot know, should not know, and will not know, because these stakeholders have no reason to publish them. As a consequence, many planners in practise do not so much spend their time in planning but in social negotiations (Szirbik, 2004).
Recently, the suitability of using agent-based models, simulation and support systems in supply chain management and advanced planning systems has been described (Stadler, 2005; Dudek, 2004; Nishioka, 2004; Szirbik, 2003; Stadler, 2002; Fox, 2000).
Several studies about distributed planning in multi-agent systems from a more artificial intelligence point of view can be found in DesJardins (1999) and De Weerdt (2003).
Until now, TALMOD has been used to model several complex planning processes. Some examples encompass the personnel planning process of a police region, the production planning process of a cookie factory and the business and sales planning of a starch processing factory.
Currently, TALMOD is being used to model the complex assignment process of elderly to houses for long term care, like hospitals, nursing homes and residential homes, in UK. You can find the results at our website.
We propose to start each analysis and modelling project with indicating all actors and roles involved in the process. Humans are the most important entities in a process, because they initiate, handle and manipulate it and they are responsible for and stakeholders of the process results.
Secondly, the static structure should be investigated because this structure represents the environment in which a process takes place. Finally, the processes can be modelled, while explicitly paying attention to the local views on the processes of each of the agents.
This modelling methodology is extensively described in the manual ‘Modelling with TALMOD’, that you can download at our website, http://tbk15.fwn.rug.nl/twiki.
TALMOD define four types of diagrams that will be discussed in the next sections:
• Agent-role diagram – displays which actors and entities play which roles in the modelled scenario (section 8).
• Role-interaction diagram – identifies the roles in the process and the specific local processes that realize the overall process from the perspective of theses roles (section 8).
• Static structure diagram – is basically the UML static structure diagram to which roles and the concept of information ownership are added (section 9).
• Process diagram – describes in detail the activities that an agent executes in a business process. This diagram is always made from the perspective of one role in the process: the role that a specific entity plays in the process (section 10).
8. Agents, roles and interactions
Many people, such as the planner(s), operational and strategic managers, supply and purchase managers, marketing and inventory people will be involved in the planning process. The agent oriented modelling activity starts with making a diagram showing all these actors as agents related to the roles they are playing. One agent can play multiple roles, whereas one role can be played by multiple agents (Koubarakis, 2002).
A role involves a set of responsibilities and actions carried out by an actor or a group of actors (Odell, 2005b; Koubarakis, 2002). Steimann (2000) and Dahchoura et al. (2004) have convincingly described the difficulties around and also conflicting meanings and usage of the role concept. Partsakoulakis et al. (2004) discuss the importance of roles for multi-agent systems to
