2007.01.09: My initial remarks on Russ Abbott's Introduction to the Symposium...
Is Russ correct? Are we ready to “formalize” our understanding of what it takes to correctly characterize systems as “complex,” and to apply that understanding to their engineering?
Certainly Russ has called to our attention specific characteristics of certain systems that seem to qualitatively distinguish them from other systems:
• they exhibit properties or behaviors that are emergent;
• they are social, that is, dependent on the operation of included but loosely coupled autonomous agents;
• they are inseparably intertwined with their environments and have boundaries that are always permeable and indistinct;
• they are employed and they are developed concurrently; in other words, the term deliverable is completely inappropriate in characterizing them.
He also notes, however, that we still need a well thought out governance structure for such systems. What is that governance structure? He doesn’t say. Despite that, he says that we are now ready to “build tools” that “anyone” can use to implement that governance.
Techniques precede technologies. And tools are the later embodiments of newly formulated technologies. I take Russ’s governance structure as technique. And first generation tools are seldom if ever mature enough for everyone to use. Has Russ set the bar too high?
I’m not sure that we have agreed techniques (never mind a new technology) for the tools Russ is seeking, useable by everyone or not.
So we might do well to set our sights less ambitiously. Let’s see if we can at least agree on what the needed techniques are; or perhaps even less than that: in which cases is a new set of techniques appropriate, whatever the new techniques might turn out to be? Now, have I set the bar too low?
I am not as sanguine as Russ is regarding the existence of a “broad consensus” regarding the nature of systems that are correctly characterized as complex and that would be the basis for such techniques. I will site just one reason here.
Russ asserts that complex systems are multi scalar systems. This is a part of the broad consensus that Russ sees. Russ also asserts that “multi scalar” is the same as “multiple levels of abstraction.” This is only superficially the case; and beneath the superficial similarity is a sinister trap.
All of our (human) conceptualizations are finite (because our brains are finite). We recognize emergence when we note that conceptualizations at one scale do not wholly include what might be available at another scale of conceptualization – and vice versa. Again, this is a consequence of the finiteness of human conceptualization. In order to comprehend more and more of the form and the structure and the behavior of the real world as patterns of conceptualization we eventually have to lose track of some of those patterns – in order to take in more of them. Abstraction does not exactly fit this situation.
Abstracting means leaving things out with the understanding that whatever has been left out can always be exactly reinserted. What must be “left out” of conceptualizations at one specific scale, relative to another distinct scale, are patterns that are only available in a conceptualization at the other scale of conceptualization. They have no place whatsoever in the conceptualization at the original scale. Although they may be “left out,” they cannot be reinserted. Ultimately, it is the finiteness of human conceptualization that precludes this. (The many examples of emergence available in the papers offered at this symposium serve to illustrate this phenomenon.)
Abstraction is part and parcel of our Aristotelian notions of the excluded middle, hierarchy, decomposition, first order logic, determinism, and so on. These notions do not work across multiple scales of human conceptualization.
Despite this, there is a real tendency to reduce the multi scalar nature of certain systems to a matter of abstraction – with the consequence that the tools that come with abstraction are also treated as always applicable. This is the trap. They aren’t, in general. Until this is widely accepted, systems that must truly be conceptualized at multiple scales in order to be more completely understood will be treated as a hierarchical pyramid of more and more abstracted levels of the same underlying conceptualization – one presumably in which everything that can be known is available for human consideration.
This is a philosophical objection at its core. Is human conceptualization bounded? And do those bounds influence in a non trivial manner the way that we comprehend the universe and act upon it? Until objection is properly understood and accommodated, we will continue to treat complex-systems (using notions like abstraction) as though they are simply very rich single scale conceptualizations. And any progress will continue to be progress at the very extreme edges of “traditional” system engineering.
There is also this matter of “techniques” (or governance structure). What should they be? I believe that such techniques must be anchored in an appreciation of evolution. The processes of evolution are presently understood by most engineers as not their processes. And so they pay them little heed. Until there is a much wider appreciation by engineers of how the processes of evolution shape development, it is very difficult to imagine how engineers will address the development of systems that are dominated by such processes.
Doug Norman is correct, in my opinion, in arguing that an understanding of how evolution bears on the engineering of complex-systems should be central to this symposium.
But this is only one facet of the roadblock facing engineers as they attempt to engineer complex-systems. Kreitman distinguishes between control of a first kind and control of a second kind. His distinction illuminates a deeply cultural facet of our challenge. (In particular, our developmental, acquisition, and legislative communities are not prepared to embrace his second kind of control.) In a note to Rich Byrne I suggest much the same as Kreitman did by calling attention to the need to separate the locus of control from the locus of accountability. Perhaps we can always preserve a center of accountability; but we must finally acknowledge that in more and more cases, there can no longer be any centrality of control.
One last point. Consensus is the wrong threshold to use as the trigger for further progress. We must accept that we need to begin experimentation with proposed new (and unproven) techniques. Techniques that succeed will call out for a deeper understanding. That will eventually lead to the formalisms Russ believes that we are now close to achieving – not before.
--George McC 08:40, 11 January 2007 (PST)
I concentrated first on those papers that I had been scheduled to discuss - I have only now got those that I had earmarked as "must read" to give them a quick skim through - your paper deserves more, I'll come back to it again - just a few brief comments for now.
- your view of the world is pretty similar to my own, while I don't yet know whether I would agree with everything, my skim of the paper hasn't thrown up anything that I would violently disagree with and reading your other comments on the wiki support that.
- before reading this (and Tyson Browning's) paper I had put a comment on my own notes pages that one thing that I hadn't found in the papers was any consideration of the different regimes - at least I think that's what you mean by the term. The number of these is open to debate - I've seen 4, 5, 6 and 7 mentioned recently - but there is no doubt that it is important to consider more than "the system being built" when looking at the application of systems engineering. I won't expand any further on that here, but it is a good subject for further debate.
- I commented on Sarah's paper that I don't necessarily see TSE and CSE as separate things - rather CSE embraces TSE where it is applicable - no reason to "throw the baby out with the bath water"! We are all to ready to embrace the "big new thing" and ignore all the good practice that we have ever done before - no wonder the "silver bullet" causes such carnage!!
- I have also mentioned elsewhere that I view systems as things that "come and go" and are defined for the purposes of the moment - I'm not sure where you would stand on that. I think that often people get too hung up about the system boundary. Yes, it needs to be defined for any given purpose, but it is (usually) an arbitrary boundary that could just as easily have been drawn in a different place. This has implications when you start to consider the way in which the different "regimes" (I would call these systems as well, but no matter) interact and trying to decide which regime particular tasks or resources might belong. Again - this is too much for here.
--George McC 10:57, 11 January 2007 (PST)
Just noticed that you had put an entry on my page almost simultaneously with mine here. I am happy to keep in contact beyond the symposium - not sure what can be done as far as the practical aspects of collaboration are concerned, but willing to try.
George, MiLK here (2007.01.12):
I observed the same race condition! Our collaboration has begun.
More MiLK stuff (2007.01.12)
As a consequence of the discussions yesterday, I am motivated to include here a very terse summary of my paper and why I am participating.
Summary of my paper:
My paper is an invitation to acknowledge two branches of general system engineering. Both branches have their place; both must continue to be used and refined. But they ought not to be confused.
All of general system engineering (GSE) is just one branch of engineering. All of engineering is about real problem solving. So GSE, and any branch of GSE, must remain true to this overarching predicate.
GSE is based on three propositional predicates. These are listed here in order of importance – but it must be remembered that to delete any of them is to change the subject. They are all essential to GSE.
• A system is the realized equivalence of any problem and a solution. So understanding what a system is is the sine qua non of GSE.
• Systems exhibit life cycles; they don’t just spontaneously appear and disappear. The activities that embody this discipline are organized around an understanding of a system’s life cycle.
• In all but the most trivial of cases, the realization of systems (of solutions to problems) involves a melding of multiplicities. This is most of what a system engineer does.
Traditional system engineering (TSE) is the first and older branch of GSE. It is predicated on a highly deterministic interpretation of the GSE’s three propositional predicates. In fact, its interpretation is not just deterministic, it is wholly Aristotelian.
Complex-system engineering (cSE) is the proposed second branch of GSE. It is predicated on a multi scale and evolutionary interpretation of GSE’s three propositional predicates. This paper’s discussion is centered on cSE’s interpretation of GSE’s propositional predicates.
Two preliminary comments are in order. Most engineers (both practicing and academic) don’t have a clue as to what the processes of evolution are. As a consequence they are ill suited today for participating in the application and development of cSE. This has to change.
Most everyone – the engineer included – does not appreciate that our individual human conceptualizations are inherently single scale and bounded, and how that influences the various ways that we attempt to solve problems. This becomes a non-trivial engineering concern when the problems and the solutions that are being addressed can only be humanly conceptualized at multiple scales. The notion of scales of conceptualization (as meant here) has been wrongly interpreted by those who insist on the universality of the Aristotelian perspective. This perspective is pandemic (and therefore usually unconscious) throughout our culture. This too has to change.