Difference between pages "Types of Systems" and "Complexity"

From SEBoK
(Difference between pages)
Jump to navigation Jump to search
(Tech and grammar edits as discussed with Bkcase)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
 
----
 
----
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Brian Wells, Scott Jackson''
+
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Hillary Sillitto, Sarah Sheard''
 
----
 
----
This article forms part of the [[Systems Fundamentals]] knowledge area (KA). It provides various perspectives on {{Term|System (glossary)|system}} classifications and types of systems, expanded from the definitions presented in [[What is a System?]].   
+
This article is part of the [[Systems Fundamentals]] knowledge area (KA). It gives the background of and an indication of current thinking on {{Term|Complexity (glossary)|complexity}} and how it influences {{Term|Systems Engineering (glossary)|systems engineering}} (SE) practice.   
  
The modern world has numerous kinds of systems that influence daily life. Some examples include transport systems; solar systems; telephone systems; the Dewey Decimal System; weapons systems; ecological systems; space systems; etc. Indeed, it seems there is almost no end to the use of the word “system” in today’s society.  
+
Complexity is one of the most important and difficult to define {{Term|System (glossary)|system}} {{Term|Concept (glossary)|concepts}}. Is a system's complexity in the eye of the beholder, or is there inherent complexity in how systems are organized? Is there a single definitive definition of complexity and, if so, how can it be assessed and {{Term|Measure (glossary)|measured}}? This topic will discuss how these ideas relate to the general definitions of a system given in [[What is a System?]], and in particular to the different {{Term|Engineered System (glossary)|engineered system}} {{Term|Context (glossary)|contexts}}. This article is closely related to the [[Emergence|emergence]] topic that follows it.
  
This article considers the different classification systems which some {{Term|Systems Science (glossary)}} authors have proposed in an attempt to extract some general {{Term|Principle (glossary)|principles}} from these multiple occurrences. These classification schemes look at either the kinds of {{Term|Element (glossary)|elements}} from which the system is composed or its reason for existing.
+
==Defining System Complexity==
 +
Complexity has been considered by a number of authors from various perspectives; some of the discussions of complexity relevant to systems are described in the final section of this article.  Sheard and Mostashari (Sheard and Mostashari 2011) synthesize many of these ideas to categorize complexity as follows:
 +
#'''Structural Complexity''' looks at the system elements and relationships. In particular, structural complexity looks at how many different ways system elements can be combined. Thus, it is related to the potential for the system to adapt to external needs.
 +
#'''Dynamic Complexity''' considers the complexity which can be observed when systems are used to perform particular tasks in an environment. There is a time element to dynamic complexity. The ways in which systems interact in the short term is directly related to system behavior; the longer-term effects of using systems in an environment is related to system evolution.
 +
#'''Socio-Political Complexity''' considers the effect of individuals or groups of people on complexity. People-related complexity has two aspects. One is related to the perception of a situation as complex or not complex, due to multiple stakeholder {{Term|Viewpoint (glossary)|viewpoints}} within a system context and social or cultural biases which add to the wider influences on a system context. The other involves either the “irrational” behavior of an individual or the swarm behavior of many people behaving individually in ways that make sense; however, the {{Term|Emergence (glossary)|emergent}} behavior is unpredicted and perhaps counterproductive. This latter type is based on the interactions of the people according to their various interrelationships and is often graphed using systems dynamics formalisms.
  
The idea of an {{Term|Engineered System (glossary)|engineered system}} is expanded. Four specific types of engineered {{Term|System Context (glossary)|system context}} are generally recognized in {{Term|Systems Engineering (glossary)|systems engineering}}: {{Term|Product System (glossary)|product system}}, {{Term|Service System (glossary)|service system}}, {{Term|Enterprise System (glossary)|enterprise system}} and {{Term|System of Systems (SoS) (glossary)|system of systems}}.
+
Thus, complexity is a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it. It occurs when there is no simple relationship between what an individual element does and what the system as a whole will do, and when the system includes some element of adaptation or problem solving to achieve its goals in different situations. It can be affected by objective attributes of a system such as by the number, types of and diversity of system elements and relationships, or by the subjective perceptions of system observers due to their experience, knowledge, training, or other sociopolitical considerations.  
  
==System Classification==
+
This view of complex systems provides insight into the kind of system for which systems thinking and a {{Term|Systems Approach (glossary)|systems approach}} is essential.
A taxonomy is "a classification into ordered categories" (Dictionary.com 2011). Taxonomies are useful ways of organizing large numbers of individual items so their similarities and differences are apparent. No single standard systems taxonomy exists, although several attempts have been made to produce a useful classification taxonomy, e.g. (Bertalanffy 1968) and (Miller 1986).  
 
  
Kenneth Boulding (Boulding 1956), one of the founding fathers of {{Term|General System Theory (glossary)|general system theory}}, developed a systems classification which has been the starting point for much of the subsequent work. He classifies systems into nine types:
+
==Complexity and Engineered Systems==
  
#Structures (Bridges)  
+
The different perspectives on complexity are not independent when considered across a {{Term|System Context (glossary)|systems context}}.  The structural complexity of a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) may be related to dynamic complexity when the SoI also functions as part of a wider system in different problem scenarios. People are involved in most system contexts, as part of the problem situation, as system elements and part of the operating environment. The human activity systems which we create to identify, design, build and support an {{Term|Engineered System (glossary)|engineered system}} and the wider social and business systems in which they sit are also likely to be complex and affect the complexity of the systems they produce and use.
#Clock works (Solar system)
 
#Controls (Thermostat)
 
#Open (Biological cells)
 
#Lower organisms (Plants)
 
#Animals (Birds)
 
#Man (Humans)
 
#Social (Families)
 
#Transcendental (God)
 
  
These approaches also highlight some of the subsequent issues with these kinds of classification. Boulding implies that physical structures are closed and natural while social ones are open. However, a bridge can only be understood by considering how it reacts to traffic crossing it, and it must be sustained or repaired over time (Hitchins 2007). Boulding also separates humans from animals, which would not fit into more modern thinking.
+
Sheard and Mostashari (2011) show the ways different views of complexity map onto {{Term|Product System (glossary)|product system}}, {{Term|Service System (glossary)|service system}} and {{Term|Enterprise System (glossary)|enterprise system}} contexts, as well as to associated development and sustainment systems and project {{Term|Organization (glossary)|organizations}}.  Ordered systems occur as system {{Term|Component (glossary)|components}} and are the subject of traditional {{Term|Engineering (glossary)|engineering}}. It is important to understand the behaviors of such systems when using them in a complex system. One might also need to consider both truly random or chaotic natural or social systems as part of the context of an engineered system.  The main focus for systems approaches is '''organized complexity '''(see below). This kind of complexity cannot be dealt with by traditional analysis techniques, nor can it be totally removed by the way we design or use solutions. A systems approach must be able to recognize and deal with such complexity across the life of the systems with which it interacts.
  
