Symposium on Complex Systems Engineering/Schedule/Friday 3b comments
From CSWiki
M Kuras here:
Elliot Axelband’s PowerPoint presentation is interesting to me for a very important reason. He exposes a difference in the mindset that separates many of us at this symposium. What is it that we are talking about when we talk about system engineering? What is this symposium really about?
There are at least two different mindsets in play. (There could well be more!) Perhaps there is more than one symposium happening at once – sort of like multiple conversations at the same dinner table. We’ll see.
Elliot suggests that you don’t need system engineering (SE) if your product is a lead pencil. I have to disagree. (Still, it’s a great and provocative suggestion!)
I take Elliot’s point to mean (basically) that if you’ve solved a problem, then you don’t need to solve it again. That seems to make good sense. So where is my hang up? What is the snag?
Here is a hint. Are all lead pencils (and the problems that they solve) really the same? And is something like a lead pencil at the heart of every engineering problem?
I understand that SE for a “first” lead pencil is substantially different than SE for a 10th batch of lead pencils, the 100th batch, and so on. And there is also a difference between the first lead pencil and the first batch of lead pencils!
But that does not cover everything about SE, does it? SE is both the formulation of a solution to a problem and its realization (in the real world). SE for lead pencils will always be needed – because in the real world the specifics of each instance of more and more pencils are going to be different. Exactly the same never exactly happens in the real world.
Now, Elliot would correctly object that talking about “exactly” as I have just done is not really fair! He would say that “bounding” a problem and its solution is what is important. Stabilizing a problem and its solution doesn’t mean (for engineers at least) an absolutely exact “point solution.” It means bounding the “space” of such points. For Elliot, progress in engineering has meant expanding the variety of spaces in which such problems and solutions can be stabilized (bounded). I get that!
Moreover, Elliot is actually focused on “innovative” system engineering – engineering the “first of a kind,” solving a problem for the first time. System engineering the “first” pencil is qualitatively different from engineering the millionth pencil – or at least it should be. I agree with him. So what is my hang up?
At the heart of Elliot’s presentation is an implicit assumption about the universality of single scale analysis and the legitimacy of abstracting a problem until it can be stabilized. For Elliot, any (and every) engineering problem can be formulated and then exactly solved (within bounds) over and over again in exactly the same way when this is done correctly. The difficult part – the part that requires innovation and why we are here at the symposium – is getting it right for the first time.
What does this have to do with single scale analysis? A lot. But before I make the connection, it is worth looking more deeply at his assumption one more time.
First there is the fact that even if every solution to the same problem is (or should be) exactly the same (within bounds!), it doesn’t always work out that way! What goes wrong?
Second, there is a class of problems for which there is exactly (I really mean exactly) one problem and solution pair. Every problem (in this class) is unique, requiring a unique solution. But if that is so, how can such problems be “engineering” problems?
The first point is nothing more than noting that when a problem is initially stabilized (either exactly, or within bounds), the scale selection and abstractions that allowed the problem to be solved by the engineer no longer correspond to the problem as it is understood by others. We encounter this when we say that we have to “change the requirements.” Or the solution is used in a way that was not intended. And so on.
Although not associated with my own continuing interest in SE, this point is still important in understanding why we can’t discard the system engineer for a problem once it’s been solved (for the first time). We still need “lead pencil” engineers. The “same” problem may have to be solved again! (In Elliot’s vocabulary, the problem-solution will have been destabilized.)
The second point is very different, however.
The sort of problems that Russ Abbott characterized at the opening of the symposium do not fit Elliot’s template! These are problems that “constantly change” (I love this oxymoron! Oxymorons are the quintessential refutation of our Aristotelian perspective on the Universe.). And so their solutions must be constantly changing solutions. There is no longer any advantage in getting it right “the first time.” There is never a “next time.”
And yet, there is!
There are many problems that must be addressed at multiple scales of conceptualization (including the problem of continuing the innovation in system engineering). Problems and their solutions (which must be addressed at multiple scales of conceptualization) are not entirely amenable to the Aristotelian presumption. We will have to innovate to break that barrier. Russ has attempted to catalog the characteristics of complex-systems. (For me, a system is the realized equivalence of a problem and its solution.) Russ’s characteristics are those of “animate” (or animated) systems. These systems have a metabolism; they take in energy, accumulate order, and release entropy into their environments. They learn (or they evolve, which is the same thing considered at a different scale). And so on.
No two systems are the same when they have to be addressed at multiple scales of conceptualization – even if they are that at one of more of those scales of conceptualization. This is so if only because they learn – and we know that the results of learning cannot be pre-specified. Each of us as a human being is a very familiar example of such systems. There are many other such examples. Despite that, the development (and operation) of such systems is in accordance with a set of processes, the same set of processes even. These are the processes of evolution. But these are not deterministic processes. Their results are, as we now say, stochastic (which should not be confused with random). And even though they are not deterministic, they still do obey the laws of cause and effect. So even though we can’t stamp out identical systems as solutions to many instances of the same problem (there is no “same” problem when all of the necessary scales of conceptualization are considered), we still can shape (focus and accelerate) their growth and development in ways that are not random – by manipulating the processes that are driving their development. Each instance of the system will be unique. And even if we were to know the “Generating Function” of their distribution, we still could not compel any specific instance.
So I return again to seconding Doug Norman’s suggestion. We as system engineers need to get our heads around the processes of evolution so that we can continue to expand our competence to include systems that are no longer deterministic “deliverables” as Russ has quite correctly characterized them. If we don’t do that, then we will be left to engineering more and more sophisticated pencils (like the JTF), but nothing more than that. Is that all that we want?
