December 1999        Issue: 11

Journal of Conceptual Modeling
www.inconcept.com/jcm

Conceptual Modelling of Workflow Using the Intelligent Business Object Paradigm
By Dr. Bill Karakostas and Dr. George Fakas

Abstract

This paper describes an approach for modelling workflow based on the paradigm of Workflow Intelligent Business Object (WIBO). WIBOs exhibit the properties of intelligence, autonomy, collaboration and co-operation. WIBOs automate user tasks and combine the benefits of process automation with dynamic management and the ability of dynamic (re)allocation of resources to actors. The WIBO approach bring a number of significant benefits to workflow; such as reusability of workflow objects, inheritance-specialisation, composite workflow, nesting and referencing sharing.

1. Introduction

Productivity and customer service are key business issues for companies today. They are both inextricably linked to the technology of workflow management software. Forecasts show a rapid increase in sales of workflow management software over the next few years Ovum [95].

Workflow is the name given to procedures that involve the routing of tasks from person to person in sequence, allowing each to make a contribution before moving it on to the next stage. Examples are the processing of a business order requisition, or an insurance claim. Increased productivity in workflow systems comes from automated support of storing, creating, accessing, processing and routing of forms, letters and so on. Increased management of business processes will also play a part, as management see where the effort is going, and tune the processes accordingly.

The Workflow Intelligent Business Objects (WIBO) discussed in this paper are intelligent business objects that are used to model workflow. WIBO support all the key object-oriented features such as reusability, abstract data typing, inheritance, and object identity. Every WIBO encapsulates intelligence in its structure and behaviour. Using WIBOs- that can act on user's behalf it is possible to build workflow systems that provide intelligence, autonomy, collaboration and co-operation results in further automation, improvement and dynamic management of the process and in dynamic allocation of work to users and resources.

The rest of this paper which further explains the WIBO approach is structured as follows. Section 2 presents concepts of workflow and discusses workflow modelling approaches. Section 3 provides the WIBO meta model. Section 4 discusses the analysis of a meeting scheduling workflow using WIBOs. Finally Section 5 contains conclusions of the research presented here with suggested directions for further research.

2. Concepts of Workflow

Workflow software products, like other software technologies, have evolved from diverse origins. While some offerings have been developed as pure workflow software technologies, many have evolved from image management systems, document management systems, relational or object database systems, and electronic mail systems. [WfMC 94] .

Marshak [95] defines workflow as the automation of the processes that we use every day to run a business. A workflow application automates the sequence of actions, activities, or tasks used to run the process, including tracking of each instance of the process, as well as tools for managing the process itself .

Burns in [Khoshafian 95] defines workflow automation as the structure that is applied to the movement of information in order to improve the results of a business process. Workflow automation software actively manages the co-ordination of activities among people in general business processes.

Butler Group [96] defines workflow as a set of tools for developing applications to manage, measure, and revise work processes that span the efforts of multiple workers and applications (and possibly companies).

Mentzas' [96] definition of workflow is that of a collection of tasks organized to accomplish some business process (e.g. processing purchase orders over the phone, processing insurance claims). A task can be performed by one or more software systems, one or a team of humans, or a combination of these. Human tasks include interacting with computers closely (e.g., providing input commands) or loosely (e.g., using computers only to indicate task progress). Examples of tasks include updating a file or database, generating or mailing a bill. In addition to a collection of tasks, a workflow defines the order of task invocation or condition(s) under which tasks must be invoked, task synchronization, and information flow.

In a Microsoft white paper, workflow is defined, as a sequence of actions or steps used in business processes. Automated workflow applies messaging technology to the workflow process. Microsoft views reliable messaging connectivity between all participants and interested parties as a fundamental prerequisite to a robust and reliable workflow infrastructure. [Microsoft 96]

2.1 Workflow Modelling Approaches

The Workflow Management Coalition (WfMC)

