Hyperlinking the Work For Self-Management of Flexible Workflows

Workflows describe business processes as coordinated execution of simple activities carried out by human or software applications. Over the past decade, workflow technology has been widely deployed in the domains with processes that have clear coordination requirements, and it has achieved significant commercial success in automating such routine business processes.

However, as business environment becomes increasingly dynamic, there is a growing need that workflow technology must also support domains where coordination requirements are not obvious due to the inherent flexibility of workflows. Such flexible processes are characterized by a lack of ability to completely define process structures as well as control flows, and can be found in a lot of domains, including software development, e-learning, and customer relationship management.⁸ As a result, research and development in this area have been active, and considered various types of flexibility that ranges from simple ad hoc modifications of processes to completely unstructured process specifications (see Table 1).

Yet, the existing approaches, which can be collectively characterized as process aware systems, still present some limitations in managing highly flexible processes.⁵ Regardless of whether they support flexibility to deal with run-time exceptions or accommodate ad hoc and evolutionary changes, they require the explicit process models that need to be managed centrally by an authorized process specialist. Accordingly, although the process aware approach provides several benefits such as increased effectiveness and efficiency for structured or semi-structured processes, it limits the flexibility of defining and executing processes in some domains where workflows are so dynamic and ad hoc that activities and control flows are created as needed and changed over time by distributed participants.

In this article, we attempt to pursue flexibility further and present a new metaphor, named “hyperlinking the work,” for supporting highly flexible processes without requiring the explicit workflow representation for process specification and enactment. The proposed framework aims to provide a fully decentralized workflow management environment where workflow participants are able to independently and dynamically configure their own workflows whenever necessary, workflow definition and execution are carried out locally via publish/subscribe mechanism to achieve scalability as well as loose coupling,³ and finally the entire workflow can evolve over time as the individual participants self-manage their local workflows without having to be aware of global workflow definition.

Back to Top

Pull-Style Workflow Definition

We introduce three basic modeling constructs, namely work structure, event, and hyperlink. The relationships among them are illustrated in Figure 1 (see Table 2 for notations). A work structure represents a computational abstraction of work, and it can be created and updated independently by participants anytime. It contains the specification of work structure components, including name, description, last update date, event list, hyperlink list, and authorized users.

A work structure can be associated with zero or more user defined events that are uniquely identified via URL. Each event has components such as name, creation date, sender, description, event body, and URL for specifying the details. Depending on the existence of the user defined event for a work structure, work is classified into regular work or sink work. The regular work has one or more user defined events, whereas the sink work has no associated event. (W₁ in Figure 1 is an example of a sink work.)

The user defined events represent information pertaining to the status of work, and we do not impose any limitations on the semantics of events in an attempt to maximize the flexibility. For instance, for the work representing order validation, a user can freely associate events such as “10% done” and “half done” with the work. In addition to the user defined events, there are pre-built system level events that are generated when a work structure is updated or removed, or a hyperlink pointing to the work structure is created, updated, or removed. Any such changes are broadcast in the form of a system level event to the work structures that are directly related via hyperlinks so that the corresponding users can be informed.

Once the work structures are defined, control and data flows among them are specified in pull-styleby use of hyperlinks. Given two work structures, W_i and W_j, a hyperlink from W_j to the event e_i,k of W_i is created by specifying the pair, (W_j, URL of e_i,k), which implies that e_i,k is of interest for W_j to proceed. A hyperlink may represent a variety of meanings, including a precedence relationship, prior information necessary to carry out the work, or just a need for simple alert. Hyperlink is depicted as a dotted line in Figure 1.

When necessary, users can search and locate an existing work structure or event, and use it instead of creating a new one. The underlying motivations for supporting search capability are to facilitate the reuse of work structures and also to promote organizational learning within a workgroup through providing a work blog where relevant history of event occurrences in the past can be examined and the related resources such as forms and documents can be downloaded. Furthermore, the search function also provides a convenient way to discover available events users can subscribe to in the system.

Finally, we define for each work structure two types of user groups: participant and administrator groups. The user belonging to the participant group of a work structure is only able to generate events associated with the work and receive events designated to the work. On the other hand, the user from the administrator group has the ability to modify the work structure components in addition to the rights granted to the participant group.

