In recent years, blockchain has grown in popularity due to its singular attributes, enabling the development of new innovative decentralized applications. But when companies consider leveraging blockchain for their applications, the plethora of possible choices and the di culty of integrating blockchain into architectures can hinder its adoption. Our research project aims to ease the adoption of blockchain into companies, notably with the construction of an automated decision process to solve this issue in which requirements are rst-class citizens, a knowledge base containing architectural patterns and blockchains re ned over time, and an architecture generator able to process outputs into architectural stubs. This paper will also present our current progression on this decision process, by introducing the preliminary version that is able to choose the most suitable blockchain between multiple choices and our process-driven benchmarking tool.
Building software is quite straightforward in a small project, but software
architects can struggle to cope with complexity induced by the number of system
components. Fortunately, they can take pro t from existing architectural
patterns, that are general and reusable solutions for implementing software [
In the eld of Information Systems (IS), architects have to choose among a wide range of architectures and components that meet all of their requirements Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Six
[
Multiple studies tried to address this issue by introducing blockchain decision
models to help to choose whether adopting blockchain or not and if yes, which
type. In [
Through a doctoral thesis, we want to address those problems by building an automated decision process that determines the most suited architectural pattern for a given case. To this end, one needs multiple types of inputs inserted into the decision process, such as requirements or business assets. A major part of this work will be to build a knowledge base, from academic studies, expert feedback, or other information sources, and to update it over time. We also propose an architecture generator, to ease the adoption of blockchain architectures by automating the creation of architectural stubs. The paper will be organized as follows: the Section 2 will introduce our research questions and goals to address mentioned problems and research gaps, Section 3 will present our research methodology, Section 4 will introduce the current chosen approach, and Section 5 will show current doctoral thesis progress. 2
The problematic mentioned in the introduction can be translated into multiple research questions that need to be addressed to ease blockchain adoption: RQ1: How can we extract and structure the data of business processes, assets, and requirements? RQ2: How can we process those data to make decisions regarding system architecture? RQ3: What are the impacts of blockchain speci city in the expression of the architectural model and the domain? RQ4: How blockchain can be integrated into existing architectural patterns?
To address those questions, we articulate this doctoral thesis around the construction of an automated decision process named the BLADE project (for BLockchain Automated DEcision process) where requirements are rst-class citizens. The construction of this decision process will not be easy, as it raises a tremendous amount of locks. The major ones could be to nd a method to compare every decision process inputs (infrastructure, requirements, assets, etc.) with architectural patterns in the knowledge base to nd the pattern that ts best those inputs, as those elements are di erent from each other. Validating the decision process results' accuracy will also be di cult.
To extend the decision process, another goal of this doctoral thesis is to use recommendations and previous inputs to create architectural stubs, including entities, automated setup les, and interfaces. This aims to give architects a clean pattern to develop their applications, since implementing blockchain into architectures is a di cult task, but also to reduce the time between development and deployment, in a logic of cost-saving. 3
This doctoral work will be based on the Design Science Research (DSR)
methodology [
As the goal of this Ph.D. thesis is being able to determine the most suitable blockchain and architectural pattern, we need to know in detail their characteristics. To do that, we will incrementally construct our knowledge base, using previous studies on architectural and blockchain topics (benchmark results, methods, performance simulations, architectural patterns details, ...) as a rst step, and then by performing studies on those topics by ourselves. Each update will allow us to incrementally re ne our artifacts to be more accurate and support more blockchains or architectural patterns. 4
Building such a process is a complex task, as there is a tremendous amount of possible inputs, plus the domain of software architecture is constantly evolving with new patterns and practices. To get an architectural recommendation tting with most of the initial requirements, we must be able to submit as many company requirements as possible and other valuable inputs in our decision process, such as business processes, existing architectures, or infrastructures. Moreover, as technologies evolve, we have to feed our decision process with new data to keep it accurate from available architectural patterns. In this section, we cover
Six possible inputs of such a process, we introduce the processing part of it and associated locks that will have to be lifted, and we present our methods to construct then re ne the knowledge base of the process. Finally, we introduce an architecture generator based on the decision process result. 4.1
The decision process uses 3 types of inputs to compute the most suitable
architectural pattern and blockchain for a given case. The rst one is the
requirements. This input is de ning desired non-functional requirements (eg.
throughput, latency, ...) and functional requirements of chosen architecture. They can be
expressed as strict requirements ("must have") or preferences ("better if the
system has that"). Preferences are rated on a Likert scale [
Inputs processing using the knowledge base is one of the biggest locks that
will have to be lifted during this doctoral thesis. Indeed, as inputs are di erent
from each other regarding their unit, scale, or type, it is di cult to compare
them. A possible solution to address this problem is the utilization of
multicriteria decision making methods [
Following our methodology and our plans for this doctoral thesis, one of the biggest steps will be the construction of a relevant knowledge base, where data comes from multiple sources. First, academic studies will help us to build this knowledge base and the decision process (eg. case studies, state-of-the-art, benchmarks, ...). They will provide empirical data about blockchains attributes and performance, requirements elicitation and weighting, and architectural implementation examples. In a second step, interviews with experts or software architects will be a major advantage to strengthen our decision process. We identi ed 2 types of potential interviews. The rst one is the peer-review of the decision process where interviewees could deep dive into the functioning and make comments on it to x process aws right before going on further tests. The second one is solving a sample test case study using their experience and knowledge, then compare their choices to the decision process and architecture generator results. We would obtain a bias between interviewees' results and ours that could be discussed to understand why di erent choices were made.
The decision process will have to be improved over time following either the creation of new architectural patterns or studies released after the rst version. In addition to that, we are expecting to challenge our decision process on reallife use-cases with experts. We plan to ask companies that plan to build a new application to run the decision process and get in return architecture stubs, that they will use to build their software. Using monitoring tools, we would be able to collect execution traces and analyze them to identify potential overheads or architectural aws then improve the decision process and the architecture generator. Finally, to keep the decision process accurate, we need a relevant up-to-date knowledge base. To do so, we envision collaborating with industrial and open source communities, that could bene t from our work. Also, inputs de ned in the current knowledge base will be re ned as a whole using companies' feedbacks but also by category depending on the use-case under consideration. 4.3
Getting architectural recommendations is the main goal of our project, but we plan to go one step further by adding a generator tool at the end of the decision process. With all the inputs that were submitted and the result of the decision process, we have all the information about all future layers of the architecture.
For the application layer, one of the decision process inputs is a collection of BPMN les, that are modeling company business processes and thus applications that will have to run on the architecture. Thus, as it is possible to generate entities from them, we implemented a tool called BPMN Adapter available on Github1. Regarding network and physical layers, as the infrastructure and the architectural pattern are known, it is possible to generate con guration and setup les for servers and network equipment, to de ne desired communication protocols, operating systems, or network interfaces.
This work is important as it aims to drastically reduce the time between software conception and production deployment by automating all possible steps and therefore cutting on costs. This is also a way for us to get validations of our decision process, as one of our goals is having generated architectures implemented 1 https://github.com/nherbaut/bpmnadapter
Six 5 5.1 within real business case studies where execution traces would be monitored. This would indicate eventual bottlenecks and imperfections of generated architectures and thus help us improve our project artifacts.
Since the beginning of this work, progress has been made on the automated
decision process and results in a study [
Our current knowledge base is constituted with the 4 most used blockchains (in businesses2) attributes, plus Bitcoin, currently considered as the most-known blockchain. Their characteristics have been extracted from multiple sources: studies, technical documentation, whitepapers, and other relevant sources. Current results are promising, as the application of our automated decision process to the case study mentioned before returned the same result as recommended by blockchain experts in the case study. 5.2
As one of our goals is the improvement of our knowledge base with benchmark studies, we decided to implement a highly customizable benchmark framework based on business processes and work ows. With business processes (as XML les) or JSON work ow les as inputs, we are able to generate and deploy sample smart-contracts as microservices on blockchains to benchmark their performance on those environments. Sample (blockchain smart-contracts) microservices exposes 4 methods, that respectively try to solve a di cult dummy computing problem, an increment on a loop, store data, and read data. The "di culty of completion" of each method can be chosen using a method parameter called 2 https://www.hfsresearch.com/pointsofview/whos-winning-the-battle-of-enterpriseblockchain-platforms di culty. As it rises, the number of increments on the loop, the size read and stored and the di culty of the computing problem increases.
Our initial idea was to compare microservices architectures with blockchain technology (eg. Ethereum) by benchmarking them using our suite, but we broader the possibilities by implementing the support of custom smart-contracts benchmark. Instead of generating dummy smart-contracts, we can provide one. Therefore, we can benchmark blockchain performance over a dedicated smart-contract, by varying the number of nodes, their hardware, and the characteristics of the blockchain used (eg. block time, block size, consensus protocol, ...). This will help us to strengthen our knowledge base during this thesis. 6
The choice between multiples architectures is not trivial for enterprises. A lot of inputs and features had to be taken into account when determining which architectural pattern will be chosen, an impossible task when non-automated. Moreover, the decision process could be biased with the software architect's personal experience.
In this paper, we are introducing our plans to build a decision process focused on blockchain architectures to address those issues. From a set of inputs, that are requirements, business processes, and business assets, the decision process will be able to translate them into architectural suggestions, but also using these latter to generate architecture stubs (entities generation, communication protocols, interfaces, etc.). One of the main challenges of this project will be nding a way to translate all inputs and all architectural patterns, into a set of numeric values, but also weighting them in the decision process as all the features do not have the same importance. To do that, we proposed to use many available scienti crelated studies, but also to ask software architects and experts for feedback to validate the decision process or re ne it. We also introduced our plans to improve the decision process after the rst release with an iterative approach, taking new studies as inputs and having it tested by companies on real-life projects. Finally, we present our preliminary results on this topic that is a decision process for blockchain technologies called the BLADE project. It is able to recommend the most suitable blockchain from non-functional software-related requirements and user preferences, but also our process-based benchmarking tool.
As we saw that in the decision process performances are expressed in wide intervals instead of xed values, we plan in the near future to improve this aspect by nding a way to determine those values from the context (blockchain technologies and speci c blockchain parameters) using our benchmarking tool to determine such formulas. Another planned work will be to study possibilities of integration of blockchain into existing architectural patterns notably by performing a literature review on blockchain and architecture, to be able to include them inside the decision process in the future. As we adopted a constructive research methodology, we plan to move forward following this step by step approach to construct the automated decision process that takes into account business assets and requirements.
This doctoral thesis is supervised by Pr. Camille Salinesi and Dr. Nicolas Herbaut.
Six