### Analysis without assumptions

Figure of an Architecture of a simple system (see Basic software solution) presents five components dependent on virtual components. Components *C1*, *A1* and *A* have a transitional virtual component and a virtual processing component, respectively *C1c1, C1t1, A1c1, A1t1, A2c1* and *A2t1. * With the availability of the solution being reached without assumptions about the availability of the physical implementation of the virtual components, the pessimistic availability of 0.9384 is used. Availability of components *C1c1, C1t1, A1c1, A1t1, A2c1* and *A2t1* can be determined by calculating these two virtual components in series, which gives an availability of 0.8806 for each.

Component *D1,* meanwhile, is composed of a virtual processing component, *D1t1,* and an immutable component, *D1i1*. The availability is therefore calculated in the same manner, by multiplying the respective availabilities of 0.9384 and 0.9384, which also gives a component availability of 0.8806. Component *A3* depends on a transitional virtual component (*A3c1*), as well as two virtual processing components in parallel (*A3t1*, and *A2T2*). It is possible to calculate the availability of as follows:

The total availability of the solution can be calculated by multiplying the availability of the series system *Dc1, Da1, Da2, Da3 *and* Dd1*:

We can infer the availability of the solution as 0.54284. This availability follows from the unknown implementation of the virtual components, causing a direct effect on the availability of the solution. The physical implementation of this solution allows adjustment of the availability of each virtual component, and thus obtainment of a different availability.

In order to improve this availability, components that have the greatest impact on the availability must be targeted. To find these bottlenecks, the first step is to identify the parallel components, using the methodology described in section *Methodology of Analysis*. In this solution, all components are unique, and no component duplicate is put in place to improve availability. We must therefore assess the contextual availability of each component, identifying all components having a dependency on a particular component, and do this for each of the components of the solution. A summary of these dependencies is given in the following table.

The bottleneck is component *D1* : it is necessary to improve the availability of this component to maximize the impact of architectural changes on the availability of the solution. The two dependencies of this component are an immutable virtual component (*D1i1*) and a virtual processing component (D1t1). Since these are the only two dependencies of this component, the changes made will be duplication of these two virtual components by adding two additional virtual processing components (*P2*_{ }and *P3*) and two immutable virtual components (*I2* and *I3*)

The availability of this component is recalculated as follows :

This component has an availability of 0.9924 or 88.7% more available than the initial configuration (with availability of 0.8806). The total availability of the solution is also affected, rising from 0.5428 to 0.6117, still making no assumption about the physical implementation of the virtual components. Given that the changes were made on a single component of the software solution and that there is no duplication of components, the difference between the availability of the original solution and that of the amended solution is proportional to the difference in availability of the modified component. Calculation of availability for the modified solution is as follows :

Since this analysis was done with no assumption of availability, availability is low, at 0.6117. Comparison of this availability with the availability previously calculated reveals improved availability following the architectural changes.