Tag: IntlBPM

Remco Dijkman of the Technical of Technology of Eindhoven presented a paper on Diagnosing Differences between Business Process Models, focusing on behavioral differences rather than the structural differences that were examined in the previous paper by IBM. The problem is the same: there are two process models, likely two versions of the same model, and there is a need to detect and characterize the differences between them.

He developed a taxonomy of differences between processes, both from similar processes in practice and from completed trace inequivalences. This includes skipped functions, different conditions (gateway type with same number of paths traversed), additional conditions (gateway conditions with a potentially larger number of paths traversed), additional start condition, different dependencies, and iterative versus once-off.

You can tell it’s getting near the end of the day — my posts are getting shorter and shorter — and we have only a panel left to finish off.

Jochen Kuester of IBM Zurich Research presented a paper on Detecting and Resolving Process Model Differences in the Absence of a Change Log, co-authored by Christian Gerth, Alexander Foerster and Gregor Engels. Detecting differences would be done in the case where a process model is changed, and there is a need to detect and resolve the differences between the models. They focus on detection, visualization and resolution of differences between the process models.

Detection of differences between process model, which involves reconstructing the change log that transforms one version to another. This is done by computing fragments for the process models similar to the process structure tree methods that we saw from other IBM researches yesterday, then identifying elements that are identical in both models (even if in a different part of the model), elements that are in the first model but not the second, and those that are in the second model but not the first. This allows correspondences to be derived for the fragments in the process structure tree. From there, they can detect differences in actions/fragments, whether an insertion, deletion or move of an action within or between fragments.

They have a grammar of compound operations describing these differences, which can now be used to create a change log by creating a joint process structure tree formed by combining the process structure tree of both models, tagging the nodes with the operations, and determining the position parameters of each of the operations.

They’ve prototyped this in IBM WebSphere Process Modeler.

The afternoon started with the section on Quantitative Analysis, beginning with a presentation by Anne Rozinat from the Technical University of Eindhoven on Workfow Simulation for Operational Decision Support Using Design, Historic and State Information, with the paper co-authored by Moe Wynn, Wil van der Aalst, Arthur ter Hofstede and Colin Fidge.

As she points out, few organizations are using simulation in a structured and organized way; I’ve definitely seen this in practice, where process simulation is used much more during the sales demo than in the customer implementations. She sees three issues with how simulation is done now: resources are modeled incorrectly, simulation models may have to be created from scratch, and there is more of a focus on design than on operational decisions through lack of integration of historical operational data back into the model. I am seeing these last two problems solved in many commercial systems already: rarely is it necessary to separately model the simulation from the process model, and some number of modeling systems allow for the reintegration of historical execution data to drive the simulation.

Their approach uses three types of information:

• design information, from the original process model
• historic information, from historical execution data
• state information, from currently executed workflows, primarily for setting the initial state of the simulation

They have created a prototype of this using YAWL and ProM, and she walked through the specifics of how this information is extracted from the systems, how the simulation model is generated, and how the current state is loaded without changing the simulation model: this latter step can happen often in order to create a new starting point for the simulation that corresponds to the current state in the operational system.

This last factor has the potential to turn simulation into a much more interactive and frequently-used capability, if you consider the capability of being able to run a simulation forward from the current state in the operational system in order to predict behavior over the upcoming period of time: consider, for example, being able to use the current state as the initial properties of the simulation, then adding resources to predict how long it will take to clear the actual backlog of work in order to determine the optimal number of people to add to a process at this point in time. This turns short-term simulation into a operational decision-making tool, rather than just a design tool.

Ksenia Wahler of the IBM Zurich Research lab presented the first paper in the Modelling Paradigms & Issues section, on Predicting Coupling of Object-Centric Business Process Implementations, co-authored by Jochen Kuester.

Although activity-centric approaches are in the mainstream — e.g., BPMN for modeling and BPEL for implementation — object-centric approaches are emerging. The main principles of object-centric approaches are that process logic is distributed among concurrently running components, each component represents a life cycle of a particular object, component interaction ensures that overall logic is correctly implemented.

They are using Business State Machines (BSM) in IBM WebSphere Integration Developer to model this: object-centric modeling is offered as an alternative to BPEL for service orchestration. It uses finite state automation, tailored for execution in a service-oriented environment, with event-condition-action transitions. The advantages of this approach is that it is distributable, adaptable, and maintainable. However, this works when objects are independent, but this is rarely the case; hence the research into the management of coupling of objects. What they found is that rather than using a unidirectional mapping from the activity-centric view to the object-centric implementation, wherein the models can get out of sync, their approach is to feed back from any changes in the object-centric implementation to the process model. They needed to establish a coupling metric in order to asses the coupling density of the object model, as well as develop the mapping from activity-centric process models to object life cycle components, which they have based on workflow patterns.

She showed examples of translation from activity-centric to object-centric models: starting with a BPMN process model, consider the objects for which each activity is changing the state, and re-model to show the state changes for each object and the interactions between the objects based on their state changes. Each state-changing object becomes a component, and interactions between objects in terms of control handovers and decision notifications become wires (connections) between components in the assembly model. The degree of coupling is calculated from the interactions between the components, and a threshold can be set for the maximum acceptable degree of coupling. Objects with a high degree of coupling may be candidates for merging into a single life cycle, or may be targeted for refactoring (actually not true refactoring since it doesn’t preserve behavior; more like simplifying) the process model in order to reduce control handovers and decision notifications.

