It can be argued that this role is not really necessary, as most of the tasks could also be performed by the software architect. In fact, task 2), 4), and 5), should even be encapsulated into user-friendly tools, so that no special knowledge would be required to perform the QoS analysis. Task 3) might require special knowledge of a QoS domain, but software architects should at least be able to provide rough estimation for missing values, which might be sufficient for early QoS analysis.
However, it can also be argued, that existing tools are not so far advanced to automate the tasks of this role. The manual specification of additional value might be too time-consuming and thus expensive for the software architect. Additionally, it remains questionable if task 5) can be encapsulated into tools as it is sometimes difficult to map analysis or simulation results to problems in the architecture. Furthermore, designing QoS-improving architectural alternatives requires special knowledge (such as performance patterns or configuration options of component containers).
We have decided to keep the role in the model, because of limited tools support, and because we suppose that today the QoS analysis task is often delegated to specialists. The goal of QoS predictions approaches should nevertheless be to eliminate this role, so that QoS predictions become an integral part of architectural design and would belong to the standard set of tasks of the software architect.