7.2 Trade-off Techniques

7.2.1 General Structure of a Trade-Off Process

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:

identify the set of stakeholders involved in the trade-off decision process,
identify & share the architectures that shall be discussed,
define & share the decision criteria to be used,
evaluate each possible architecture according to the decision criteria,
prioritize the evaluated architectures

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 – typically managed in a collective prioritization workshop – 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 – stakeholder identification – 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 – architecture identification – “just” 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 – decision criteria identification – can then rely on need and requirements architecture as discussed in the previous chapters: the “good” 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.
The fourth step – architecture evaluation – 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 – prioritization – 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.
One shall finally point out that such a technique is not making the decision, just helping to prepare it¹. 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 governance², who are the only ones habilitated to take the decision as already mentioned above.

7.2.2 Managing Trade-Offs in Practice

As already discussed in the last subsection, it is a good practice – that we can only highly recommend – 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 :

1. their value, measured through the covering of five structuring needs (in green in Figure 60),
2. their level of risk, measured through four risk factors (in red in Figure 60).

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.

Example of a collective vote during a prioritization workshop figure

Figure 60 – Example of a collective vote during a prioritization workshop

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 – each option being now represented by a simple dot in that matrix – where one can easily compare them (see below Figure 61). One can then easily see that:

architectures S5 and S6 would lead to a project with the maximal level of risk,
it is better take S8 rather than S4 and S3, since S8 has more value and less risk than these two other variants, the same conclusion occurring for S7 with respect to S4,
architectures S0, S1 and S2 have poor business value.

– Example of a collective evaluation during a prioritization workhop figure

Figure 61 – Example of a collective evaluation during a prioritization workhop

On the basis of that analysis which was collectively shared during the prioritization workshop, the participants to the workshop proposed to their governance body to launch a project oriented toward architecture S8, with architecture S7 as a fallback option. Their choice was fully confirmed by the governance committee that took place in the week following the workshop. As a matter of fact, the collective prioritization technique allowed to successively achieve a complex arbitration on a 700 million euro budget dedicated to a strategic system development project!

7.2 Trade-off Techniques