Process flexibility and evolution
Process flexibility and evolution topic folder
The academic Database research community has had huge impact on enterprise-scale data management, with the relational data model and more recently query languages and systems for XML. But following the lead of Juliana Freire I ask the question: what data model is used in the majority of databases? The answer: spreadsheets, by far. This is because spreadsheets offer a very lightweight basis to start with, and can be enriched over time. And the simplicity of spreadsheets outweighs their shortcomings from a data management perspective, including inability for multiple users to share a spreadsheet, lack of a query language, challenges in data integration, and absence of data integrity mechanisms.
Similarly, much of BPM research has focused on large-scale, enterprise-level solutions. Many of the small-scale business processes used at the department level in commercial enterprises, and by many community organizations, are specified and executed in ad hoc ways, often using spreadsheets as an anchor to keep track of progress. There is a rich opportunity for our community to create a lightweight approach to BPM, analogous to spreadsheets for data management.
Two key differences between data mgmt and BPM are (a) the presence of process, and (b) the presence of side-effects. The ubiquity of SaaS solutions enables an approach for addressing (b). Specifically, imagine that the BPM framework is hosted in the cloud, and has access to a variety of side-effecting services, e.g., for sending email, for scheduling events, for storing/accessing data in repositories, and for transferring money. (This also overcomes the problem of spreadsheets that a single copy of a spreadsheet cannot be shared by multiple users.)
What about (a), the modeling of process, or more generally, the modeling of both the process and the data involved in a business process. I would argue that the artifact-centric approach offers a useful starting point for creating a candidate light-weight BPM model. Importantly, the artifact approach provides an intuitively natural way of modeling data and process in a unified way. The data component of artifacts could be represented using nested data structures (e.g., JSON at the implementation level), enabling extensibility of the data schemas over time. With regards to process, the artifact “lifecycles” could use a relatively simple model that follows the Case Management paper by van der Aalst, Weske, and Grunbaüer from 2005, that describes placing the family of tasks in a business process into a directed acyclic graph (DAG), and uses conditions as “guards” that govern when a task should be launched. (Roll backs and exceptions are handled as a layer above this.) The DAG would correspond to the family of possible “happy” paths, and offers relatively easy extensibility. While this is a declarative model, the left-to-right nature of a DAG provides some of the intuitive advantages of an activity-flow-based model. For simple business processes we would need only one artifact type, which is somewhat analogous to using a single tab in a spreadsheet. If more than one artifact type is needed, then synchronization between artifact instances must be addressed. This is perhaps a bit intricate to specify and visualize; the work on correlation by Sun, Xu, and Su (ICSOC 2012) will be relevant here. (See also the BPM 2013 paper by Meyer, Pufahl, Fahland and Weske.)
Of course a BPM schema will be more complex than a basic spreadsheet, and so we should allow some richness in the proposed visualization for BPM schemas. In particular, three kinds of pane can be imagined. The first would show the data snapshot of an artifact instance. This could take advantage of the tree-based nature of the data model to enable showing the data snapshot at different levels of abstraction. The second kind of pane could show the status of the lifecycle for an artifact instance. In particular it could show the DAG of tasks, and use colors to indicate their status (e.g., executed, not yet executed, cannot be executed for this instance based on already existing information). Finally, the third kind of pane could show the relationship between multiple artifact instances, including representations of where, e.g., one artifact instance was created by another, or one artifact instance synchronizes in some way with another. There would also be links between the different kinds of panes, to enable users to easily navigate between different views of an artifact instance.
Finally, if a team were to start building up a lightweight framework in the spirit of the above, it would be important to find a real world application area and user group that could be using the framework. Only by having a vibrant user community can the project quickly learn what aspects of the framework are working, what aspects are not working, and what features should be incorporated into the next release. Barbara Weber has suggested the collaborative process of paper writing as a candidate application area. This could include tasks for launching a collaborative paper-writing exercise, registering individual authors, deciding on a venue, incorporating key dates, storing/accessing versions of the paper, etc. Having a “dashboard” for the status of a paper-in-progress, including indication of key deadlines and tasks yet to be completed, could be quite useful to many of us in the academic publishing circuit.
So here are some questions for people to comment on:
1) What kind of model would you propose as the basis for a lightweight BPM framework?
2) What real-world application area would be appropriate for testing out and refining a prototype lightweight BPM framework?
3) What criteria or use-cases should the BPM community use to assess whether one lightweight BPM framework is better than some other lightweight BPM framework?
To effectively be able to manage their business processes, companies must be able to deal with changes in their environment in a quick and flexible way. Examples for such changes include regulatory adaptations (e.g., to the introduction of Sarbanes-Oxley or Basel II), market evolution, changes in customer behavior, process improvement, and strategic shifts. The ability to deal with such changes is called process flexibility and includes the ability to handle exceptions, to deal with unforseen situations through process adaptations, to deal with evolving business processes, to cope with business process variability, and to deal with unpredictability. Process flexibility and evolution have emerged to a key concern of BPM as indicated by the high number of successful submissions on this topic in the last couple of years.
Topics in this track include:
- Process exception handling
- Adaptive and context-aware processes
- Case handling
- Process-enhanced groupware
- Process change management
- Monitoring and provenance across change
We hope that next year there will many successful submissions related to process flexibility and evolution !!!