Founded in 1993, the Workflow Management Coalition (Wf'MC) is a non profit making organisation comprising of workflow vendors, analysts and users, their common goal being to promote the use of workflow technology. The organisation's core objectives are the establishment of standards for workflow terminology; the enabling of interoperability between different workflow systems, and the enhancement of understanding through a standard reference model. WfMC is now the primary standards body for workflow software and technology and those considering a workflow solution should, to protect their investment, ensure that the chosen vendor adheres to the Coalition's work.

Many workflow vendors have invented their own terminology, whilst some products have carried forward terminology associated with their roots, most notably from the imaging arena. One of the major objectives of the Coalition is to help users understand workflow through the standard reference model. This reference model depicts common characteristics of workflow products and defines seven layers of interoperability: from level 1 (basically that workflow systems can run on the same hardware and software) to level 7 (common look and feel and method of operation) The model also provides a framework for interface standards, five interfaces with the workflow enactment service (a workflow engine which provides the runtime environment in which workflow processes are executed) are being worked on.

Object-Oriented Workflow Management Systems

Object-orientation is becoming very popular by dominating all software technologies today, because of the advantages it offers to both users and developers. Many workflow vendors advertise their workflow products as object-oriented. However, the fact that a workflow product was developed in an object-oriented environment or uses object-oriented databases does not necessarily mean that the product could be described as object-oriented. In an object-oriented workflow system everything must be an object; there must be a uniform object-oriented feel to the product and support for the fundamental object-oriented concepts.

Workflow Modelling with UML

UML has recently become a popular notation for the specification of workflow.

Hruby [98] demonstrates how UML can be used for specification of workflow management systems, how to trace the description of business processes to the object-oriented software design and how to structure the project repository with UML deliverables. In this modelling approach, business objects are represented by classes and instances. Business processes are represented by use cases and use case instances. Workflows are automated business processes. They are represented as use cases or use case instances with a stereotype "workflow". Team roles are represented by classes and objects in UML. Classes represent types of team roles, objects represent concrete workers playing the role.

The UML Revision Task Force is in the process of defining extensions to activity diagrams to address these problems [OMG 98]. According to Schmidt [98] when this work is completed, UML workflow models could become a base for generation of workflow components and the integration of other business components into workflows.

3. Intelligent Objects for Workflow Management

Workflow Intelligent Business Objects (WIBOs) as proposed in this paper are objects that are used to implement workflow management systems. Every WIBO encapsulates intelligence in its structure and behaviour. Using WIBOs that can act on user's behalf- like Intelligent Agents do- to develop workflow systems that provide intelligence, autonomy, collaboration and co-operation can result in further automation, improvement and dynamic management of the process. WIBOs can also provide dynamic allocation of work to users and resources.

Intelligent process management is a key requirement from workflow tools. This is catered for in our approach as WIBOs are able to manage themselves. Process management in current workflow systems is often limited to warning. In contrast, WIBOs support dynamic processes that are capable of dealing with exceptions and changes by intelligently assigning and reassigning work and resources to roles.

3.1 Object-oriented characteristics of WIBOs

WIBOs exhibit the following features:

• Reusability of workflow objects. New WIBOs can be built by using pre-defined WIBOs. Any requirement changes can be easily accommodated for since only the affected objects will need to change rather than the whole application.

• Inheritance-Specialisation. WIBOs can be generalised by extending their structure or behaviour. Alternatively classes can also be specialised through restricting the structure or services.

• Composite workflow. WIBOs can contain or refer to other objects. Programmers can dynamically construct arbitrary composite or complex objects, objects that are constructed from sub-objects.

• Encapsulation. The information and processing rules are combined into single objects. A typical workflow object contains not only the information being routed but also the knowledge with its path through a process and the roles that act on it.

• Instantiation. The WIBOs are class objects from which instances of objects can be created.

3.2 Object Collaboration

WIBOs are examples of collaborative agents. Collaborative agents emphasise autonomy and co-operation (with other agents) in order to perform tasks for their owners. They may learn, but learning is not typically a major emphasis of their operation. To have a co-ordinated set up of a collaborative agents, they may have to negotiate in order to reach mutually acceptable agreements on some matters.

• Autonomy refers to WIBOs' principle of co-operation without the need for human guidance. Hence a WIBO have individual internal states and goals, and they act in such a manner as to meet its goals on behalf of its user. A key element of their autonomy is the proactivness, i.e. their ability to 'take the initiative' rather than acting simply in response to their environment.
  

• Co-operation with other WIBOs is paramount: it is the raison d'etre for having multiple WIBOs to implement the workflow management system. Co-operation is achieved through the exchange and asynchronous execution of messages.

WIBOs have several other key characteristics:

• Delegation: The user entrusts the WIBO agent to tackle some or all of an activity.

• Personalisation: The user determines how the WIBO agent interacts. Sometimes, the WIBO agent learns about the user and adapts its actions accordingly (along the lines of a personal assistant).

• Predictability: The user has a reasonable expectation of the results.

• Cost effectiveness: The benefits gained by the user (time/improved productivity.) should be of greater value than the cost (monetary, time, re-work, etc.)

3.3. The WIBO Meta-Model

WIBOs belong to one of a number of predefined interrelated classes or types which together form a meta-model i.e. process, role, actor and resources. Figure 1 shows the WIBO meta-model in UML notation. The concepts of the meta-model are explained in the remaining of this section.

Fig. 1 The WIBO Hierarchy

3.3.1 Process

A collection of co-ordinated activities that have explicit and/or implicit relationships among themselves in support of a specific process objective [WfMC]. A new instance of this object is created for every workflow process created. Process object is responsible for creating the instances of all the forms involved in the process and also communicating and exploiting the other WIBOs (e.g. Actors, Roles Resources). Its main functionality is managing, assisting and routing the workflow.

Process management in a workflow system is often limited to warning. It is difficult for the designer to create a system which automatically corrects a poorly functioning process environment. Many products contain event triggers for time-based alerting, but few open up this facility fully to the designer and allow the system to take corrective action automatically (besides notification or escalation of priorities) e.g. ability to change priorities or reassign work. One of the key differentiators in this area is the extend to which the process can be changed on-the-fly.

The process WIBO has the following features:

1. Processes utilise and generate resources. Processes make use of resources in order to generate other resources.

2. Intelligent Process management. Process WIBOs are able to manage themselves:
   
   · Via alerting using deadlines. A deadline is assigned for every activity. If the activity is not completed before the deadline then the process is responsible to send an alert message to the actor responsible executing the concerned activity.
   · By prioritising. Every activity is characterised by a priority level relatively to other activities. This knowledge is used by the role object for more efficient task allocation and scheduling. Priority like any other knowledge in this work is measured on a scale between "high" and "low".
   · By real-time monitoring. The Process WIBO is capable to report about its current state; i.e. Total Running Time, Current Activity and its status (Waiting Time, Deadline, Role and Actor Selected) etc. This information is useful to trace any bottlenecks of the process.
   · By estimating the time and resources required for execution. The process is capable to estimate the total duration of the execution and the resources required.
   

3. Dynamic Process optimisation. WIBOs support dynamic process optimisation by:
   
   · Dynamically altering the resourcing of tasks, to enable more workers to help clear bottlenecks
   · Dynamically altering the allocation of tasks, to transfer a backlog of pending tasks from one user to another or from one group of users to another; for more information see roles who actually take over of this optimisation.

3.3.2. Role

It is important to define roles independently of the people who carry out the activities. It ensures the flexibility of the system. Roles assign activities to people. If an employee is unavailable then somebody else is chosen to carry on the work [Ovum 95].

In current workflow tools, pure roles have their limitations: if roles are used, it is not always possible to block the indirection which this introduces. The use of role-based reference, while powerful, can obscure important relationships between tasks and the individuals who perform them. This is most easily seen in the case of process loops, as might occur in an approval cycle: do it until it's done right. On the second iteration of Task A, it may be desirable either for the same person to adopt role A as had the role in the previous iteration, or for a different person to adopt role A. WIBO Roles maintain knowledge about each process activity so they can block or not (always according to the current needs), role indirection.

Role WIBOs have the following features and responsibilities:

1. Allocation of Activities to Actors. It is Role WIBO's responsibility to allocate activities to Actors. Its aim is to make an optimised allocation of work which is dynamic by taking into account parameters such as:
   
   · Actor's level of Experience. Every candidate Actor has a different level of experience (novice, expert and guru) in performing an activity. Actors classified as gurus will be more preferable than the others
   · Actor's Workload. Actors with a heavy workload are less preferable
   · Use of role-base reference. In the case of process loops, Role WIBO's give the option to allocate iterated activities either to same actor or to a different one.
   

2. Report Actors Overload.
   The Role WIBO investigates its Actors' workload. If none of the Actors is able to execute the activity before its deadline because they are overloaded, then Role reports that. Overload could be solved by:
   
   · Extending the activity's deadline
   · Allocating more Actors to the process
   · Changing Activities' priorities
   
   If Role traces an Actor that will not be able to execute any of his/her already allocated activities before the deadlines or he/she is overloaded relatively to other Actors then apart from the above mentioned solutions, reallocation of the activities might take place.
   

3. Reallocation of Work.
   It is the Role's responsibility to alter the allocation of tasks, to transfer a backlog of pending tasks from one user to another. Reallocation of work considers the same criteria as Allocation of Work does (i.e. Actor's level of experience, workload, use of role-base reference).

