Requirements

To explore the requirements that need to be fulfilled in order to fulfil the stakeholders’ goals, first the software architecture design process and its interaction with decision-making should be understood. As said, not all challenges are merely architecture-design problems, but many of them are. It is therefore useful to consider what a software architecture design process looks like in general, and how the practice of decision-making fits into this. The prospective decision-making framework will need to support this process, but not necessarily be limited by it.

6.1.1

Software Architecture Design and Decision-Making Process

In software engineering, software architectures are used to design and analyse software systems. This is done on a high level, so that one can reason about the structures of large and complex systems. It describes such structures by their elements, relations and the properties of these elements and relations [74]. As Kruchten et al. state, this is “the key to achieving intellectual control over a sophisticated system’s enormous complexity” [75] and facilitates both system design and maintenance [74]. When used at the start of a system’s design process, a software architecture “significantly constrains and facilitates the achievement of requirements and business goals” [10]. Therefore it can be used to validate whether a system being developed is adhering to the set objectives [76]. Falessi et al. [10] also rightly indicate that every software system has a software architecture; implicit or explicit. The driving factors behind software architecture design were described by Kruchten [77] as reuse, method and intuition. They state that many software architects rely on their own experience and intuition when designing software architecture elements. Some follow a certain method – i.e. language or process model – to help designing a software architecture. Reuse is also used quite broadly; both in the sense of reusing parts of previous or similar systems, as well as organisation-wide experience and domain-specific knowledge. A driving force behind reuse is that it can help simplify the difficult task of architecting [77].

The possible designs of a software (sub)architecture are also referred to as architectural alternatives [10]. Often, there are multiple viable ways to design part of a software architecture. Such possible designs of software architectures are also influenced by the means by which they can be implemented and the required effort to do so. There might also be (commercial) off-the-shelf (OTS) solutions that can solve specific challenges in a (sub)architecture – possibly in conjunction with other solutions. ‘Commercial’ is optional here, since the nowadays there are many Open Source Software (OSS) solutions [78] to architectural challenges

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 64/130

available, sometimes for free. Such solutions could be used by multiple organisations facing similar challenges, and these same organisations can in their turn sometimes also contribute to the development of this software. Depending on the available solutions for architectural challenges and the requirements and constraints to a system, the decision to either develop part of a software system from the ground up or use an OTS solution can be made.

With usually many possible architectural alternatives for solving an architectural problem, the question becomes how to choose between them. This is where decision-making techniques become relevant to help software architects choose between architectural alternatives by describing a process and methodology to systematically compare options.

The basic process of deciding between architectural alternatives is relatively straight-forward. Falessi et al. [10] describe it on a high level using three main phases in an iterative process. A schematic representation of this is shown in Figure 18.

Figure 18 - Software Architecture Design Process - Adopted from [10].

First is the requirements analysis phase, in which a software architect aims to develop an understanding of the problem by “extracting the most critical needs from the big, ambiguous problem description”. These system requirements are influenced by the project context. Also, an organisation’s business strategy or goals may be of influence [79]. The output of this process should be requirements that are architecturally significant. Quality attributes are determined which together with business goals form the basis for architectural decisions. In the next phase of decision-making, the solutions that fulfil the established requirements are sought. The properties of different available options and their relationships are defined to allow comparing these options. This results in candidate solutions. Finally, the question of how well these alternative solutions solves the problem is answered in the architectural evaluation phase. The process can then be repeated if the end result is not an acceptable architecture. While this process description given by Falessi et al. [10] is clear and highlights the main activities, it is not explained in too much detail. A work by Kontio [80], in which they describe the so-called OTSO process for reusable (OTS) component selection, gives more comprehensive though still high-level guidance on the decision-making process. For example,

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 65/130

they explicitly address the searching and selection process of possible architectural alternatives. An overview of the main phases they define is shown in Figure 19.

Figure 19 - Main Phases in Reusable Component Selection Process - adopted from [80].

In this graph-like overview, the vertical axis is used to show the number of alternatives being considered in a phase and the horizontal axis to show time progression throughout the selection process. During the search phase, there can be many alternatives that arise from literature, the internet, vendors, experts and many more sources. The goal here is to identify all possible candidates. These are then put through a screening process to determine which of the found alternatives are worth to consider in a more detailed evaluation. These are then – similar to what was described by Falessi et al. [10] – evaluated and analysed to select the most promising alternative. After this, Kontio also puts emphasis on assessing how successful the selected alternative or component was in solving the given problem after deployment. This might impact the potential further reuse of this same alternative. Besides this, the design process can be further improved given the experiences of the just completed selection process. As stated before in section 3.3, decision-making techniques used in this process should deal with multiple stakeholders, competing and conflicting objectives, uncertainty both in the descriptions of requirements and in their associated solutions, and interdependencies between decisions [10].

To show where these decision-making processes fit in the overall processes for software architecture design exist, a general model of software architecture design – shown in Figure 20 – developed by Hofmeister et al. [81] is used. This model is based on five approaches from industry, for which the commonalities were analysed.

Figure 20 - Architectural Design Activities - adopted from [81]

The decision-making process used to decide between architectural alternatives largely lies in the Architectural Synthesis step in this model. Requirements are used as input to select between alternatives. However, the view shown before from work by Falessi et al. [10] shows that in general, most methodologies aimed at choosing between architectural alternatives take into account more than the mere decision-making step. Often, they also describe how to identify and formulate relevant requirements as well. As for analysis of the choices made; this is mostly done in the form of comparing the decisions made with the requirements and

DECISION-MAKING IN A MICROSERVICE ARCHITECTURE PAGE 66/130

constraints set at the start of the process. If these are fulfilled, the process is seen as complete. That still leaves out the actual implementation and operational evaluation to assess how well these decisions perform into practice. Furthermore, the Architectural Analysis step generally not given too much detail. How to arrive at the architecturally significant requirements used as input for the decision-making process is often not described in too much detail. Therefore, the main focus of these decision-making methodologies can be said to be on the Architectural Synthesis part of software architecture design.

6.1.2

Requirements Definition

These descriptions together with those given in the Problem Investigation stage can be translated into requirements for the decision-making framework to be designed. The goal is that in fulfilling these requirements, the desired interaction between the artifact and the problem context can be created. As was done before for the goal-level requirements, the requirements are subdivided according to the goal-design scale formalised by Lauesen [11] and are shown in Table 10. The initial goal-level requirements are also included in this table for completeness.

Table 10 - Decision-Making Framework Requirements

Goal-level requirements

G1 The framework shall improve decision-makers’ work in managing design

challenges related to communication between, integration and management of microservices.

G2 The framework shall give confidence in its outcomes.

G3 The framework shall require limited effort in its use.

G4 The framework and its outcomes shall be practical. Domain-level requirements

D1 The framework shall support the selection of optimal architectural alternatives.

D2 The framework shall support the use of quality attributes for rating alternatives.

D3 The framework shall support input from multiple stakeholders.

D4 The framework shall deal with competing and conflicting objectives.

D5 The framework shall take into account uncertainty both in the descriptions of requirements and in their associated solutions.

D6 The framework shall deal with interdependencies between decisions.

D7 The framework shall support providing guidelines and industry practices when no clear decision can be made for managing a challenge.