Peter Checkland (Checkland 1999, 111) divides systems into five classes: {{Term|Natural System (glossary)|natural systems}}, designed physical systems, designed abstract systems, human activity systems and transcendental systems. The first two classes are self-explanatory.  
+
Sillitto (2014) considers the link between the types of system complexity and system {{Term|Architecture (glossary)|architecture}}. The ability to understand, manage and respond to both objective and subjective complexity in the problem situation, the systems we develop or the systems we use to develop and sustain them is a key component of the [[Systems Approach Applied to Engineered Systems]] and hence to the practice of systems engineering.
  
*'''Designed abstract systems''' – These systems do not contain any physical artifacts but are designed by humans to serve some explanatory {{Term|Purpose (glossary)|purpose}}.
+
==Origins and Characteristics of Complexity==
*'''Human activity systems''' – These systems are observable in the world of innumerable sets of human activities that are more or less consciously ordered in wholes as a result of some underlying purpose or {{Term|Mission (glossary)|mission}}. At one extreme is a system consisting of a human wielding a hammer. At the other extreme lies international political systems.
 
*'''Transcendental systems''' – These are systems that go beyond the aforementioned four systems classes, and are considered to be systems beyond knowledge.
 
  
Checkland refers to these five systems as comprising a “systems map of the universe”. Other, similar categorizations of system types can be found in (Aslaksen 1996), (Blanchard 2005) and (Giachetti 2009).
+
This section describes some of the prevailing ideas on complexity. Various authors have used different language to express these ideas. While a number of common threads can be seen, some of the ideas take different {{Term|Viewpoint (glossary)|viewpoints}} and may be contradictory in nature.
  
Magee and de Weck (Magee and de Weck 2004) provide a comprehensive overview of sources on system classification such as (Maier and Rechtin 2009), (Paul 1998) and (Wasson 2006). They cover some methods for classifying natural systems, but their primary emphasis and value to the practice of {{Term|Systems Engineer (glossary)|systems engineer}} is in their classification method for human-designed, or man-made, systems. They examine many possible methods that include: degree of {{Term|Complexity (glossary)|complexity}}, branch of the economy that produced the system, realm of existence (physical or in thought), {{Term|Boundary (glossary)|boundary}}, origin, time dependence, system {{Term|State (glossary)|states}}, human involvement / system control, human wants, ownership and functional typeThey conclude by proposing a functional classification method that sorts systems by their {{Term|Process (glossary)|process}} (transform, transport, store, exchange, or {{Term|Control (glossary)|control}}), and by the entity on which they operate (matter, energy, information and value).
+
One of the most widely used definitions of complexity is the degree of difficulty in predicting the properties of a system if the properties of the system's parts are given (generally attributed to Weaver).  This, in turn, is related to the number of {{Term|Element (glossary)|elements}} and connections between them. Weaver (Weaver 1948) relates complexity to types of elements and how they interact. He describes simplicity as {{Term|Problem (glossary)|problems}} with a finite number of variables and interaction, and identifies two kinds of complexity:
 +
#'''Disorganized Complexity''' is found in a system with many loosely coupled, disorganized and equal elements, which possesses certain average properties such as temperature or pressureSuch a system can be described by “19th Century” statistical analysis techniques.
 +
#'''Organized Complexity''' can be found in a system with many strongly coupled, organized and different elements which possess certain {{Term|Emergence (glossary)|emergent}} properties and phenomena such as those exhibited by economic, political or social systems.  Such a system cannot be described well by traditional analysis techniques.
  
==Types of Engineered System==
+
Weaver's ideas about this new kind of {{Term|Complex (glossary)|complex}} problem are some of the foundational ideas of {{Term|Systems Thinking (glossary)|systems thinking}}. (See also [[Systems Thinking]].)
  
The figure below is a general view of the context for any potential application of an {{Term|Engineered System (glossary)}} {{Term|Life Cycle (glossary)}}.
+
Later authors, such as Flood and Carson (1993) and Lawson (2010), expand organized complexity to systems which have been organized into a {{Term|Structure (glossary)|structure}} intended to be understood and thus amenable to {{Term|Engineering (glossary)|engineering}} and {{Term|Life Cycle Management (glossary)|life cycle management}} (Braha et al. 2006).  They also suggest that disorganized complexity could result from a heterogeneous {{Term|Complex (glossary)|complex}} system evolving without explicit architectural {{Term|Control (glossary)|control}} during its life (complexity creep).  This is a different use of the terms “organized” and “disorganized” to that used by Weaver. Care should be taken in mixing these ideas
  
 +
Complexity should not be confused with "complicated".  Many authors make a distinction between ordered and disordered collections of elements.
  
[[File:Part2 ServiceSystemofInterest 201905.png|center|thumb|600px|'''Figure 1: General types of Engineered System of Interest (SoI) (SEBoK original)''']]
+
Ordered systems have fixed relationships between elements and are not adaptable. Page (2009) cites a watch as an example of something which can be considered an ordered system.  Such a system is complicated, with many elements working together.  Its {{Term|Component (glossary)|components}} are based on similar technologies, with clear mapping between form and function. If the operating {{Term|Environment (glossary)|environment}} changes beyond prescribed limits, or one key component is removed, the watch will cease to perform its {{Term|Function (glossary)|function}}.
  
 +
In common usage, {{Term|Chaos (glossary)|chaos}} is a state of disorder or unpredictability characterized by elements which are not interconnected and behave randomly with no adaptation or control. Chaos Theory (Kellert 1993) is applied to certain dynamic systems (e.g., the weather) which, although they have structure and relationships, exhibit unpredictable {{Term|Behavior (glossary)|behavior}}. These systems may include aspects of randomness but can be described using deterministic models from which their behavior can be described given a set of initial conditions. However, their structure is such that (un-measurably) small perturbations in inputs or environmental conditions may result in unpredictable changes in behavior.  Such systems are referred to as deterministically chaotic or, simply, chaotic systems. {{Term|Simulation (glossary)|Simulations}} of chaotic systems can be created and, with increases in computing power, reasonable predictions of behavior are possible at least some of the time.
  