The table below summarises the responsibilities of a role WIBO.

3.3.3. Actor

An actor could be either a person or a machine. An actor can perform a process activity or be responsible for it [Sheth Joosten 96]. Actor WIBOs have the following features:

1. The capability of scheduling his/her activities
   Actors like all other WIBOs encapsulate intelligent agents. These agents are empowered with knowledge about their working environment. By having this knowledge, they have the capability to schedule activities, based on criteria given to them. These criteria could be:

• The earliest due job is done first

• The shortest job is done first

• Or even a combination of all the above.

3.3.4. Resource

Resources are assets of the organisation that enable processes or are generated by processes. Examples of resources include products, documents, equipment, policies etc.[Taylor 95]. A specialisation of Resources is the Form or document. Resource WIBOs support the following features.

1. Resources enable and result from processes
   Resources enable processes, and resources result from processes. Resources may be created, destroyed, consumed, reused, owned, or controlled in other way.

2. Resources schedule their utilisation
   When a process is asked to schedule itself, it checks its required resources for availability. If resource objects can supply the requested quantities, they commit these quantities and schedule their delivery.

4 Modelling of a Meeting Scheduling Workflow

4.1 Background

The application of Workflow Intelligent Business Objects (WIBOs) can be demonstrated on meeting scheduling case study. Although applications for scheduling of meetings generally belong to the domain of groupware the meeting scheduling process selected for this case study is quite well defined and repetitive and thus suitable for workflow automation. This case demonstrates how WIBOs who act as software agents of human participants collaborate in arranging a meeting. Part of the WIBOs intelligence lies in their ability to contain and utilise knowledge about the preferences of the participants regarding the meeting, such as preferred dates and locations etc.