Back to Top

Push-Style Workflow Execution

Our framework supports proactive message pushing to users so that execution of work can be carried out in an event-driven way. Workflow execution is triggered by event occurrences that are propagated in the reverse direction by which hyperlinks are defined. Whenever an event occurs, it is forwarded to all work structures that have a hyperlink to the event. Each user can also specify the set of users whose events are of interest to her. For instance, (e_j,1, U_j,1,D) in Figure 1 denotes that user D is interested in the event e_j,1 only when it is generated by the users in U_j,1,D. In this way, workflows are implicitly defined in pull-style, whereas execution of the workflows is carried out in push-style based on events.

While the events are delivered to a destination work structure as soon as they are generated by other work structures, some of them may need to have temporal relationships with the events of the destination work. For this purpose, we classify the events into two categories: absolute and conditional. The absolute event defined for a work structure can be generated anytime user wants, whereas the conditional event must be enabled before it can be generated. The condition that must be satisfied for enabling an event varies depending on the type of link condition,⁹ and we support three types of link conditions, namely conjunction, disjunction, and selection.

Specifically, an event, e_i,j is said to be enabled for user A, if all the events in pre(W_i, A) have occurred at least once in case of that its link condition is conjunction, at least one of events in pre(W_i, A) has occurred in case that its link condition is disjunction, or exactly one event e* in pre(W_i, A) has occurred in case that its link condition is selection. For example, assuming that the link condition for e_k,1 of user D in Figure 1 is conjunction, event e_k,1 will not be enabled for user D until both of e_i,n(i) and e_j,1 are generated by users in U_i,n(i),D and U_j,1,D, respectively.

Many of the activities within an organization take place through information exchanges that are made possible by using documents and forms as interfaces. To address this requirement, an event may contain a work item that needs attention from the recipient. The work item may include a simple description for necessary actions, a URL to an electronic form through which the recipient input the result of action, or a document that the recipient can simply reference or modify depending on the nature of work. Once the recipient of the event completes her own work based on the event delivered, the outcome of the work can be prepared by constructing another event. This event can then be sent to the subsequent users in workflow, resulting in event-driven interactions among users.

We remark that it is possible in some cases for a user to prepare an event to be generated from her work even before it is enabled. As an example, consider an activity of making a purchase order that requires an activity of receiving a quote as its predecessor. If all the other order details except the price are already known, the user will be able to start preparing a necessary purchase order document even though the event “quote received” is not yet delivered to her. The “request purchase order” event can then be immediately generated without delay by simply filling out the price information in the purchase order document as soon as the “quote received” event is received. That is, in contrast to the conventional workflow management systems (WfMSs) that do not allow a work to be instantiated unless its preceding work has finished, our framework allows the user to early start her work to enhance flexibility.

Back to Top

Self-Managed Workflows

The proposed framework presents several benefits. First, the work structures can be created, modified, and reused locally by users as long as they are authorized. Workflows can be flexibly configured as needed, and users can dynamically join and leave the system anytime. These facilitate totally loosely coupled process specifications and also make it possible to naturally specify and execute the ad hoc, flexible workflows.

Second, since the workflows are configured in a bottom-up manner through searching and identifying necessary work structures and hyperlinking them, the redundancy of having the same activities across independent processes can be significantly reduced. This contrasts to the situation in which same activities carried out by the same user are redundantly defined across individual processes, which is a common phenomenon in most WfMSs due to the hierarchical nature of process definitions.

Third, process monitoring becomes easier. Process monitoring provides visibility into a particular process’s status, and it also reports information on resource requirements that can be utilized for further process improvement. In the proposed framework, any events associated with a work structure can be easily monitored by hyperlinking to it from a sink work in an ad hoc manner. Furthermore, the implicit workflow configurations collectively made by participants can be structured to an explicit workflow representation whenever necessary for visualization purpose through navigating event and hyperlink definitions.

Finally, with the proposed approach, workflows can autonomously evolve over time. As users dynamically create and update work structures, events, and hyperlinks to better account for the characteristics of their work, we believe that the overall workflows will be improved gradually, leading to an optimized workflow structure eventually. Therefore, contrary to the conventional practice in which workflows are defined and given to users by a process specialist, the workflows can be self-managed by the participants in our framework.

