Blockchains for Business Process Management - Challenges and Opportunities

Blockchains for Business Process Management - Challenges and Opportunities JAN MENDLING,Wirtschaftsuniversität Wien, Austria INGO WEBER,Data61, CSIRO, Australia WIL VAN DER AALST,Eindhoven University of Technology, The Netherlands JAN VOM BROCKE,University of Liechtenstein, Liechtenstein CRISTINA CABANILLAS,Wirtschaftsuniversität Wien, Austria FLORIAN DANIEL,Politecnico di Milano, Italy SØREN DEBOIS,IT University of Copenhagen, Denmark CLAUDIO DI CICCIO,Wirtschaftsuniversität Wien, Austria MARLON DUMAS,University of Tartu, Estonia SCHAHRAM DUSTDAR,TU Wien, Austria AVIGDOR GAL,Technion - Israel Institute of Technology, Israel LUCIANO GARCÍA-BAÑUELOS,University of Tartu, Estonia GUIDO GOVERNATORI,Data61, CSIRO, Australia RICHARD HULL,IBM Research, United States MARCELLO LA ROSA,Queensland University of Technology, Australia Authors’ addresses: J. Mendling, Wirtschaftsuniversität Wien, Vienna, Austria; email: [email protected]; I. Weber, Data61, CSIRO, Sydney, Australia; email: [email protected]; W. van der Aalst, Eindhoven University of Tech-nology, Eindhoven, The Netherlands; email: [email protected]; J. vom Brocke, University of Liechtenstein, Vaduz, Liechtenstein; email: [email protected]; C. Cabanillas, Wirtschaftsuniversität Wien, Vienna, Austria; email: cristina. cabanillas@ wu.ac.at; F. Daniel, Politecnico di Milano, Milan, Italy; email: [email protected]; S. Debois, IT University of Copenhagen, Copenhagen, Denmark; email: [email protected]; C. Di Ciccio, Wirtschaftsuniversität Wien, Vienna, Austria; email: [email protected]; M. Dumas, University of Tartu, Tartu, Estonia; email: [email protected]; S. Dustdar, TU Wien, Vienna, Austria; email: [email protected]; A. Gal, Technion - Israel Institute of Technology, Haifa, Israel; email: [email protected]; L. García-Bañuelos, University of Tartu, Tartu, Estonia; email: [email protected]; G. Governatori, Data61, CSIRO, Brisbane, Australia; email: [email protected]; R. Hull, IBM Research, Yorktown Heights, United States; email: [email protected]; M. La Rosa, Queensland University of Technology, Brisbane, Australia; email: [email protected]; H. Leopold, Vrije Universiteit, Amsterdam, The Netherlands; email: h.leopold@ vu.nl; F. Leymann, IAAS, Universität Stuttgart, Stuttgart, Germany; email: [email protected]; J. Recker, Queensland University of Technology, Brisbane, Australia; email: [email protected]; M. Reichert, Ulm University, Ulm, Germany; email: [email protected]; H. A. Reijers, Vrije Universiteit, Amsterdam, The Netherlands; email: [email protected]; S. Rinderle-Ma, University of Vienna, Vienna, Austria; email: [email protected]; A. Solti, Wirtschaftsuniversität Wien, Vienna, Austria; email: [email protected]; M. Rosemann, Queensland University of Technology, Brisbane, Australia; email: [email protected]; S. Schulte, TU Wien, Vienna, Austria; email: stefan. [email protected]; M. P. Singh, North Carolina State University, Raleigh, United States; email: [email protected]; T. Slaats, University of Copenhagen, Copenhagen, Denmark; email: [email protected]; M. Staples, Data61, CSIRO, Sydney, Australia; email: [email protected]; B. Weber, Technical University of Denmark, Lyngby, Denmark; email: [email protected]; M. Weidlich, Humboldt-Universität zu Berlin, Berlin, Germany; email: [email protected]; M. Weske, Hasso- Plattner-Institute, Universität Potsdam, Potsdam, Germany; email: [email protected]; X. Xu and L. Zhu, Data61, CSIRO, Sydney, Australia; email: [email protected]. HENRIK LEOPOLD,Vrije Universiteit, The Netherlands FRANK LEYMANN,IAAS, Universität Stuttgart, Germany JAN RECKER,Queensland University of Technology, Australia MANFRED REICHERT,Ulm University, Germany HAJO A. REIJERS,Vrije Universiteit, The Netherlands STEFANIE RINDERLE-MA,University of Vienna, Austria ANDREAS SOLTI,Wirtschaftsuniversität Wien, Austria MICHAEL ROSEMANN,Queensland University of Technology, Australia STEFAN SCHULTE,TU Wien, Austria MUNINDAR P. SINGH,North Carolina State University, United States TIJS SLAATS,University of Copenhagen, Denmark MARK STAPLES,Data61, CSIRO, Australia BARBARA WEBER,Technical University of Denmark, Denmark MATTHIAS WEIDLICH,Humboldt-Universität zu Berlin, Germany MATHIAS WESKE,Hasso-Plattner-Institute, Universität Potsdam, Germany XIWEI XU and LIMING ZHU,Data61, CSIRO, Australia Blockchain technology offers a sizable promise to rethink the way interorganizational business processes are managed because of its potential to realize execution without a central party serving as a single point of trust (and failure). To stimulate research on this promise and the limits thereof, in this article, we outline the challenges and opportunities of blockchain for business process management (BPM). We first reflect how blockchains could be used in the context of the established BPM lifecycle and second how they might become relevant beyond. We conclude our discourse with a summary of seven research directions for investigating the application of blockchain technology in the context of BPM. Key Words and Phrases: Blockchain, business process management, research challenges 1 INTRODUCTION Business process management (BPM) is concerned with the design, execution, monitoring, and improvement of business processes. Systems that support the execution of processes have been used extensively by companies to streamline and automate intraorganizational processes. Yet, for interorganizational processes, challenges of joint design and a lack of mutual trust have hampered a broader uptake. Emerging blockchain technology has the potential to drastically change the environment in which interorganizational processes are able to operate. Blockchains offer a way to execute processes in a trustworthy manner even in a network without any mutual trust between nodes. Key aspects are specific algorithms that lead to consensus among the nodes and market mechanisms that motivate the nodes to progress the network. Through these capabilities, this technology has the potential to shift the discourse in BPM research about how systems might enable the execution, monitoring, or improvement of business processes within or across business networks. In this article, we describe what we believe are the main new challenges and opportunities of blockchain technology for BPM. This leads to directions for research activities to investigate both challenges and opportunities. Section 2provides a background on fundamental concepts of blockchain technology and an illustrative example of how this technology applies to business processes. Section 3focuses on the impact of blockchains on the traditional BPM lifecycle phases (Dumas et al. 2018). Section 4goes beyond it and asks which impact blockchains might have on core capability areas of BPM (Rosemann and vom Brocke 2015). Section 5summarizes this discussion by emphasizing seven future research directions. 2 BACKGROUND This section summarizes the essential aspects of blockchain technology and discusses initial research efforts at the intersection of BPM and blockchains. 2.1 Blockchain Technology In its original form, Blockchain is a distributed database technology that builds on a tamper-proof list of timestamped transaction records. Among other uses, it is employed for cryptocurrencies such as Bitcoin (Nakamoto 2008). Its innovative power stems from allowing parties to transact with others they do not trust over a computer network in which nobody is trusted. This is enabled by a combination of peer-to-peer networks, consensus-making, cryptography, and market mechanisms. Blockchain derives its name from the fact that its essential data structure is a chained list of blocks. This chain of blocks is distributed over a peer-to-peer network, in which every node maintains the latest version of it. Blocks can contain information about transactions. In this way, we can know, for instance, that a buyer has ordered 200 items of a particular type of material from a vendor at a specific time. When a new block is added to the blockchain, it is signed using cryptographic methods. In this way, it can be checked if its content and its signature match. For example, if we take the content c=“Buyer orders 200 items from vendor” and apply a specific hash function h(c), we get a unique result r. Every block is associated with a hash generated from its content and the hash value of the previous block in the list. Hash values thus uniquely represent not only the transactions within blocks but also the ordering of every block. This mechanism is at the basis of the chain. In case somebody would try to alter a transaction, this would change the hash value of its block and, therefore, break the chain. Since every node can create blocks in a peer-to-peer network, there has to be consensus on the new version of the blockchain, including a new block. This is achieved with consensus algorithms that are based on concepts such as proof-of-work or proof- of-stake (Bentov et al. 2016) and, more recently, proof-of-elapsed-time.1In proof-of-work, miners guess a value for a specific field to fulfill the condition that rmust be smaller than a threshold (which is dynamically adjusted by the network based on a predefined protocol). In proof-of-stake, miner selection considers the size of their stake, i.e., amount of cryptocurrency held by them. The rationale is that a high stake is a strong motivation for not cheating: if the miners cheat (and this is detected), the respective cryptocurrency will be devalued. The network protocols and dynamic 1Intel: Proof-of-elapsed-time (PoET). Available from http://intelledger.github.io/. adjustment of thresholds are designed to avoid network overload. In summary, these foundational blockchain concepts support two important notions that are also essential for business processes: the blockchain as a (tamper-proof) data structure captures the history and the current state of the network and transactions move the system to a new state. Blockchain offers an additional concept that is important for business processes, called smart contracts (Szabo 1997). Consider again the example of the buyer ordering 200 items from the vendor. Business processes are subject to rules on how to respond to specific conditions. If, for instance, the vendor does not deliver within two weeks, the buyer might be entitled to receive a penalty payment. Such business rules can be expressed by smart contracts. For instance, the Ethereum blockchain supports a Turing-complete programming language for smart contracts.2Thecodein these languages is deterministic and relies on a closed-world assumption: only information that is stored on the blockchain is available in the runtime environment. Smart contract code is deployed with a specific type of transaction. As with any other blockchain transaction, the deployment of smart contract code to the blockchain is immutable. Once deployed, smart contracts offer a way to execute code directly on the blockchain network, such as the conditional transfer of money in our example if a certain condition is fulfilled. By using blockchain technology, untrusted parties can establish trust in the truthful execution of the code. Smart contracts can be used to implement business collaborations in general and interorganizational business processes in particular. The potential of blockchain-based distributed ledgers to enable collaboration in open environments has been successfully tested in diverse fields ranging from diamond trading to securities settlement (Walport 2016). At this stage, it has to be noted that blockchain technology still faces numerous general technological challenges. A mapping study by Yli-Huumo et al. (2016) found that a majority of these challenges have not been addressed by the research community, though we note that blockchain developer communities actively discuss some of these challenges and suggest a myriad of potential solutions.3Some challenges can be addressed by using private or consortium blockchains instead of a fully open network (Mougayar 2016). In general, the technological challenges include the following (Swan 2015). Throughput in the Ethereum blockchain is currently limited to approximately 15 transaction inclusions per second (tps). In comparison, transaction volumes for the VISA payment network are 2,000 tps, on average, with a tested capacity of up to 50,000 tps. However, the experimental Red Belly Blockchain, which particularly caters to private or consortium blockchains, has achieved more than 400,000 tps in a lab test.4 Latency is also an issue. Transaction inclusion in the absence of network congestion takes a certain amount of time. In addition, a number of confirmation blocks are typically recommended to ensure that the transaction does not get removed due to accidental or malicious forking. This means that transactions can be seen as committed after 60 minutes on average in Bitcoin, or 3 to 10 minutes in Ethereum. Even with improvements of techniques such as the lightning network or side chains spawned off from the main chain, blockchains are unlikely to achieve latencies as low as centrally controlled systems. Size and bandwidth limitations are variations of the throughput issue: if the transaction volume of VISA were to be processed by Bitcoin, the full replication of the entire blockchain data structure would pose massive problems. Yli-Huumo et al. (2016) quote 214 PB per year, thus posing a challenge in data storage and bandwidth. Private and 2https://www.ethereum.org/. 3http://www.the-blockchain.com/2017/01/24/adi-ben-ari-outstanding-challenges-blockchain-technology-2017/. 4http://poseidon.it.usyd.edu.au/∼concurrentsystems/rbbc/. consortium chains and concepts such as the lightning network or side chains all aim to address these challenges. In this context, it is worth noting that most everyday users can use wallets instead, which require only small amounts of storage. Usability is limited at this point in terms of both developer support (lack of adequate tooling) and end-user support (hard to use and understand). Recent advances on developer support include efforts by some of the authors toward model-driven development of blockchain applications (García-Bañuelos et al. 2017;Tranetal.2017; Weber et al. 2016). Security will always pose a challenge on an open network such as a public blockchain. Security is often discussed in terms of the CIA properties (Dhillon and Backhouse 2000). First, confidentiality is per se low in a distributed system that replicates all data over its network but can be addressed by targeted encryption (Kosba et al. 2016). Second, integrity is a strong suit of blockchains, though challenges do exist (Eyal and Sirer 2014; Gervais et al. 2016). Third, availability can be considered high in terms of reads from blockchain owing to the wide replication but is less favorable in terms of write availability (Weber et al. 2017). New attack vectors exist around forking, e.g., through network segregation (Natoli and Gramoli 2017). These are particularly relevant in private or consortium blockchains. Wasted resources, particularly electricity, are owing to the consensus mechanism, in which miners constantly compete in a race to mine the next block for a high reward. In an empirical analysis, Weber et al. (2017) found that about 10% of announced new blocks on the Ethereum network were uncles (forks of length 1). This can be seen as wasteful but is just a small indication of the vast duplication of effort in proof-of-work mechanisms. Longer forks (at most of length 3) were extremely rare; thus, accidental forking seems unlikely in a well-connected network such as the Internet, but could occur if larger nations were cut off temporarily or even permanently. Alternatives to the proof-of-work, such as proof-of-stake (Bentov et al. 2016), have been discussed for a while and would be much more efficient. At the time of writing, they remain an unproven but highly interesting alternative. Proof-of-work makes very low assumptions in trusting other participants, which is well suited for an open network managing digital assets. Designing more efficient protocols without relaxing these assumptions has proven a challenge. Hard forks are changes to the protocol of a blockchain that enable transactions or blocks previously considered invalid (Decker and Wattenhofer 2013). They essentially change the rules of the game and therefore require adoption by a vast majority of the miners to be effective (Bonneau et al. 2015). While hard forks can be controversial in public blockchains, as demonstrated by the split of the Ethereum blockchain into a hard forked main chain and Ethereum Classic (ETC), this is less of an issue for private and consortium blockchains, in which such a consensus is more easily found. Many of these general technological challenges of blockchains are currently the focus of the emerging body of research. As noted, our main interest is in the potential of blockchain technology to enable a shift in BPM research. Our belief is vested both in the novel technological properties discussed above and in the already available attempts of using blockchain technology in the definition and implementation of fundamentally novel business processes. We review these attempts in the following. 2.2 Business Processes and Blockchain Technology We are not the first to identify the application potential of blockchain technology to business processes. In fact, several blockchains are currently adopted in various domains to facilitate the operation of new business processes. For example, Nofer et al. (2017) list applications in the financial Fig. 1. Supply chain scenario from Weber et al. (2016). sector, including cryptocurrency transactions, securities trading and settlement, and insurance as well as nonfinancial applications, such as notary services, music distribution, and various services such as proof of existence, authenticity, or storage. Other works describe application scenarios involving blockchain technology in logistics and supply chain processes, for instance, in the agricultural sector (Staples et al. 2017). A proposal to support interorganizational processes through blockchain technology is described by Weber et al. (2016): large parts of the control flow and business logic of interorganizational business processes can be compiled from process models into smart contracts that ensure that the joint process is correctly executed. So-called trigger components allow the connection of these interorganizational process implementations to Web services and internal process implementations. These triggers serve as a bridge between the blockchain and enterprise applications. The cryptocurrency concept enables the optional implementation of conditional payment and built-in escrow management at defined points within the process, when this is desired and feasible. To illustrate these capabilities, Figure 1 shows a simplified supply chain scenario, in which a bulk buyer orders goods from a manufacturer. The manufacturer, in turn, orders supplies through a middleman, which are sent from the supplier to the manufacturer via a special carrier. Without global monitoring, each participant has restricted visibility of the overall progress. This may very well be a basis for misunderstandings and shifting blame in cases of conflict. Model-driven approaches, such as those proposed by García-Bañuelos et al. (2017)and Weberetal. (2016), produce code for smart contracts that implement the process (see Figure 2). If executed using smart contracts on a blockchain, typical barriers complicating the deployment of interorganizational processes can be removed. (i) The blockchain can serve as an immutable public ledger so that participants can review a trustworthy history of messages to pinpoint the source of an error. This means that all state-changing messages have to be recorded in the blockchain. (ii) Smart contracts can offer independent process monitoring from a global viewpoint such that only expected messages are accepted and only if they are sent from the player registered for the Fig. 2. Smart contract snippet illustrating how code is generated from a BPMN model. It shows the implementation of function PlaceOrder from the above process model. This function is to be executed by the manufacturer, which is checked in Line 6. Subsequently, we check to see whether the function is activated in Line 7. If so, any custom task logic is executed and the activation of tasks is updated in Line 9. For more details, see García-Bañuelos et al. (2017). respective role in the process instance. (iii) Encryption can ensure that only the data that must be visible is public while the remaining data is readable only for the process participants who require it. These capabilities demonstrate how blockchains can help organizations to implement and execute business processes across organizational boundaries even if they cannot agree on a trusted third party. This is a fundamental advance, because the core aspects of this technology enable support of enterprise collaborations going far beyond asset management, including the management of entire supply chains, tracking food from source to consumption to increase safety, or sharing personal health records in privacy-ensuring ways among medical service providers. The technical realization of this advance is still nascent at this stage, although some early efforts can be found in the literature. For example, smart contracts that enforce process execution in a trustworthy way can be generated from BPMN process models (Weber et al. 2016)andfrom domain-specific languages (Frantz and Nowostawski 2016). Further cost optimizations are proposed by García-Bañuelos et al. (2017). Figure 2shows a code excerpt that was generated by this approach. In a closely related work, Hull et al. (2016) emphasize the affinity of artifact-centric process specification (Cohn and Hull 2009; Marin et al. 2012) for blockchain execution. Even at this stage, research on the benefits and potentials of blockchain technology is mixed with studies that highlight or examine issues and challenges. For example, Norta (2015,2016) discusses ways to ensure secure negotiation and creation of smart contracts for Decentralized Autonomous Organizations (DAOs), among others, in order to avoid attacks such as the DAO hack during which approximately US$ 60 million was stolen. This, in turn, was remediated by a hard fork of the Ethereum blockchain, which was controversial among the respective mining node operators and resulted in a part of the public Ethereum network splintering off into the ETC network. This split, in turn, caused major issues for the network in the medium term, allowing, among others, replay attacks in which transactions from Ethereum can be replayed on ETC. A formal analysis of smart contract participants using game theory and formal methods is conducted by Bigi et al. (2015). As pointed out by Norta (2016), the assumption of perfect rationality underlying the game-theoretic analysis is unlikely to hold for human participants. These examples show that blockchain technology and its application to BPM are at an important crossroad: technical realization issues blend with promising application scenarios; early implementations mix with unanticipated challenges. It is timely, therefore, for the scholarly community to discuss open questions in broad and encompassing ways. We do so in the two sections that follow. 3 BLOCKCHAIN TECHNOLOGY AND THE BPM LIFECYCLE In this section, we discuss blockchain in relation to the traditional BPM lifecycle (Dumas et al. 2018), including the following phases: identification, discovery, analysis, redesign, implementation, execution, monitoring, and adaptation. Using the traditional BPM lifecycle as a framework of reference allows us to discuss many incremental changes that blockchains might provide. 3.1 Identification Process identification is concerned with the high-level description and evaluation of a company from a process-oriented perspective, thus connecting strategic alignment with process improvement. Currently, identification is mostly approached from an inward-looking perspective (Dumas et al. 2018). Blockchain technology adds another relevant perspective for evaluating high-level processes in terms of the implied strengths, weaknesses, opportunities, and threats. For example, how can a company systematically identify the most suitable processes for blockchains or the most threatened ones? Research is needed into how this perspective can be integrated into the identification phase. Because blockchains have affinity with the support of interorganizational processes, process identification may need to encompass not only the needs of one organization but broader known and even unknown partners. 3.2 Discovery Process discovery refers to the collection of information about the current way a process operates and its representation as an as-is process model. Currently, methods for process discovery are largely based on interviews, walkthroughs, and documentation analysis, complemented with automated process discovery techniques over nonencrypted event logs generated by process-aware information systems (van der Aalst 2016). Blockchain technology defines new challenges for process discovery techniques: the information may be fragmented and encrypted, accounts and keys can change frequently, and payload data may be stored partly on-chain and partly off-chain. For example, how can a company discover an overall process from blockchain transactions when these might not be logically related to a process identifier? This fragmentation might require a repeated alignment of information from all relevant parties operating on the blockchain. Work on matching could represent a promising starting point to solve this problem (Cayoglu et al. 2014; Euzenat and Shvaiko 2013;Gal 2011). There is both the risk and opportunity of conducting process mining on blockchain data. An opportunity could involve establishing trust in how a process or a prospective business partner operates, while a risk is that other parties might be able to understand operational characteristics from blockchain transactions. There are also opportunities for reverse-engineering business processes, among others, from smart contracts. 3.3 Analysis Process analysis refers to obtaining insights into issues relating to the way a business process currently operates. At present, the analysis of processes mostly builds on data that is available inside of organizations or from perceptions shared by internal and external process stakeholders (Dumas et al. 2018). Records of processes executed on the blockchain yield valuable information that can help to assess the caseload, durations, frequencies of paths, parties involved, and correlations between unencrypted data items. These pieces of information can be used to discover processes, detect deviations, and conduct root cause analysis (van der Aalst 2016), ranging from small groups of companies to an entire industry at large. The question is which effort is required to bring the available blockchain transaction data into a format that permits such analysis. 3.4 Redesign Process redesign deals with the systematic improvement of a process. Currently, approaches such as redesign heuristics build on the assumption that there are recurring patterns of how a process can be improved (Vanwersch et al. 2016). Blockchain technology offers novel ways of improving specific business processes or resolving specific problems. For instance, instead of involving a trustee to release a payment if an agreed condition is met, a buyer and a seller of a house might agree on a smart contract instead. The question is where blockchains can be applied for optimizing existing interactions and where new interaction patterns without a trusted central party can be established, potentially drawing on insights from related research on Web service interaction (Barros et al. 2005). A promising direction for developing blockchain-appropriate abstractions and heuristics may come from data-aware workflows (Marin et al. 2012) and BPMN choreography diagrams (Decker and Weske 2011). Both techniques combine two primary ingredients of blockchain, data and process, in a holistic manner that is well suited for top-down design of interorganizational processes. It might also be beneficial to formulate blockchain-specific redesign heuristics that could mimic how Incoterms (Ramberg 2011) define standardized interactions in international trade. Specific challenges for redesign include the joint engineering of blockchain processes between all parties involved, an ongoing problem for choreography design. 3.5 Implementation Process implementation refers to the procedure of transforming a to-be model into software components executing the business process. Currently, business processes are often implemented using process-aware information systems or business process management systems inside single organizations. In this context, the question is how the involved parties can make sure that the implementation that they deploy on the blockchain supports their process as desired. Some of the challenges regarding the transformation of a process model to blockchain artifacts are discussed by Weber et al. (2016). Several ideas from earlier work on choreography can be reused in this new setting (Chopra et al. 2014; Decker and Weske 2011; Mendling and Hafner 2008;Telang and Singh 2012; van der Aalst and Weske 2001; Weber et al. 2008). Note that choreographies have not been adopted by industry to a large extent yet. Despite this, they are especially helpful in interorganizational settings, where it is not possible to control and monitor a complete process in a centralized fashion because of organizational borders (Breu et al. 2013). To verify that contracts between choreography stakeholders have been fulfilled, a trust basis, which is not under control of a particular party, needs to be established. Blockchains may serve to establish this kind of trust between stakeholders. An important engineering challenge on the implementation level is the identification and definition of abstractions for the design of blockchain-based business process execution. Libraries and operations for engines are required, accompanied by modeling primitives and language extensions of BPMN. Software patterns and anti-patterns will be helpful to engineers designing blockchainbased processes. There is also a need for new approaches for quality assurance, correctness, and verification, as well as for new corresponding correctness criteria. These can build on existing notions of compliance (van der Aalst et al. 2008), reliability (Subramanian et al. 2008), quality of service (Zeng et al. 2004), or data-aware workflow verification (Calvanese et al. 2013) but will have to go further in terms of consistency and consideration of potential payments. Furthermore, dynamic partner binding and rebinding is a challenge that requires attention. Process participants will have to find partners, either manually or automatically, on dedicated marketplaces using dedicated look-up services. The property of inhabiting a certain role in a process might itself be a tradable asset. For example, a supplier might auction off the role of shipper to the highest bidder Ingo Weber, Jochen Haller, and Jutta Mülle. 2008. Automated derivation of executable business processes from choreographies in virtual organizations. International Journal of Business Process Integration and Management (IJBPIM’08) 3, 2, 85–95. Ingo Weber, Xiwei Xu, Regis Riveret, Guido Governatori, Alexander Ponomarev, and Jan Mendling. 2016. Untrusted business process monitoring and execution using blockchain. In Proceedings of 14th International Conference on Business Process Management (BPM’16). Lecture Notes in Computer Science, Vol. 9850. Springer, Berlin, 329–347. J. Yli-Huumo, D. Ko, S. Choi, S. Park, and K. Smolander. 2016. Where is current research on blockchain technology? – A systematic review. PLoS ONE 11, 10, e0163477. Liangzhao Zeng, Boualem Benatallah, Anne Ngu, Marlon Dumas, Jayant Kalagnanam, and Henry Chang. 2004. QoS-aware middleware for web services composition. IEEE TSE 30, 5, 311–327.