{ HAUPTBEITRAG / BLOCKCHAIN SUPPORT FOR BUSINESS PROCESSES

Blockchain Support forCollaborative Business Processes

Claudio Di Ciccio · Alessio CecconiMarlon Dumas

Luciano Garcia-BañuelosOrlenys López-Pintado · Qinghua Lu

Jan Mendling · Alexander PonomarevAn Binh Tran · Ingo Weber

IntroductionCollaboration between different organizations isessential to achieve greater, common goals. Considerfor example a supply chain, where collaboration ofdifferent companies yields a product via the dif-ferent steps from production to delivery [11]. As oftoday, the integration of processes of each involvedparty requires extensive information exchange.This makes the design and management of suchinterorganizational business processes difficult.Furthermore, the multitude of message exchangesentails data redundancy and lack of full knowledgeof how, when and where tasks have been conducted.For these reasons, companies still rely on authorizedthird parties to mediate and control the execution ofinterorganizational business processes.

Blockchain technology offers the unprece-dented capability to support such processes [10].The blockchain as a totally ordered data structurecan capture the history and the current state of thebusiness processes, whose transitions are registeredby the transactions. As it is tamper-proof, the loggingof executed processes cannot be subject to dispute oncounterfeiting actions from process actors or thirdparties. Since it is replicated among the nodes inthe network, the information on the process statecan be shared and updated locally to every node,thus allowing the process participants to monitorthe new process transitions and, if necessary, bereadily prompted to the next action. Other interestedparties such as auditors can inspect past executionsfor compliance. The pseudonymity guaranteed bythe protocol enables collaboration in open environ-ments. The programmability offered by blockchainssuch as Ethereum [2] is paramount to implement

the workflow, as smart contracts can encode thebusiness logic of processes and enforce its rules bydesign. Consensus algorithms, thus, create a trust-worthy infrastructure on top of potentially untrustednodes, and smart contracts make for a trusted pro-cess execution among partially trustable parties.As a result, although the technology is still novel,its adoption as a backbone for business processmanagement systems (BPMSs) is rapidly evolvingtowards a general approach for executing businessprocesses.

In this paper we illustrate how to design andrun interorganizational business processes usingblockchains. In particular, we illustrate the princi-ples and rationale of the model-driven approach tobusiness process automation on blockchains andthen report on recent advances in the field.

The remainder of the paper is structured asfollows. In Section “Model-Driven Engineering andExecution of Blockchain Processes”, we provide themotivation for our work and provide an overview of

https://doi.org/10.1007/s00287-019-01178-x© The authors 2019.

Claudio Di Ciccio · Alessio Cecconi · Jan MendlingWirtschaftsuniversität Wien,Vienna, AustriaE-Mail: {claudio.di.ciccio, alessio.cecconi,jan.mendling}@wu.ac.at

Marlon Dumas · Luciano Garcia-Bañuelos ·Orlenys López-PintadoUniversity of Tartu,Tartu, EstoniaE-Mail: {marlon.dumas, luciano.garcia, orlenyslp}@ut.ee

Qinghua Lu · Alexander Ponomarev · An Binh Tran ·Ingo WeberData61, CSIRO,Sydney, NSW, AustraliaE-Mail: {qinghua.lu, alexander.ponomarev, an.binh.tran,ingo.weber}@data61.csiro.au

182 Informatik_Spektrum_42_3_2019

AbstractBlockchain technology provides basic buildingblocks to support the execution of collaborativebusiness processes involving mutually untrustedparties in a decentralized environment. Sev-eral research proposals have demonstrated thefeasibility of designing blockchain-based col-laborative business processes using a high-levelnotation, such as the Business Process Modeland Notation (BPMN), and thereon automati-cally generating the code artifacts required toexecute these processes on a blockchain plat-form. In this paper, we present the conceptualfoundations of model-driven approaches forblockchain-based collaborative process execu-tion and we compare two concrete approaches,namely Caterpillar and Lorikeet.

how to design interorganizational business processesfor execution on the blockchain. Thereupon, we de-scribe the support of process execution as providedby the novel Lorikeet [12] (Section “The LorikeetSystem”) and Caterpillar [8] (Section “The Caterpil-lar System”) systems. Finally, in Section “Discussionand Outlook”, we discuss the current status and lookat the future of this research stream.

Model-Driven Engineeringand Execution of Blockchain Processes

Blockchains can operate as decentralized pro-grammable platforms [15]. Platforms such asEthereum [2] allow for the encoding of smart con-tracts, namely fully executable distributed programsoperating on the blockchain. Smart contracts dictatehow business is to be conducted among contractingparties. They, thus, naturally allow for the enact-ment of processes on-chain. The knowledge ofprogramming languages for blockchain-specificapplications is crucial to understand the behaviorof those programs, which tend to become mono-lithic algorithms regulating the data to exchange,the control-flow logic, the access grants and thebusiness rules.

Working in the blockchain is mostly a preroga-tive of individuals with such technical knowledge.Furthermore, existing solutions for business-to-blockchain services are often tailored to customerson a case-based approach. Organizations willing to

move the coordination and tracking of the informa-tion exchange of their inter-organizational businessprocesses onto the blockchain are thus hampered bytechnical skills requirement. Managers and businessanalysts should be interfaced through a model-driven approach, thus reducing the need to knowencoding language details to create, manage and ver-ify smart contracts underpinning the collaborativeprocesses [16, Ch. 1].

In traditional business process management,this abstraction has long been established throughprocesses notations like BPMN [4]. A modern BPMSlets the user define and manage a process throughhigh-level notation. The system then manages theimplementation details, thus hiding the stream-line between the high-level design language andthe software code behind the executable process. Atthe time of writing, such an abstraction has not yetbeen achieved for the blockchain. With blockchains,the problem is twofold: on the one hand, there isthe need for abstracting the design from the imple-mentation of smart contracts; on the other hand,a framework for their integration with processes isyet to be defined. The preference is to not introduceyet another process modeling language but to rely onexisting established ones extended with blockchainfeatures.

The design of smart contracts should be compre-hensible, fast, reliable and verifiable. The automatedgeneration of smart contracts code as interfaces tobusiness processes can allow for faster prototyp-ing and inspection already at the level of models.This would diminish the hindrance to the alignmentbetween the expected behavior of the business pro-cess, and its implementation as supported by theblockchain. This solution would bring a higher de-gree of customizability than a catalogue of contracttemplates, such as the ones offered by the Cordablockchain.

To answer that call for standardization, differentproposals are emerging from academia and industry.These proposals attempt to apply already existing in-terorganizational process representations, includingprocess choreographies [9, 14] and orchestrationdiagrams [8] from the BPMN standard.

Figure 1 depicts a choreography diagram,namely a particular type of process representationfocused on the information flow between organi-zations, rather than on the internal workflows ofeach actor. The parties in a collaborative business

Informatik_Spektrum_42_3_2019 183

{ BLOCKCHAIN SUPPORT FOR BUSINESS PROCESSES

Fig. 1 A process choreography diagram

Fig. 2 The process in Fig. 1 as a collaboration diagram [14]

process cooperate through message exchanges. Theblockchain records these messages and checks or en-forces that these exchanges occur in a certain order.The process of each party remains off-chain and ishidden from the other actors.

An orchestration diagram such as the one inFig. 2 details the individual processes of the partic-ipants. Communications are depicted as in-bound

or out-bound message exchanges occurring whencertain activities are performed. The blockchainis the shared process execution platform whereevery party executes their sub-processes and sendor receive messages within the orchestration.

In the following sections, we present two novelexamples of systems enacting processes on theblockchain: Lorikeet and Caterpillar. Both sys-

184 Informatik_Spektrum_42_3_2019

Fig. 3 The software architecture of Lorikeet

tems are based on the Ethereum blockchain andallow for smart contract deployment on public,private or permissioned blockchains. The for-mer uses the blockchain as the message exchangemechanism for process choreographies, whilethe latter deploys the entire collaborative processon-chain.

The Lorikeet System

Overview and Design PrinciplesLorikeet is a model-driven engineering (MDE) toolfor the development of blockchain applications inthe space of business processes and asset control.Management of assets is considered to be the first“killer application” of the blockchain, starting withfungible assets like cryptocurrency (Bitcoin, Ether,etc.) and tokens (second-tier coins that are managedon existing blockchain networks like Ethereum, suchas Golem or Gnosis). Business processes that man-age nonfungible assets (e. g., by transferring carsor land titles) are a promising application domainfor blockchains. Unlike fungible assets, nonfungi-ble assets can be highly individualized, which canintroduce inefficiencies and uncertainty, leading tocounterparty risks. The management of nonfungibleassets traditionally relies on a centralized trustedauthority, which again causes trust issues. A systemthat enables the automation of business processes onthe blockchain, therefore, should not overlook theaspects pertaining to asset management.

Lorikeet can automatically produce blockchainsmart contracts from business process modelsand asset data schemata. Lorikeet incorporatesthe registry editor Regerator [13] and implementsthe BPMN translation algorithms from both [14]and [5]. In a traditional BPMS, the process model isthe artifact or blueprint which is enacted. In con-trast, Lorikeet creates the code that implementsthe process, and the code is subsequently executed.The generated code can be reviewed, adapted oraugmented before execution. This feature supportsthe potential need for building trust into the smartcontracts generated and helps technical expertsunderstand the code. Furthermore, it allows forrapid prototyping at the beginning and later ex-tension toward a production system. Finally, MDEallows for amendment of the code beyond the ex-pressiveness of process model notations. It is anentirely separate tool from Caterpillar [7], whichwe describe in the next section. Lorikeet is in com-mercial use by Data61 and has been applied innumerous industry projects. A demonstration pa-per [12] outlines the tool architecture and usage.The content of this section is partly based on thatpublication.

ArchitectureLorikeet is a well-evaluated tool that is used for cre-ating blockchain smart contracts in industry andacademia. Figure 3 illustrates the architecture ofLorikeet, which consists of a modeler user interface

Informatik_Spektrum_42_3_2019 185

{ BLOCKCHAIN SUPPORT FOR BUSINESS PROCESSES

Fig. 4 A screenshot of the Lorikeet business process modeler

(UI, shown in Fig. 4), and back-end componentsincluding the BPMN translator, Registry generatorand Blockchain trigger.

The modeler UI component is presented asa web application for users to build business pro-cess and registry models. Business processes aremodeled in BPMN 2.0. Lorikeet extends that stan-dard to support representation of, and interactionwith, registries in the BPMN process model. Theextension comprises two new elements, namely Reg-istryReference and ActionInvocation, in terms ofnew graphical notations and new XML attributes.A RegistryReference represents an asset data storeon a blockchain, while an ActionInvocation showsthe asset registry action to invoke. On the registryside, the registry modeler provides a form for usersto fill in the registry model input. The registry modelconsists of four parts, including basic information(registry name, description, user-defined data fieldsand their types), registry type (single or distributed),basic CRUD operations and advanced operations(record lifecycle management and foreign key).Specifically, an access control policy is providedto regulate the registry manipulations. Process in-stances can also manipulate the registry records.For an action invocation from the process instanceto the registry, changes to the registry record arefinalized only after the execution of the process step

logic is completed. Since registry actions could fail,there is a check box on Lorikeet’s user interface foratomic behavior across registry actions and busi-ness process tasks: if marked as atomic, the registryupdate and the process state change either both failor succeed.

The back-end components, including the BPMNtranslator, Registry generator, and Blockchain trig-ger, are built to adhere to a microservice-basedarchitecture and are deployed independently asDocker containers. The BPMN translator automat-ically generates Solidity smart contracts from theaforementioned BPMN models. The smart contractsinclude the information to call registry functionsand to instantiate and execute the process model.The Registry generator creates Solidity smart con-tracts as well, based on registry models that provideinformation on the data structure, registry types,plus basic and advanced operations. Users canthen deploy the smart contracts on the blockchain.The Blockchain trigger communicates with anEthereum blockchain node and handles compila-tion, deployment and interaction with Solidity smartcontracts.

The BPMN and registry modeler UI interactswith the back-end microservices via an API gate-way. The API gateway forwards API calls from themodeler UI, such as translating a BPMN model,

186 Informatik_Spektrum_42_3_2019

to the corresponding microservice. Figure 4 de-picts the business process modeler UI of Lorikeet.It is split into two panels: one for modeling pro-cesses in BPMN, on the left-hand side, and oneshowing the source code, on the right. Once theuser applies changes to the BPMN model, thecorresponding Solidity smart contract code isaltered correspondingly at design time. The ap-pearance and concept of the registry modeler UIis similar to the business process modeler UI.Lorikeet has been used within international col-laborations with academics and industry partners.A screencast demonstrating the usage of the Lori-keet tool can be found at https://drive.google.com/open?id=1rpy-oHbDVkXa6u4Fn73wSX8rINn1sv3U.

The Caterpillar System

Overview and Design PrinciplesCaterpillar’s aim is to enable its users to build na-tive blockchain applications to enforce the correctexecution of collaborative business processes start-ing from a BPMN process model. In this context,the meaning of “native” is that code artifacts de-ployed on the blockchain encode all the executionlogic captured in the process model. Specific-ally, Caterpillar aims at fulfilling the followingthree design principles [8]. First, the collabora-tive process is modeled as if all the parties sharedthe same process execution infrastructure (theblockchain). Accordingly, the starting point forimplementing a collaborative business processis a single-pool BPMN process model and nota collaborative process model or a choreographymodel where parties communicate via messageexchanges. Second, the full state of the process in-stance and of its subprocess instances is recordedon the blockchain. All the metadata required inorder to retrieve the links between a given pro-cess instance and its related subprocess instancesare also recorded on the blockchain. Third, theexecution of a process instance can proceed evenif all the off-chain components of Caterpillar areunavailable.

To achieve these principles, Caterpillar trans-lates a BPMN process model into a set of smartcontracts, which can enforce the business processwithout making assumptions about any of the off-chain components that trigger transactions on thesecontracts. While Caterpillar comes with off-chain

components for deploying, triggering and monitor-ing business processes, these off-chain componentsare optional. Parties can, thus, either directly in-voke the smart contract transactions without goingthrough Caterpillar’s off-chain components or im-plement their own runtime. Accordingly, multipleinstances of the off-chain runtime component maybe running simultaneously (e. g., one instance perparticipant).

ArchitectureThe architecture of Caterpillar comprises threelayers, as shown in Fig. 5. The lower layer, namely theOn-Chain Runtime, implements the process execu-tion logic as a set of smart contracts spread acrossfive components. The central component of thislayer, namely the Workflow Handler, encodes thecontrol-flow perspective of the process. This com-ponent is responsible for determining which tasks(work items) are enabled within a given process in-stance. On the right-hand side, the Service Bridgeand Worklist Handler manage the interactions withexternal applications and users and validate the dataproduced by the execution of a task. The fourth com-ponent, Contract Factories, provides a configurationmechanism to create new instances of a process.For example, a Factory establishes which worklistis used by the users to interact with the process orhow a process must be bound to a subprocess inthe process hierarchy. Finally, the Runtime Registryis a smart contract that keeps track of the processinstances and their relation with other contractsin the On-Chain Runtime. The Runtime Registry isa critical component of the architecture, as it al-lows for the recovery of the status of any processinstance, independently of any application mon-itoring the process off-chain. The Ethereum Logprovides a medium for interaction between off-chain and on-chain components. For example, asthe execution of a task must be mined as a transac-tion in the blockchain, an event can be emitted inthe log to notify the external components that theminers accepted the execution. Finally, the ProcessRepository stores and provides access to compi-lation artifacts and metadata required to deploythe smart contracts and tracking the process in-stances off-chain. Unlike the On-chain Runtime andthe Ethereum Log, the Process Repository is storedoff-chain in other decentralized networks like theInterPlanetary File System (IPFS), which provides

Informatik_Spektrum_42_3_2019 187

{ BLOCKCHAIN SUPPORT FOR BUSINESS PROCESSES

Fig. 5 The software architecture of Caterpillar

tamper-resilient storage but at a lower cost than theEthereum blockchain.

The middle layer, namely the Off-Chain Run-time, provides a means for external applications tointeract with the components of the bottom layer ina service-oriented fashion. The Off-Chain Runtimeconsists of five components. From left to right, thefirst one is the BPMN Compiler, which is responsiblefor translating the BPMN models into smart con-tracts. In a second step, the BPMN Compiler interactswith a standard Solidity Compiler to produce themetadata (i. e., EVM bytecode and ABI definitions)required for the deployment of the smart contracts inEthereum. The Deployment Mediator is responsiblefor creating new instances of the process. In addition,the Deployment Mediator triggers the compilation ofa model and serves to (re)bind process contracts,factories, worklists and services, not necessarily

produced by Caterpillar but relying on the structureoutlined by its interfaces. The Execution Monitorcomponent allows for the querying of the processexecution state (e. g., which tasks are enabled to beexecuted and to execute such tasks). Last, the EventMonitor is a listener component for events emitted inthe Ethereum Log, which pushes notifications to theExecution Monitor or other external applications.

The top layer, namely the Web Portal, exposesthe functionalities of the Off-Chain Runtime compo-nents to end users (e. g., the process stakeholders).The Web Portal provides three panels. First, theModeling Panel allows drawing or uploading BPMNmodels which are deployed later via the DeploymentMediator. Second, the Configuration Panel supportsthe binding/rebinding of relations on the processcontracts already deployed. Last, the ExecutionPanel, depicted in Fig. 6, offers a visual representa-

188 Informatik_Spektrum_42_3_2019

Fig. 6 A screenshot of the Caterpillar execution panel

tion of the process status and allows for the executionof tasks.

Discussion and OutlookIn this paper, we analyzed the current state of theart for the model-driven design and implementa-tion of blockchain-based process execution andmonitoring – the first research challenge in [10].In order to ground the analysis, we presented tworesearch prototypes in the field, namely Caterpil-lar and Lorikeet. Table 1 compares the features ofthese two systems. They share the common aim ofexploiting the features of blockchain technologyto ensure that a collaborative business process, in-volving untrusted parties, abides to a given BPMNprocess model. Moreover, they both rely on com-piling a BPMN process model into Solidity smartcontracts, with the difference that Caterpillar addi-tionally provides predefined runtime componentsthat are packaged together with the compiled code.Lorikeet supports asset control and access control

Table1

Features of Lorikeet and Caterpillar

Lorikeet Caterpillar

Model execution approach MDE (code generation) MDE (code generation)BPMN elements support Medium HighDiscovery of incorrect behavior Supported SupportedSequence enforcement Supported SupportedParticipant selection Predefined N/AData sharing Mixed AllAsset control Supported Not supportedAccess control Supported Not supported

to restrict access to operations and data, whereasCaterpillar, in its current version, is focused oncontrol-flow aspects. On the other hand, Caterpil-lar provides almost full coverage of the control-flowperspective of BPMN, whereas Lorikeet provideslimited support.

Both Lorikeet and Caterpillar are focused onBPMN-style process models. Other proposals haveinvestigated the possibility of modeling blockchain-based collaborative process models using alternativeparadigms such as artifact-centric process model-ing [6]. The advancements brought about by thoseendeavors have already facilitated applications suchas the automated tracking of process instances onthe blockchain [3] and will aid more advancedtasks, like automated discovery and auditing forblockchain-based processes.

Important issues to resolve for future studiesmainly pertain to the connection between real-world objects and the digital space of blockchains.Indeed, business processes often have a tight bond

Informatik_Spektrum_42_3_2019 189

{ BLOCKCHAIN SUPPORT FOR BUSINESS PROCESSES

with physical assets and resources. Therefore, up-dates on their status should be notified within theblockchain space, and commands triggered fromsmart contracts may need to be conveyed outwardsto actually modify their status. To that extent, therole of in-bound and out-bound oracles seem promi-nent. Studies on the requirements that they have tomeet in this context and investigations on their in-tegration with existing approaches, are, therefore,paramount. Another aspect to be examined is thattransactions recorded in the most recent blockscannot be taken for granted, as blockchains guar-antee only eventual consistency as long as Proof ofWork is the main consensus model. This fact col-lides with the expenses or hurdles that an off-chainrollback or compensation might require, shouldcommands be executed on the physical world basedon transactions from forks that are no longer valid.By the same line of reasoning, engineering the datamanagement is key in the context of process au-tomation, and even more so when blockchains comeinto play. The trade-off between on-chain and off-chain data involves both governance and pragmaticaspects. On the one hand, the storage of processdata on-chain entails higher gas costs and posessecurity threats. On the other hand, resorting tooff-chain data signifies the potential renouncementof tamper-proof, signed recordings, and looserlinks between process flows and data flows. Ei-ther way, studies should be conducted to addressby design the privacy concerns that arise whensensitive data are stored in the context of processexecution [1].

As outlined in [10], the research communitiesinvolved will engage in endeavors in diverse di-rections, including not only the aforementionedtechnical ones, but also regarding the strategic deci-sions of the organizations embracing the blockchaintechnology to implement their interorganizationalprocesses. With this paper, by proposing nascentconceptual foundations of model-driven approachesfor blockchain-based collaborative process execu-tion, we have reported on the initial, promisingsteps toward overcoming the many challenges thatlie ahead of scientific investigators.

Open Access. This article is distributed under theterms of the Creative Commons Attribution 4.0 In-ternational License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use,distribution, and reproduction in any medium, pro-vided you give appropriate credit to the originalauthor(s) and the source, provide a link to the Cre-ative Commons license, and indicate if changeswere made.

Funding. Open access funding provided by ViennaUniversity of Economics and Business (WU).

References1. Basin D, Debois S, Hildebrandt T (2018) On purpose and by necessity: compliance

under the GDPR. In: FC. Springer, Berlin Heidelberg2. Dannen C (2017) Introducing Ethereum and Solidity: Foundations of Cryptocur-

rency and Blockchain Programming for Beginners. Apress3. Di Ciccio C, Cecconi A, Mendling J, Felix D, Haas D, Lilek D, Riel F, Rumpl A,

Uhlig P (2018) Blockchain-based traceability of inter-organisational businessprocesses. In: BMSD. Springer, Cham, pp 56–68

4. Dumas M, La Rosa M, Mendling J, Reijers HA (2018) Fundamentals of businessprocess management. 2nd edn. Springer, Berlin Heidelberg

5. Garcia-Bañuelos L, Ponomarev A, Dumas M, Weber I (2017) Optimized executionof business processes on blockchain. In: BPM. Springer, Cham, pp 130–146

6. Hull R, Batra VS, Chen Y, Deutsch A, Heath III FFT, Vianu V (2016) Towardsa shared ledger business collaboration language based on data-aware processes.In: ICSOC. Springer, Cham, pp 18–36

7. López-Pintado O, Garcia-Bañuelos L, Dumas M, Weber I (2017) Caterpillar:A blockchain-based business process management system. In: BPM Demos. CEUR-WS

8. López-Pintado O, Garcia-Bañuelos L, Dumas M, Weber I, Ponomarev A (2018)CATERPILLAR: A business process execution engine on the Ethereum blockchain.Technical report. http://arxiv.org/abs/1808.03517

9. Madsen MF, Gaub M, Høgnason T, Kirkbro ME, Slaats T, Debois S (2018) Collab-oration among adversaries: Distributed workflow execution on a blockchain. In:FAB

10. Mendling J, Weber I, van der Aalst WMP, vom Brocke J, Cabanillas C, Daniel F,Debois S, Di Ciccio C, Dumas M, Dustdar S, Gal A, Garcia-Bañuelos L, Governa-tori G, Hull R, La Rosa M, Leopold H, Leymann F, Recker J, Reichert M, Reijers HA,Rinderle-Ma S, Solti A, Rosemann M, Schulte S, Singh MP, Slaats T, Staples M,Weber B, Weidlich M, Weske M, Xu X, Zhu L (2018) Blockchains for business pro-cess management – challenges and opportunities. ACM Trans Manag Inf Syst9(1):4:1–4:16

11. Snyder LV, Shen ZJM (2011) Fundamentals of supply chain theory. Wiley,Hoboken

12. Tran AB, Lu Q, Weber I (2018) Lorikeet: A model-driven engineering tool forblockchain-based business process execution and asset management. In: BPMDemos. CEUR-WS, pp 56–60

13. Tran AB, Xu X, Weber I, Staples M, Rimba P (2017) Regerator: a registry generatorfor blockchain. In: CAiSE Forum. CEUR-WS, pp 81–88

14. Weber I, Xu X, Riveret R, Governatori G, Ponomarev A, Mendling J (2016) Un-trusted business process monitoring and execution using blockchain. In: BPM.Springer, Cham, pp 329–347

15. Wood G (2017) Ethereum: A secure decentralised generalised transaction ledgereip-150 revision (759dccd – 2017-08-07). https://ethereum.github.io/yellowpaper/paper.pdf. Accessed: 2018-01-03

16. Xu X, Weber I, Staples M (2019) Architecture for blockchain applications.Springer, Berlin Heidelberg

190 Informatik_Spektrum_42_3_2019