Section 2.4.2 briefly introduced FRAM (Hollnagel 2012b), which consists of
functions that are connected with each other through aspects. Functions are abstractions to capture work routines and related resources, tangible and intangible ones. The six aspects are Input, Output, Time, Control, Precondition, and Resources. Figure 23 shows an example of a FRAM model.
Figure 23 - Example of a single FRAM function and its six aspects responsible for marketing
It is possible to define functions on different levels of organisation. The level of detail and the number of functions depend on the purpose for which FRAM is being used. <Market products>, for example, could be a function, like in Figure 23, but it is also possible to go into more detail by decomposing <Market products>, as shown in Figure 24 at the end of this section (page 122). The first step in a FRAM analysis should therefore always be the identification of functions that are necessary to succeed in everyday situations. It is possible and sometimes advantageous to concentrate on high-level functions at first and go into more detail in later stages of the analysis. It is not important which function is identified first. In a FRAM analysis there are not always clear start and end functions. Furthermore, the aspects of the functions ensure that all necessary functions are identified.
118 Once an initial set of functions has been identified, the functions need to be described in more detail by defining (some of) their aspects:
• Input: is used or transformed by the function to produce the Output. Input can be anything like material, information, etc. The Input starts a function.
• Output: the result of what the function does. The Output can be anything like material, information, etc. When the Output has been produced, the function is completed.
• Precondition: has to be true or verified in order for a function to start. It does not in itself, however, constitute a signal to start a function. The Input starts a function. This distinction can be used to decide whether something should be an Input or a Precondition.
• Control: regulates or supervises a function so that the desired (or planned) Output is produced. Control can be a plan, a set of guidelines or rules, a schedule, etc. Control can also be social expectations, e.g. those by management or supervisors.
• Resource: is consumed when the function is executed. A Resource can be anything like matter, information, a machine, a software tool, etc.
• Time: captures the different ways in which time can affect a function. Time can be considered another form of Control. For example, a function may need to be carried out before, after, or in parallel to another function. Time can also relate to a single function that needs to start at a certain point in time.
Functions need to have at least an Input or Output. Only the Output of a function can be connected to other aspects of other functions, i.e. connecting Precondition to Control is not allowed. It is often useful not to describe all aspects of a function at first, as this can make the analysis complex and it is easy to loose sight of the bigger picture. It is recommended to describe only those aspects that are deemed appropriate for the analysis and for which information is available. For all other cases background functions can be defined. Background functions only have an Input or Output and are assumed to be stable during the execution of the function (background functions are grey in FRAM models).
119 FRAM allows the analysis of resilience (see section 2.4.2 for a description of the underlying principles of FRAM). As software vendors that migrate their software products into the cloud take over responsibilities from the customer and, at the same time, outsource responsibilities to the cloud provider, understanding the resilience of the software vendor and how it can be increased enables them to react to and anticipate changing circumstances faster. In addition, a higher level of resilience will also help the software vendor bounce back to normal performance after a major negative event, e.g. if the cloud provider has an outage.
Section 2.4.2 introduced the concept of performance variabilities, as it was the main reason for choosing FRAM as a method to investigate resilience. The concept of performance variabilities captures how the variability of individual functions in FRAM models can sometimes reinforce each other, causing the variability of one function to exceed its limits. The consequences can be negative as well as positive (Hollnagel 2012b). The identification of performance variabilities in FRAM requires the instantiation of a FRAM model. As the aim of a FRAM model is to capture functions and their couplings for everyday situations, a FRAM model always shows potential couplings between functions until the model has been instantiated. Instantiating a model means investigating the functions and couplings in/for a specific situation in a specific context. For the purpose of this chapter it is the migration of software products into the cloud. By knowing how functions behave in this situation and context, it is possible to identify performance variabilities. Three types of performance variabilities can be distinguished.
First, the function itself can experience performance variabilities, so called internal performance variability. In this case a function can fail due to organisational pressures that affect human performance or because equipment has not been maintained properly (wear and tear). Second, the function can fail due to a change in the working environment, so called external performance variability. In this case, a function fails because it operates outside its designed parameters, e.g. extreme weather conditions. Third, the output from other functions can affect downstream functions. Downstream functions are those functions that use the Output of other
120 functions as Input, Precondition, etc. If an upstream function varies in performance (or fails) and the Output is not as it should be (or not available at all) it can affect downstream functions. For example, if the Output of an upstream function is the Precondition for a downstream function, the downstream function will not start as not all conditions are fulfilled (similar to the example in Figure 24 at the end of this section).
The Output of functions can be affected by the internal, external, and downstream performance variability in terms of time and precision. Performance variability can cause functions to produce Output (1) too early, (2) on time, (3) too late, or (4) not at all. With regard to precision, performance variability can cause functions to produce Output that is (1) precise, (2) acceptable, or (3) imprecise. Investigating performance variabilities only with regard to time and precision represents a simplified version of performance variabilities. There is also a more elaborate way, which includes the identification of performance variabilities through common conditions (CCs). CCs are, for example, the availability of procedures and plans, conditions of work, circadian rhythm and stress, etc. (a complete list can be found in Hollnagel 2012a). The more elaborate way has been deemed inappropriate for the adoption of cloud computing because the majority of CCs deal with accidents where people’s lives are at risk (and thus the CCs cover factors related to relevant causes). The reason for this is that FRAM has originally been developed for accident investigations (retrospective analysis) and safety assessments (prospective analysis). Although in today’s environment all software vendors rely on technologies such as cloud computing, they are business critical but do not necessarily cause the loss of life in case of disruptions.
When using the more elaborate way to identify performance variabilities it is necessary to categorise each function:
• Human (M-functions): functions that are carried out mainly by people, thus, performance variabilities depend on the performance of people;
• Technology (T-functions): functions that depend on technology to perform appropriately, thus, performance variabilities depend on the performance of the technology, such as automated functions;
121
• Organisation (O-functions): functions that are carried out by a group of people with additional means, e.g. a technology, thus, performance variabilities depend on the performance of the whole group;
When investigating the performance variabilities of a software vendor that plans to migrate their software product into the cloud, the classification of functions into the three categories will not be done. This study aims to investigate how PP1 has migrated their software products into the cloud from a technical and organisational perspective. Hence, the study will only capture those functions that contain both perspectives, i.e. O-functions.
The FRAM model from Figure 23 has been extended to show <Market products> in more detail in Figure 24. To connect the first three functions only their Input and Output aspects have been described. The description of the aspects is shown as text boxes on the lines between the hexagons. <Provide advertising budget> is different from the rest as its Output is a Resource aspect for <Develop under 20s commercial>
(it is a Resource aspect because budget is consumed during the execution and needs to be available throughout the execution of the function). <Develop under 20s commercial> can only start (and be continued) when budget is available. The functions in Figure 24 have also been analysed for performance variabilities. <Develop under 20s commercial> is likely to experience performance variabilities (shown by the wave symbol in the hexagon) due to the Resource aspect of <Provide advertising budget>. If the budget is not sufficient, <Develop under 20s commercial>
is likely to produce an Output that is imprecise. Thus, the performance of an upstream function affects the performance of a downstream function.
122 Figure 24 – Same FRAM as in Figure 4 to show performance variabilities (as a wave symbol in the hexagon).
Background functions are shown in grey.