Difference between revisions of "Synthesizing Possible Solutions"
| Line 1: | Line 1: | ||
This article considers the activities of the [[Systems Approach (glossary)]] related to the [[Synthesis (glossary)]] of possible solutions options in detail. Any of the activities described below may need to be considered [[concurrently (glossary)]] with other activities of in the Systems Approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the Systems Approach and how this relates in detail to elements of Systems Engineering. | This article considers the activities of the [[Systems Approach (glossary)]] related to the [[Synthesis (glossary)]] of possible solutions options in detail. Any of the activities described below may need to be considered [[concurrently (glossary)]] with other activities of in the Systems Approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the Systems Approach and how this relates in detail to elements of Systems Engineering. | ||
| − | == | + | ==Synthesis Overview== |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Essential to synthesis is the concept of [[Holism (glossary)]] discussed by (Hitchins 2009). It states that a system must be considered as a whole and not simply as a collection of its elements. The holism of any potential solution system requires that the properties of the whole be determined by considering the behavior of the whole and not simply as the accumulation of the properties of the elements. The latter process is known as reductionism and is the opposite of holism. (Hitchins 2009, p. 60) puts it this way: “The properties, capabilities, and behavior of a system derive from its parts, from interactions between those parts, and from interactions with other systems.” | |
| − | + | When the system is considered as a whole, properties called emergent properties often appear (see [[Emergence]]). These properties are often difficult to predict from the elements alone. They must be evaluated within the Systems Approach to determine the complete set of performance levels of the system. According to (Jackson et al. 2010) these properties can be designed into the system, but to do so, an iterative approach is required. | |
| − | + | ||
| + | In complex systems, individual elements will adapt to the behavior of the other elements and to the system as a whole. The entire collection of elements will behave as an organic whole. Therefore, the entire synthesis activity, particularly in complex systems, must itself be adaptive. | ||
| − | + | ==Problem or Opportunity Context== | |
| − | + | System Synthesis needs the [[Identifying and Understanding Problems and Opportunities|problem or opportunity]] that the system is intended to address to have been identified and described or, more likely for any non-trivial system, is being identified and understood concurrently with solution synthesis activities. | |
| − | + | As discussed in [[Identifying and Understanding Problems and Opportunities]] the Systems Approach should not consider strictly Soft or Hard situations. More properly, a problem or opportunity will have aspects of both. In general, the application of the Systems Approach with a focus on [[Engineered System (glossary)]] contexts will lead to [[Hard System (glosssary)]] contexts, in which an identified System of Interest and required outcome can be defined. Even in these cases, a soft context view of the SoI context will help ensure wider Stakeholder concerns are considered. | |
| − | + | If a [[Soft System (glossary)]] context has been defined this may include a Conceptual Model (Checkland 1999) which describes the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders. In problem contexts with a strong [[Coercive (glossary)]] dimension the problem context should include identification of the relative power and importance of stakeholders. If appropriate Synthesis may consider solutions which move decision making power to best effect in the solution, rather than retaining the authority of those currently in positions of power. | |
| − | + | In a [[Hard System (glossary)]] problem context a description of a logical or ideal system solution may be included. Like the conceptual system above, this ideal system cannot be implemented directly, but describes the properties required of any realizable system solution. In this case, System Synthesis activities will be used to describe one or more realizable solutions which enact the idea solution. | |
| − | In | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ==Synthesis Activities== | |
| − | |||
| − | |||
| − | |||
| − | + | The following outlines activities for defining the system of interest (SoI): Identification of the Function of System Elements, Identification of System Elements, Division of Elements into Smaller Elements, Grouping of Elements, Identification of the Boundary of a System and Identification of the Interactions Among the Elements. | |
| − | + | The activities of Systems Synthesis are built on the idea of a balanced Reduction vs Holism approach as discussed in [[What is Systems Thinking]]. It is necessary to divide system elements and functions to create a description of the SoI which is realisable, either through combinations of available elements or through the design and build of new elements. However, if we simple decompose the system into smaller and smaller elements the Holistic nature of systems will make it more and more impossible to predict the function and behavior of the whole. Thus synthesis progress through activities which divide, group and allocate elements and then assess the resulting complete systems properties in context. | |
| − | + | ===Identification of the Boundary of a System=== | |
| + | Establishing the boundary of a system is essential to Synthesis and the determination of the system's interaction with its environment and with other systems and the extent of the system of interest (SOI). (Buede 2009, p. 1102) provides a comprehensive discussion of the importance and methods of defining the boundary of a system in a SE context. | ||
| − | + | ===Identification of the Functions the System=== | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | The function of a system at a given level of abstraction is critical to synthesis, since the primary goal of the synthesis activity is to proposed realizable system descriptions which can provide a given function. The function of a system is distinct from its behavior, as it describes what the system can be used for or asked to do in a larger system context. | ||
| + | |||
| + | (Buede 2009, pp. 1091-1126) provides a comprehensive description of functional analysis in a SE context. | ||
| + | |||
| + | ===Identification of the Elements of a System=== | ||
| + | |||
| + | System Synthesis calls for the identification of the elements of a system. Typical elements of an [[Engineered Systems Context]] may be physical, conceptual, or processes. Physical elements may be hardware, software, or humans. Conceptual elements may be ideas, plans, concepts, or hypotheses. Processes may be mental, mental-motor (writing, drawing, etc.), mechanical, or electronic (Blanchard and Fabrycky 2006, p. 7). | ||
| + | |||
| + | System Synthesis will include activities to understand the properties of system elements, the structure of proposed system solutions and the resultant behavior of the composed system. A number of system concepts for describing system behavior are discussed in [[System Concepts]]. Note, to fully understand a systems behavior we must consider the full range of environments in which it might be placed and its allowable state in each. According to (Page 2009), in complex systems the individual elements of the system are characterized by properties which enhance the systems as a whole, such as their adaptability. | ||
| + | |||
| + | In addition to the operational elements of the system under consideration (i.e., a System of Interest, SOI), ISO/IEC 15288 (2008) also calls for the identification of the enabling systems. These are systems utilized at various stages in the life cycle; for example, maintenance and other systems that support the operational elements to solve problems or achieve opportunity. | ||
| + | |||
| + | Today's systems often include existing elements. It is rare to find a true "greenfield" systems in which the developers can specify and implement all new elements from scratch. "Brownfield" systems are much more typical, where legacy elements constrain the system structure, capabilities, technology choices, and other aspects of implementation. (Boehm 2009) | ||
| + | |||
| + | ===Division of System Elements=== | ||
| + | |||
| + | System Synthesis may require elements to be divided into smaller elements. The division of elements into smaller elements allows the systems to be grouped, and leads to the Systems Engineering concept of physical architecture as described by (Levin 2009, pp. 493-495). Each layer of division leads to another layer of the hierarchical view of a system. As Levin points out, there are many ways to depict the physical architecture including wiring diagrams, block diagrams, etc. All of these views depend on arranging the elements and dividing them into smaller elements. According to the principle of recursion, these decomposed elements are either terminal elements or are further decomposable. The hierarchical view does not imply a top-down analytical approach to defining a system. It is simply a view. In the systems approach levels of the hierarchy are defined and considered recursively, with one level forming the context for the next. | ||
| + | |||
| + | ===Grouping of System Elements=== | ||
| + | |||
| + | System Synthesis may require that elements can be grouped. This leads to the identification of the subsystems essential to the definition of a system. Synthesis determines how a system may be partitioned and how each subsystem fits and functions within the whole system. The largest group is the system of interest (SOI), also called the relevant system by (Checkland 1999, p. 166). According to (Hitchins 2009, p. 61), some of the properties of an SOI are as follows: the SOI is open and dynamic; the SOI interacts with other systems, and; the SOI contains sub-systems. The SOI is brought together through the concept of synthesis. | ||
| + | |||
| + | ===Identification of the Interactions among System Elements=== | ||
| + | |||
| + | System Synthesis may require the identification of the interactions among system elements. These interactions lead to the SE process of interface analysis. Integral to this aspect is the principle of interactions. Interactions occur both with other system elements and also with external elements and the environment. In a Systems Approach, interfaces have both a technical and managerial importance. Managerial aspects include contracts between interfacing organizations. Technical aspects include the properties of the physical and functional interfaces. (Browning 2009, pp. 1418-1419) provides a list of desirable characteristics of both technical and managerial interface characteristics. | ||
| + | |||
| + | ==Defining the System of Interest== | ||
| + | |||
| + | (Flood and Carson 1993) identify two ways to identify system boundaries. A bottom-up, or '''structural approach''', in which we start with significant system elements and build out. A top down, or '''behavioral approach''', in which we identify major systems needed to fulfill a goal, and then work down. They identify a number of rules, proposed by (Beishon 1980) and (Jones 1982) to help in the select of the best approach. | ||
| + | |||
| + | In either case, the ways in which system elements are refined, grouped and allocated must be driven towards the synthesis of a realizable system solution description. Note, realizable must consider elements which are either already available, can be created from existing system elements or are themselves described as System contexts which will need to be synthesized at a future point. In the third case, it is one of the outcomes of the [[Analysis and Selection between Alternative Solutions]] activities to assess the risk that a given element may not be able to be synthesized in the required timescales or cost budget. | ||
| + | |||
| + | In a top down approach we might start with a system boundary and an overall description of system functions. Through the repeated application of element identification, division, grouping and allocation of function a complete description of the elements needed for the SoI can be defined. In this case the choice of system elements and allocation of function may be guided by pre defined ways of solving a given problem or identified System Patterns (reference needed). | ||
| + | |||
| + | In a bottom up approach we start with major elements and interactions. Again, division, grouping and identification allows us to build up a full system description able to provide all necessary functions, at which point the final SoI boundary can be set. In this case the choice of system elements and groupings will be driven by ensuring the major system elements can be formed together into a viable system whole. | ||
| + | |||
| + | The systems approach aspect of synthesis leads to Systems Engineering terms such as “design” and “development”. (Wasson 2006, 390-690) describes synthesis from a Systems Engineering point of view. (White 2009, 512-515) provides a comprehensive discussion of methods of achieving design synthesis. Systems approach treats synthesis at the abstract level while Systems Engineering process definitions provide the concrete steps. | ||
==References== | ==References== | ||
Revision as of 23:49, 26 February 2012
This article considers the activities of the systems approach related to the synthesis of possible solutions options in detail. Any of the activities described below may need to be considered concurrently with other activities of in the Systems Approach. The final article in this knowledge area, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the Systems Approach and how this relates in detail to elements of Systems Engineering.
Synthesis Overview
Essential to synthesis is the concept of holism discussed by (Hitchins 2009). It states that a system must be considered as a whole and not simply as a collection of its elements. The holism of any potential solution system requires that the properties of the whole be determined by considering the behavior of the whole and not simply as the accumulation of the properties of the elements. The latter process is known as reductionism and is the opposite of holism. (Hitchins 2009, p. 60) puts it this way: “The properties, capabilities, and behavior of a system derive from its parts, from interactions between those parts, and from interactions with other systems.”
When the system is considered as a whole, properties called emergent properties often appear (see Emergence). These properties are often difficult to predict from the elements alone. They must be evaluated within the Systems Approach to determine the complete set of performance levels of the system. According to (Jackson et al. 2010) these properties can be designed into the system, but to do so, an iterative approach is required.
In complex systems, individual elements will adapt to the behavior of the other elements and to the system as a whole. The entire collection of elements will behave as an organic whole. Therefore, the entire synthesis activity, particularly in complex systems, must itself be adaptive.
Problem or Opportunity Context
System Synthesis needs the problem or opportunity that the system is intended to address to have been identified and described or, more likely for any non-trivial system, is being identified and understood concurrently with solution synthesis activities.
As discussed in Identifying and Understanding Problems and Opportunities the Systems Approach should not consider strictly Soft or Hard situations. More properly, a problem or opportunity will have aspects of both. In general, the application of the Systems Approach with a focus on engineered system contexts will lead to Hard System (glosssary) contexts, in which an identified System of Interest and required outcome can be defined. Even in these cases, a soft context view of the SoI context will help ensure wider Stakeholder concerns are considered.
If a soft system context has been defined this may include a Conceptual Model (Checkland 1999) which describes the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders. In problem contexts with a strong coercive dimension the problem context should include identification of the relative power and importance of stakeholders. If appropriate Synthesis may consider solutions which move decision making power to best effect in the solution, rather than retaining the authority of those currently in positions of power.
In a hard system problem context a description of a logical or ideal system solution may be included. Like the conceptual system above, this ideal system cannot be implemented directly, but describes the properties required of any realizable system solution. In this case, System Synthesis activities will be used to describe one or more realizable solutions which enact the idea solution.
Synthesis Activities
The following outlines activities for defining the system of interest (SoI): Identification of the Function of System Elements, Identification of System Elements, Division of Elements into Smaller Elements, Grouping of Elements, Identification of the Boundary of a System and Identification of the Interactions Among the Elements.
The activities of Systems Synthesis are built on the idea of a balanced Reduction vs Holism approach as discussed in What is Systems Thinking. It is necessary to divide system elements and functions to create a description of the SoI which is realisable, either through combinations of available elements or through the design and build of new elements. However, if we simple decompose the system into smaller and smaller elements the Holistic nature of systems will make it more and more impossible to predict the function and behavior of the whole. Thus synthesis progress through activities which divide, group and allocate elements and then assess the resulting complete systems properties in context.
Identification of the Boundary of a System
Establishing the boundary of a system is essential to Synthesis and the determination of the system's interaction with its environment and with other systems and the extent of the system of interest (SOI). (Buede 2009, p. 1102) provides a comprehensive discussion of the importance and methods of defining the boundary of a system in a SE context.
Identification of the Functions the System
The function of a system at a given level of abstraction is critical to synthesis, since the primary goal of the synthesis activity is to proposed realizable system descriptions which can provide a given function. The function of a system is distinct from its behavior, as it describes what the system can be used for or asked to do in a larger system context.
(Buede 2009, pp. 1091-1126) provides a comprehensive description of functional analysis in a SE context.
Identification of the Elements of a System
System Synthesis calls for the identification of the elements of a system. Typical elements of an Engineered Systems Context may be physical, conceptual, or processes. Physical elements may be hardware, software, or humans. Conceptual elements may be ideas, plans, concepts, or hypotheses. Processes may be mental, mental-motor (writing, drawing, etc.), mechanical, or electronic (Blanchard and Fabrycky 2006, p. 7).
System Synthesis will include activities to understand the properties of system elements, the structure of proposed system solutions and the resultant behavior of the composed system. A number of system concepts for describing system behavior are discussed in System Concepts. Note, to fully understand a systems behavior we must consider the full range of environments in which it might be placed and its allowable state in each. According to (Page 2009), in complex systems the individual elements of the system are characterized by properties which enhance the systems as a whole, such as their adaptability.
In addition to the operational elements of the system under consideration (i.e., a System of Interest, SOI), ISO/IEC 15288 (2008) also calls for the identification of the enabling systems. These are systems utilized at various stages in the life cycle; for example, maintenance and other systems that support the operational elements to solve problems or achieve opportunity.
Today's systems often include existing elements. It is rare to find a true "greenfield" systems in which the developers can specify and implement all new elements from scratch. "Brownfield" systems are much more typical, where legacy elements constrain the system structure, capabilities, technology choices, and other aspects of implementation. (Boehm 2009)
Division of System Elements
System Synthesis may require elements to be divided into smaller elements. The division of elements into smaller elements allows the systems to be grouped, and leads to the Systems Engineering concept of physical architecture as described by (Levin 2009, pp. 493-495). Each layer of division leads to another layer of the hierarchical view of a system. As Levin points out, there are many ways to depict the physical architecture including wiring diagrams, block diagrams, etc. All of these views depend on arranging the elements and dividing them into smaller elements. According to the principle of recursion, these decomposed elements are either terminal elements or are further decomposable. The hierarchical view does not imply a top-down analytical approach to defining a system. It is simply a view. In the systems approach levels of the hierarchy are defined and considered recursively, with one level forming the context for the next.
Grouping of System Elements
System Synthesis may require that elements can be grouped. This leads to the identification of the subsystems essential to the definition of a system. Synthesis determines how a system may be partitioned and how each subsystem fits and functions within the whole system. The largest group is the system of interest (SOI), also called the relevant system by (Checkland 1999, p. 166). According to (Hitchins 2009, p. 61), some of the properties of an SOI are as follows: the SOI is open and dynamic; the SOI interacts with other systems, and; the SOI contains sub-systems. The SOI is brought together through the concept of synthesis.
Identification of the Interactions among System Elements
System Synthesis may require the identification of the interactions among system elements. These interactions lead to the SE process of interface analysis. Integral to this aspect is the principle of interactions. Interactions occur both with other system elements and also with external elements and the environment. In a Systems Approach, interfaces have both a technical and managerial importance. Managerial aspects include contracts between interfacing organizations. Technical aspects include the properties of the physical and functional interfaces. (Browning 2009, pp. 1418-1419) provides a list of desirable characteristics of both technical and managerial interface characteristics.
Defining the System of Interest
(Flood and Carson 1993) identify two ways to identify system boundaries. A bottom-up, or structural approach, in which we start with significant system elements and build out. A top down, or behavioral approach, in which we identify major systems needed to fulfill a goal, and then work down. They identify a number of rules, proposed by (Beishon 1980) and (Jones 1982) to help in the select of the best approach.
In either case, the ways in which system elements are refined, grouped and allocated must be driven towards the synthesis of a realizable system solution description. Note, realizable must consider elements which are either already available, can be created from existing system elements or are themselves described as System contexts which will need to be synthesized at a future point. In the third case, it is one of the outcomes of the Analysis and Selection between Alternative Solutions activities to assess the risk that a given element may not be able to be synthesized in the required timescales or cost budget.
In a top down approach we might start with a system boundary and an overall description of system functions. Through the repeated application of element identification, division, grouping and allocation of function a complete description of the elements needed for the SoI can be defined. In this case the choice of system elements and allocation of function may be guided by pre defined ways of solving a given problem or identified System Patterns (reference needed).
In a bottom up approach we start with major elements and interactions. Again, division, grouping and identification allows us to build up a full system description able to provide all necessary functions, at which point the final SoI boundary can be set. In this case the choice of system elements and groupings will be driven by ensuring the major system elements can be formed together into a viable system whole.
The systems approach aspect of synthesis leads to Systems Engineering terms such as “design” and “development”. (Wasson 2006, 390-690) describes synthesis from a Systems Engineering point of view. (White 2009, 512-515) provides a comprehensive discussion of methods of achieving design synthesis. Systems approach treats synthesis at the abstract level while Systems Engineering process definitions provide the concrete steps.
References
Works Cited
Beishon, J. 1980. Systems Organisations: the Management of Complexity. Milton Keynes; Open University press.
Blanchard, B. and W.J. Fabrcky. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ: Prentice Hall.
Boehm, B. 2009. "Applying the Incremental Commitment Model to Brownfield System Development". Proceedings of the 7th Annual Conference on Systems Engineering Research (CSER), Loughborough, UK.
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations". In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management," 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
Buede, D.M. 2009. "Functional Analysis". In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management," 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
Checkand, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.
Flood, R. L. and E.R. Carson. 1993. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science, 2nd ed. New York, NY, USA: Plenum Press.
Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight. 12(4) (December 2009): 59-63.
INCOSE. 1998. "INCOSE SE Terms Glossary." INCOSE Concepts and Terms WG (eds.). Seattle, WA, USA: International Council on Systems Engineering.
Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the Systems Approach?". INCOSE Insight. 13(1) (April 2010): 41-43.
Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the Systems Approach?". INCOSE Insight. 13(1) (April 2010): 41-43.
Jones, L. 1982, "Defining System Boundaries in Practice: Some Proposals and Guidelines." Journal of Applied Systems Analysis, 9: 41-55.
Levin, A.H. 2009. "System Architectures". In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management," 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
Page, S.E. 2009. Understanding Complexity. The Great Courses. Chantilly, VA, USA: The Teaching Company.
Shorter Oxford English Dictionary on Historical Principles, 3rd ed. s.v. "Analysis." Oxford, UK: Oxford University Press. 1973.
Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.
White, Jr., K.P. 2009. "Systems Design." In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
Primary References
Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight. 12(4) (December 2009): 59-63.
Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight. 13(1) (April 2010): 41-43.
ISO/IEC 2008. Systems and software engineering -- System life cycle processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.
Additional References
Blanchard, B. and W.J. Fabrcky. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ: Prentice Hall.
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations". In A.P. Sage and W.B. Rouse, W.B. (eds.) Handbook of Systems Engineering and Management, 2nd Ed. Hoboken, NJ: John Wiley & Sons.
Buede, D.M. 2009. "Functional Analysis." In A.P. Sage and W.B. Rouse, W.B. (eds.). Handbook of Systems Engineering and Management, 2nd Ed.. Hoboken, NJ: John Wiley & Sons.
INCOSE. 1998. "INCOSE SE Terms Glossary." INCOSE Concepts and Terms WG (eds.). Seattle, WA, USA: International Council on Systems Engineering.
Levin, A.H. 2009. "System Architectures." In A.P. Sage and W.B. Rouse, W.B. (eds.). Handbook of Systems Engineering and Management, 2nd Ed. Hoboken, NJ: John Wiley & Sons.
Page, S.E. 2009. Understanding Complexity. The Great Courses. Chantilly, VA, USA: The Teaching Company.
Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.
White, Jr., K.P. 2009. "Systems Design." In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons