Process Overview and Meta-Model

To make the theoretical description of the decision-making framework usable in practice, thought must be put into how to present and communicate it. This way, decision-makers can more easily get an overview of the different parts of the framework and the steps involved. A first step in this is to explain the different steps in the process, as previously depicted in Figure 23. Next, a process overview – shown in Figure 24 – was created to show how all parts in this process interact with one another.

Figure 24 - Decision-Making Process Overview

As can be seen, central at the start of the process are the requirements to the solution that is worked towards using the decision-making framework. These can be defined by the decision- makers themselves, as well as other stakeholders that may not necessarily be directly involved with decision-making. When referring to the stakeholders as discussed in chapter 3, the ones in the system layer of the stakeholder overview are most likely to be directly involved as decision-maker. The requirements are also dependent on the project context; each system

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 81/130

has its own intricacies, and these are reflected in the requirements that decision-makers should take into account. A business’ strategy that supersedes a single project, including business-specific requirements and goals can also be of influence [79].

Next are the challenges, each with their own category. These are the final challenges from Table 8 in chapter 4 These categories are depicted as three distinct groups of decisions to be made. Between the challenges in each

category are arrows showing the dependencies between them. For example, in the communication category, the communication mechanisms challenge should be addressed before service interconnection, as the choice of communication mechanism – i.e. how to structure communication – restricts the alternatives that are available for service interconnection – i.e. how to implement this style communication. This is called an Alternative- Based Dependency in the work by Al-Naeem et al. [87]. In this case, the communication mechanism decision is superior to service interconnection. The authors propose that there can also be Context-Based Dependencies; in which an alternative’s support for a certain quality attribute can change based on the alternative chosen in a superior decision. The challenges along with their interdependencies are discussed in chapter 5. There could also be interdependencies between challenges outside of a single category. In fact, the complete dependency graph could become fairly intricate fast with this number of challenges. This is one of the reasons the choice was made to not decide on all of the challenges in one go as a single optimisation problem. The aim is to address such category-transcending dependencies in the discussion stage within the framework. This way, the framework should be more practical and transparent to practitioners, expectantly increasing their confidence in it. The challenges are not solved by choosing between alternatives but rather by incorporating guidelines or industry practices are also shown in this overview. The distinction between decisions and guidelines is made by showing them as a question or exclamation mark, respectively. The output of this process are decisions and guidelines that each act as a building block in the overall design for managing the design challenges related to the communication between, integration and management of microservices.

To further explain how all parts of the process interact and which actors are involved in what activities of the decision-making activities, a meta-model was created. This is shown in Figure 25.

Design decision:

Focus on dependencies within category

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 82/130

Figure 25 - Artifact Meta-Model

In this model, certain parts of the process overview can be recognised. The requirements are still central at the start of the process, along with the actors, and influencing factors. Also, this picture makes the separate steps as previously shown in Figure 23 explicit; showing how each step influences another along with the inputs and outputs of each step. This way, the interactions between all parts of the framework are made clear.

Several Thales Naval practitioners were asked for initial feedback on these descriptions and figures. They were presented with the figures in this chapter and an explanation was given on how it all fits together. Most were interested in the artifact and were interested in how it could help them in their day-to-day work. The overview of challenges also looked correct and complete to them. They did have a hard time imagining how it would work in practice. They indicated that this was in part due to them not having seen it be used in a real-life setting yet, but also because the theoretical description was not practical enough yet in their view. Practitioners indicated that a simplified explanation outlining the steps to be taken, why and in what way would probably be helpful in making the framework more usable in practice. Therefore, this was provided in presentation-form during the case studies, as well as a short cheat-sheet-style manual to explain the main ideas and goals of the artifact together with descriptions of the challenges and their possible solutions.