In this paper, the authors aim “to explicitly consider uncertainty in the [software] performance modeling and analysis process” to evaluate its robustness. They propose a probabilistic formulation of parameter uncertainties, such as workload, operational profile, resource demand of services, service time of hardware devices, and so on, for a simulation-based approach to the systematic assessment of robustness of an architectural model. They also present refactoring actions designed to generate new software architectural models that better tolerate parameter uncertainties in case of unsatisfactory performance.

The proposed approach is applied over three consecutive phases: modeling, which involves building a software architectural model with the chosen parameters for evaluation (including their uncertainty); performance analysis, which systematically assesses the performance of generated model samples for robustness; and refactoring, which involves checking for desired performance thresholds. The paper provides a system of four heuristics: improving multiplicity of network resources; improving multiplicity of node resources; reducing message complexity in communications; and refactoring to reducing resource demands. The paper also presents an illustrative case study on a notional e-health system to demonstrate the approach.

The proposed heuristics are well known and applied by competent software system architects, so there is not anything new in the paper as such. However, the authors have done a good job of assimilating such knowledge into one paper and using a case study for illustrative purposes to further demonstrate the refactoring alternatives in a formal manner.

Unfortunately, the paper does not really simplify the complexity that proliferates in the domain of model-based performance analysis, or the issue of validating the model itself, which can be an arduous task for architects not well versed in probabilistic modeling. Nevertheless, the paper will help aspiring and junior software architects learn the tricks of the trade, and might encourage them to adopt a stepwise approach to considering specific architectural decisions and alternatives.