Figure 1 shows four general cases of {{Term|System of Interest (SoI) (glossary)|system of interest (SoI)}} which might be the focus of a life cycle. 
+
On a spectrum of order to complete disorder, complexity is somewhere in the middle, with more flexibility and change than complete order and more stability than complete disorder (Sheard and Mostashari 2009).  
*A technology focused {{Term|Product System (glossary)}} SoI embedded within one or more integrated products,
 
*An integrated multi-technology product system SoI used directly to help provide a service,
 
*An enabling {{Term|Service System (glossary)}} SoI supporting multiple service systems
 
*A {{Term|Service System (glossary)}} SoI created and sustained to directly deliver {{Term|Capability (glossary)}}.
 
  
===Products and Product Systems===
+
Complex systems may evolve “to the edge of chaos,” resulting in systems which can appear deterministic but which exhibit counter intuitive behavior compared to that of more ordered systems. The statistics of chance events in a complex system are often characterized by a power-law distribution, the “signature of complexity” (Sheard 2005). The power-law distribution is found in a very wide variety of natural and man-made phenomena, and it means that the probability of a low probability—large impact event is much higher than a Gaussian distribution would suggest. Such a system may react in a non-linear way to exhibit abrupt phase changes. These phase changes can be either reversible or irreversible. This has a major impact on engineered systems in terms of the occurrence, impact and public acceptance of {{Term|Risk (glossary)|risk}} and failure.
The word {{Term|Product (glossary)}} is defined as "a thing produced by labor or effort; or anything produced" (Oxford English Dictionary). In a commercial sense a product is anything which is acquired, owned and sustained by an {{Term|Organization (glossary)}} and used by an enterprise (hardware, software, information, personnel, etc.).
 
  
A {{Term|Product System (glossary)|product system}} is an engineered system in which the focus of the life cycle is to develop and deliver products to an {{Term|Acquirer (glossary)}} for internal or external use to directly support the delivery of services needed by that acquirer.   
+
'''Objective''' complexity is an attribute of complex systems and is a measure of where a system sits on this spectrum. It is defined as the extent to which future {{Term|State (glossary)|states}} of the system cannot be predicted with certainty and precision, regardless of our knowledge of current state and history. Subjective complexity is a measure of how easy it is for an observer to understand a system or predict what it will do next. As such, it is a function of the perspective and comprehension of each individual. It is important to be prepared to mitigate subjective complexity with consistent, clear communication and strong {{Term|Stakeholder (glossary)|stakeholder}} engagement (Sillitto 2009).   
  
A product systems life cycle context will describe a technology focused SoI plus the related products, people and services with which the SoI is required to interact. Note, the people associated with a product system over its life (e,g, operators, maintainers, producers, etc.) sit outside of the product SoI, since they are not delivered as part of the product.  However, to develop a successful product, it is essential to fully understand its human interfaces and influences as part of its context. The product context will also define the service systems within which it will be deployed to help provide the necessary {{Term|Capability (glossary)|capability}} to the acquiring {{Term|Enterprise (glossary)|enterprise}}.
+
The literature has evolved to a fairly consistent definition of the characteristics of system elements and relationships for objective systems complexity. The following summary is given by Page (2009):
 +
#'''Independence''': Autonomous system elements which are able to make their own decisions, influenced by information from other elements and the adaptability algorithms the autonomous elements carry with themselves (Sheard and Mostashari 2009).
 +
#'''Interconnectedness''': System elements connect via a physical connection, shared data or simply a visual awareness of where the other elements are and what they are doing, as in the case of the flock of geese or the squadron of aircraft.  
 +
#'''Diversity''': System elements which are either technologically or functionally different in some way. For example, elements may be carrying different {{Term|Adaptability (glossary)|adaptability}} algorithms.
 +
#'''Adaptability''': Self-organizing system elements which can do what they want to do to support themselves or the entire system in response to their environment (Sheard and Mostashari 2009). Adaptability is often achieved by human elements but can be achieved with software. Pollock and Hodgson (2004) describe how this can be done in a variety of complex system types, including power grids and {{Term|Enterprise (glossary)|enterprise}} systems.  
  
In a product life cycle, this wider context defines the fixed and agreed relationships within which the SoI must operate, and the environmental influences within which the life cycle must be delivered. This  gives the product developer the freedom to make solution choices within that context and to ensure these choices fit into and do not disrupt the wider context.
+
Due to the variability of human behavior as part of a system and the perceptions of people outside the system, the inclusion of people in a system is often a factor in their complexity. People may be viewed as observing systems or as system elements which contribute to the other types of complexity (Axelrod and Cohen 1999). The rational or irrational behavior of individuals in particular situations is a vital factor in respect to complexity (Kline 1995).  Some of this complexity can be reduced through education, training and familiarity with a system. Some is irreducible and must be managed as part of a problem or solution. Checkland (1999) argues that a group of stakeholders will have its own world views which lead them to form different, but equally valid, understandings of a system context. These differences cannot be explained away or analyzed out, and must be understood and considered in the formulation of problems and the creation of potential solutions.
  
A product life cycle may need to recommend changes to enabling services such as recruitment and training of people, or other infrastructure upgrades. Appropriate mechanisms for the implementation of these changes must be part of the agreement between acquirer and supplier and be integrated into the product life cycle. A product life cycle may also suggest changes in the wider context which would enhance the product’s ownership or use, but those changes need to be negotiated and agreed with the relevant owners of the systems they relate to before they can be added to the life cycle outputs.
+
Warfield (2006) developed a powerful methodology for addressing complex issues, particularly in the socio-economic field, based on a relevant group of people developing an understanding of the issue in the form of a set of interacting problems - what he called the “problematique”. The complexity is then characterized via several {{Term|Measure (glossary)|measures}}, such as the number of significant problems, their interactions and the degree of consensus about the nature of the problems. What becomes clear is that how, why, where and by whom a system is used may all contribute to its perceived complexity.  
  
A more detailed discussion of the system theory associated with product systems can be found in [[History of Systems Science]] and an expansion of the application of systems engineering to service systems in the [[Product Systems Engineering]]  KA in Part 4.
+
Sheard and Mostashari (2011) sort the attributes of complexity into causes and effects. Attributes that cause complexity include being non-linear; emergent; chaotic; adaptive; tightly coupled; self-organized; decentralized; open; political (as opposed to scientific); and multi-scale; as well as having many pieces. The effects of those attributes which make a system be perceived as complex include being uncertain; difficult to understand; unpredictable; uncontrollable; unstable; unrepairable; unmaintainable and costly; having unclear cause and effect; and taking too long to build.
  
