{"id":25606,"date":"2021-02-04T09:48:54","date_gmt":"2021-02-04T08:48:54","guid":{"rendered":"https:\/\/cesam.community\/?p=25606"},"modified":"2023-01-20T11:50:48","modified_gmt":"2023-01-20T10:50:48","slug":"7-2-trade-off-techniques","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/02\/04\/7-2-trade-off-techniques\/","title":{"rendered":"7.2 Trade-off Techniques"},"content":{"rendered":"

7.2 Trade-off Techniques<\/h2>

7.2.1 General Structure of a Trade-Off Process<\/h3>

The objective of any trade-off process is to help its involved stakeholders to make a rational choice among several possible architectural choices, based on shared decision criteria. As a consequence, any trade-off process shall consist in the following main steps:<\/p>\n

    \n
  1. identify the set of stakeholders involved in the trade-off decision process,<\/li>\n
  2. identify & share the architectures that shall be discussed,<\/li>\n
  3. define & share the decision criteria to be used,<\/li>\n
  4. evaluate each possible architecture according to the decision criteria,<\/li>\n
  5. prioritize the evaluated architectures<\/li>\n<\/ol>\n

    Steps 1 to 3 can be typically prepared by the systems architect alone (or with a small team), without opening too much the circle of stakeholders. Steps 4 and 5 shall however necessarily be achieved through a collective decision process \u2013 typically managed in a collective prioritization workshop \u2013 as soon as one wants the involved stakeholders to be part of the decision in order them to be collectively engaged in the decision (and respect it). Each of these steps is quickly described below. The first step \u2013 stakeholder identification \u2013 is not the easier. We however will here only to the last paragraph of section 2.3 were this question was already discussed. The second step \u2013 architecture identification \u2013 \u201cjust\u201d consists in applying all the systems architecture techniques we presented from Chapter 3 up to Chapter 6 and tracing the valuable architectural options that occur during the systems architecting process. The third step \u2013 decision criteria identification \u2013 can then rely on need and requirements architecture as discussed in the previous chapters: the \u201cgood\u201d decision are indeed typically structuring high level needs and\/or requirements. One thus sees that these three first steps totally rely on already discussed systems architecture techniques.
    \nThe fourth step \u2013 architecture evaluation \u2013 is quite easy since the only complementary technical ingredient it requires is to provide an evaluation scale when defining the decision criteria. The main difficulty here lies however not in technique, but in the human dimension of that step, that is to say in workshop facilitation as soon as one is using a collaborative prioritization workshop to achieve that evaluation, as we highly recommend. The fifth and last step \u2013 prioritization \u2013 is the more complex since one cannot apply any deterministic protocol to achieve it. Prioritization can only be obtained by a collective discussion, using the results of step 4 as an input, without however being prisoners of them, in order to make collectively the most rational choice, taking into account all the dimensions of the decision that will be brought by the different actors involved in a collective prioritization workshop.
    \nOne shall finally point out that such a technique is not making the decision, just helping to prepare it1<\/a><\/sup>This is why one also speaks of decision-aid techniques for such trade-off techniques. <\/span>. Ultimately the real decision can indeed only taken by a suitable system governance board. It is thus extremely important to integrate any trade-off technique within a shared governance process where roles are transparently distributed between the people involved in the trade-off protocol as presented above and the people involved in governance2<\/a><\/sup>It is in particular a key good practice to separate completely the roles and not to mix the people who are preparing the decision with the people who are taking \u2013 formally \u2013 the decision. Such a role separation indeed allows the governance body not to follow the recommendation brought by the trade-off process, which may happen \u2013 even if normally not if the systems architect made a good job \u2013 if some strategic decision criteria were not taken into account during the collective prioritization workshop. <\/span>, who are the only ones habilitated to take the decision as already mentioned above.<\/p>\n<\/div>

    7.2.2 Managing Trade-Offs in Practice<\/h3>

    As already discussed in the last subsection, it is a good practice \u2013 that we can only highly recommend \u2013 to manage trade-offs in practice through collaborative prioritization workshops, involving all key actors that may be impacted by the trade-off decision. We would therefore just like to conclude this short chapter dedicated to trade-off techniques by presenting some illustrations coming from a real collaborative prioritization workshop. The first one is an example of vote that took place during such a workshop. Each sticker corresponds to a vote of one of the forty-five domain experts who participated to this workshop. These experts were asked to evaluate nine architectural options (represented through columns in Figure 60, the seven first ones being prepared by the systems architect before the workshop, while the two last emerged through the collective discussion during the workshop) in order to know :<\/p>\n

    1. their value, measured through the covering of five structuring needs (in green in Figure 60),
    \n2. their level of risk, measured through four risk factors (in red in Figure 60).<\/p>\n

    Each of these value \/ risk criteria were then evaluated by the involved experts on a low-medium-high scale, the evaluation being concretely achieved by putting a sticker on the relevant location of the evaluation 12 meters x 1,5 meter panel depicted in the below Figure 60.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25607″ img_size=\u00a0\u00bb450×270″ alignment=\u00a0\u00bbcenter\u00a0\u00bb]

    Figure 60 \u2013 Example of a collective vote during a prioritization workshop<\/span><\/strong><\/p>\n<\/div>

    It is also interesting to share the synthetic final evaluation that achieved during this collaborative prioritization workshop. The nine architectural options that were analyzed during the workshop are now put on a value \/ risk matrix \u2013 each option being now represented by a simple dot in that matrix \u2013 where one can easily compare them (see below Figure 61). One can then easily see that:<\/p>\n