Back to Top

evFlow at Work

To demonstrate the key ideas, a prototype, named evFlow, has been implemented. In order to illustrate evFlow’s functionality, we first consider a simplified purchase order process that consists of three steps: John makes a purchase request which calls for the manager’s approval, Cathy, the manager of John, reviews the request, and makes a decision – approval or rejection, and finally James, working at procurement department, places an order when the order has been approved. This process definition is conveniently represented in terms of work structures, events, and hyperlinks, as shown in Figure 2 (up to time t).

Now, suppose that at time t + d₁, John gets interested in receiving a notification whenever a rejection is made for his future purchase requests. Not knowing the exact URL for the hyperlink of this event, he tries the search menu provided by evFlow which allows work structures, events, and users to be retrieved based on keywords. After finding out that “reject” event of work structure “purchase request review” is the one he looks for, John creates a sink work structure “alert for rejection” and simply hyperlinks it to this event, as indicated in Figure 2.

Finally, at time t + d₂, we assume that Cindy who works for audit department has realized that she needs to record every purchase order made for book-keeping purpose. Again, this is taken care of by searching the URL for the event pertaining to order placement, creating a new work structure, “audit order”, and finally hyperlinking it to the URL found, as shown in Figure 2. We emphasize that addressing the requirements of John and Cindy becomes a simple matter of creating and hyperlinking work structures in our approach, which would otherwise require two additional entire process re-definitions under the conventional WfMS framework. Therefore, the effect of process changes has been completely localized.

Back to Top

Implementation Architecture

The implementation architecture of evFlow is shown in Figure 3. In evFlow, asynchronous interactions among the users are supported by a desktop widget through which the users can coordinate their work. Whenever an event is generated, it is delivered in the form of RSS (Really Simple Syndication) to a destination work structure, and displayed on the widget of the corresponding user in a timely manner. Since every part of the RSS feed format is optional, users can freely define work items. This kind of push technology increases the efficiency of process execution through raising users’ attention immediately as well as relieving the burden on the users to periodically pull tasks.¹

The developed system is lightweight compared to the conventional WfMSs mainly because it does not directly support transactions and integration with existing enterprise applications through APIs and adapters. Instead, evFlow supports external integration via RSS feeds as illustrated in Figure 3.

As long as a remote system can expose its output in form of RSS feeds, it can be asynchronously integrated with evFlow. For instance, if it is necessary to retrieve some data from enterprise database to carry out a work, a corresponding work structure can be created so that it can provide the necessary data by pulling the remote RSS feed generated from the DBMS. In this sense, evFlow can be considered as a system enabling the flow of RSS feeds since it cascades the feeds as process progresses. The major server-side architectural components include:

• Event handler that receives events from client applications, records them in the database, identifies the destination work structures, evaluates the link conditions defined for hyperlinks, generates events, and requests sending them to the event dispatcher.
• Event dispatcher that delivers the events to client applications. It formats the generated events and transforms them according to the content format required by client applications. Currently, only the RSS format is supported for evFlow desktop widgets.
• Work manager that allows users to define, modify, and remove work structures and their associated events as well as hyperlinks through Web interface. It is also responsible for managing users and handling search requests from users by invoking search module.
• Search module by which users can discover the work structures and their events registered in the system through simple keyword based queries.
• Process manager that tracks event occurrence history, and analyzes it for the purpose of process monitoring.

Back to Top

Conclusion

Dealing with flexible workflows is becoming an increasingly important issue in present-day WfMSs. While a number of commercial products incorporate support for flexibility in various ways, accommodation of highly collaborative and dynamic workflows into the system remains a fundamental challenge. The proposed framework effectively supplements the capabilities of conventional WfMSs that are responsible for core structured processes through providing flexible supports for defining and executing ad hoc and unstructured processes found at the edges in process hierarchy within an organization.

Back to Top

Acknowledgement

This work was supported by the Korea Science and Engineering Foundation (KOSEF) grant funded by the Korea government (MOST) (No. R01-2007-000-11167-0)

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top

Back to top