4.2. The Meeting Scheduling Process

This section describes the Meeting Scheduling process. It first provides a description of the meeting scheduling domain and then proceeds with the requirements for a system that can automate the process.

4.2.1. Domain Description

Meetings are typically arranged in the following way. A meeting initiator sends a date range to all potential participants (attendees) asking them whether they are free to attend a meeting within a given date range.

A date range for a meeting is defined by a starting date and time and an ending date and time.

A meeting date is defined by a pair (calendar date(1-30), time period).

The initiator asks the participants if they request any special equipment required for the meeting (e.g. overhead-projector, workstation, network connection, telephones, etc.) The initiator may also ask the participants to state their preferences about the meeting location. Some of the participants may be more important than the others for the purpose of the meeting.

Each participant should reply to the initiator with a set of preferred dates for the meeting, called a preference set. Ideally the different preference sets of the participants should have some common dates. A date conflict occurs when no common date can be found in the different preference sets. Conflicts can be resolved in several ways:

• the initiator extends the date range;

• the initiator decides to exclude some participants from the meeting;

• combination of the above two.

Furthermore, a meeting room must be available at the selected meeting date. It should meet the equipment requirements and it should ideally belong to one of the locations preferred by as many important participants as possible. A new round of negotiations may be required when no such room can be found.

4.2.2 Requirements

The purpose of the Meeting Scheduler system is to support the organisation of meetings - that is, to determine, for each meeting request, a meeting date and location so that most of the intended participants can participate. The meeting date and location should thus be as convenient as possible for all participants. Information about the meeting should also be made available as early as possible to all potential participants. The intended system should considerably reduce the amount of overhead usually incurred in organising meetings where potential attendees are distributed over many different places. On the other hand, the system should as closely as possible reflect the way meetings are typically managed (i.e. according to the domain description above).