This type of object-centric approach is new to me, and although it is starting to make sense, I’m not sure that these notes will make sense to anyone else. It’s not clear (and the speaker couldn’t really clarify) the benefit of using this approach over an activity-centric approach.

Michael Rosemann from the BPM Research Group at Queensland University of Technology, gave us today’s opening keynote on Understanding and Impacting the Practice of BPM, exploring the link between academia and industry. QUT hosted this conference last year, and has a strong BPM program.

He believes that research can be both rigorous and relevant, satisfying the requirements of both industry and academia, and his group works closely with industry, in part by offering BPM training but also looking to foster networking across the divide. It can be a mutually beneficial relationship: research impacts practice through their findings, and practice provides understanding of the practical applicability and empirical evidence to research.

Obviously I’m in strong agreement with this position: part of why I’m here is to bring awareness of this conference and the underlying research to my largely commercial audience. I had an interesting conversation earlier today about how vendors could become more involved in this conference; at the very least, I believe that BPM vendors should be sending a product development engineer to sit in the audience and soak up the ideas, but there’s probably also room for some low level of corporate sponsorship and a potential for recruitment.

Rosemann discussed how research can (and should) be influenced by industry demand, although there’s not a direct correlation between research topics and what’s missing in industry practice. There is some great research going on around process analysis and modeling, and some smaller amount (or so it seems) focused on process execution. He looks at the distinction between design science research — where the goal is utility — and behavioral science research — where the goal is truth — and the relationship between them: design science produces BPM artifacts to provide utility to behavioral science, which in turn provides truth through BPM theories.

BPM artifacts produced by research include constructs (vocabulary and symbols) such as process modeling techniques, models (abstractions and representations) such as process reference models, methods (algorithms and practices) such as process modeling methodologies, and instantiations (implemented and prototype systems) such as workflow prototype systems. Through an artifact’s lifecycle, design scientists test its soundness (internal consistency) and completeness (general applicability), and the behavioral scientists test its effectiveness at solving the problem and adoption in practice. In other words, design scientists create the artifacts, the artifacts are implemented (in a research facility or by industry), and behavioral scientists test how well they work.

There is a BPM community of practice in Australia that hosts events about BPM: originally just a showcase to expose QUT research to industry and government, it has become a much more collaborative community where the practitioners can indicate their interest in the research areas. All of the QUT research students have to have their elevator pitch worked out — why is their research important, and its applicability — which is going to start to tune their thinking towards where their research might (eventually) end up in practice.

He showed a BPM capability framework, showing various capability areas mapped against key success factors of strategic alignment, governance, methods, IT, people and culture; this framework has been replicated by a number of different organizations, including Gartner, to show areas on which companies need to focus when they are implementing BPM. He discussed other areas and methods of research, and the value of open debate with the practitioners; as always, it’s gratifying to see my blog used as an example in a presentation, and he used a snapshot of my post on the great BPMN debate as well as posts by Bruce Silver and Michael zur Muehlen. He walked through a number of other examples of interaction between research and industry, using a variety of techniques, and even the concept of private (consumer) process modeling.

He ended with a number of recommendations for BPM researchers:

• have a BPM research vision
• design a BPM research portfolio
• conduct critical-path research
• seek impact without compromising research rigor
• build and maintain an industry network
• collaborate with complementary research partners

Interestingly, a question at the end resulted in a discussion on BPM vendors and how they have the potential to span boundaries between research and practice. The larger vendors with significant research facilities are represented here: apparently almost 40% of the attendees here are from industry, although it appears that most are from deep within the research areas rather than product development or any customer-facing areas.

Jussi Vanhatalo of the IBM Zurich Research Lab presented a paper on the Refined Process Structure Tree, co-authored by Hagen Voelzer and Jana Koehler. We’re in the last section of the day, on formal methods.

The research looks at the issues of parsing a business process model, and they offer a new parsing technique called the refined process structure tree that provides a more fine-grained model. Applications for parsing include:

• translating a graph-based process model (e.g., BPMN) into a block-based process model (e.g., BPEL)
• speeding up control-flow analysis
• pattern-based editing
• processing merging
• understanding large process models
• subprocess detection

He showed us an example of the last use case, subprocess detection, where sections of a process are detected and replaced by subprocesses, making the process more understandable (as we saw in the earlier paper on modularity).

There are a few requirements for parsing:

• uniqueness: e.g., the same BPMN model is always translated to the same BPEL process
• modularity: e.g., a local change in BPMN translates to a local change in BPEL
• fast computation of parse tree, e.g., for process version merging, pattern-based editing, or control-flow analysis
• granularity

The Normal Process Structure Tree, which they have presented in earlier research, is both unique and modular, and represents a hierarchy of canonical (non-overlapping) fragments. Its computing time is linear.

The Refined Process Structure Tree uses a relaxed notion of a fragment through specific definitions of boundary (entry and exit) nodes, and allows only for non-overlapping fragments that can be assembled into a hierarchy. Like the NPST, it is unique and modular, but is more fine-grained than the NPST (presumably because of the relaxed definition of a fragment). It can also be computed in linear time, and he walked through a linear time algorithm for computing the RPST.

In this paper, they assumed that there is only one start and one end node in a process, and that loops have separate entry and exit node; since the publication of this paper, their research has progressed and they have lifted both of these restrictions.