It’s hard to argue that the same goal can be achieved by different means. Without restrictions, any decision will be acceptable, and the choice of a supplier of certain technologies, development approaches and utilized patterns and platforms will not have a fundamental impact on the success of the goal.
In practice, there are always such restrictions: time, budget, team experience, available resources, acquired licenses etc.
Is the choice of a certain approach to achieve the goal always well-balanced? The architects often use their gut feeling. It means that personal experience, preferences and intuition are key factors of decision-making, whereas other important circumstances can be overlooked:

  • Successful experience will lead to the same proven decisions.
  • The decisions that led to failure will be avoided, even if these approaches could become successful in the new projects.
  • The architect’s choice may depend on education and training.

Besides, the composition of relevant factors may differ depending on the point of view. For example, the decisions taken by a project office will often consider such non-technical factors as: business, budget and time limitations, available resources etc., without giving due attention to technical matters. Similarly, a subject matter expert will take into account only technical aspects, at the same time losing sight of non-technical nuances.
Poorly motivated decisions are often the main reason for the project’s failure, since it tells on the quality of the architecture that does not entirely take into consideration the stakeholders needs, the existing restrictions, available alternatives and so forth.
To make a well-balanced decision, it is vital to take into account internal and external factors of both technical and non-technical nature.
A high-level process of architecture design can be regarded as shown in the picture. It becomes obvious that to render a deliberate decision, one needs to have access to the requirements and the context, having previously evaluated alternative decisions.

Fig. 1. The concept of architectural design

Sounds quite simple, doesn’t it? But in fact, developing the alternatives and choosing “the right” criteria for their evaluation is a very challenging task. To deal with it, you will need to be prepared and armed with our recommendations.
Usually, the evaluation of alternatives is represented in a table, with the options shown horizontally and the criteria – vertically. The cells contain evaluation marks, which can then be weighed depending on the importance of each criterion.
By way of example, let’s look at the comparison table of three methods of communication between the components. Keep in mind that without thorough comprehension of the context and the task it is impossible to make a conscious choice between these options. Each approach has its own pros and cons. This is an illustrative example, and all evaluation marks are random.

It is worth mentioning that the weights and the marks should not necessarily be numerical, since it’s quite difficult to interpret these values and to restore the logic of such marks.
Functionality – 3.7; price – 2.3; team experience – 4.1? Is it good or bad?
It is recommend using integer values which correspond with “bad”, “good”, “great”, “n/a” etc. Then it will be much easier to interpret the marks and the final choice.
The main problem is to define the “complete” composition of evaluation criteria. For this, the context boundary must be set, since the context is the source of criteria. The picture below shows how the content of the context may differ depending on the architect’s point of view.

Fig. 2. Decision-making context

In the simplest case, two things are taken into account when making a decision: the description of the requirements and the architect’s experience. Formal approach to work and doing what is written can have a result that is completely different from what was expected. Such situation can happen for various reasons – for example, if the requirements have been laid down by another person. In this case, even if the document is “flawless”, the analyst and the architect might understand the problem differently.
This is the very reason why the notion of “business problem” and others have been taken out of the “narrow” context. By making an architectural decision that is based solely on the requirements, the architect restricts communication with the stakeholders, which inevitably leads to an increase of risk.
For example, a “beautiful” solution based on cloud technologies, which instantly solves an array of problems related to scaling, may seem totally unacceptable if there are operating expense restrictions or if there is an obligation to comply with specific legal requirements.
As the context under consideration expands, new variables are added to the equation. Thus, on the one hand, the decision becomes more balanced, but on the other hand, the expansion will require extra labor costs to conduct the analysis.
It is recommended to define the optimal context boundary depending on the current task, as shown in the picture below. For example, when it comes to a system that is critical for the business and whose successful implementation is crucial for the company’s future, it is reasonable to try to expand the context as much as the resources allow to do it. On the other hand, the development of a system with limited influence on the business should perhaps be limited only to a minimum analysis.

Fig. 3. Value/design maturity matrix

Therefore, we can conclude that, when making a decision, the architect’s main task is to define the comprehensive context (a set of evaluation criteria) that will allow to make well-balanced architectural decisions.
For those decisions that are critical for the business, it is recommended to spend extra time to analyze the alternatives and architecturally significant requirements, as well as expanding the analysis context in order to minimize the risk of making an unbalanced decision.