Higher-Order Process Engineering (HOPE) is a business process modeling solution that elegantly overcomes unpredictable hurdles when it comes to dealing with integration, (runtime) variability, and interoperability. Even in its simplicity-oriented version it allows for a powerful plug&play fashion, where processes and services can be moved around just like data.


The overall goal: Narrowing the semantic gap between application experts (business-level) and technical experts
The overall goal: Narrowing the semantic gap between application experts (business-level) and technical experts

Business process modeling solutions aim at tightly involving the application expert (i.e. an expert of the field that is not necessarily a technical expert) in the software development process to avoid common and costly misunderstandings during requirements engineering as well as to decrease time to market. Their popularity, especially the recent standard BPMN 2.0, clearly indicates the need for this new involvement. At the same time there are unpredictable hurdles when it comes to dealing with integration, (runtime) variability, and interoperability. Higher-Order Process Engineering (HOPE) elegantly overcomes these issues as even in its simplicity-oriented version it allows for a powerful plug&play fashion, where processes and services can be moved around just like data. This is reminiscent to standardization efforts known from hardware like the universal serial bus (USB).

In IT projects in general two worlds meet: The business level and the technical level. Unfortunately, they have in general use different terminology, have a different field and level of expertise, and most importantly they have a different mindset. This mismatches can be subsumed with the notion semantic gap.

The major question is:

How can we narrow the semantic gap?

One way to approach the answer is to answer another question:

What — of the rich feature set on the technical level — can be transported up to the business level?

With HOPE we show, that rich features like higher-order processes and parametric polymorphy can be elevated to the business-level in a tamed and simplicity-oriented manner.



State of the Art

Computer-aided processes increasingly influence the daily life: be it for shopping, travel planning, travelling itself, tax declaration, or as part of business life, people are confronted with different software applications (i.e. in the web or as an app) all the time. The quality and flexibility is varying enormously. Additionally, there are very different solutions for almost the identical problem, even by the same provider, depending on the profile of a particular user/customer situation. The variance does not affect the look-and-feel, only, but also the required user process, and, at the technical level1, the application programming interfaces (APIs) for the interoperation between systems. As a consequence, users continuously have to struggle with this historically grown but unintended technical diversity, and producers with exploding maintenance costs.

Increased interest in business process modeling came with BPMN 2.0,2 due to its promise to make application-level business processes directly executable. It looked like an almost universal cure, as it seemed to close the semantic gap, the main source of ‘communication accidents’ between business and IT. A closer look reveals, that this dream becomes true only for very specific scenarios. Especially, it still does not support variability, as it lacks means to manage process variation and variant-rich systems.3 All current BPM standards like BPEL, BPMN and even the recent BPMN 2.0 are limited to fixed bindings between business activities in a model and the services or substructures they correspond to. Thus each variant has to be modeled explicitly via decision structures that are either modeling counterparts to if-and switch-clauses — in comprehensive but very large models — or maintained individually, as a collection of separate instances. Both alternatives cause severe problems:

  • whereas the comprehensive modeling leads to unmanageably large models,
  • the maintenance and support of many structurally similar individual variant models is a nightmare.

This is far away from the ideal of simplicity that made business process modeling so appealing in the first place.4 5


Concept

Enhancing BPM with a simplicity-oriented version of higher-order process passing breaks the spell. Being higher-order, it supports a very flexible form of (type-based) process integration. Furthermore, it introduces a new discipline of variability modeling6 that captures variants comprising functionality that has been unknown when the process started. Already deployed and even running processes can be seamlessly enhanced with new functionality, without changing their code base.

In fact, based on the higher-order concepts, (new) services and (component) processes can be selected, constructed, modified, and then safely passed as a parameter just like data. Though unlike data they may be plugged into activities and executed (played) at runtime. This plug&play approach allows one to add new components, services, and processes without the need to change the system or interrupt running processes. Even if this flexibility is not essential and all functionalities are known in advance, this results in drastic size reductions and more comprehensible models.

Controlling variability means controlling the exploding wealth of combinations, a concern orthogonal to computational aspects. Hence, especially at the level of (business) process modeling, variability concerns and computational aspects should be separated in favor of simplicity and understandability.

Simplicity-orientation in this regard refers to the user-centeredness — focused on the business level — of the paradigm shielding the user from the complexity. This goes hand in hand with aiming at compatibility between components which is essential for plug&play semantics. Correspondingly, two different types of abstraction layers support a strict enforcement of separation of concerns: hierarchical modeling and preconfiguration of activities.

The need for hierarchical modeling is owed to the fact that on the one hand systems gain complexity, resulting in the need to break the specifications down into manageable parts in a divide and conquer fashion. On the other hand, with the increasing globalization of systems and therefore processes,7 the number of participants involved in the development process is also steadily increasing. This results in a complex network of participants, where a technical expert on one level is application expert on the next lower level, in terms of getting more technical, and so forth. Preconfiguration of activities further helps to guard the modeler from the complexity of handling data-flow as well as doing repetitive work.

Compatibility is achieved via sophisticated (type-aware) interface descriptions of activities leading to compositionality. Data-dependencies are consequently modeled via a common execution context sharing resources between activities. The models are hierarchical starting on a domain-specific level, down to a technical level where each activity bases on structures of a conventional programming language (i.e. the target language).

The idea is to give more power to application experts as well as avoiding technological breaks, leading to more complete process models which

  • are a better basis for communicating with technical experts,
  • allow for more concise validations on the modeling level, and
  • need no round-trip engineering as they are based on semantically well-defined structures of a target language.

Therefore, these process models are directly executable. The major challenge is to prevent becoming overly complex. The key to this is to consequently support the paradigm separation of concerns.


  1. The application/business level and the technical level are distinguished. While the technical level concerns the
    IT aspects and the implementation, the business level is focused on the essence of the application. That is, it
    comprises all levels above implementation, which should not require programming expertise. 
  2. T. Allweyer. BPMN 2.0-Business Process Model and Notation. Bod, 2009. 
  3. The need for variant-rich systems is often addressed via static approaches in general subsumed by the notion of (software) product-lines in the literature. 
  4. Tiziana Margaria and Bernhard Steffen. Simplicity as a Driver for Agile Innovation. IEEE Computer, 43(6):90–92, 2010. 
  5. T. Margaria and B. Steffen. Special session on “Simplification through Change of Perspective”. In Software Engineering Workshop (SEW), 2011 34th IEEE, pages 67–68. IEEE, Jun 2011. 
  6. Sven Jörges, Anna-Lena Lamprecht, Tiziana Margaria, Ina Schaefer, and Bernhard Steffen. A Constraint-based Variability Modeling Frame- work. International Journal on Software Tools for Technology Transfer (STTT), 14(5):511–530, 2012. 
  7. E.g., end-to-end-processes naturally comprise various management levels.