===Services and Service Systems===
+
==References==
A {{Term|Service (glossary)|service}} can be simply defined as an act of help or assistance, or as any outcome required by one or more users which can be defined in terms of outcomes and {{Term|Quality (glossary)|quality}} of service without detail to how it is provided (e.g., transport, communications, protection, data processing, etc.). Services are processes, performances, or experiences that one person or organization does for the benefit of another, such as custom tailoring a suit; cooking a dinner to order; driving a limousine; mounting a legal defense; setting a broken bone; teaching a class; or running a business’s {{Term|Information Technology (glossary)|information technology}} infrastructure and applications. In all cases, service involves deployment of knowledge and skills ({{Term|Competency (glossary)|competencies}}) that one person or organization has for the benefit of another (Lusch and Vargo 2006), often done as a single, customized job. To be successful, service requires substantial input from the client and related stakeholder, often referred to as the co-creation of value (Sampson 2001). For example, how can a steak be customized unless the customer tells the waiter how the customer wants the steak prepared?
+
 +
===Works Cited===
  
A {{Term|Service System (glossary)|service system (glossary)}} is an engineered system created and sustained by an {{Term|Organization (glossary)}} that provides outcomes for clients within an enterprise. A service system context contains the same kinds of system elements as a product system context but allows greater freedom for what can be created or changed to deliver the required service.
+
Axelrod, R. and M. Cohen. 1999. ''Harnessing Complexity: Organizational Implications of a Scientific Frontier''. New York, NY, USA: Simon and Schuster.
  
A service system life cycle may deliver changes to how existing products and other services are deployed and used. It may also identify the need to modify existing products or create new products, in which case it may initiate a related product life cycle. In most cases the service developer will not have full freedom to change all aspects of the service system context without some negotiation with related system element owners. In particular, people and infrastructure are part of the service context and changes to how system elements are used to provide desired outcomes are part of the service life cycle scope.
+
Braha, D., A. Minai, and Y. Bar-Yam (eds.). 2006. ''Complex Engineered Systems: Science Meets Technology''. New York, NY, USA: Springer.
  
The description of product system context above might be viewed as a special case of a service system context in which a specific product is created and integrated into a fixed service system by an organization and used by an enterprise directly related to the organization to provide a capability.   
+
Checkland, P. 1999''Systems Thinking, Systems Practice''. New York, NY, USA: John Wiley & Sons.
  
In a general service system context, it is not necessary to deliver all hardware or software products to the service provider. In some cases, some of the hardware, software or human elements may be owned by a third party who is not responsible for the service directly but provides enabling outputs to a number of such services. In other cases, the whole service may be provided by an organization that is completely separate to the enterprise which needs the service. Nor is it necessary for the exact versions of products or enabling services to be defined and integrated prior to service delivery. Some service system elements can be selected and integrated closer to the point of use. To allow for this late configuration of a service system, it will contain some method of discovery by which appropriate available elements can be found, and an overall service management element to implement and direct each instance of the service system. The use of a service system approach gives greater freedom for acquirers in how they obtain and support all of the capital equipment, software, people, etc. in order to obtain the capabilities needed to satisfy users.
+
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.
  
Services have been part of the language of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) for many years, either as a way to describe the context of a product-focused life cycle or to describe commercial arrangements for the 'outsourcing' of product ownership and operation to others.  The use of the term {{Term|Service System (glossary)|service system}} in more recent times is often associated with software configurable and information intensive systems, i.e.,
+
Lawson, H. W. 2010. ''A Journey Through the Systems Landscape''. Kings College, UK: College Publications.  
<blockquote>''...unique features that characterize services – namely, services, especially emerging services, are information-driven, customer-centric, e-oriented, and productivity-focused.'' (Tien and Berg 2003, 13)</blockquote>
 
  
A more detailed discussion of the system theory associated with service systems can be found in [[History of Systems Science]] and an expansion of the application of systems engineering to service systems in the [[Service Systems Engineering]] KA in Part 4.
+
Kellert, S. 1993. ''In the Wake of Chaos: Unpredictable Order in Dynamical Systems'', Chicago, IL, USA: University of Chicago Press.
  
==Enterprises and Enterprise Systems==
+
Kline, S. 1995. ''Foundations of Multidisciplinary Thinking''. Stanford, CA, USA: Stanford University Press.
An {{Term|Enterprise (glossary)|enterprise}} is one or more organizations or individuals sharing a definite mission, goals, and objectives to offer an output such as a product or service.
 
  
An {{Term|Enterprise System (glossary)|enterprise system}} consists of a purposeful combination ({{Term|Network (glossary)|network}}) of interdependent resources (e.g., people; processes; organizations; supporting technologies; and funding) that interact with each other (e.g., to coordinate functions; share information; allocate funding; create workflows; and make decisions) and their environment(s), to achieve business and operational goals through a complex web of interactions distributed across geography and time (Rebovich and White 2011).  
+
Page, Scott E. 2009. ''Understanding Complexity''. Chantilly, VA, USA: The Teaching Company.
  
Both product and service systems require an enterprise system to create them and an enterprise to use the product system to deliver services, either internally to the enterprise or externally to a broader community.
+
Pollock, J.T. and R. Hodgson. 2004. ''Adaptive Information''. Hoboken, NJ, USA: John Wiley & Sons.
  
Enterprise systems are unique, compared to product and service systems, in that they are constantly evolving; they rarely have detailed configuration controlled requirements; they typically have the goal of providing shareholder value and customer satisfaction, which are constantly changing and are difficult to verify; and they exist in a context (or environment) that is ill-defined and constantly changing.
+
Senge, P.M. 1990. ''The Fifth Discipline: The Art & Practice of The Learning Organization''. New York, NY, USA: Doubleday/Currency.
  
While an enterprise system cannot be described using the general system context above, an enterprise may wish to create a model of the capabilities and services it needs to achieve its strategy and goals. Such a model can be extended to describe a baseline of service system and product system contexts related to its current capabilities, and to proposed future capabilities. These are referred to as {{Term|Enterprise Architecture (glossary)|enterprise architectures}} or enterprise reference architectures.
+
Sheard, S.A. 2005. "Practical applications of complexity theory for systems engineers". ''Proceedings of the Fifteenth Annual International Council on Systems Engineering,'' vol. 15, no. 1.
  
