This study is intended for software architects designing stand-alone solutions and using third-generation programming languages and less.  Included here are programming languages running on an application virtual machine (the Microsoft Common Language Runtime (CLR), for one), insofar as they have not been designed for a specific area, as was, for example, the Logo language, which was originally designed for the field of education. [22]  According to IEC 9126 [3], several quality attributes must be observed during the development of a software solution.  Fault tolerance is one of these attributes, and availability is a measure to evaluate it.

The availability of a solution is a quantifiable measure: it allows one to highlight the fault tolerance of a system.  The availability of the solution is the proportion of time that the services of the public interface of the solution are fully available for a representative sample of the software solution under analysis.

The aim of this study is to determine mechanisms to put in place which, when designing a solution, could provide better availability.  Availability is based only on assumptions about the availability of the physical implementation of the solution.  There is no availability specifically sought in this study; what is sought is an improvement in availability.  This improvement can be verified by the increased availability of the solution.

A software solution is based on software components conceived only within the framework of the solution.  The software and the hardware on which the solution is based are external dependencies to it.  For example, the operating system, network cards, and hard disks are dependencies of a software component that are essential for it to function.  Dependencies are external dependencies, unless otherwise stated.

The first part of the study is focused primarily on the abstraction of these dependencies.  An example would be to abstract a network link as a communication means, or a hard disk as a storage unit.  Based on existing models, the characteristics of different types of dependencies will be established in order to allow identification of dependencies when analyzing a solution.

Once abstractions are identified and their characteristics established, the mechanisms to put in place to maximize the availability of a given solution are determined.  Thus, the second part of the study is dedicated to mechanisms for better availability.  Additional features are then added to the external dependencies.

The third part focuses on adapting the analysis method of Tsai and Sang [23] to analyze the availability of a software architecture by adding the characteristics of the external dependencies.

Finally, the analysis method is applied in two separate contexts to validate its effectiveness.  The evaluation of the architecture before and after integrating the changes establishes the difference in availability.  Also, assumptions will be added to the contexts in order to refine the analysis result.

Validation tests highlight the limitations of the analytical method used in the study.  Several avenues for improvement are also detailed in order to evolve the framework of analysis and to make the method applicable to different contexts.

The method of analysis excludes any component that is uncontrolled during development of an autonomous solution, as well as all components that are not imposed during deployment of a solution.  Solutions using software already in place (e.g. enterprise resource management software or customer relationship management software) and solutions developed with fourth-generation languages are excluded.  The implementation of the solution is outside the control of the solution designer; this is a premise of this analysis.