Applying systems thinking and aligning it to systems engineering
چکیده
1 . This is a paper on thinking about thinking. Systems engineering is an emerging discipline in the area of defining and solving problems in the manner of (Wymore, 1993). The emerging paradigm for problem solving is “systems thinking”. Both systems engineering and systems thinking have recognized the need to view a system from more than one perspective. This paper proposes a set of perspectives for applying systems thinking in systems engineering and then defines a systems thinking perspective set of views for a system, the use of which will provide one way of aligning systems thinking to systems engineering. The paper then provides an example of applying the set of perspectives to the Royal Air Force Battle of Britain Air Defence System and shows that not only does the set of perspectives provide a way to model the system; it also picked up two potentially fatal flaws in the system. The paper then concludes with some observations on the state of systems engineering from a number of the perspectives. The need for systems thinking The need for systems thinking is widely recognized at this time. Figuring out how to meet the need and actually apply systems thinking in a systemic and systematic manner constitutes a problem yet to be solved. (Khisty and Mohammadi, 2001) page 22) quote Ackoff (1986)‟s suggestion that there are at least four ways of treating problems. These are: 1. Absolving the problem. 2. Resolving the problem. 3. Optimizing the solution. 4. Dissolving the problem. Absolving the problem is traditionally known as “ostrich management”. This approach ignores the problem or imagines that it will eventually disappear on its own. Resolving the problem is a traditional systems engineering approach to removing or suppressing the problem. This approach takes appropriate action based on experience, common sense and expertise. Optimizing the solution is another traditional systems engineering approach based on working out an outcome through experimentation or analysis. Dissolving the problem. This approach redesigns the system containing the problem or changes the perspective from which the problem is viewed to produce an innovative solution. 1 The research underlying this paper was funded by a grant from The Leverhulme Trust to Cranfield University. Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-2 This approach generally requires systems thinking. And, as systems thinking is emerging both as a school of management thought and an academic discipline, the ability to perform systems thinking is a critical competency for a systems engineer. The research that is described in the remainder of this paper takes this fourth approach. Applying systems thinking The literature abounds with: 1. publications advocating the use of systems thinking, e.g. (Flood and Jackson, 1991), 2. publications describing how an understanding of the way things are connected together provides one with a competitive advantage over those who do not share the same understanding 2 (Morgan, 1997) . 3. philosophical and academic theories of systems thinking, e.g. (Flood and Jackson, 1991), and 4. the need to view problems from various perspectives, e.g. (Morgan, 1997). However, the literature on how to actually apply systems thinking to get something seems to be mostly limited to advice advocating the use of causal loops, non-linear thinking, and the recognition that systems exhibit behaviour that may be cyclic. This is a critical gap in systems engineering. In addition, if a practical application of systems thinking to be developed can also be aligned with systems engineering, and then applied in the workplace, the practice of systems engineering should undergo a marked improvement because the application of systems thinking, namely much of systems engineering would become “a philosophy and a way of life” (Hitchins, 1998). This paper tackles the issue of applying systems thinking, filling that gap in systems engineering. It does this by using a modified version of the streams of systems thinking (Richmond, 1993) and further proposes an alignment of systems thinking with systems engineering to build systems thinking into the systems engineering process by definition. Traditional systems engineering has focused on analysis which has three steps (Ackoff, 1991). This is reductionism – reducing the parts to ever decreasing components. Systems thinking on the other hand also has three steps but they are slightly different (Ackoff, 1991). Comparing the two sets of steps in the manner shown in Table 1, one can see that the focus of analysis or reductionism is to look inwards while the focus of systems thinking is to look outwards. Both have their place in developing an understanding of a system (Hitchins, 1992) page 14). The application of systems thinking in the literature is generic with references to 2 The earliest description found in the literature was in Luzzatto, M.C., The Way of God, about 1735. Table 1 Analysis and Systems Thinking Analysis (Machine Age) Systems Thinking (Systems Age) 1. Take apart the thing to be understood 1. A thing to be understood is conceptualized as a part of one or more larger wholes, not as a whole to be taken apart; 2. Try to understand how these parts worked 2. An understanding of the larger system is sought; 3. Assemble an understanding of the parts into an understanding of the whole. 3. The system to be understood is explained in terms of its role or function in the containing system. Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-3 understanding relationships, casual loops, but does not seem to be organized in a consistent manner 3 . However, one organized approach to applying systems thinking discovered in the literature was by (Richmond, 1993) who introduced seven streams of system thinking. Richmond used a reductionist approach on systems thinking to allow it to be applied holistically to real world. The research behind this paper has developed a similar set of streams or viewpoints called System Thinking Perspectives (STP). The STPs can provide a competitive edge since “people who learn to read situations from different (theoretical) points of view have an advantage over those committed to a fixed position. For they are better able to recognize the limitations of a given perspective. They can see how situations and problems can be framed and reframed in different ways, allowing new kinds of solutions to emerge” (Morgan, 1997). The System Thinking Perspectives Systems engineers are used to viewing systems through sets of models or views such as (Hately and Pirbhai, 1987) or the (DoDAF, 2004) each of which examines a situation from a number of points of view. This paper makes use of that concept and describes a set of STPs along the lines of (Richmond, 1993) to be used in conjunction with both developing an understanding of a system and organizing its representation. These perspectives are: 1. Operational 2. Functional 3. Big picture 4. Structural 5. Generic 6. Continuum 7. Temporal 8. Quantitative 9. Scientific The first eight perspectives are descriptive, while the scientific perspective is prescriptive. Consider each perspective in turn. Operational perspective. The operational perspective is the manner in which the system operates or will operate (in the case of a new system). The system is viewed as a black box. The perspective shows the inputs and outputs and their relationships. This corresponds to the traditional „open system‟ view. The black box perspective abstracts out (filters) the details of the internal nature of the system providing a view of the forest rather than the individual trees. The perspective is documented in the form of Use Cases, concept of operations, and other appropriate formats and is used when producing operational requirements. Functional perspective. The functional perspective describes the functions or activities performed by the system without reference to which of the elements of the system perform those functions. This corresponds to the traditional „closed system‟ view and includes the cause and effect feedback loops. The system is viewed as a white box. Depending on the level of system decomposition, this can be a view of what is being done or how it is being done. This perspective is used when producing functional requirements. 3 Another characteristic of an emerging discipline. Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-4 Big picture perspective. The big picture perspective provides a view of the forest rather than the trees. It views the system within the context of its containing system – its environment, the closely coupled adjacent systems with which it interacts and any loosely coupled more distant systems as shown in Figure 1 (Kasser, 2001). Thus the perspective contains information about the external boundary of the system and the assumptions behind the location of the boundary. Structural perspective. The structural perspective views the systems‟ architecture and the internal subsystem partition boundaries and any effects on the system due to its internal structure. This perspective incorporates the traditional physical, technical and architectural framework views. Generic perspective. The generic perspective looks for similarities between the system and other systems in the same or other domains, in the present or in the past. This perspective leads to the: Inheritance of domain requirements from similar systems in Area 2B of the HKM framework (Kasser, 2007a, c). Adoption of lessons learned from other projects and determination if those lessons are applicable to current project. Innovative design approaches in the system domain using approaches from other domains. It is probable that someone else in another domain has already faced and solved the problem currently being faced (Barry, et al., 2007). For example, one of the factors leading to the successful architecture of the LuZ Solar Electrical Generating System in the early 1980‟s (Kasser, 2007b) was the insight that generically the network of microprocessor controlled local controllers on the mirrors and a central station was similar to a constellation of satellites and their central control station. Continuum perspective. The continuum perspective recognizes that: Things are not necessarily „either-or‟, there may be states in between. This leads to concepts such as „fail soft‟ in operation and the replacement of „either-or‟ questions such as “is systems engineering an undergraduate or a postgraduate subject?” by questions in the form of “to what degree is systems engineering a postgraduate subject?” or “what is the knowledge needed by a systems engineering engineer and how much of it can be taught as an undergraduate subject?” This is a very different perspective to the traditional „either-or‟ „one right way‟ perspective. Changing conditions may cause movement along the continuum. This leads to the insight that systems can exhibit different types of behaviour in different situations rather than always behave in the same way and that the transition conditions causing that change in behaviour may not be known. In the case of human systems, the continuum perspective points out that: Figure 1 The big picture system of interest and adjacent systems Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-5 1. Maslow‟s hierarchy (Maslow, 1970) may not be so much as a pyramid, but a pie, and motivating people becomes a matter of figuring out which slices of the pie to offer them (Kasser, 1995). 2. Theory X and Theory Y (McGregor, 1960) behaviour may be two ends of a situational continuum of behaviour rather than two opposing behaviour patterns. The „fail soft‟ perspective leads to an analysis of failure modes for the system and each of its components. The analysis may influence the structural and functional perspectives in the design of the system. The perspective also leads to a risk analysis of the probability and effect of internal and externally induced failures and ways to mitigate the failures. Internal failures are failures of components due to aging and normal wear and tear (Moubray, 2005), external failures are those inflicted from without, such as natural disasters, sabotage and enemy action. Temporal perspective. The temporal perspective looks at how the system behaves over time. If the system exists, past patterns of behaviour are examined and future patters are predicted using this perspective. Insights from this perspective include: The consideration of Availability, maintenance, logistics, obsolescence, etc. The concept of prevention. The need to consider the effects due to aging, the need for upgrades and replacement and the effect of diminishing sources of materiel such as spare parts for the technology to be used in the system. Lessons to be learned from the system implementation and improvements for future iterations of the system. An understanding that even if the implemented solution works it may introduce further problems that only show up after some period of time. These time delays were grouped (Kasser, 2002) as: o First order noticeable effect within a second or less. o Second order noticeable effect within a minute or less. o Third order noticeable effect within an hour or less. o Fourth order noticeable effect within a day or less. o Fifth order noticeable effect within a week or less. o Sixth order noticeable effect within a month or less. o Seventh order noticeable effect within a year or less. o Eighth order noticeable effect within a decade or less. o Ninth order noticeable effect within a century or less. o Tenth order – noticeable effect after a century or more. This is the perspective in which temporal cause and effect loops are considered and the reflection on the past provides lessons learned from the system. This perspective also alerts analysts that past performance may not be a useful predictor of future performance unless the factors contributing to the past performance are understood. Quantitative perspective. The quantitative perspective relates to the big picture and to the operational and functional perspectives to develop the performance requirements. According to (Richmond, 1993), the quantitative perspective however is not about the need to measure everything, “it is more the recognition that numbers must be useful, not necessarily perfect and need not be absolute”. Sometimes relative comparisons are more useful. This perspective is about quantification rather than measurement, and helps to understand relationships and leads to the mathematical relationships in (functional) models and simulations. An example of quantification is the Likert scale, named after its originator Rensis Likert (1903-1981). The Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-6 Likert scale offers a means of determining attitudes across a continuum of choices, such as “strongly agree,” “agree”, “don‟t care”, “disagree” and “strongly disagree.” A numerical value can then be allocated to each statement for further analysis. The numerical values may not necessarily be in a linear relationship. Scientific perspective. Whereas the other descriptive perspectives are used to examine (and document) a system, problem or situation, this prescriptive perspective covers the formulation and testing of hypothetical candidate representations of the system to meet the need that will be constructed in the design and implementation phases of the system development life cycle (SDLC), and the construction of the tests used to validate the representation by the Test and Evaluation (T&E) function of systems engineering. The scientific perspective forms the basis for the „trial and error‟ approach to problem solving. Using the systems thinking perspectives The application of each of the descriptive STPs begins by asking the questions “who, what, where, when, why and how” (Kipling, 1912). However, since the boundaries of the STPs are artificial for the benefit of applying systems thinking, the understanding gained from one of the STPs might generate a scientific perspective (hypothesis or solution) documented in a different STP or even a mixture as demonstrated by the following examples: 1. The HKM Framework (Kasser, 2007a, c) is a hypothesis (scientific STP) presenting the concept using a structural STP, yet the insight to postulate it came from the big picture STP (vertical axis), the temporal STP (horizontal axis) and the continuum STP (for the problem solving dimension). 2. Figure 3 (Kasser, 2001) depicts the parallel evolution of the systems in the big picture STP shown in Figure 1. The colours in the figure emphasize that each of the systems may be in different stages of their in-service operate and upgrade part of the SDLC. This is a temporal big picture STP and provides insight on the need to consider the effects of evolution of adjacent systems on the system of interest. This insight was applied in about 1992 in the NASA Goddard Space Flight Center Systems Engineering and Support Contract when Code 560 was faced with a major problem. When the manufacturer of the minicomputer used in their Packet Data Processing facility announced that they would no longer be supporting the minicomputer, Code 560 realized that they had a major risk in that the then current architecture would probably not be able to support the operational spacecraft due to the aging of equipment and the lack of spare parts to repair expected failures. This is a problem being faced by many current systems in the Defence environment. In this instance, this insight resulted in an out-of-the box solution to the problem not only provided the needed support but also saved NASA $1,500,000 (Kasser, 2006). Figure 2 Parallel evolution Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-7 An example of the application of the STPs Having discussed a way of applying systems thinking to systems engineering via the STPs, the methodology for applying the STPs is to make use of the template shown in Table 2 until they become intuitive. For each perspective, ask the appropriate Kipling question. If nothing comes to mind, skip to the next question. The template is a starting point for discussion and documentation. The paper now demonstrates the application of the STPs by aligning views of a system to the STPs. The example system under consideration is the Royal Air Force (RAF) Battle of Britain Air Defence System (RAFBADS) which was used to foil the Luftwaffe‟s attempt to gain control of the sky over southern England in 1940. The RAFBADS was designed in the late 1930‟s and deployed in time to meet the Luftwaffe threat. Travel back in time to the period in which the RAFBADS was being designed and view the problem of providing an air defence system from the STPs. However, the following discussion is not intended to be a complete application of the STPs to the problem of providing an air defence system. Rather, the discussion highlights aspects brought out by the STPs. Operational STP. The system inputs are pilots, aircraft, ordnance, fuel, and mains generated electrical power. The system outputs (the products it produces) are damaged and destroyed enemy aircraft. The feedback function or relationship between outputs and inputs is that pilots and aircraft lost to enemy action, ordnance and fuel consumed must be replaced. From a self-regulating perspective the system strives to maintain a steady state in terms of operational aircraft (the combination of mission-ready aircraft and trained pilots). The purpose of the RAFBADS is defence; it will be a reactive system responding to stimuli. A set of detailed operational scenarios would be developed to describe anticipated responses to specific enemy threats in terms of the way it makes use of people and the technology. This is currently done in traditional systems engineering. Functional STP. This STP is also employed in traditional systems engineering. Thus, a functional analysis would be performed showing what functions the RAFBADS performs (in terms of information flows, vectoring of RAF aircraft, etc.) so as to gain and maintain control of the air. Big picture STP. The big picture STP described below covers: 1. the context or environment of the RAFBADS, 2. the assumptions in the design of the RAFBADS, and 3. its relationships with its adjacent systems. Context. The context consists of two containing systems as follows: The situational context, a war in which the country is facing an enemy intent in invading and conquering it. The RAFBADS is the first line of defence responding to enemy attempts to open a breech in the defences. The organizational context, the RAF with its traditions, procedures and organizational structure. Assumptions. The assumptions upon which the RAFBADS are based are as follows: The resources needed to operate the RAFBADS, namely, pilots, fuel, aircraft and (mains generated) electrical power are outside the boundary of the RAFBADS and provided to it. Weather is an important factor. The state of technology is such that enemy attacks are to be expected only in good weather 4 . This assumption, if validated, allows the down 4 The term needs a more precise definition with respect to visibility, cloud, etc. Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-8 time due to bad weather to be applied to maintaining the system (non-critical preventive maintenance, pilot rest time, etc.). The rescue of downed pilots is outside the system. However, this was changed in 1941 after having learned the need to bring the function inside the system (Bungay, 2000) page 68). Adjacent systems. Adjacent systems perform the other functions of fighting a war. The immediate adjacent (tightly coupled) systems provide the inputs to the system, namely fuel, ordnance, pilots and aircraft to the RAFBADS. Identifying these systems outside the boundary of the RAFBADS pointed out a need for a meta-system in which the RAFBADS and the systems producing the resources for the RAFBADS are subsystems of the metasystem. When implemented, the need for pilots, ordnance, replacement aircraft and fuel was identified and appropriate adjacent systems instituted. However, the reliance on external power seems to have been overlooked until enemy action destroyed the power lines and brought down a section of the system. Early identification of this reliance on external power might have led to a requirement for emergency standby power generators. Other loosely coupled adjacent systems perform functions such as: Prevention of attacks by destroying resources needed by the Luftwaffe to mount attacks. Damaging the enemy‟s ability to wage war. Contributing to ending the war in England‟s favour. Structural STP. The structural STP in this case is very much a physical view. Information about the location of the enemy is generated by the audio and visual observers and Radar sites and sent to Fighter Command HQ. HQ sends the information on to the Groups and finally it is disseminated to the appropriate airfields. Information about the state of readiness of the airfields and squadrons and the results of air engagements are sent back from the airfields to Fighter Command HQ. Generic STP. From the generic STP the RAFBADS is operating in a siege situation. Historically, sieges have ended either when the enemy gives up and departs, or when the enemy breaks through the defences and slaughters the defenders. Thus the purpose of the RAFBADS is to prevent the enemy attacks from succeeding until the enemy decides to go away or is defeated by one of the loosely coupled adjacent systems mentioned in the Big Picture STP. In traditional city sieges, the pivotal situation is when the enemy breaks though the defences and enters the city usually through a hole in the defences. The generic STP indicates that the analogy to a hole in the defences in this situation would be the control of the air over the south coast of England by the Luftwaffe. Factors contributing to this situation would be 5 : Loss of airfields – since aircraft cannot be launched. Loss of radar information – since the point of attack cannot be determined and defenders scrambled and vectored to meet them. This information is made use of in the operational scenarios. This STP indicates that the airfields would be primary targets for destruction by the enemy by likening the situation to the need by a besieger to destroy the guns that deterred attackers from approaching too close to the city to effect and utilize a breech in the defences. This STP would also provide the insight that if the airfields are prime targets, then any physical structures adjacent to the 5 Remember the war is still in the future at the time this analysis is being performed. Module 5 Accepted to the18th INCOSE International Symposium, Utrecht, Holland, 2008 0507-9 airfield would be likely to suffer bomb damage. Continuum STP. This STP shows the need for an ability to operate with damage, the „failsoft‟ concept discussed above. This should produce requirements for the architecture of the system. The design process would use the scientific STP to postulate failure scenarios (operational STP) and corresponding requirements. Temporal STP. The system contains both people and technology. It can be expected to get better in time. Consequently, there will be several learning curves including: Pilots learning tactics of air combat, and Ground to air communications.