Design Decisions

With the ArchDesigner methodology [10] as a conceptual basis and the knowledge of microservice challenges from literature in practice, the design of the artifact to treat the problem of designing a microservice architecture starts.

First, the high-level process was defined as shown in Figure 23. A more extensive model, also showing the challenges involved is shown in Figure 24. In this process, clues were taken from ArchDesigner, but made more explicit to show the different steps more clearly. It was also extended to specifically show discussion and evaluation steps – which will be discussed in more detail – to be taken, as well as an arrow looping back to the first step to indicate that the process is often iterative.

Figure 23 – High-Level Artifact Decision-Making Process

The first step is to capture requirements that are significant for the decisions to be made. As said before, these can be given at the start of the project, and also be influenced by a project context and the business strategy

of an organisation. There can be many requirements, so it is vital to select those that are of most importance and have most implications on the system design when making decisions. The goal is to select those requirements and QAs that are most impactful and most distinguish possible alternatives from each other. As described by Lindblom [90] in their paper on the Science of Muddling Through, often many of the alternatives under consideration all fulfil a large part of the requirements. The alternatives then differ only on a marginal number of requirements. Therefore, it is important to focus on those requirements that best set the alternatives apart. That is not to say, though, that selecting between alternatives this way is promoting an informal evaluation process. In terms of different evaluation modes described by Mintzberg [91], the decision-making process should still mainly be done by analysis. In some cases, though, support for certain QAs can be hard to quantify. An example of this is maintainability. In this case some judgement by decision-makers can still be involved, making the process more bargaining-like. As Mintzberg also points out in their research, “judgement seems to be the favoured mode of selection, perhaps because it is the fastest, most convenient and least stressfull of the three [evaluation modes]” [91].

Design decision:

Explicitly show detailed overview of steps to be taken

Design decision:

Focus on selecting impactful and distinguishing requirements

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 78/130

Whereas functional requirements can often either be fulfilled or not, QAs are generally expressed with a measure and possibly a norm. For QAs, it is again important to select those that mostly distinguish the different alternatives from each other and leave out those that are only important as constraint. For example, if latency would be a distinguishing factor between alternatives, then it should be considered. If, however, the only requirement to latency is that a system should respond within a set amount of time, this can be seen as a constraint and therefore it need not necessarily be included in the requirements by which to compare alternatives.

In the next step, the requirements are prioritised. This is done in a pairwise manner as described by ArchDesigner using the AHP. These pairwise comparisons ultimately result in a weight assigned to each requirement. Refer to [89] for a more detailed explanation of how such calculations are done. It is proposed to allow

multiple decision-makers to first make their own comparisons, and then aggregate these to a consolidated list of requirements and weights. This is in an effort to

reduce bias that could be introduced when communally deciding on relative weights in a group setting. In group settings, certain decision-makers could also be more forward about their views and aiming to convince the group of these. Another possible bias is that of Groupthink [92]; the phenomenon in which judgements are altered because of a desire for harmony and conformity within a group. One other possible source of bias is the phenomenon of anchoring – described by Kahneman et al. [93]. A description given by the authors is as follows: “[…] different starting points yield different estimates, which are biased toward the initial values. We call this phenomenon anchoring” [93]. In this case, it concerns the situation in which group members might subconsciously make their judgements depend on a weight suggested by one group member. E.g. when decision-makers are unsure about what weight to assign to a certain comparison and are still undecided, one decision-maker might say that they believe it should be a certain value. At this point, the other decision-makers start comparing their views with this set value – the anchor – and depend on it to compare their own weight ranking. This way, the value that a decision-maker assigns to a comparison may be different than the one they would have assigned without having first been presented with an anchor.

After establishing a prioritised list of requirements, the previously mentioned constraints to alternatives should be identified. These can be used to include or exclude candidate alternatives for comparison. In terms described by Kontio [80], these can be used in the screening stage of finding suitable alternatives. Constraints can be in the form of a QA as described before, but also other motivation that are not always captured in the requirements of a project. One example of this might be an organisation not selecting alternatives made by a certain supplier for competitive reasons. With these constraints in mind, the actual search for alternatives can start. Kontio describes several sources where alternatives can come from, such as in-house libraries, online sources, magazines and journals, vendor offerings, experience, colleagues, experts and consultants [80]. These alternatives are searched for each decision to be made.

