The Systems Approach

Systems Methods, System Metaphors, Systems Abstractions...

Systems Synthesis

Systems as Placeholders...

The Systems Approach

Derek Hitchins

SysApproach.mov

• The file SysApproach.mov identified by urn:sha1:K7YXUCUEOVYARDWAFAXCFBV7XHXTMSVB is licensed to the public under the Attribution 3.0 Unported license.

The Systems Approach

The Systems Approach was developed around the middle of the 20th Century, and proved an immediate, resounding success. Essentially, the approach considered a system-of-interest (SOI) to be open, dynamic, to exist in an environment, to interact with - and adapt to - other systems in that environment, and to form part of a larger, wider system. The systems could be of any kind, but are generally characterized as functional, i.e, the systems, subsystems, containing systems, etc., all perform functions and exhibit behavior

See the figure above, referred to as "the Poached Egg" diagram, for obvious reasons. It shows three levels of system hierarchy explicitly, and infers two more:

• the System-in-Focus (SiF) (or System-of-Interest (SOI)) is shown at the nominal level, interacting with three sibling systems - there could be many more.
• The SiF is shown as containing three interacting subsystems (i.e., one level down) - there could be many more of these, too, and each could, in its turn, contain many interacting sub-subsystems (i.e., two levels down) - not shown.
• Similarly the SiF is shown, with its siblings, as being part of some Containing System (i.e., one level up) which is, in its turn, shown as having interconnections with other Containing Systems...
• .. suggesting an even higher level of hierarchy - not shown.
• Essentially, then, the poached egg shows three levels of systems hierarchy in an infinite hierarchy of systems within systems within systems, and systems in systems in system... not unlike Babushka Russian dolls
• while at each level, the various entities have the properties of an open system (qv)(qv)
• and observers may position themselves anywhere on that vertical hierarchy according to purpose or interest...

The systems approach, then, considers a System-of-Interest in context, as an open, functioning system, part of some greater/wider/containing system, interacting with and adapting to other systems (siblings?) in the environment. An open system is one that exchanges energy, substance and information with its environment... You and I are open systems, so is a factory, so is an airliner, an automobile, etc... So, when designing a system, or when simulating the functioning or behavior of a system, the system-in-design is set into surrounding functional systems with which it interacts, and to which it may adapt, while at the same time, the system-in-design is actively operating/functioning, passing throughput from inflow to outflow... and, according to problem, the systems in question could be processes as systems, human activity systems, social systems, economic systems, ecological systems, political systems, theological systems... Just so long as they are open, interacting, functional systems

For another view of the systems approach, see the figure below, where the SOI could be any of the small circles, or - as labeled - the larger contained circle on the left, with its 'contained' subsystems...

Using the systems approach, it became the practice to understand the behavior of the part only in the context of the whole, interacting with, and adapting to, its environment. While the hard sciences, notably physics, viewed the systems approach with suspicion, it became de rigueur in almost every other sphere of scientific endeavor, including the social sciences, and the life sciences - it had its roots, of course, in biology where there is no rational alternative. Management and organization sciences, in particular, adopted the systems approach.

The Systems Approach became core to understanding system behavior and systems design in systems engineering. Using the approach, systems were seen as dynamic and in operation, acting upon, and being acted upon by, other systems. The Systems Approach resolved a significant difficulty in systems design:

• Consider a set of open, interacting subsystems (represented by small circles) comprising an open system (System of Interest in the figure), such that a designer wishes to synthesize particular emergent properties, capabilities and behaviors from this whole System of Interest (SOI).
  
• The designer (usually working with dynamic models of systems behavior) may affect the overall system (the 'whole') by changing any of the subsystems.

  • But as he/she (hereafter 'he') changes any one subsystem (small circle), that change impacts on other subsystem to which the first is connected: they will react to the change, and will be changed, too, such that any one change will result in a dynamic reverberation throughout the set, before settling to some unpredictable dynamic steady state (homeostasis).
    • (Stability may be an inappropriate term when considering open systems, which reach a dynamic steady state at high energy levels - as opposed to the more usual low energy stability associated with closed physical systems.)
• This pattern of behavior is typical of such open systems. Moreover, the set of subsystems forming the whole exists in an environment in which there are many other wholes, some interacting directly, others indirectly - see figure again

  • So, reverberation will result in changes to the whole (SOI) which, in turn, will affect other interacting systems - and they in turn, may react upon the whole, causing it to adapt.
• It is possible to analyze this complex behavior using mathematical techniques, including perturbation methods, and non-linear simultaneous difference equations. However, by far the simplest approach is to employ dynamic purposeful behavior simulation...

Systems Methods, Systems Metaphors, Systems Abstractions...