A more detailed discussion of the system theory associated with service systems can be found in [[History of Systems Science]] and an expansion of the application of systems engineering to service systems in the [[Enterprise Systems Engineering]] KA in Part 4. The notion of enterprises and enterprise systems also permeates Part 5 [[Enabling Systems Engineering]].
+
Sheard, S.A. and A. Mostashari. 2009. "Principles of complex systems for systems engineering." ''Systems Engineering'', vol. 12, no. 4, pp. 295-311.
  
==Systems of Systems==
+
Sheard, SA. and A. Mostashari. 2011. "Complexity types:  From science to systems engineering."  Proceedings of the 21st Annual of the International Council on Systems Engineering (INCOSE) International Symposium, Denver, Colorado, USA, 20-23 June 2011.
  
A product, service or enterprise context can be defined as a  {{Term|Hierarchy (glossary)|hierarchy}} of system elements, with the additional definition of which elements are part of a SoI solution, which form the related problem context and which influence any life cycle associated with that context.  
+
Sillitto, H. 2014. "Architecting Systems - Concepts, Principles and Practice", London, UK: College Publications.
  
The additional concepts of {{Term|System of Systems (SoS) (glossary)|Systems of Systems (SoS)}} or {{Term|Federation of Systems (FoS) (glossary)|Federations of Systems (FoS)}} is used for some contextsIn terms of the general description in Figure 1 above, this would apply to any life cycle context in which elements within the SoI have independent life cycle relationships. This concept could apply to any of the life cycle contexts above, although it is of particular relevance to the service and enterprise contexts. 
+
Warfield, J.N. 2006. ''An Introduction to Systems Science''London, UK: World Scientific Publishing.
  
It is important to understand that the term SoS is an addition to the general concept of system hierarchy that applies to all systems.  Maier examined the meaning of System of Systems in detail and used a characterization approach which emphasizes the independent nature of the system elements (Maier 1998, 268).   Maier describes both independence in how a system element operates (e.g. an element in the SoI also has its own separate mission or is part of another SoI) and in how an element is developed or sustained (e.g. an element is made available, modified or configured by a different organization to the one responsible for the rest of the SoI).
+
Weaver, W. 1948. "Science and complexity." ''American Science,'' vol. 36, pp. 536-544.
  
There are advantages to being able to have elements shared across a number of engineered systems and to being able to quickly create solutions to problems by combining existing engineered systems. As the technology to enable integration of independent systems becomes more common, this SoS approach becomes a common aspect of many SE life cycles.
+
===Primary References===
 +
Flood, R. L., & 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.
  
Wherever system elements in an engineered system context have any degree of independence from the SoI life cycle, this adds a further {{Term|Complexity (glossary)|complexity}}; specifically, by constraining how the resulting engineered system can be changed or controlled.  This dimension of complexity affects the management and control aspects of the {{Term|Systems Approach (glossary)|systems approach}}.
+
Page, Scott E. 2009. ''[[Understanding Complexity]]''. Chantilly, VA, USA: The Teaching Company.
  
A more detailed discussion of the different system grouping taxonomies developed by systems science can be found in Part 4 [[Applications of Systems Engineering]] and an expansion of the ways we deal with SoS complexity can be found in the [[Systems of Systems]] KA in Part 4.
+
Sheard, S.A. and A. Mostashari. 2009. "[[Principles of Complex Systems for Systems Engineering|Principles of complex systems for systems engineering]]". ''Systems Engineering'', vol. 12, no. 4, pp. 295-311.
  
==Applying Engineered System Contexts==
+
===Additional References===
 
 
From the discussions of product and service contexts above, it should be clear that they require similar systems understanding to be successful and that the difference between them is more about the scope of life cycle choices and the authority to make changes than about what kinds of systems they are.
 
 
 
These contexts are presented here as generalizations of the system engineering approach. All real projects may have both product and service system dimensions to them. In this general view of engineered systems, there is always an enterprise system directly interested in the service system context and either directly owning and operating any product systems and enabling services or gaining access to them as needed.  This enterprise system may be explicitly involved in initiating and managing an engineering system life cycle or may be implicit in the shared ownership of a problem situation.  Any engineered system context may have aspects of the SoS independence discussed above.  This may be part of the context in the wider system or environment or it may be related to the choice of elements within the SoI.
 
 
 
A real SE life cycle typically combines different aspects of these general contexts into a unique problem and solution context and associated acquirer and supplier commercial relationships.  These must be identified by that life cycle as part of its SE activities. More details of these different life cycle contexts are given in part 2 and their applications to SE practice are expanded upon in Part 4.
 
 
 
A good example of a general description of the above is given by Ring (1998), who defines the overall context as the Problem Suppression System, describes a cycle by which an enterprise will explore its current needs, uses these to identify one or more life cycle interventions and relevant organizations, then conduct and deliver those life cycles and integrate their outputs into the PSS; the enterprise can then review the results in the environment and begin the cycle again.
 
 
 
This general [[Systems Approach Applied to Engineered Systems|systems approach]] is described in part 2 and used as a focus to identify areas of foundational knowledge. The current practices of SE described in the rest of the SEBoK reference these foundations as appropriate.
 
 
 
==References==
 
 
 
===Works Cited===
 
 
 
Aslaksen, E.W. 1996. ''The Changing Nature of Engineering''. New York, NY, USA: McGraw-Hill.
 
 
 
Bertalanffy, L. von. 1968. ''General System Theory''. New York, NY, USA: Brazillier.
 
 
 
Blanchard, B.S., and W.J. Fabrycky. 2005. ''Systems Engineering and Analysis,'' 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
 
 
 
Boulding, K. 1956. “General systems theory: The skeleton of science” ''Management Science,'' vol. 2, no. 3, Aprilpp.197-208, 1956; reprinted in ''General Systems, Yearbook of the Society for General Systems Research,'' vol. 1, 1956.
 
 
 
Checkland, P.B. 1999. ''Systems Thinking, Systems Practice''. Chichester, UK: John Wiley & Sons Ltd.
 
 
 
Dictionary.com, s.v. "Taxonomy." Accessed 3 December 2014.  Available at: http://dictionary.reference.com/browse/taxonomy.
 
 
 
Encyclopedia Britannica, s.v. "Service Industry." Accessed 3 December 2014.  Available at:http://www.britannica.com/EBchecked/topic/535980/service-industry.
 
 
 
DeRosa, J. K. 2005. “Enterprise systems engineering.” ''Air Force Association, Industry Day, '' Day 1, 4 August 2005, Danvers, MA, USA. 
 
 
 
Giachetti, R.E. 2009. ''Design of Enterprise Systems: Theory, Architectures, and Methods.'' Boca Raton, FL, USA: CRC Press.
 
 
 
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: Wiley.
 
 
 