The system should assist its users in the following activities:

• Plan meetings under the constraints specified by participants.

• Re-plan a meeting dynamically to support as much flexibility as possible. On one hand, participants should be allowed to modify their preference set and/or preferred location before a meeting date/location is proposed. On the other hand, it should be possible to take some external constraints into account after a date and location have been proposed - e.g., due to the need to accommodate a more important meeting. The original meeting date or location may then need to be changed; sometimes the meeting may even be cancelled. In all cases some re-planning should be set up.

• Support conflict resolution according to resolution policies stated by the user.

• Manage all the interactions among participants required during the organisation of the meeting, for instance, to communicate requests, to get replies even from participants not reacting promptly, to support the negotiation and conflict resolution processes, to make participants aware of what is going on during the planning process, to keep participants informed about schedules and their changes, to make them confident about the reliability of the communications, etc.

The amount of interaction among participants (e.g., number and length of messages, amount of negotiation required) should be kept as small as possible.

The meeting scheduler system must in general handle several meeting requests in parallel. Meeting requests can be competing by overlapping in time or space. Concurrency must thus be managed.

The following aspects should also be taken into account:

• The system should accommodate decentralised requests; any authorised user should be able to request a meeting independently of his/her whereabouts.

• Physical constraints should not be broken - e.g., a person may not be at two different places at the same time, a meeting room may not be allocated to more than one meeting at the same time, etc.

• The system should provide an appropriate level of performance, for example:
  * the elapsed time between the submission of a meeting request and the determination of the corresponding meeting date/location should be as small as possible;
  * the elapsed time between the determination of a meeting date/location and the communication of this information to all participants concerned should be as small as possible;
  * a lower bound should be fixed between the time at which the meeting date is determined and the time at which the meeting is actually taking place.

• Privacy rules should be enforced; a non-privileged participant should not be aware of constraints stated by other participants.

• The system should be usable by non-experts.

• The system should be customisable for professional as well as private meetings. These two modes of use are characterised by different restrictions on the time periods that may be allocated (e.g., meeting during office hour, private activities during leisure time).

• The system should be easily extendable to accommodate the following typical variations:
  * handling of explicit priorities among dates in preference sets;
  * handling of explicit dependencies between meeting date and location;
  * participation through delegation - a participant may ask another person to represent him at the meeting;
  * partial attendance - a participant may only attend part of the meeting;
  * variations in date formats, address formats, interface language, etc.
  * partial reuse of in other contexts - e.g., to help establish course schedules.

4.2.3 Extending the system with additional knowledge

Knowledge about the various participants is encoded in WIBOs. This concerns the hierarchical importance of participants, the importance for a participant to attend a particular meeting relatively to other participants or to other meetings, and the ease with which a participant can make a particular date interval free. Such knowledge is used in the conflict resolution process.

1. Participant Status.

The participant status captures the hierarchical importance of a participant with respect to others independently of any specific meeting he/she is expected to participate in. Status can be used to determine a best compromise on date and location whenever several ones are possible. For instance, in the context of scheduling university faculty meetings the heads of departments would have higher statuses than student representatives.

2. Participant Importance.

The participant importance captures the importance for a specific person to attend a particular meeting relatively to other participants. Participant importance is typically determined by the meeting initiator. For instance, the meeting chair and secretary must be present as they have the highest participant importance.

3. Meeting Significance.

The meeting significance represents the importance for a specific person to attend a particular meeting relatively to other meetings or meeting requests. Meeting significance is typically determined by the participants concerned. For instance, participants to a specific task in a research project would assign a greater significance to a project meeting where their task will be discussed.

4. Participant Flexibility.

The participant flexibility is intended to indicate how easily a user can make a particular date interval free to allow meetings to be scheduled within the interval. Dates in exclusion sets and/or preference sets can thus be weighted accordingly. The participant flexibility is typically determined by the participants concerned. For instance, professors cannot move lecture times easily; their participant flexibility for the corresponding date intervals should be low. A date interval which is not in the exclusion set of a participant should have flexibility for that participant. This information must be kept confidential.

5. Participant Preference.

The preferences of every participant about their meetings; i.e., the time they prefer the meeting to start etc. should be known. For example the head of the department might prefer having their mornings free to do their paperwork and participate in meeting in the afternoons.

The advantage of Using Knowledge about Status and Priorities.

The following rules illustrate how WIBOs can utilise the above knowledge:

• Best meeting dates and locations should be determined by considering participants with higher participant status first.

• If no date can be found for the meeting, the system could exclude from the meeting persons having low participant importance. If no date can be found to organise a meeting, the system could ask a participant to cancel (or to withdraw from) another meeting having a lower importance for that participant.

4.3. Object-Oriented Modelling Of The Meeting Scheduling Process

In the previous section the domain description and system requirements of the Meeting Scheduling process were given. In this section, the meeting process is modelled using WIBOs. Firstly, all the WIBOs are identified as in table 1.

Table 1 Summary of WIBOs comprising the Meeting Scheduling Process.

The next step is to define the above WIBOs in terms of their attributes services, and associations. Figure 4 shows the WIBOs model of the process. The model is based on the UML notation. The diagram illustrates how the WIBOs for meeting scheduling are derived from the generic WIBOs discussed in Section 3.

Fig. 2 The Objects of the Meeting Scheduling Process

The tables below contain the Meeting Scheduling WIBOs and the definitions of their attributes and services. 

 4.4. Design Meeting Scheduling Process In WIBOs

The Meeting Scheduling process is now modelled in terms of WIBOs. This section describes the automated workflow process and the advantage of it over the manual process.

The Meeting Scheduling process developed using WIBOs will be as follows:

Activity 1: The initiator sends a preference form to all candidate attendees to fill in with their preferences about the meeting.

Activity 2: The WIBO of every candidate attendee that receives the preference form tries to fill it in according to the attendee agenda's information and its knowledge about user's meeting preferences. If the WIBO is lacking information to do this then it requests the human user to provide it.

Activity 3: When all attendee WIBOs reply by sending back to the initiator their preferences the initiator WIBO uses this information and its knowledge to fix a date. Again if the WIBO is not able to fix a date without assistance from the human initiator it will ask for his/her assistance.

Activity 4: If there is a date conflict then the initiator's WIBO will try to solve this problem by applying any from the solutions below or a combination of them:

a. the initiator WIBO extends the date range
b. some participants are excluded from the meeting

In all cases the WIBO will try to resolve the conflict but if it is not successful it will seek assistant from the human.

Activity 5: IF a date can be fixed

THEN the initiator WIBO automatically fixes a room meeting equipment requirements
OTHERWISE the initiator WIBO starts a new round i.e. go to activity 1.

Fig. 3 shows the interactions of the WIBOs comprising the process.

Fig. 3 The Interaction Diagram Of the Meeting Scheduling Process.

4.5 Benefits from the new process design.

In the WIBO approach to workflow, intelligence, autonomy, collaboration and co-operation reduces the need for human intervention and therefore their workload.

The WIBO acts on the user's behalf and the user is involved only when the WIBO cannot decide what the next action should be. In this way the user is relieved from trivial or menial tasks and can afford to spend time on other things of higher complexity.

There are significant differences between the old and new meeting scheduling process. The manual process is complicated. It relies on meeting initiator's skills to fix a good meeting that satisfies attendees' preferences. Meeting initiator and attendees have to do complicated matching between their preferences and everybody else's preferences and availability before fixing a meeting. This is very difficult especially when there are a lot of attendees for a meeting. In contrast the new process:

• employs autonomous, co-operating and collaborating intelligent agents (WIBOs) acting and negotiating on users' behalf.

• hides complexity; as WIBOs are doing the more complicated tasks on behalf of the humans,

• avoids delays, the system does not have to wait until all human attendees send their replies back ; their WIBOs do this automatically for them,

• performs parallel processing, the initiator's and attendees' WIBOs are working in parallel.

5. Conclusions

The WIBO approach to workflow can relieve human workflow participants from trivial or menial tasks so that they can afford to spend time on other things of higher complexity. The advantage that WIBOs bring are therefore many-fold. They try to further improve workflow process's performance and overcome limitations of current workflow systems and then by taking advantage of state of the art technologies in object-orientation, Internet/Intranets and use of intelligent agents.

