The availability of a solution using the generic availability for each virtual component may be very small, since the generic assumption is a pessimistic assumption. To overcome this, assumptions about availability may be included in the calculation for availability. Adding assumptions requires more detail on the implementation of the logic layer and the architecture by the physical layer. Some constraints shape architectural decisions made during the development of the solution.

For example, the development of a solution for Microsoft Windows 7 requires a platform with an x86 instruction set [15]. This accordingly excludes any deployment on other types of processing units. The availability of the processing units can then be replaced by the availability of a representative sample, e.g. 99.95 %, or 0.9995, based on the assumptions of section *Calculating availability of a Virtual Component*.

Some constraints may be imposed when deploying a software solution. For example, if the components *A1, A2, A3* and D*1* must be deployed on infrastructure more available than infrastructure with the same availability as the worst assumption, communication links at 1 Gbps, in a network composed entirely of Cisco^{TM} components, can be taken for granted. Therefore, an availability of 99.999 % can be used, in place of the pessimistic availability [4]. Likewise, Western Digital Velociraptor^{TM} hard disks and a Highpoint Technologies^{TM} SAS controller having a serial availability of 0.9999942, can be used to implement the immutable virtual component *D1i1*.

Component availability changes dramatically when moving from a pessimistic rate to a rate based on deployment assumptions. The availability of series virtual components *C1, A1, A2 *and *A3* then goes from 0.8806 to 0.9995 X 0.9999 and that of component *D1* passes from 0.8806 to 0.9995 x 0.9999942 = 0.999494. Also, the availability of virtual components parallel to component *A3* can be calculated as follows :

Availability of the solution is adjusted :

Bottlenecks are reassessed, taking into account the new availability. The following table details the new calculations:

By making assumptions about the physical implementation of the solution, contextual component availability has improved; but the bottleneck is still the component *D1*. The availability of this component is not sufficient so that another component becomes the bottleneck. The availability of other components was not affected; by incorporating the same architectural changes as in the preceding scenario, one can determine availability.

The architectural changes made in the context of improving the availability of the solution improved the total availability of the solution by 0.05%, from 0.997955 to 0.9984605.