Lusch, R.F. and S. L. Vargo (Eds). 2006. ''The Service-Dominant Logic of Marketing: Dialog, Debate, and Directions''. Armonk, NY, USA: ME Sharpe Inc.
 
 
 
Magee, C.L. and O.L. de Weck. 2004. "Complex System classification". Proceedings of the 14th Annual International Symposium of the International Council on Systems Engineering, Toulouse, France, 20-24 June, 2004.
 
 
 
Maier, M. W. 1998. "[[Architecting Principles for Systems-of-Systems|Architecting principles for systems-of-systems]]". ''Systems Engineering'', vol. 1, no. 4, pp. 267-84.
 
 
 
Maier, M., and E. Rechtin. 2009. ''The Art of Systems Architecting'', 3rd Ed. Boca Raton, FL, USA: CRC Press.
 
 
Miller J. G. 1986. "Can Systems Theory Generate Testable Hypothesis?: From Talcott Parsons to Living Systems Theory" ''Systems Research,'' vol. 3, pp. 73-84.
 
 
 
Paul, A.S. 1998. "Classifying systems." Proceedings of the 8th Annual International Council on Systems Engineering International Symposium, Vancouver, BC, Canada, 26-30 July, 1998.
 
 
 
Rebovich, G., and B.E. White (eds.). 2011. ''Enterprise Systems Engineering: Advances in the Theory and Practice''. Boca Raton, FL, USA: CRC Press.
 
 
 
Ring, J., 1998. "A value seeking approach to the engineering of systems." Proceedings of the IEEE Conference on Systems, Man, and Cybernetics. p. 2704-2708.
 
  
Sampson, S.E. 2001. ''Understanding Service Businesses''. New York, NY, USA: John Wiley.  
+
Ashby, W.R. 1956. ''An Introduction to Cybernetics''. London, UK: Chapman and Hall.
  
Tien, J.M. and D. Berg. 2003. "A case for service systems engineering." ''Journal of Systems Science and Systems Engineering'', vol. 12, no. 1, pp. 13-38.
+
Aslaksen, E.W. 2004. "System thermodynamics: A model illustrating complexity emerging from simplicity". ''Systems Engineering'', vol. 7, no. 3. Hoboken, NJ, USA: Wiley.
  
Wasson, C.S. 2006. ''System Analysis, Design and Development.'' Hoboken, NJ, USA: John Wiley and Sons.
+
Aslaksen, E.W. 2009. ''Engineering Complex Systems: Foundations of Design in the Functional Domain''.  Boca Raton, FL, USA: CRC Press.
  
===Primary References===
+
Aslaksen, E.W. 2011. "Elements of a systems engineering ontology". Proceedings of SETE 2011, Canberra, Australia.
  
Checkland, P. B. 1999. ''[[Systems Thinking, Systems Practice]].'' Chichester, UK: John Wiley & Sons.
+
Eisner, H. 2005. ''Managing Complex Systems: Thinking Outside the Box''. Hoboken, NJ, USA: John Wiley & Sons.
  
Magee, C. L., O.L. de Weck. 2004. "[[Complex System Classification|Complex system classification]]."  Proceedings of the 14th Annual International Council on Systems Engineering International Symposium, Toulouse, France, 20-24  June 2004.
+
Jackson, S., D. Hitchins, and H. Eisner. 2010. “What is the Systems Approach?” INCOSE ''Insight,'' vol. 13, no. 1, April, pp.  41-43, 2010.
  
Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]]''. Boca Raton, FL, USA: CRC Press.  
+
MITRE. 2011. "Systems engineering strategies for uncertainty and complexity.''Systems Engineering Guide.'' Accessed 9 March 2011. Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/sys_engineering_strategies_uncertainty_complexity.html.
  
Tien, J.M. and D. Berg. 2003. "[[A Case for Service Systems Engineering|A case for service systems engineering]]". ''Journal of Systems Science and Systems Engineering,'' vol. 12, no. 1, pp. 13-38.
+
Ryan, A. 2007. "Emergence is coupled to scope, not Level, complexity". A condensed version appeared in INCOSE ''Insight'', vol. 11, no. 1, January, pp. 23-24, 2008.
  
===Additional References===
+
Sillitto H.G. 2009. "On systems architects and systems architecting: Some thoughts on explaining the art and science of system architecting."  Proceedings of the 19th Annual International Council on Systems Engineering (INCOSE) International Symposium, Singapore, 20-23 July 2009.
None.
 
  
 
----
 
----
<center>[[Introduction to System Fundamentals|< Previous Article]] | [[Systems Fundamentals|Parent Article]] | [[Complexity|Next Article >]]</center>
+
<center>[[Types of Systems|< Previous Article]] | [[Systems Fundamentals|Parent Article]] | [[Emergence|Next Article >]]</center>
  
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
+
<center>'''SEBoK v. 2.0, released 2 June 2019'''</center>
  
[[Category:Part 2]]
+
[[Category:Part 2]][[Category:Topic]]
[[Category:Topic]]
+
[[Category:Systems Science]]
[[Category:Systems Fundamentals]]
 

Revision as of 19:59, 28 February 2020


Lead Author: Rick Adcock, Contributing Authors: Hillary Sillitto, Sarah Sheard


This article is part of the Systems Fundamentals knowledge area (KA). It gives the background of and an indication of current thinking on complexitycomplexity and how it influences systems engineeringsystems engineering (SE) practice.

Complexity is one of the most important and difficult to define systemsystem conceptsconcepts. Is a system's complexity in the eye of the beholder, or is there inherent complexity in how systems are organized? Is there a single definitive definition of complexity and, if so, how can it be assessed and measuredmeasured? This topic will discuss how these ideas relate to the general definitions of a system given in What is a System?, and in particular to the different engineered systemengineered system contextscontexts. This article is closely related to the emergence topic that follows it.

Defining System Complexity

Complexity has been considered by a number of authors from various perspectives; some of the discussions of complexity relevant to systems are described in the final section of this article. Sheard and Mostashari (Sheard and Mostashari 2011) synthesize many of these ideas to categorize complexity as follows:

  1. Structural Complexity looks at the system elements and relationships. In particular, structural complexity looks at how many different ways system elements can be combined. Thus, it is related to the potential for the system to adapt to external needs.
  2. Dynamic Complexity considers the complexity which can be observed when systems are used to perform particular tasks in an environment. There is a time element to dynamic complexity. The ways in which systems interact in the short term is directly related to system behavior; the longer-term effects of using systems in an environment is related to system evolution.
  3. Socio-Political Complexity considers the effect of individuals or groups of people on complexity. People-related complexity has two aspects. One is related to the perception of a situation as complex or not complex, due to multiple stakeholder viewpointsviewpoints within a system context and social or cultural biases which add to the wider influences on a system context. The other involves either the “irrational” behavior of an individual or the swarm behavior of many people behaving individually in ways that make sense; however, the emergentemergent behavior is unpredicted and perhaps counterproductive. This latter type is based on the interactions of the people according to their various interrelationships and is often graphed using systems dynamics formalisms.

