Active Knowledge Modeling

Several languages have been proposed for business process modelling. Though most of them follow the conventional representation of processes as a series of steps, they emphasize different aspects of processes and related structures, such as organizations, products, and data. Consequently, they are suited for different kinds of processes. Even if you are determined to use a particular technique, knowledge of alternative approaches can still guide the modelling, by surfacing complementary points of view. In addition to the common transformational process models, this post discusses block structured languages, storytelling, and process modeling languages that are hierarchical, flow-oriented, role-oriented, communication-oriented, declarative, goal-oriented, timelines, product and document state machines etc.

Tranformational Process Models

Most process models take a transformational (input-process-output) approach. Processes are divided into activities, which may be divided further into sub-activities. Each activity takes inputs, which it transforms to outputs. Input and output relations thus define the sequence of work. Commonly, control flow structures for sequences, iteration, parallel and alternative branching are included. This perspective is chosen for the standards of the Workflow Management Coalition (WfMC) and the Object Management Group (OMG) as well as most commercial systems. BPMN, IDEF, Data Flow Diagrams, UML Activity diagrams, ARIS Event-driven Process Chains, and Petri nets are well-known transformational languages.

A simple transformational process model, with organizational roles and information resources.

The example above shows a typical transformational process model, with decomposition, sequences and branching. In this case, it is combined with organizational roles and information resources as mechanisms, similar to IDEF. (This particular notation was refined to support both structured, unstructured, and semi-structured processes, as part of my previous research work).

Block Structured Programming Languages

Programming languages can be seen as a particular kind of transformational process models. BPEL is an example of such a language with an XML syntax. However, transforming a high level, graphical process model like BPMN to a block structured language like BPEL is not always straight-forward. In particular, graphs can be used to express more complex flow and loop patterns, which cannot be directly translated. Some graphical languages also tolerate partial ordering of tasks, leaving out details which an execution level language needs. We do not regard this type of languages as modeling languages, though some time ago, there was a standard which proclaimed itself as a modeling language, which followed this paradigm.

Storytelling

At the other extreme from programming languages, we find natural language. Storytelling has long been recognized as perhaps the most important means for communicating and teaching processes and experiences, informally over lunch, around the watercooler or coffee maker. Modeling combines text with visual representations. In particular, use cases with user stories and pattern languages rely on semi-structured text to convey a richer, more nuanced context than formalisms allow.

The lessons that process modellers can take away from narratives, are probably less important for modeling than for how we can make our models interesting, entertaining, easy to understand etc. for the audience. The narrative structure may, but need not, follow the conventional straight-forward sequences that most processes are modelled according to. The introduction to a narrative typically sets the scene and introduces the plot or main theme, while the end of the story offers some sort of point, resolution, morale etc. Some process modelers, especially in the area of project management, likewise structure the process into three parts (subprocesses) for initiation, main body, and closing. Sometimes the pattern is repeated inside the main body, introducing internal opening and closing steps. I am not a fan of this pattern because if emphasises administration and ceremony, while almost all the real work takes place inside a single subprocess 2-3 layers down in the work breakdown structure.

Most stories are about concrete individuals, doing something concrete in a concrete situation. Stories, even fiction, can convey true meaning effectively because they offer a rich description of a concrete context. The listener/reader will often recognize parallels between their own situation, the world they know, and the one in which the story takes place. Process modelers should thus be vary of abstracting away too much of the context, of replacing typical individuals (persona in stories) by generic roles, classes, etc.

Hierarchical Process Models

Project management, planning, and monitoring typically relies on manual scheduling of activities. Rather than complete process graphs, work breakdown structures (WBS) or process trees are most common in this domain. Typically the tree is complemented by a numbering of tasks that propose a logical sequence, but detailed routing logic is seldom modelled. A hierarchical model directs attention to what should be done, without bothering too much about the details of how it should be coordinated. Some task modelling languages add more structure to process trees by defining different kinds of decompositions, similar to gateways in transformational process:

• Multiple, for repetitive loops,
• AND for concurrent subprocesses,
• XOR for alternative subprocesses,
• OR for more complex or uncertain structures,
• Sequential, for ordered processes, and
• One-at-a-time, for subprocesses that can be executed in any order, but only one at a time.

