From People to Services to UI: Distributed Orchestration of User Interfaces
The first paper, from University of Trento and Huawei Technologies, focused on a model for distributed user interfaces, bringing together people, web services and UIs in a single tool, rather than developing process models and UIs independently. They consider UI components (effectively a widget) as objects representing process state; changes in the UI will cause underlying process services to be invoked, and changes in the underlying process/data will change the UI representation.
The goal is to bring together the needs of UI synchronization and service orchestration into a single language, even though UIs are event-based and services are invoked as part of control flows, and the don’t typically speak the same language. To do this, they extended BPEL to create BPEL4UI, which is the standard business process execution language with UI-specific modeling constructs. This manifests as a three new basic object types: pages, actors and UI components. They extended a BPEL Eclipse plug-in to included these new object types, allowing the UI to modeled as part of the BPEL process model, and added hooks so that the BPEL engine calls a UI engine server rather than the UI directly.
Other solutions tend to focus on either one or two of services, UI support and people; the tool that they have built, MarcoFlow, supports all three in a unified environment.
A Collaborative Approach to Maturing Process-Related Knowledge
The second paper, from SAP Research and University of Applied Sciences Northwestern Switzerland, introduced an approach for supporting knowledge workers in sharing process-related knowledge using a hybrid between a top-down process model and a bottom-up “wisdom of the crowds” for capturing work practices in process models.
A predefined process model provides a context for experience sharing, allowing people to collaborate around tasks in the process by creating “task patterns” that include descriptions of shared experiences in executing that task, and the related resources such as documents or links. Others executing that same task can access the associated task pattern to see what other people did in the same situation in the past, including problem and solution scenarios. The task pattern content is stored in MediaWiki, and linked directly to the execution environment for a task (although it doesn’t go as far as one of the social software workshop participants recommended yesterday in integrating the collaborative feedback directly into the execution environment).
Currently, all of the information in the task pattern is entered manually, but in response to an audience question, he said that they are looking at adding process analysis that can include more automated process intelligence and mining data as well.
Self-adjusting Recommendations for People-driven Ad-hoc Processes
The last paper of the session, from Vienna University of Technology and German Research Center for Artificial Intelligence, looked at providing guidance to a user in ad hoc workflows, allowing for the exploitation of best practices while still allowing individual flexibility. By flexibility, they specifically mean the ability to adapt a process flow on the fly by adding, skipping or re-ordering process steps. As in the previous presentation, they noted that processes may be based on pre-defined process models or crowdsourced best practices, but rarely both. In some cases, personalized recommendations can be beneficial to a specific user at a relatively high skill level, representing their personal best practices and high degree of flexibility that may not be suited for the general population of users. Crowd-based recommendations, however, may be more useful for less skilled users doing more general work who need to follow overall best practices in order to ensure process quality and efficiency.
Comparing the actual actions of a user relative to the recommendation establishes and reinforces their classification as either Eagle (expert user with personalized recommendations and work methods) or Flock (follows crowd-based recommendations for best practices); an Eagle will be reset to the middle of the classification if there is a repeatedly high error rate, and from there will migrate either back to Eagle or to Flock, depending on their behavior. A Flock user may migrate to Eagle over time as they become more skilled, or may stay as Flock based on their performance.
The prototype was not in a standard BPM system, but an overlay on email exchanges, intercepting and analyzing message traffic to detect process steps. An initial simple sequential process is modeled – and later refined by the user actions – and when the system recognizes that these steps are occurring in the email traffic, it pops up the process recommendations and tracks the user’s actual actions.