Systems Methods, System Metaphors, Systems Abstractions...
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 behaviour...
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 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 behaviour 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:
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 :
Similarly, consider the nature of a conveyance: is it a means of transporting a family by road (abstract description, addressing the purpose of the conveyance) or is it a Toyota RAV 4 T180 2.2litre D4-D SUV (specific description of a particular model)? Clearly the abstract definition leaves plenty of room for maneuver as the total system concept and design develop - it may prove, for instance, that sets of in-line roller skates fit the bill best, once it is discovered that the family has to transport itself at speed through a very busy part of town in the rush hour... or maybe motorized scooters would be better, or a helicopter, or an underground railway? Certainly, prematurely deciding that the Toyota RAV 4 was the solution to some problem before fully understanding the problem would be ill advised - although, it has to be said that the Toyota RAV4 T180 is an excellent vehicle... in the right circumstances.
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...
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 2008