Thus, complexity is a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it. It occurs when there is no simple relationship between what an individual element does and what the system as a whole will do, and when the system includes some element of adaptation or problem solving to achieve its goals in different situations. It can be affected by objective attributes of a system such as by the number, types of and diversity of system elements and relationships, or by the subjective perceptions of system observers due to their experience, knowledge, training, or other sociopolitical considerations.

This view of complex systems provides insight into the kind of system for which systems thinking and a systems approachsystems approach is essential.

Complexity and Engineered Systems

The different perspectives on complexity are not independent when considered across a systems contextsystems context. The structural complexity of a system-of-interestsystem-of-interest (SoI) may be related to dynamic complexity when the SoI also functions as part of a wider system in different problem scenarios. People are involved in most system contexts, as part of the problem situation, as system elements and part of the operating environment. The human activity systems which we create to identify, design, build and support an engineered systemengineered system and the wider social and business systems in which they sit are also likely to be complex and affect the complexity of the systems they produce and use.

Sheard and Mostashari (2011) show the ways different views of complexity map onto product systemproduct system, service systemservice system and enterprise systementerprise system contexts, as well as to associated development and sustainment systems and project organizationsorganizations. Ordered systems occur as system componentscomponents and are the subject of traditional engineeringengineering. It is important to understand the behaviors of such systems when using them in a complex system. One might also need to consider both truly random or chaotic natural or social systems as part of the context of an engineered system. The main focus for systems approaches is organized complexity (see below). This kind of complexity cannot be dealt with by traditional analysis techniques, nor can it be totally removed by the way we design or use solutions. A systems approach must be able to recognize and deal with such complexity across the life of the systems with which it interacts.

Sillitto (2014) considers the link between the types of system complexity and system architecturearchitecture. The ability to understand, manage and respond to both objective and subjective complexity in the problem situation, the systems we develop or the systems we use to develop and sustain them is a key component of the Systems Approach Applied to Engineered Systems and hence to the practice of systems engineering.

Origins and Characteristics of Complexity

This section describes some of the prevailing ideas on complexity. Various authors have used different language to express these ideas. While a number of common threads can be seen, some of the ideas take different viewpointsviewpoints and may be contradictory in nature.

One of the most widely used definitions of complexity is the degree of difficulty in predicting the properties of a system if the properties of the system's parts are given (generally attributed to Weaver). This, in turn, is related to the number of elementselements and connections between them. Weaver (Weaver 1948) relates complexity to types of elements and how they interact. He describes simplicity as problemsproblems with a finite number of variables and interaction, and identifies two kinds of complexity:

  1. Disorganized Complexity is found in a system with many loosely coupled, disorganized and equal elements, which possesses certain average properties such as temperature or pressure. Such a system can be described by “19th Century” statistical analysis techniques.
  2. Organized Complexity can be found in a system with many strongly coupled, organized and different elements which possess certain emergentemergent properties and phenomena such as those exhibited by economic, political or social systems. Such a system cannot be described well by traditional analysis techniques.

Weaver's ideas about this new kind of complexcomplex problem are some of the foundational ideas of systems thinkingsystems thinking. (See also Systems Thinking.)

Later authors, such as Flood and Carson (1993) and Lawson (2010), expand organized complexity to systems which have been organized into a structurestructure intended to be understood and thus amenable to engineeringengineering and life cycle managementlife cycle management (Braha et al. 2006). They also suggest that disorganized complexity could result from a heterogeneous complexcomplex system evolving without explicit architectural controlcontrol during its life (complexity creep). This is a different use of the terms “organized” and “disorganized” to that used by Weaver. Care should be taken in mixing these ideas

Complexity should not be confused with "complicated". Many authors make a distinction between ordered and disordered collections of elements.

Ordered systems have fixed relationships between elements and are not adaptable. Page (2009) cites a watch as an example of something which can be considered an ordered system. Such a system is complicated, with many elements working together. Its componentscomponents are based on similar technologies, with clear mapping between form and function. If the operating environmentenvironment changes beyond prescribed limits, or one key component is removed, the watch will cease to perform its functionfunction.

In common usage, chaoschaos is a state of disorder or unpredictability characterized by elements which are not interconnected and behave randomly with no adaptation or control. Chaos Theory (Kellert 1993) is applied to certain dynamic systems (e.g., the weather) which, although they have structure and relationships, exhibit unpredictable behaviorbehavior. These systems may include aspects of randomness but can be described using deterministic models from which their behavior can be described given a set of initial conditions. However, their structure is such that (un-measurably) small perturbations in inputs or environmental conditions may result in unpredictable changes in behavior. Such systems are referred to as deterministically chaotic or, simply, chaotic systems. SimulationsSimulations of chaotic systems can be created and, with increases in computing power, reasonable predictions of behavior are possible at least some of the time.

On a spectrum of order to complete disorder, complexity is somewhere in the middle, with more flexibility and change than complete order and more stability than complete disorder (Sheard and Mostashari 2009).

Complex systems may evolve “to the edge of chaos,” resulting in systems which can appear deterministic but which exhibit counter intuitive behavior compared to that of more ordered systems. The statistics of chance events in a complex system are often characterized by a power-law distribution, the “signature of complexity” (Sheard 2005). The power-law distribution is found in a very wide variety of natural and man-made phenomena, and it means that the probability of a low probability—large impact event is much higher than a Gaussian distribution would suggest. Such a system may react in a non-linear way to exhibit abrupt phase changes. These phase changes can be either reversible or irreversible. This has a major impact on engineered systems in terms of the occurrence, impact and public acceptance of riskrisk and failure.

Objective complexity is an attribute of complex systems and is a measure of where a system sits on this spectrum. It is defined as the extent to which future statesstates of the system cannot be predicted with certainty and precision, regardless of our knowledge of current state and history. Subjective complexity is a measure of how easy it is for an observer to understand a system or predict what it will do next. As such, it is a function of the perspective and comprehension of each individual. It is important to be prepared to mitigate subjective complexity with consistent, clear communication and strong stakeholderstakeholder engagement (Sillitto 2009).