Compared to the standard transformational languages, these features open up for more partially structured, semi-formal processes. By focusing on the breaking up of processes into steps, hierarchical languages further avoid some of the dangers of over-serialisation associated with transformational models. Studies have shown that some modelling consultants project the sequence of the interview with users onto the resulting process models, introducing sequences that are not really required for the processes to work correctly. Increased concurrency is important for process improvement aiming to reduce cycle times, so over-serialisation is a real problem.

Flow-Oriented Process Models

In process industries, we have encountered business process modelling notations that apply ideas from the chemical process plants that are the core of that industry. For instance, piping diagrams show the flows between activities as pipes. Different sizes of pipes are used to separate the major strands of the workflow from the rarer special cases and exception handling flows. This metaphor, seeing the process as a fluid flow, directs focus to the size and content of the workflow, not just the activities of the diagram. It is very similar to standard transformational process models, but with a twist in perspective that is the opposite of the one achieved by hierarchical process models.

Timeline Process Models

Gantt charts and similar models that organize process steps along the time axis, is particularly useful for project management, planning, and monitoring. Some of these diagrams explicitly represent sequential order relationships between activities, but more commonly the dependencies are implicitly represented in the ordering along the time axis. In quality management, process models typically include many concurrent activities, with well defined phases and decision gates controlling the handover from one phase to the next. With the strong emphasis on stages and gates, these models are typically also laid out in a timeline, though the many concurrent activities  create a matrix structure, rather than a timed sequence.

Process Models Focusing on Artifact States

In some domains the end result of the process is most important. In bureaucratic case processing, legal rules typically define the different documents that are to be produced. Systems have therefore been designed that define the process as a set of state transitions on the case file, which represents the process instance. State transitions deal with addition and revision of documents or a change in the state of a document (e.g. from draft to approved). This approach makes it simple to document legal compliance and compliance with ITIL and similar standards. In product design and engineering, document status is also important, but the status of the different product elements is even more essential. For instance, a quality control process model defines each milestone in terms of which status the different product elements should have, according to this state transition diagram:

Process model represented as a state machine for product components. The complexity of the process is captured by the relationships between the product components, instead of in a process model.

One important benefit of this approach is of course that it directs focus on the value-adding steps in the process. It is also aligned with current project and process management practices in many industries. In these domains, the dependencies between product components are often far more important for collaboration and coordination than the dependencies that can be represented between process steps. The process above is extremely simple, the complexity of the full business process arises from the number of concurrent process instances (up to several thousand), and the dependencies between these instances, because the product components they work on are connected in some way. Some transformational languages, e.g. event-driven process chains (EPC), allow a combination of a product- and a process-oriented approach, through constructs like event or state that are connected to the sequence flows between activities.

Role-Oriented Process Models

Roles can be applied as an optional primary structure for processes in BPMN and in UML activity diagrams. This technique originates in earlier languages such as Role Interaction Nets (RIN) and Role Activity Diagrams (RAD). In these notations, the activities performed by a role are grouped together in the diagram, either in swimlanes (RIN), or inside boxes (RAD). The use of roles as a structuring concept, makes it very clear who is responsible for what. RAD has also been merged with speech acts (see below) for interaction between roles. The role-based approach also has limitations, e.g. making it difficult to change the organisational distribution of work. It primarily targets analysis of administrative procedures, where formal roles are important. Below we see an example from a BPMS application, where the roles involved are different infrastructure layers, rather than organizational roles.

Role-oriented process model (in BPMN, for BPEL execution in Intalio)

For an interesting approach that continues this work, have a look at human interaction management. 

Process Models for Communication and Collaboration

The ActionWorks process support system is informed by speech act theory, which extends the notion that people use language to describe the world with a focus on how people use language for coordinating action and negotiating commitments. The main strength of this approach is that it facilitates analysis of the communicative aspects of the process. It highlights that each process is an interaction between a customer and a performer, represented as a cycle with four phases: preparation, negotiation, performance and acceptance. The dual role constellation is a basis for work breakdown, e.g. the performer can delegate parts of the work to other people, and she then becomes the customer of their tasks. Process models may thus spread out  through decomposition, as shown in this paper.

This explicit representation of communication and negotiation, and especially the structuring of the conversation into predefined speech act steps, has also been criticised. Minimal support for situated conversations, the danger that explication leads to increased external control of the work, and a simplistic one-to-one mapping between utterances and actions are among the weaknesses. On the other hand, it has been reported that the language-action approach is useful when people act pragmatically and don’t always follow the encoded rules of behaviour, i.e. when the communication models are interactively activated. The language action approach has also found new application areas in electronic business transactions and web services.

Communication loops can also be applied for capturing the processes of more creative collaboration. Louridas and Loucopoulos  propose a modelling language for representing the argumentation and rationale of decision making processes. Extending the vocabulary of Issue Based Information Systems (IBIS), they break down the decision making process into goal (issue to be resolved), hypotheses (positions or solution alternatives), justifications (arguments pro and contra the hypotheses), and finally the decision that completes the loop.

Reflective design process loop

Decision rationale loops can be decomposed by spreading out new loops for sub-discussions, just like Action loops. The strength of this approach is that it combines an intuitive language for representing argumentative structures (IBIS) with a process loop. The decisions made and the rationale behind them are captured for later reference and learning. On the other hand, this notation does not fully cover business process modelling, so it should be combined with other approaches.

System Dynamic Process Models

Holistic systems thinking regards causal relations as mutual, circular and non-linear. The straightforward sequences in business process models are seen as an over-simplification that hides important facts. This perspective is also reflected in mathematical models of interaction. System dynamics have been utilised for analysis of complex relationships in cooperative work arrangements. A simple example is depicted below. It shows one aspect of the interdependencies between design and implementation in a software development project. The more time you spend designing, the less time you have for coding and testing, hence you better get the design right the first time. This creates a positive feedback loop, a “snowball effect” similar to “analysis paralysis” that must be balanced by some means, in our example iterative development. System dynamic process models are used for analysis and simulation, but not for operation. Most importantly, system dynamics shows the complex interdependencies that are so often ignored in conventional notations, illustrating the need for articulating more relations between tasks, beyond simple sequencing.

A simple system dynamic process model with causal loops.

Goal-Oriented, Declarative and Constraint-Based Process Models

Declarative process modelling languages have also been promoted. Constraint based languages do not prescribe a course of events, rather they capture the boundaries within which the process must be performed, leaving the performers to control the internal details. Constraints define the goals and activities, the why and what of the processes, but not the how. Instead of telling people what to do when, these systems warn about rule violations and enforce constraints. Thus, common problems with over-serialisation are avoided. On the other hand, the resulting models are logic formulas, and not very comprehensible. A graphic depiction is difficult since it would correspond to a visualisation of several possible solutions to the set of constraint equations constituting the model. The support for articulation of planned  tasks is limited. Consequently, constraints are often combined with transformational models. Constraints mainly capture outside control on the workflow, not articulation inside the process group. On the other hand, these approaches put forward a central question to how we interpret business process models: Does a blank sheet mean that anything, any process can happen (no constraints), or nothing, no process?

Agent-based process environments often use goal-oriented, declarative process models. Agents are assigned goals and constraint rules, but are left to work out for themselves the details of how to reach these goals. Such systems facilitate adaptive, distributed, and decentralised processs execution. Typically, the work breakdown structure, reflecting goals and sub-goals, is represented, but the ordering of the tasks is not. Scheduling of tasks is done dynamically during process enactment, influenced by modelled preconditions, inputs and outputs that reflect causal dependencies among tasks. Fuzzy logic can be applied to open up a richer set of alternatives to the agents that interpret and activate the model.

Process Visualization

In addition to the different kinds of graph structures applied in process modelling notations, other visualization tricks can be applied to represent and communicate a business process more clearly. Symbols, colours, positions, and sizes of activities can say a lot to human actors, without formally representing anything according to the modelling language rules. These useful visual techniques include placing related activities together, placing activities roughly in the order from left to right that they should be performed in, and using colours to separate different kinds of activities or the roles and disciplines responsible for them. Size is typically used for saying something about the importance or amount of work involved in each task. Some go even further, developing full-fledged process visualization tools. An example is shown below. Here a 3D Gantt diagram is used for monitoring and coordinating thousands of concurrent activities. The horizontal axis across is used for organizing activities according to where (in which system area) they occur.

Process visualization in a 3D Gantt world

Summary

This post has discussed a number of complementary approaches to the standard input-output sequential process modelling notations. Some approaches better reflect the influence of business goals, communication, organizational hierarchies, or product structures upon the processes, while others emphasise the cyclical nature of process dependencies. While a standard approach to process modelling is probably simplest and most straight-forward, we believe in keeping other perspectives in mind as well, in order to improve the quality of business process models.