Then comes the decision-making part. The challenges that need to be considered in the case of a microservice architecture arise from the literature research as well as interviews from practice as discussed in chapter 4. They

are subdivided by their categories: management, integration and communication. In order to show the dependencies between decisions, further research was done to each challenge and how they relate to one another. This was discussed in chapter 5. The outcomes for each

Design decision:

Allow for prioritisation input from multiple decision-makers

Design decision:

Initially make decisions one-by- one

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 79/130

decision are the highest scoring solution alternatives, each serving as a building block for the microservice architecture to be designed. Because of the number of challenges that need to be addressed, and when considering the unfavourable feedback from practitioners on dealing with interdependencies by merely solving an optimisation problem, the choice was made to approach these decisions as a process in which decisions are initially treated one-by-one. When one decision influences another, that first decision is first made and then used as input for the next decision. This way, the results are consolidated before moving on to each next decision. This does however imply that now sub-optimisation is happening; having the optimal alternative for each decision does not guarantee the best overall solution. To deal with this, the next step is introduced.

In step 6, the decisions are discussed to see how they fit together. Practitioners indicated that they would likely not take the best alternative at face value based on merely a ranking. Therefore, it is proposed that the outcome of

each decision to be made are one or more best alternatives instead of a single optimal one. In the discussion stage, these are then combined to an overall solution to the problem. Guidance in determining the interdependencies between decisions is given through their descriptions as was discussed in chapter 5. This way, decision-makers can combine alternatives in a way that makes most sense to them. Recall that during the problem investigation phase (chapter 3) of present research, practitioners indicated that the framework should in their view mainly guide the discussion on the challenges that are encountered when designing a microservice architecture. The goal is to achieve this by including this distinct discussion phase in the process. Together with considering one or more best alternatives instead of a single optimal one, the goal is to also increase practitioners’ confidence in the framework by making it more transparent and not deciding on the overall solution merely by solving an optimisation problem.

Finally, there is the evaluation stage. In this stage, the outcome of the decision-making process is put into practice and the quality of the solution is assessed. The outcome of this evaluation can serve as new input for next iterations. This step is crucial in both improving

future outcomes as well as the decision-making framework itself. First, the decision-making process is iterative. If during evaluation it turns out that the outcomes are not sufficient, the lessons learnt from one iteration can be used to improve the next one. For example, the selected requirements could be altered, their relative weights, the alternatives under consideration and so on. On the other hand, if it turns out that certain parts of the decision- making framework itself can be improved, this could also be considered.

As stated before, not all challenges found in literature and practice translate to decisions with clear alternatives to choose between. One example used before is that of service granularity – how ‘big’ a single microservice should be. The solution to this challenge cannot just be

expressed as a number of lines of code or function points that are optimal. There are, however, guidelines and techniques to decide on this. While such challenges have less to do with the main decision-making process put forward by this framework, the goal is to also provide guidance on managing these challenges. To accomplish this, first a distinction should be made between challenges that can be decided upon by selecting between alternatives, and those for which this is not the case. For each challenge that comes with guidelines instead of

Design decision:

Discuss best decision alternatives to define the overall solution

Design decision:

Evaluate outcomes and iterate to improve outcomes and framework

Design decision:

Find solutions in guidelines and techniques when no clear decision between alternatives can be made

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 80/130

alternatives, solution examples are given to help practitioners toward finding a way to manage these challenges as well. It can also be foreseen that the framework is used in cases where some decisions are already set. For example, if the communication mechanism used in a system is predetermined by for example external compatibility requirements, this challenge might not need further addressing and can be filled out with this choice. Another example is the case in which only changes to part of a system need to be made without completely overhauling its implementation of service interconnection.

To assess how reliable the decision outcomes are, the aforementioned advice by Svahnberg et al. [84] of assessing uncertainty can be incorporated. Saaty [89] describes the use of a Consistency Ratio (CR) for this to assess how well pairwise comparisons are in line with one another. If this ratio becomes too large – higher than 0.1 according to Saaty – then the comparisons can be inconsistent or contradicting. In this case, possibly the comparisons may need adjustment or need to be re-done as continuing with inconsistent rankings as input can make for unreliable decision outcomes.