In conclusion, Workflow Intelligent Business Objects (WIBOs) can provide the basis for building workflow management systems. The WIBO approach promises further improvements in productivity and efficiency of workflow systems. Further research along this line could address issues of interoperability between WIBOs and other groupware and workflow systems. Such interoperability should be based on existing (e.g. Workflow Management Coalition [WfMC 94]) and emerging standards (e.g. Object Management Group- [OMG 98]).

References

1. Butler Group, (1996) Workflow, Louint, S., Wright, S., Webster, S. Cooper, S. Frost, A. Edited by P. Makey.
2. Hruby, P., (1998), Structuring Specification of Business Systems with UML (with an emphasis on Workflow Management Systems), OOPSLA' 98 Business Object Workshob IV
3. Khoshafian, S. (1995) Introduction to groupware, workflow, and workgroup computing, Wiley.
4. Marshak, R. (1995) Perspective on Workflow, The Workflow Paradigm, Edited by E. White and L. Fischer.
5. Mentzas, G. (1996)Coupling Object-oriented and Workflow Modelling in Business and Information Process Reengineering. Dept. Of Informatics, University of Athens, Greece.
6. Microsoft, (1996) Microsoft Exchange Server: Infrastructure for Workflow Solutions, White Paper, November.
7. OMG, Workflow management facility specification. OMG Document Number bom/98-03-01, 1998. Available on the Web at ftp://ftp.omg.org/pub/docs/bom/98-03-01.pdf
8. Ovum (1995) Ovum evaluates Workflow, Stark, H., Lachal, L., Ovum Ltd.
9. Schmidt M., (1998), Building Workflow Business Objects, OOPSLA' 98 Business Object Workshop IV
10. Sheth, A., Joosten S., Workshop on Workflow Management: Research, Technology, Products, Applications and Experiences, August 1996.
11. Taylor, D. (1995) Business Engineering With Object Technology, John Wiley.
12. Workflow Management Coalition (WfMC), (1994), The Workflow Reference Model, November, 1994, WfMC Document TC00-1003
    URL: http://www.aiai.ed.ac.uk:80/WfMC/DOCS/refmodel/rmv1-16.html

Dr. Bill Karakostas (DEng Computer Engineering & Informatics from University of Patras, Greece, 1986, M.Sc. by research from UMIST, UK,1987, PhD. from UMIST, 1990) is a lecturer in the Department of Computation, UMIST since 1990. Prior to that he held the Research Fellow position in the same Department, sponsored by electronics companies. Since 1988 he has been involved in 7 Esprit projects in the capacity of researcher and technical manager. Between 1994 and 1996 he was a director of a virtual organisation, the Business Engineering Partnership, consisting of fifteen UK companies and institutes. Currently he is the scientific advisor for several Greek and UK software houses. More recently, he collaborated with e-commerce vendors such as Intershop Communications in a European project on Web based retailing. He has also developed commercial applications for Internet publishing and virtual exhibition centres. He is the author of more than fifty research publications and the co-author of a book on systems requirements engineering. The list of his research interests includes Web architectures for e-commerce, distributed object computing and software component technologies.

Contact Information:

Department of Computation
UMIST, PO Box 88,
Manchester M60 1QD, UK

Tel: + 44 161 2003340
Fax: + 44 161 2003324

bill@co.umist.ac.uk

Dr. Fakas holds an HND Diploma in Computer Studies from HTI, a B.Sc. in Computation, an M.Phil. and a Ph.D. in Computer Science from the Department of Computation, UMIST in the UK. Currently he is a Post Doctoral Research Associate with the department of Computer Science at the University of Cyprus. He is the Technical Manager for Cultural Journeys in the Information Society (CJIS) project (INCO Project). His research interests include Workflow Management, Groupware, Coordination, Business Process Reengineering, Internet, Object-oriented analysis and design (UML, OMT, Coad & Yourdon), Java, Java RMI, and CORBA.

Contact Information:

Department of Computer Science
University of Cyprus
Nicosia, PO Box 537, Cyprus

Tel: +357 2 338705
Fax: + 357 2 339062

fakas@ucy.ac.cy

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825