Besides holism and synthesis, there is one other tenet of systems thinking and systems engineering - the organismic analogy. The organismic analogy observes that open systems of all kinds, although they may not be organisms, yet they behave like organisms, with conception, birth, lifecycle and finally collapse, often catastrophic collapse, followed by decay and death. Examples of the organismic analogy include civilizations, enterprises and businesses, and the former Soviet Union, with its spectacular collapse in 1989/90.

So, for systems thinking, understanding systems behavior, and system design, it is more realistic to adopt an organic metaphor for complex systems, rather than a mechanistic metaphor such as that generally perceived by engineers for technological and engineering systems. Adopting the organic metaphor, then, is compatible with the systems approach in systems engineering for creating an optimum solution to a complex problem.

[To learn more about complexity, emergence, hierarchy, architecture, and more, see Emergence, Hierarchy, Complexity, Architecture: How do they all fit together? A guide for seekers after enlightenment…]

People, including some engineers - who mistakenly think that systems engineering "obviously" has to be about engineering - have difficulty relating to systems in the abstract. However, systems in the abstract are so very powerful that they form the driving power and thrust of systems thinking, systems design, systems engineering and many, many more.

What is a system in the abstract? Consider the problem of detecting intruders trying to get into a secure building. A specific system to detect them might be a burglar alarm. A system in the abstract would simply be - a system to detect intruders, deliberately without further definition: such a system has purpose and performs functions, but it has few specifics; no form, no structure, no size, no cost, no concept of operations...

However, if we continue to think about this system in the abstract, we might conceive that it could take the form of :

Using abstractions in this way leaves the door open for innovation, adaptation and flexibility.

By working with abstractions in the first instance, then, it is possible to avoid the trap - so often fallen into - of jumping at some 'obvious' solution, which later turns out to be either wrong, or at least far from the best... And, surprisingly perhaps, customers with problems are among those most likely to jump to premature conclusions; telling the systems engineers what they need (i.e., in effect designing the solution themselves) rather than explaining their problem. This is currently referred to as "describing the need." And, if you think about it, that expression does strongly suggest that the customer has already come up with (what he hopes is) the solution to his problem...

It is remarkable how far one can go in addressing problems, developing conceptual solutions, etc., by postulating systems in the abstract as performing functions, but without being specific as to form, fit, etc. For instance, a problem - any problem - can be seen as dysfunctional behavior/interaction between systems, where the systems can be of just about any kind... and identifying which systems are dysfunctional is the first step on the path to conceiving a remedial solution to the problem!

A large part of systems engineering is the process of progressively refining the description and definition of abstract functional systems until the abstract aspects are all eventually supplanted by specifics. Eventually, it may be practical to define all aspects of an initially-functional-only system, including form, size, mass, structure, architecture, relationships, interactions, internal processes, intelligence, etc., to the level that the system can be 'instantiated' using technology, or people working together, or most likely people and machines working together... cooperating, coordinating, performing functions, reacting, interacting, adapting, behaving...

Systems in the abstract, or functional systems, or just systems, can interact with each other, can adapt to such interactions, and so can exhibit behavior - response to stimulus. Functional systems are flexible and adaptable - in the beginning, they have no defined structure to inhibit their essential 'squidginess;' this can prove immensely powerful, and really enables the systems approach to address problems that would otherwise be quite intractable. Indeed, using functional subsystems to synthesize whole systems, using the systems approach outlined above, permits the effective design and realization of non-linear systems - something that is presently beyond the classically reductionist methods used by engineers in engineering design and engineering management...

Systems Synthesis

Systems - whole solutions to complex problems - may be synthesized by bringing together appropriate subsystems, and causing them to interact. Being open, these subsystems may adapt to each other as they interact, such that their overall behavior may prove complex and non-linear. According to classical systems theory, each subsystem, having the characteristics of a system, is capable of exhibiting emergent properties. Similarly, the whole system, when interacting with other open systems in some operational environment, will also exhibit emergent properties, i.e.,

"properties of the whole that are not exclusively attributable to any of their constituent parts,
and which may not be meaningful in the terms appropriate at the level of those interacting parts."

Levels of emergence, in this fashion, mark levels of hierarchy in systems organization. See the figure below:

In the figure, a system of interest is shown at left, comprising a number of 'organic' subsystems interacting to form a Containing System-of-Interest. The Containing System, the system-of-interest (SOI), is marked as being at Level 0. System hierarchy is a 'movable feast,' being set to suit the eye of the beholder: in this case, the SOI may be set at level 0 for convenience. Then, the organic subsystems interacting within it are at Level -1 - down one level of hierarchy. Each of these will contain parts - organs - but we need not concern ourselves with the internals of the subsystems, so long as we can describe the appropriate subsystem in terms of its properties, capabilities and behaviors as it interacts with the other subsystems. And since each subsystem 'sees' the sum of the other subsystems as its environment, it may also exhibit emergent properties to be seen within that environment...

Subsystems are called organic in the figure in recognition of:

• the organic metaphor used by systems engineers, as opposed to the more rigid mechanistic metaphor used by engineers.
• organicism: 'organic' also refers to organicism, a basic tenet of systems engineering, indicating that SE is more concerned with the organization of subsystems at the level of the whole system (SOI), rather than with the internals of subsystems,
  • which tend to be the province of engineers, trainers, psychologists, analysts, etc., according to subsystem type.

The figure above shows a more general view of a Systems of Interest, interacting with others systems in their common operational environment. Each of the interacting systems reveals its interacting organic subsystems. However, an observer in the operational environment would not see any subsystems: he/she would see only wholes, complete unified, unitary systems. This, then, is perhaps the most basic of emergent properties; that the many interacting parts be perceived, and may be seen to behave, only as a singular entity, when viewed as a whole

The diagram above may be perceived as a block diagram, referring to technology - although such perceptions are in the eye of the beholder. Again, we can see a System of Interest containing organic subsystems, together forming a unified whole, which is interacting with other, seemingly 'hard' boxes in their joint environment. As before, there are three levels of hierarchy here, and - although many engineers might be uncomfortable with the idea - emergence can be identified as shown, as the organic subsystems interact, and as the System of Interest also interacts...

The synthesis of whole systems, perhaps surprisingly, is directly concerned only with the three levels shown, and is not concerned with the organs or parts within organic subsystems. Instead, it is concerned principally with subsystems, their interactions and their organization, configuration, or architecture - all these terms are consistent with the concept of organicism. [Organicism is a philosophical orientation that asserts that reality is best understood as an organic whole. By definition it is close to holism. Organicism is also a doctrine that stresses the organization, rather than the composition, of systems.]

Why the disinterest in organs and parts within subsystems? Each subsystem is described and delineated by its properties, capabilities and behaviors; this renders knowledge of subsystem internals irrelevant in terms of synthesis which, rather than look inwards, is looking upwards and outwards. For an analogy, consider a human body, with its various organic subsystems: skin; bones, joints and skeletal muscles; alimentary canal; urinary system; cardiovascular system; nervous system; sensing organs; respiratory system; energy management system; reproductive system. (There are other way of identifying and describing anatomical subsystems.)

Each of these is a subsystem with parts: the cardiovascular (sub)system has many parts (a heart, arteries, veins, capillaries, muscles, nerves, etc., etc.,) but one purpose: to circulate blood throughout the body. The respiratory system also has many parts and has as its purposes the intake of oxygen and the excretion of carbon dioxide. In each case, when thinking about how the whole body functions, it is necessary to consider the various subsystems, their purposes, their interactions and synergies only; it is unnecessary to consider, say, the heart or the lungs in any detail, since their activities are 'incorporated' into, and expressed, in the purpose, performance and behavior of their containing subsystems.

Suppose, however, we were to shift our hierarchy perspective down one level, say, to place the cardiovascular system at Level 0, then we would become interested in its parts as subsystems - Level -1, and the contribution that the cardiovascular system makes to the whole body, Level+1. Then again, we could focus on the heart as Level 0, with its atria, ventricles, bicuspid, tricuspid and mitral valves, aorta, superior and inferior vena cava, pulmonary arteries and veins, etc., etc, at Level -1, and the cardiovascular system at Level +1.

So, we are able to move up and down the systems hierarchy, choosing to set our point of focus anywhere that suits us, and we may then refer to that point of focus as Level 0. And, to synthesize a whole, we need be interested in only three levels: Level -1, Level 0 and Level +1. This is a valuable perspective, allowing us to greatly reduce any perceived complexity which may be otherwise likely to overwhelm us.

Incidentally, it renders the term 'system of systems,' which has become increasingly popular, even amongst those who should, perhaps, know better, rather redundant. From the above prspective, every system is a 'system of systems,' just as every system comprises interacting subsystems. The term 'system of systems,' is thus a tautology; not so much wrong, as an error in style revealing that the user of the term is unfamiliar with 'systems.'

Systems as "Placeholders"

It is even possible to develop a complete systems engineering methodology, using a model of a system in place of the system. Such a "model of a system" may be called a Generic Reference Model (GRM). The GRM contains "pigeonholes" to represent the many and different aspects of any system - but generically, rather than specifically. So, for instance, it is possible to think about a system, any systems as having features of Being, Doing and Thinking. Each of these can be elaborated into many further aspects - follow the GRM link to see how it all works.

So, the process of systems engineering can use a GRM as a representation of a System of Interest, and may start with only the functional aspects being defined. Progressively through the development of concept, threat analysis, purposing, CONOPS, etc., leading on to design, the various generic aspects become replaced/instantiated with particular aspects, until the whole GRM has been replaced with data and information sufficient to constitute a complete design. Surprisingly, perhaps, it works... You might even go so far as to say that it works well.

derek hitchins

May 2009

http://www.hitchins.net