The literature has evolved to a fairly consistent definition of the characteristics of system elements and relationships for objective systems complexity. The following summary is given by Page (2009):

  1. Independence: Autonomous system elements which are able to make their own decisions, influenced by information from other elements and the adaptability algorithms the autonomous elements carry with themselves (Sheard and Mostashari 2009).
  2. Interconnectedness: System elements connect via a physical connection, shared data or simply a visual awareness of where the other elements are and what they are doing, as in the case of the flock of geese or the squadron of aircraft.
  3. Diversity: System elements which are either technologically or functionally different in some way. For example, elements may be carrying different adaptabilityadaptability algorithms.
  4. Adaptability: Self-organizing system elements which can do what they want to do to support themselves or the entire system in response to their environment (Sheard and Mostashari 2009). Adaptability is often achieved by human elements but can be achieved with software. Pollock and Hodgson (2004) describe how this can be done in a variety of complex system types, including power grids and enterpriseenterprise systems.

Due to the variability of human behavior as part of a system and the perceptions of people outside the system, the inclusion of people in a system is often a factor in their complexity. People may be viewed as observing systems or as system elements which contribute to the other types of complexity (Axelrod and Cohen 1999). The rational or irrational behavior of individuals in particular situations is a vital factor in respect to complexity (Kline 1995). Some of this complexity can be reduced through education, training and familiarity with a system. Some is irreducible and must be managed as part of a problem or solution. Checkland (1999) argues that a group of stakeholders will have its own world views which lead them to form different, but equally valid, understandings of a system context. These differences cannot be explained away or analyzed out, and must be understood and considered in the formulation of problems and the creation of potential solutions.

Warfield (2006) developed a powerful methodology for addressing complex issues, particularly in the socio-economic field, based on a relevant group of people developing an understanding of the issue in the form of a set of interacting problems - what he called the “problematique”. The complexity is then characterized via several measuresmeasures, such as the number of significant problems, their interactions and the degree of consensus about the nature of the problems. What becomes clear is that how, why, where and by whom a system is used may all contribute to its perceived complexity.

Sheard and Mostashari (2011) sort the attributes of complexity into causes and effects. Attributes that cause complexity include being non-linear; emergent; chaotic; adaptive; tightly coupled; self-organized; decentralized; open; political (as opposed to scientific); and multi-scale; as well as having many pieces. The effects of those attributes which make a system be perceived as complex include being uncertain; difficult to understand; unpredictable; uncontrollable; unstable; unrepairable; unmaintainable and costly; having unclear cause and effect; and taking too long to build.

References

Works Cited

Axelrod, R. and M. Cohen. 1999. Harnessing Complexity: Organizational Implications of a Scientific Frontier. New York, NY, USA: Simon and Schuster.

Braha, D., A. Minai, and Y. Bar-Yam (eds.). 2006. Complex Engineered Systems: Science Meets Technology. New York, NY, USA: Springer.

Checkland, 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.

Lawson, H. W. 2010. A Journey Through the Systems Landscape. Kings College, UK: College Publications.

Kellert, S. 1993. In the Wake of Chaos: Unpredictable Order in Dynamical Systems, Chicago, IL, USA: University of Chicago Press.

Kline, S. 1995. Foundations of Multidisciplinary Thinking. Stanford, CA, USA: Stanford University Press.

Page, Scott E. 2009. Understanding Complexity. Chantilly, VA, USA: The Teaching Company.

Pollock, J.T. and R. Hodgson. 2004. Adaptive Information. Hoboken, NJ, USA: John Wiley & Sons.

Senge, P.M. 1990. The Fifth Discipline: The Art & Practice of The Learning Organization. New York, NY, USA: Doubleday/Currency.

Sheard, S.A. 2005. "Practical applications of complexity theory for systems engineers". Proceedings of the Fifteenth Annual International Council on Systems Engineering, vol. 15, no. 1.

Sheard, S.A. and A. Mostashari. 2009. "Principles of complex systems for systems engineering." Systems Engineering, vol. 12, no. 4, pp. 295-311.

Sheard, SA. and A. Mostashari. 2011. "Complexity types: From science to systems engineering." Proceedings of the 21st Annual of the International Council on Systems Engineering (INCOSE) International Symposium, Denver, Colorado, USA, 20-23 June 2011.

Sillitto, H. 2014. "Architecting Systems - Concepts, Principles and Practice", London, UK: College Publications.

Warfield, J.N. 2006. An Introduction to Systems Science. London, UK: World Scientific Publishing.

Weaver, W. 1948. "Science and complexity." American Science, vol. 36, pp. 536-544.

Primary References

Flood, R. L., & 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.

Page, Scott E. 2009. Understanding Complexity. Chantilly, VA, USA: The Teaching Company.

Sheard, S.A. and A. Mostashari. 2009. "Principles of complex systems for systems engineering". Systems Engineering, vol. 12, no. 4, pp. 295-311.

Additional References

Ashby, W.R. 1956. An Introduction to Cybernetics. London, UK: Chapman and Hall.

Aslaksen, E.W. 2004. "System thermodynamics: A model illustrating complexity emerging from simplicity". Systems Engineering, vol. 7, no. 3. Hoboken, NJ, USA: Wiley.

Aslaksen, E.W. 2009. Engineering Complex Systems: Foundations of Design in the Functional Domain. Boca Raton, FL, USA: CRC Press.

Aslaksen, E.W. 2011. "Elements of a systems engineering ontology". Proceedings of SETE 2011, Canberra, Australia.

Eisner, H. 2005. Managing Complex Systems: Thinking Outside the Box. Hoboken, NJ, USA: John Wiley & Sons.

Jackson, S., D. Hitchins, and H. Eisner. 2010. “What is the Systems Approach?” INCOSE Insight, vol. 13, no. 1, April, pp. 41-43, 2010.

MITRE. 2011. "Systems engineering strategies for uncertainty and complexity." Systems Engineering Guide. Accessed 9 March 2011. Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/sys_engineering_strategies_uncertainty_complexity.html.

Ryan, A. 2007. "Emergence is coupled to scope, not Level, complexity". A condensed version appeared in INCOSE Insight, vol. 11, no. 1, January, pp. 23-24, 2008.

Sillitto H.G. 2009. "On systems architects and systems architecting: Some thoughts on explaining the art and science of system architecting." Proceedings of the 19th Annual International Council on Systems Engineering (INCOSE) International Symposium, Singapore, 20-23 July 2009.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 2 June 2019