The User's Concerns

[Jack Ring]

I will appreciate any information or guidance you can provide regarding the following:

1. How can we know the relative contribution by any given component in a system given a situation and the intended effects on that situation?

2. In baseball the relative contribution of the pitcher is probably higher than the relative contribution of the right fielder. However, this may be true on defense but not on offense (as batters).

3. How can we anticipate a) the relative contribution to the Mission of a System of Systems by a constituent in that System of Systems AND b) the relative loss of contribution to the mission of that constituent system due to its being involved in the SoS?

4. Increasingly, brigade-scale SoS in-theater exhibit unexpected vulnerabilities and mind-numbing characteristics. How can these be foreseen?

5. Given a configuration composed by someone else, a) how can we “decomplexify” it by deleting interrelations and even constituents that do not have significant effect on mission contribution and b) how can we assess its likely dynamic and integrity limits?

[Steven Krane]

On Nov 28, 2016, at 3:49 PM, Jack Ring <jri...@gmail.com> wrote:

I will appreciate any information or guidance you can provide regarding the following:

1. How can we know the relative contribution by any given component in a system given a situation and the intended effects on that situation?

Instrumentation and analysis.  If the situation is hypothetical, by model extension.

2. In baseball the relative contribution of the pitcher is probably higher than the relative contribution of the right fielder. However, this may be true on defense but not on offense (as batters).

Runs per game above replacement level

3. How can we anticipate a) the relative contribution to the Mission of a System of Systems by a constituent in that System of Systems AND b) the relative loss of contribution to the mission of that constituent system due to its being involved in the SoS?

What is a system of systems?

4. Increasingly, brigade-scale SoS in-theater exhibit unexpected vulnerabilities and mind-numbing characteristics. How can these be foreseen?

Maybe they cannot.  What then?  Maybe we should avoid creating systems that will do irreversible things we cannot reasonably understand in advance.  Maybe that is the failure.

5. Given a configuration composed by someone else, a) how can we “decomplexify” it by deleting interrelations and even constituents that do not have significant effect on mission contribution and b) how can we assess its likely dynamic and integrity limits?

Pass :)

The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.  

Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/syssciwg.
For more options, visit https://groups.google.com/d/optout.

[Ferris, Tim]

There seems to be something culturally deep-seated going on here.

 

This discussion of ‘relative contribution’ seems to lose sight of the fact that we are talking of elements in a system.

 

If the team need a certain player’s role then that role is important, if the role is not important, why waste resources on having the player?

 

In systems a better approach is to ask the resilience question: what happens to my system if this or that subsystem, or group of subsystems, is out of action? Is the effect acceptable/tolerable in terms of my measures of success related to the system as a whole.

 

The ‘relative contribution’ discussion seems to come from a mindset that one must identify who contributes to the organisation. Organisations that pay bonuses on the basis of individual performance generate this mental approach to such judgements. (Managers and accountants seem to get bigger bonuses that technical occupation engineers. The accountant wrote up the accountant wrote up the accounts that showed profit – ergo the accountant made the profit and deserves a big bonus.) But if the organisation needs a janitor, the janitor, contributing that role, enabled others to do grand, outward facing things, and so contributed to the profit, and therefore the janitor should get just as much proportion of their salary in bonus as the CEO – the dollar amount is different!. East Asian companies are known to the job market as ‘one month’, ‘two month’, ‘three month’ companies, reflecting the bonus rate they historically pay all their staff. Woe betide a company that does not keep to its past record. The converse is looking for the person proximate to a disaster and blaming them for the disaster. Safety in engineering has discovered that that is by far an ineffective way to either find out why disasters happened or to develop means to pre-empt future disasters.

 

Tim Ferris

--

[Jack Ring]

On Nov 28, 2016, at 7:59 PM, Steven Krane <sk5...@gmail.com> wrote:

On Nov 28, 2016, at 3:49 PM, Jack Ring <jri...@gmail.com> wrote:

I will appreciate any information or guidance you can provide regarding the following:

1. How can we know the relative contribution by any given component in a system given a situation and the intended effects on that situation?

Instrumentation and analysis.  If the situation is hypothetical, by model extension.

ISM?

2. In baseball the relative contribution of the pitcher is probably higher than the relative contribution of the right fielder. However, this may be true on defense but not on offense (as batters).

Runs per game above replacement level

3. How can we anticipate a) the relative contribution to the Mission of a System of Systems by a constituent in that System of Systems AND b) the relative loss of contribution to the mission of that constituent system due to its being involved in the SoS?

What is a system of systems?

A system that you control which relies on interoperation with a one or more systems you do not control. 

4. Increasingly, brigade-scale SoS in-theater exhibit unexpected vulnerabilities and mind-numbing characteristics. How can these be foreseen? 

Maybe they cannot.  What then?  Maybe we should avoid creating systems that will do irreversible things we cannot reasonably understand in advance.  Maybe that is the failure.

Yes, so how can we detect the capability to do irreversible things.

5. Given a configuration composed by someone else, a) how can we “decomplexify” it by deleting interrelations and even constituents that do not have significant effect on mission contribution and b) how can we assess its likely dynamic and integrity limits?
Pass :)

Years ago one technique was called Value Engineering wherein people simplified an existing design. 

The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.  

Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/syssciwg.
For more options, visit https://groups.google.com/d/optout.

--

[Jack Ring]

Tim,

By ‘here’ did you mean ‘over there where you are’? ;-)

Yes, there may be a deep seated culture (the way things are done around here) among those who engage in systems engineering that encourages a focus on the elements in a system but not the emergence of the interplay of the elements, particularly the emergences that are not helpful to the users and ways of preventing such emergences. 

For instance many hardware practitioner strive for Zero Defects while most software and systems people think ‘bugs’ are inevitable.

It isn’t whether a player’s role is important it is about How Important on a scale that relates to mission effect-iveness. 

Then it is about how much any given instance of that role (staffing or choice of source data, etc.) will change the likelihood of mission effectiveness then whether the learning that may accrue offsets the likely reduction of How much.. 

This seeks ways of coping with complexity, particularly avoiding the two ingredients, Complexness of the system and Ignorance of the Observer.

Jack

[b...@lawson.se]

Interesting set of rules for SoS. Could well apply in the SoS of cities attempting to be smarter. We are addressing this in a new volume in the Systems Series entitled:

Creating, Analyzing and Sustaining Smarter Cities: A Systems Perspective.

What is the source information for the rules?

Best, Bud

--
Dr. Harold "Bud" Lawson - Prof. Emeritus, ACM, IEEE and INCOSE Fellow, IEEE Computer Pioneer, INCOSE Systems Engineering Pioneer.
Phone +46 8 7659740 Mobile +46 70 5658077, E-mail
b...@lawson.se
For book information see http://www.thesystemslandscape.com/
LinkedIn: https://www.linkedin.com/in/harold-lawson-66810b2

>----Ursprungligt meddelande----
>Från : hillary....@blueyonder.co.uk
>Datum : 2016-11-29 - 11:21 (CET)
>Till : jri...@gmail.com
>Kopia : Fellows...@incose.org, syss...@googlegroups.com
>Ämne : Re: [fellows discuss] The User's Concerns
>
>Jack
>
>While this method has limitations it has a benefit I had not appreciated. One of the issues in many SoS is how to set up rules to manage resource under situations of concurrency and overload. For example you may have: 1. routine management, surveillance and situation awareness; 2. managing and executing the current primary mission; 3. planning the next primary mission; 4. responding to unforeseen events and disruptions; 5. discerning patterns in the noise and detecting early signs of fundamental change in the situation. Typically military operations get disrupted and misdirected when the demands of item 4. consumes resources that are then no longer able to do the other tasks, particularly 5. The QFD matrix formalism allows rapid qualitative assessment of these issues, and would allow one to identify the questions to ask of a more mathematical approach.
>
>As an example from the British experience in Helmand, because we didn't have enough helicopters our guys spent all their time looking for IEDs that wouldn't have been there if they were not so effective at dragging all resources into 4.
>
>Interestingly the pattern I describe above is very close to, and could probably be mapped onto, Beer's Viable System Model (VSM), which does attend to the interactions between system elements.
>
>Best regards
>
>HillaryOn 29 Nov 2016 8:21 am, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:
>>
>> Jack,
>>
>> The core part of the QFD matrix, the 'voice of the customer' table, allows the analyst to illustrate the contribution of each SoS element to each capability need or scenario. This will show force elements whose contribution is small, negligible, or even negative in some situations (for example if a particular type of asset becomes a vulnerability in some situations), or which are only useful in a small subset of scenarios. It will also, with a bit of extra logic to record how well the SoS meets (or doesn't meet) each scenario, show scenarios for which there is no adequate solution.
>>
>> You can go further and put quantitative weights into the model, and crank handles and do sums, though such quantitative analyses can be misleading if the underlying assumptions are not well founded, or if key needs or scenarios have been omitted.
>>
>> This is not a perfect solution (for example it emphasises components at the expense of interactions) but gives a lot of insight for a relatively modest investment. It's a standard product development tool which maybe deserves more attention than it currently gets from our community.
>>
>> Best regards
>>
>> Hillary
>>
>> Sent from my iPad

>>
>> > On 28 Nov 2016, at 23:49, Jack Ring <jri...@gmail.com> wrote:
>> >
>> > I will appreciate any information or guidance you can provide regarding the following:
>> >
>> > 1. How can we know the relative contribution by any given component in a system given a situation and the intended effects on that situation?
>> >

>> > 2. In baseball the relative contribution of the pitcher is probably higher than the relative contribution of the right fielder. However, this may be true on defense but not on offense (as batters).
>> >

>> > 3. How can we anticipate a) the relative contribution to the Mission of a System of Systems by a constituent in that System of Systems AND b) the relative loss of contribution to the mission of that constituent system due to its being involved in the SoS?
>> >

>> > 4. Increasingly, brigade-scale SoS in-theater exhibit unexpected vulnerabilities and mind-numbing characteristics. How can these be foreseen?
>> >

[Ferris, Tim]

“Here” referred to the conversation within the thread discussion. “Culture” referred to the embedded assumptions of the predominant ethnic culture in the group and the impact that has made on the presuppositions of SE.

 

Even I am old enough to remember stories of people driving who broke a con-rod and drove home on the remaining cylinders of the engine, with the broken con-rod through the block.

 

More modern design has tried to ‘optimise’ performance and lost that kind of resilience to broken bits. In a modern engine it is almost impossible to keep going with a structural failure like that. (In many cases it is difficult or impossible to keep going with unavailability of the engine’s favourite grade of fuel. My grandfather drove petrol cars 300,000 miles during WWII on kerosene, because petrol was rationed and not available to him, even though most of his driving was for government contracted business, that they compulsorily relocated him to do, but he had to find his own sources of fuel to do the travel to do the work. His old style engines, with all their inefficiencies an inherent unreliability would operate in a much wider envelope of conditions.) The current design philosophy is to aim for great performance and function, but only if the inputs are all in place, but with little adaptivity to wrong inputs. The effect is that all the elements of the system are necessary to get it to work, so all the parts are, potentially, the one part for which it fails.

 

“A horse, a horse, my kingdom for a horse”. Any horse would have done, and they found him under a carpark.

 

Tim Ferris

[Jack Ring]

I think ‘modern’ SE culture does not acknowledge that a system has dynamic and integrity limits and therefore ensures that a candidate system design has a sufficient envelope for the extent, variety (temporal and semantic) and ambiguity of the problem system to be suppressed. In this sense a failure is not only something that discontinues but also anythings that makes the limits inadequate in the first place. This is particularly evident when you acknowledge that most systems continuously change and even evolve.

Jack Ring

[Steven Krane]

Jack,

If a SOS is a system that you control which relies on interoperation with a one or more systems you do not control, can you offer an example of a system that is not a SOS? I can’t think of one. My other question for you is in regard to your choice of the word “control”. Control is rarely complete. I’m not even sure I can “control” me. Maybe instead of “do not control”, you mean “do not have decision rights to change”.

[Jack Ring]

Steve,
Although almost all systems in use are SoS’s therefore the distinction is superfluous, it is possible to devise a system that consists only of your own code that also flags Not System conditions if they occur.
Jack

> On Nov 29, 2016, at 6:45 PM, Steven Krane <sk5...@gmail.com> wrote:
>
> Jack,
>
> If a SOS is a system that you control which relies on interoperation with a one or more systems you do not control, can you offer an example of a system that is not a SOS? I can’t think of one. My other question for you is in regard to your choice of the word “control”. Control is rarely complete. I’m not even sure I can “control” me. Maybe instead of “do not control”, you mean “do not have decision rights to change”.
>

[Jack Ring]

If you don’t have control then you do not know when the thing becomes Not system.

[Steven Krane]

Code is inert. Not a system.

[Jack Ring]

When executed.

[Steven Krane]

Code in execution is not a system that consists only of your own code.

Any other examples of a system that is not a system of systems? Don’t get me wrong, I understand, I think, the paradigm shift people are attempting with the SOS moniker, but it is, for me, an unnecessary and complicating contrivance layered on the notion of System.

[Jack Ring]

Steve,
I differ with your claim, "Code in execution is not a system that consists only of your own code.”
What other code is there?
Perhaps you are presuming that my code runs on hardware that contains code by others. Such is not the case.

As I said in a previous post, “… almost all systems in use are SoS’s therefore the distinction is superfluous…” and have earlier said, “...those who use SoS are on the verge of understanding system.” However, Azad keeps telling me that such claims do not help them get on to understanding ‘system.”

For example, one of my goals is to help the "Maier cohort" think not only about the effect-iveness of their perceived SoS but also also about the change of effect-iveness of the constituent system in its own misson.

Jack

[Steven Krane]

I'm assuming that executing your code will require some number of watts and someone or something to push the start button and perhaps someone or something to see/use what it does. Code includes no sensors or effectors. Systems need those. My systems anyway.

[Jack Ring]

No sense quibbling about system vs. components. For those not comfortable with "all is connected' they can use SoS.

>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>>>>> Visit this group at https://groups.google.com/group/syssciwg.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
>>>>>
>>>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>>>> ---
>>>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>>>> Visit this group at https://groups.google.com/group/syssciwg.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
>>>>
>>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>>> ---
>>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>>> Visit this group at https://groups.google.com/group/syssciwg.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
>>>
>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>> ---
>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>> Visit this group at https://groups.google.com/group/syssciwg.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
>>
>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>> ---
>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>> Visit this group at https://groups.google.com/group/syssciwg.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
>
> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
> ---
> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/syssciwg.
> For more options, visit https://groups.google.com/d/optout.

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.

Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

[Steven Krane]

And the Ptolemaic system.  I understand it can be rigged to predict fairly accurately, with great effort.  Parsimony.  Peace.

Sent from my iPad

To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.

[Jack Ring]

Derek,

Thanks for reminding us of this. Suggest you do an INCOSE Webinar with it.

Jack 

On Dec 6, 2016, at 9:13 AM, D K Hitchins <profhi...@mac.com> wrote:

I see from your note that you are contemplating the use of Beer’s VSM. As you know it is conceived and intended for business organizations, and is founded on Beer’s understanding of the human central nervous system. It was used in Chile to underpin the development of their then developing state, but did not meet with universal acclaim, some declaring it to be totalitarian. IOW, it takes no account of humans, but expects machine-like observance… not entirely fair, but there you are.

As an alternative, you might care to look at my own poor offering, Hitchins’ VSM, a presentation of which which is to be found on YouTube at https://youtu.be/-dwzb_NN4II. You may find it more appropriate for socio-technology systems: military engagements; air traffic management; transport; societal; engineering management; etc., etc.

Cheers

Derek Hitchins

profhi...@mac.com

<derek hitchins.vcf>

On 5 Dec 2016, at 17:18, jac...@burnhamsystems.net wrote:

With regard to item 5, I find that the complexity world is highly fragmented.  So it depends on which type of complexity your system falls into.  Here is my summary of complexity types:

 

(1) A system an outside observer does not understand. The INCOSE Complexity Primer focuses on this type. 

 

(2) A system with lots of components and interfaces.  This is the type defined by Holland You can decomplexify this type of system by eliminating components and interfaces. You can do this until the system ceases to function.   This is probably the easiest type of system to decomplexify. 

 

(3) The  third types is the type more favored by system scientists.  It focuses on the uncertainties in the relationships between components.  This is sometimes called Shannon  entropy.  This entropy can be reduced by good design and making sure there is no "slack" between components. 

 

There are other types of complexity models, such as dynamic complexity. I do not know how dynamic complexity fits into the three types I mention above. 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: [fellows discuss] The User's Concerns
From: Jack Ring <jri...@gmail.com>
Date: Mon, November 28, 2016 3:49 pm
To: Sys Sci <syss...@googlegroups.com>, "INCOSE
Fellows...@incose.org" <Fellows...@incose.org>

I will appreciate any information or guidance you can provide regarding the following:

1. How can we know the relative contribution by any given component in a system given a situation and the intended effects on that situation?

2. In baseball the relative contribution of the pitcher is probably higher than the relative contribution of the right fielder. However, this may be true on defense but not on offense (as batters).

3. How can we anticipate a) the relative contribution to the Mission of a System of Systems by a constituent in that System of Systems AND b) the relative loss of contribution to the mission of that constituent system due to its being involved in the SoS?

4. Increasingly, brigade-scale SoS in-theater exhibit unexpected vulnerabilities and mind-numbing characteristics. How can these be foreseen?

[b...@lawson.se]

I think Sarah Shread did a great job on complexity in our Vol. 7 - Software Engineering in the Systems Context.

Bud Lawson

--
Dr. Harold "Bud" Lawson - Prof. Emeritus, ACM, IEEE and INCOSE Fellow, IEEE Computer Pioneer, INCOSE Systems Engineering Pioneer.
Phone +46 8 7659740 Mobile +46 70 5658077, E-mail b...@lawson.se                
For book information see http://www.thesystemslandscape.com/
LinkedIn: https://www.linkedin.com/in/harold-lawson-66810b2

----Ursprungligt meddelande----
Från : hillary....@blueyonder.co.uk
Datum : 2016-12-07 - 12:18 (CET)
Till : profhi...@mac.com
Kopia : jac...@burnhamsystems.net, jri...@gmail.com, syss...@googlegroups.com, Fellows...@incose.org
Ämne : Re: [fellows discuss] The User's Concerns

Derek,

I think you understate your case. 

There are compelling arguments that complexity is what enables  adaptability, flexibility, survivability, self-healing and viability. 

See for example Jan Benyus’s “Biomimicry” which I quoted from briefly in my book.

Cheers

Hillary

On 7 Dec 2016, at 11:14, D K Hitchins < profhi...@mac.com> wrote:

Scott,

Good to hear from you! I agree that complexity is hard to get a hold of… I don’t go a bundle on Wikipedia as a rule, but there seems to be an excellent article at https://en.wikipedia.org/wiki/Complexity which really covers the ground. 

One thought which occurs; while engineers may seek to “de-complexify,” or reduce complexity in a system-of-interest (SOI), there is an argument that sees complexity as emergent, so something that happens, often in course of the conception, design, modification and upgrade of a system. It is also observed that “complexity autogenerates,” i.e., sociotechnical systems tend to become more complex over time in operation, as modifications are continually made to “cater for this,” “improve that,” and so on. You will have come across this many times, I’m sure. A mature system may end up very much more complex than it was at inception. 

It is also true to say that complexity correlates with capability, adaptability, flexibility, survivability, self-healing and viability. That is not to say that complexity is the cause and these so-called “-ilities." Instead, it is to say that designing and incorporating these “-ilities” inevitably results in increased complexity. You can also look at that the other way around, and suggest that to “de-complexify” is to threaten capability, adaptability, flexibility, survivability, self-healing and viability in general.

Oh, and for your entertainment, why not take a peek at:

Systems & Systems Engineering—Systems Science & Complexity 

.. which you can find on YouTube at https://youtu.be/Ar0Jz4fRkOI?list=PLHlV63L37EI39cy0usd1jsdqJ_gvQzG1X It suggests that, as systems engineers, we should consider how to exploit complexity.

Regards

Derek Hitchins

profhi...@mac.com

[Eric Honour]

I don’t often contribute to these discussions, but this topic is dear to my heart these days.  Just wanted to point out that complexity can certainly enable these -ilities, but it can also act to their detriment.  It depends on what kinds of emergent behaviors are created by the complexity.  The whole cyber-security world is an example of complexity destabilizing systems.  Survivability problems are also often caused by complexity.

My observation is that complexity can be both positive and/or negative for a system; what it certainly does is require a closer closed-loop management of the system in operation.  This can happen either within the self-organizing system, or by external continual engineering.

Cordially,

Eric

[Jack Ring]

IF you understand, as Warfield counseled, that a) complexness is a system attribute (applicable to both the problem system and the problem suppression system),  b) ignorance is an observer attribute, and c) complexity is an attribute of the relationship between system and observer THEN you will have a clue to whether to bother about complex or ignorance. ELSE you will continue to muddle in the fiction of system complexity. It really is that simple.

cheers,

On Dec 7, 2016, at 9:18 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

So - Complexity is like oxygen - essential for viability, yet lethal in excess or in the wrong place!

Hillary

Sent from my iPad

[Jack Ring]

Or complexity is like respect — if you don’t have enough self-respect you will see lots of lack of respect from others regardless of their intent.

Complexity is in the eye of the beer-holder.

On Dec 7, 2016, at 9:18 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

So - Complexity is like oxygen - essential for viability, yet lethal in excess or in the wrong place!

Hillary

Sent from my iPad

On 7 Dec 2016, at 16:16, Eric Honour <eho...@hcode.com> wrote:

[Jack Ring]

Scott,

Pls explain a) why Persian rugs cost so much more than plain ones or b) why Navajo women put so much effort into weaving their rugs with multiple colors and patterns. 

Then explain why Christopher Alexander encouraged us to understand a pattern language and the rules for interrelating patterns.

Then, if you are old enough to remember the 1960’s, tell us why Value Engineering was invented. I was told it was done to decomplexify a design (once the designers understood the problem)?

Perhaps it is time to revitalize Value Engineering.

Jcka Rgni

On Dec 7, 2016, at 9:40 AM, jac...@burnhamsystems.net wrote:

I cannot find a single example of human-made system for which complexity is beneficial.

[Jack Ring]

I posited an IF:THEN:ELSE. I think your post amplifies the ELSE.

Labeling complexness as a non-word signifies the beer-holder’s lack of awareness, not the validity of the word. 

http://www.thefreedictionary.com/complexness

Do you also not comprehend wetness, dryness, friendliness, open-mindedness?

Do you have a rule for when to use the suffix, -ity or -ness?

If complexness is not widely understood or shared then perhaps that is the problem. Could it be that a) complexness is too complex or b) ignorance widely prevails?  

I dare say system and system engineering are not widely understood either. Should we abandon efforts to increase understanding (decrease ignorance)?

No Warfield did not use the word for what you have alluded to as ‘technical’ or ‘objective’ complexity. I dare say he would not attempt to  clarify the meaning of a word by adding adjectives, particularly when there is no unambiguous distinction between objective and subjective (as Carl Jung explained centuries ago).

It is unfortunate that some will have to unlearn the objective/subjective allusion but some also had to unlearn other fictions. 

Or they don’t — clarity of thought is voluntary.

Please be assured that  my objective appreciation of your views caused the content of this message while my subjective appreciation for your efforts caused its transmission. ;-)

Jack

On Dec 7, 2016, at 9:51 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

Unfortunately Warfield's use of the non-word complexness is not widely understood or shared.

 I take it he uses it as a label for what I label technical or objective complexity. It is important to distinguish between this, whatever we call it, and subjective or perceived complexity, which is an attribute of the relationship between observer and system. 

Derek used the word complexity in the sense of objective complexity, and in so doing would be entirely understood by scientists who study these phenomena in the domains he refers to. We will learn better from other domains how to use their understanding of how objective complexity achieves capability, adaptability, flexibility, survivability, self-healing and viability if we do not invent our own language, which they will see as unnecessary and impenetrable jargon.

 Because there is a large body of science that has studied objectively complex systems, and found interesting attributes we would like to copy, I see it as almost certainly unhelpful to restrict the word 'complexity' to the subjective or perceived kind.

Better to qualify it using neutral language so we can bring a wider community into constructive dialogue.

Sent from my iPad

[Jack Ring]

Scott,

An excellent example of a man-made monoculture is [15288, SEHandbook, SEBoK, INCOSE Vision 2025 and SE Certification]. The advent of the nondeterministic world of autonomous systems, genetics and cybersecurity is demonstrating Mark’s prediction that ‘mono’ can be deadly —from within.

Jack

On Dec 7, 2016, at 10:41 AM, jac...@burnhamsystems.net wrote:

Thank you, Mark.  Although one may consider "monocultures" as natural rather than human-made, when you "pick your poison", you have introduced the human intervention in it. When you do this you have crated a human-made system. 

 

Regarding our previous discussion of the Internet as a human-made system for which complexity is beneficial, I have been studying Taleb a bit more. Although he mentions the Internet several times, even he does not specifically identify it as a human-made system for which complexity is beneficial.  The point that he makes is that, to paraphrase him, the Internet is an "accidental" system. That is what it does is very different from what was originally intended for it.  

 

Scott 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: RE: [fellows discuss] The User's Concerns
From: Mark W Maier <mark.w...@aero.org>
Date: Wed, December 07, 2016 9:15 am
To: "jac...@burnhamsystems.net" <jac...@burnhamsystems.net>, Eric
Honour <eho...@hcode.com>, Hillary Sillitto
<hillary....@blueyonder.co.uk>
Cc: D K Hitchins <profhi...@mac.com>, Jack Ring <jri...@gmail.com>,
"syss...@googlegroups.com" <syss...@googlegroups.com>, "INCOSE
Fellows...@incose.org" <Fellows...@incose.org>

Scott,

 

Monocultures, whether natural or human-made, are vulnerable to collapse and attack in ways that more complex arrangements are not. A monoculture, whether ecological or technical, is usually regarded as less complex than one that is composed of many diverse interacting elements. I think that is a case for where “complexity is beneficial.” Of course, you can argue that only the right complexity is beneficial in such or case, or that there might be alternative approaches, etc. But, I think that the example of uniformity being vulnerable to certain types if common-mode failure where a more diverse system is not is the example you are looking for. Not to say that different sorts of common-mode failure don’t exist in systems with high variety, but in human-made systems we get to pick our poison according to our own tastes.

 

Mark Maier

 

 

From: jac...@burnhamsystems.net [mailto:jac...@burnhamsystems.net] 
Sent: Wednesday, December 07, 2016 11:40 AM
To: Eric Honour <eho...@hcode.com>; Hillary Sillitto <hillary....@blueyonder.co.uk>
Cc: D K Hitchins <profhi...@mac.com>; Jack Ring <jri...@gmail.com>; syss...@googlegroups.com; INCOSE Fellows...@incose.org <Fellows...@incose.org>
Subject: RE: [fellows discuss] The User's Concerns

 

Eric, thank you so  much for joining this discussion.  

 

In his book Antifragility Taleb tries to make the point that complexity can often be good for a system.  However, I have studied this book closely and I cannot find a single example of human-made system for which complexity is beneficial.  He describes evolution, for example, as a system for which complexity is beneficial. Of course, evolution is a natural system and not a human-made system.  

 

The only time that complexity can be beneficial for a human made system, like an aircraft, is when you define system in the Holland way, that is a system consisting of many parts and interfaces.  So when you add a part to achieve physical redundancy, you are also making it more complex by that definition.  

 

I need to point out that Taleb is a dilettante and not a system scientist. His observations about the Gaussian distribution in the Black Swan are completely wrong.   

Scott

[Jack Ring]

Scott, 

Apparently you have not found that authors do not imply, only observers do that. 

if think about positive and negative atoms as objective and subjective atoms you will know that they differ but never know why they differ. Best you should discover electrons and protons.

We might even progress to acknowledging the role of neutrons. SysML cannot.

Jack

On Dec 7, 2016, at 10:45 AM, <jac...@burnhamsystems.net> <jac...@burnhamsystems.net> wrote:

Jack,

 

I have found that like Warfield, many authors use the word complexity without defining it.  When they do this, they usually imply objective complexity. 

 

Scott

 

 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: Re: [fellows discuss] The User's Concerns
From: Jack Ring <jri...@gmail.com>
Date: Wed, December 07, 2016 9:34 am
To: Hillary Sillitto <hillary....@blueyonder.co.uk>
Cc: Eric Honour <eho...@hcode.com>, Hitchins Derek
<profhi...@mac.com>, "jac...@burnhamsystems.net"
<jac...@burnhamsystems.net>, Sys Sci <syss...@googlegroups.com>,
"INCOSE Fellows...@incose.org" <Fellows...@incose.org>

I posited an IF:THEN:ELSE. I think your post amplifies the ELSE.

Labeling complexness as a non-word signifies the beer-holder’s lack of awareness, not the validity of the word. 

http://www.thefreedictionary.com/complexness

Do you also not comprehend wetness, dryness, friendliness, open-mindedness?

Do you have a rule for when to use the suffix, -ity or -ness?

If complexness is not widely understood or shared then perhaps that is the problem. Could it be that a) complexness is too complex or b) ignorance widely prevails?  

I dare say system and system engineering are not widely understood either. Should we abandon efforts to increase understanding (decrease ignorance)?

No Warfield did not use the word for what you have alluded to as ‘technical’ or ‘objective’ complexity. I dare say he would not attempt to  clarify the meaning of a word by adding adjectives, particularly when there is no unambiguous distinction between objective and subjective (as Carl Jung explained centuries ago).

It is unfortunate that some will have to unlearn the objective/subjective allusion but some also had to unlearn other fictions. 

Or they don’t — clarity of thought is voluntary.

Please be assured that  my objective appreciation of your views caused the content of this message while my subjective appreciation for your efforts caused its transmission. ;-)

Jack

On Dec 7, 2016, at 9:51 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

Unfortunately Warfield's use of the non-word complexness is not widely understood or shared.

 I take it he uses it as a label for what I label technical or objective complexity. It is important to distinguish between this, whatever we call it, and subjective or perceived complexity, which is an attribute of the relationship between observer and system. 

Derek used the word complexity in the sense of objective complexity, and in so doing would be entirely understood by scientists who study these phenomena in the domains he refers to. We will learn better from other domains how to use their understanding of how objective complexity achieves capability, adaptability, flexibility, survivability, self-healing and viability if we do not invent our own language, which they will see as unnecessary and impenetrable jargon.

 Because there is a large body of science that has studied objectively complex systems, and found interesting attributes we would like to copy, I see it as almost certainly unhelpful to restrict the word 'complexity' to the subjective or perceived kind.

Better to qualify it using neutral language so we can bring a wider community into constructive dialogue.

Sent from my iPad

On 7 Dec 2016, at 16:33, Jack Ring <jri...@gmail.com> wrote:

IF you understand, as Warfield counseled, that a) complexness is a system attribute (applicable to both the problem system and the problem suppression system),  b) ignorance is an observer attribute, and c) complexity is an attribute of the relationship between system and observer THEN you will have a clue to whether to bother about complex or ignorance. ELSE you will continue to muddle in the fiction of system complexity. It really is that simple.

cheers,

On Dec 7, 2016, at 9:18 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

So - Complexity is like oxygen - essential for viability, yet lethal in excess or in the wrong place!

Hillary

Sent from my iPad

On 7 Dec 2016, at 16:16, Eric Honour <eho...@hcode.com> wrote:

[Jack Ring]

Hillary,

Dictionary does not imply, only observers do.

Technical complexity may mean the same as complexness but fails the test of parsimony.

On Dec 7, 2016, at 11:03 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

Jack

I cannot discern from the free dictionary link any distinction between complexness and complexity, which it implies are synonyms.

I moved from 'objective and subjective in my 2009 paper to technical and perceived in my book. In the latter I find the words "Technical complexity is an intrinsic attribute of the system of interest" - which sounds, if I may say so, uncannily like Warfield's "complexness is a system attribute". 

Hillary

Sent from my iPad

[Jack Ring]

Hillary,

Does not appear circular to me. More like sequential ricochets. 

I posited that IF you understand a) complexness is a system attribute (applicable to both the problem system and the problem suppression system),  b) ignorance is an observer attribute, and c) complexity is an attribute of the relationship between system and observer THEN you will have a clue to whether to bother about complex or ignorance. ELSE you will continue to muddle.

You took issue with complexness, and promoted adjectives of objective and subjective, while ignoring the aspect of observer ignorance (the accuracy of objective and acuity of subjective?) thus continued the muddle. 

You then promoted the "voice of the masses” over the discipline of examining fallibility while claiming the former was scientific.  For example, I accept that ‘there are thousands of papers on the subject of complexity that do not conform to Warfield's definition.’ However I am not aware of any evidence that any of these 'would be valuable to the field of systems engineering if we paid attention to them.’ Pls supply evidence. Better yet not just evidence of ‘would be valuable’ but evidence of ‘was valuable’ (and moreso than the complexness -complexity perspective.)

‘We' do not keep shooting ourselves in the foot. Only a large subset of ‘we’ keep doing so. FWIW I suspect it is because of a human habit of doing what we want to do instead of what works.  For example, we know what fosters HIV in a human being but  ‘we' keep doing so. Likewise we know what fosters complexity around systems but we keep doing so.

I encourage you and others to examine the IF:THEN:ELSE for the THEN. 

Do you recommend making less complex systems or smarter SE practitioners, particularly ones who are not mono-intellectual sheep?

Jack

On Dec 7, 2016, at 11:08 AM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

Jack

How many times do we have to go round this circular argument. It doesn't matter what Warfield said other than that it explains how we have to read and understand his work. Problem is other people define it differently - and do valuable work under that label. The usual problem - different worldviews, different definitions, total confusion. There are thousands of papers on the subject of complexity that do not conform to Warfield's definition that would be valuable to the field of systems engineering if we paid attention to them. Why do we keep shooting ourselves in the foot?

 

Sent from my iPad

On 7 Dec 2016, at 18:01, Jack Ring <jri...@gmail.com> wrote:

Warfield clearly defined complexity — the characteristic of the relationship between system and observer of system.

On Dec 7, 2016, at 10:45 AM, <jac...@burnhamsystems.net> <jac...@burnhamsystems.net> wrote:

Jack,

 

I have found that like Warfield, many authors use the word complexity without defining it.  When they do this, they usually imply objective complexity. 

 

Scott

 

 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: Re: [fellows discuss] The User's Concerns
From: Jack Ring <jri...@gmail.com>

Date: Wed, December 07, 2016 9:34 am
To: Hillary Sillitto <hillary....@blueyonder.co.uk>
Cc: Eric Honour <eho...@hcode.com>, Hitchins Derek
<profhi...@mac.com>, "jac...@burnhamsystems.net"

[Jack Ring]

Scott,

Pls consider the distinction between adaptability, complexness and complexity. Systems that excel in adaptability or self-adaptiveness may have many modes of operation but also may be too confusing to be used appropriately. For example, 

a current DARPA emphasis is on autonomous systems that explain why they did what they did. Probably this will entail an increase in their complexness but clearly pursues a decrease in the complexity of their relationship with their users. Interestingly DARPA did not ask for ideas on how to make the user a more effective observer. Bummer. 

Jack

On Dec 7, 2016, at 11:22 AM, Eric Honour <eho...@hcode.com> wrote:

Scott - 

An example I use frequently is “a military force,” a rather large system made up of many smaller systems and the people who operate them.  If a military force operates in a well-planned, deterministic manner, it can only be effective once.  Because it exhibits a great deal of complexity, it can be adaptive to the opposing forces and becomes effective repeatedly.

Most systems of systems have the same characteristic; the benefits of their complexity actually are why they have been aggregated into an SoS in the first place.  Examples:  air traffic control adapts to the ever-changing situation through a series of rule-based interactions by individual agents; urban emergency response applies its various resources (fire, police, ambulance, etc.) effectively without wasting them through dynamic interactions guided by general concepts; and so on.  I think there is a wealth of examples in which complexity adds to the effectiveness of a system.

In an even more basic thought, I’ve said for about ten years that systems engineering is the engineering of complexity - and always has been.

Cordially,

Eric

On Dec 7, 2016, at 11:07 AM, <jac...@burnhamsystems.net> <jac...@burnhamsystems.net> wrote:

Yes, the Internet is a good example. 

 

 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: Re: [fellows discuss] The User's Concerns

From: Hillary Sillitto <hillary....@blueyonder.co.uk>
Date: Wed, December 07, 2016 8:58 am
To: jac...@burnhamsystems.net
Cc: Eric Honour <eho...@hcode.com>, D K Hitchins
<profhi...@mac.com>, Jack Ring <jri...@gmail.com>,

"syss...@googlegroups.com" <syss...@googlegroups.com>, "INCOSE
Fellows...@incose.org" <Fellows...@incose.org>

Scott

The internet is a complex system which has generated interesting emergent properties as a result of its complexity that many see as beneficial. Some of these properties are good and some bad to us as individuals. Evolution too has winners and losers.  

Creating a complex system means giving up control. If you want to stay in control, shun (objective) complexity. If you want your system to have natural resilience you may have to give up control to let it work things out for itself.

Actually, reducing objective complexity and increasing perceived complexity is a great way of staying in control. That's why most professions use jargon!

I've said enough on this one! Signing out.

Hillary

Sent from my iPad

On 7 Dec 2016, at 16:40, <jac...@burnhamsystems.net> <jac...@burnhamsystems.net> wrote:

Eric, thank you so  much for joining this discussion. 

 

In his book Antifragility Taleb tries to make the point that complexity can often be good for a system.  However, I have studied this book closely and I cannot find a single example of human-made system for which complexity is beneficial.  He describes evolution, for example, as a system for which complexity is beneficial. Of course, evolution is a natural system and not a human-made system. 

 

The only time that complexity can be beneficial for a human made system, like an aircraft, is when you define system in the Holland way, that is a system consisting of many parts and interfaces.  So when you add a part to achieve physical redundancy, you are also making it more complex by that definition. 

 

I need to point out that Taleb is a dilettante and not a system scientist. His observations about the Gaussian distribution in the Black Swan are completely wrong.   

Scott

 

 

 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: Re: [fellows discuss] The User's Concerns
From: Eric Honour <eho...@hcode.com>
Date: Wed, December 07, 2016 8:16 am
To: Hillary Sillitto <hillary....@blueyonder.co.uk>
Cc: D K Hitchins <profhi...@mac.com>, "jac...@burnhamsystems.net"
<jac...@burnhamsystems.net>, Jack Ring <jri...@gmail.com>,
"syss...@googlegroups.com" <syss...@googlegroups.com>, "INCOSE
Fellows...@incose.org" <Fellows...@incose.org>

[Jack Ring]

No. 

As I understand it Hillary sees no benefit in Warfield’s ‘nonword’ perspective and champions the ongoing conversations that utilize kinds of complexity such as objective and subjective by people who have awarded themselves the label of complexity scientists.

Regardless, IMO agreement is not the goal. The goal within the INCOSE context is "systems that are fit for purpose" specifically including the kind of system that accomplish systems design, architecting, engineering and operations assurance.

I simply suggested that a different perspective from the popular one might enable resolution of certain current conundrums. Others do not see the utility in looking at a problem from an alternative point of view.

That is certainly their prerogative.

Jack

On Dec 7, 2016, at 4:21 PM, jac...@burnhamsystems.net wrote:

 

Did you and Hillary ever come to an agreement about the difference between complexness and complexity?

 

Scott

[Eric Honour]

Scott - 

My statement is broad in nature rather than precise, and it encompasses all three of Hillary’s Apples, Bananas, and Cherries artificial definitions.  Regardless of whether we talk about technical complexity or perceived complexity, systems engineering has as its primary goal to develop effective systems in the face of complexity.  All of the principles and methods (“approach and means” in the INCOSE definition) have been developed over decades as ways to work with the complexity of that day.  WWII was faced with the complex problem to build military forces at a pace never before attempted.  One key solution was the firm use of requirements and verification in contracts.  WWII also faced the complex problem to develop situation awareness, and developed operational analysis.  The development of nuclear power in the ‘50s was solved partially by development of system architecting and analysis methods, which were furthered in the NASA space development of the ‘60s and the AEGIS program of the ‘70s.  And so on.  In each decade, the complex problems of the day added to the development of SE concepts and methods.  And this continues today with MBSE and SoS issues.

In a related thought, emergent behavior is one key characteristic of complexity - and every system is designed and built for its emergent behavior.  A set of tires, engine, chassis, and interior parts does not provide transportation.  Only when they are assembled into the appropriate architectural configuration do we have an automobile that provides transportation.  This basic characteristic of emergent behavior is core to systems engineering, else why have the system?

And so: I truly believe that systems engineering is the engineering of complexity - and always has been.

This explanation, of course, begs the issue of precise definitions.  The distinction between complex and complicated is moot in this thought, as is the distinction among the three definitions of complexity.  But, also of course, this explanation is why we are all so interested in becoming more precise in our definitions and understanding of complexity.

Cordially,

Eric

On Dec 7, 2016, at 12:43 PM, <jac...@burnhamsystems.net> <jac...@burnhamsystems.net> wrote:

Eric,

 

These are all good examples.

 

The validity of the last statement though is dependent on which definition of complexity you use. I assume you know the difference between a complex system and a complicated system. Are you saying that a complicated system cannot be systems engineered?

 

Scott

 

 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: Re: [fellows discuss] The User's Concerns
From: Eric Honour <eho...@hcode.com>
Date: Wed, December 07, 2016 10:22 am
To: jac...@burnhamsystems.net
Cc: Hillary Sillitto <hillary....@blueyonder.co.uk>, D K Hitchins
<profhi...@mac.com>, Jack Ring <jri...@gmail.com>,
"syss...@googlegroups.com" <syss...@googlegroups.com>, "INCOSE
Fellows...@incose.org" <Fellows...@incose.org>

[Jack Ring]

I think Eric’s notion is quite appropriate. 

The mono-paradigm of SE pursued by INCOSE (and ones pursued by the other 90% out there) engineer complexity. Unfortunately it is the Warfield complexity — confusion and mismatch with other participant’s mental models. 

Hopefully we will be learning to engineer appropriate complexness and sufficient and efficient user trust.

Like Los Angeles Freeway Drivers, all of those left are darned good. 

[Jack Ring]

IF you build systems of fireworks THEN same or better ELSE worse if you do not also achieve Preservation of necessary, sufficient and efficient Integrity and Agility. 

On Dec 8, 2016, at 3:54 PM, Hillary Sillitto <hillary....@blueyonder.co.uk> wrote:

Engineering of complexity has a certain appeal, and some potential negatives. Is 'engineering of emergence' same, better or worse?

[Jack Ring]

Scott, 

Useful question.

Complex signifies multiple kinds and quantities of items interrelated by multiple kinds and quantities of relationships, e.g., approximately 19 kinds of relationships between any two entities.

1. Complexness: Consider Southwest Airlines. 1) they used only one model aircraft so have only one inventory of parts, one set of practices, whereas other airlines must cope with more models and ramifications. Also each employee would perform in more than one role. Then they started buying other airlines and expanding their service area. 

Competency: Complexness increased while employee agility decreased.

Complexity: The downhill slide of increased complexness and decreased employee agility has become painfully evident.

2. Complexness: About 1980 Boeing came to us (Honeywell computers) wanting help in managing the Dash 1 for the 707 because there were 1000 hulls in service and each was different from any other. 

Complexity: Boeing Dash 1 authors were experiencing cognitive dissonance. 

Competency: The advent of relational data base management software on Multics gave them new insights. 

3. Complexness: At the US Satellite Test Center the AF commissioned a new software version about annually for each of the several kinds of spacecraft being used. Complex situation made worse by frequent changes to adapt to new hardware. Expensive and complex. 

Competency: I conceived a frame-based model (informed by SIMULA and papers on AI) of a spacecraft in operation and we built software to process it.  Let the rules handle the complexity so that the designers did not have to. Nineteen years later I was told it was still in use and across nine different spacecraft for a probable saving of more than $150 million.

4. Complexness: In 1992 we replaced a Order Entry and Billing application written in COBOL because the Sales organization had evolved more than a hundred ‘discount deals.’ 

Complexity: The programmers could not model the business accurately therefore the business was losing millions of dollars per year in disputed billings. 

Competency: We created the complete package in 1/15th of the number of written instructions that was required in COBOL becsuse in Smalltalk you don’t have to prescribe the detailed processes. Then the customer wanted five persons on the held desk 24 hours per day but I provided 1 per shift. He rarely got a call and quickly resolved the issue. in three years he earned a PhD in his spare time.

5. Complexity: In system design sessions it is easy to lose a common understanding of the design. 

Complexness: The late Dr. Joe Skipper set aside RDD-100, UML and SysML and expressed the model as a set of 7 strings several feet long with 20 to 30 statements on cards along each string and other colored string among cards to denote the modes of operation. 

Competency: Designers rarely misunderstood this system of > 200 elements and most memorized it. Although the system scored high in complexness the complexity was nil because their acuity was high.

6. etc.

On Dec 7, 2016, at 4:21 PM, jac...@burnhamsystems.net wrote:

Jack,

 

I find discussions about complexness, complexity, adaptability and so forth hard to follow without examples. Can you provide examples?

 

Did you and Hillary ever come to an agreement about the difference between complexness and complexity?

 

Scott

 

 

Scott Jackson

斯科特·杰克逊

INCOSE Fellow

Principal Engineer

Burnham Systems Consulting

1-949-726-2003

ORCID 0000-0003-3386-4561

 

 

-------- Original Message --------
Subject: Re: [fellows discuss] The User's Concerns
From: Jack Ring <jri...@gmail.com>
Date: Wed, December 07, 2016 1:56 pm
To: Eric Honour <eho...@hcode.com>
Cc: jac...@burnhamsystems.net, Hillary Sillitto
<hillary....@blueyonder.co.uk>, Hitchins Derek
<profhi...@mac.com>, Sys Sci <syss...@googlegroups.com>, "INCOSE
Fellows...@incose.org" <Fellows...@incose.org>

Scott,

Pls consider the distinction between adaptability, complexness and complexity. Systems that excel in adaptability or self-adaptiveness may have many modes of operation but also may be too confusing to be used appropriately. For example, 

a current DARPA emphasis is on autonomous systems that explain why they did what they did. Probably this will entail an increase in their complexness but clearly pursues a decrease in the complexity of their relationship with their users. Interestingly DARPA did not ask for ideas on how to make the user a more effective observer. Bummer. 

Jack

On Dec 7, 2016, at 11:22 AM, Eric Honour <eho...@hcode.com> wrote:

[Eric Honour]

[Lenard Troncale]

Eric,

This is where the interactions of the systems processes (isomorphies) reveals its importance and explanatory power. It is the interaction of hierarchy and complexity that could unravel some of the conundrums you describe here. Sometimes the complexity at a higher level of the hierarchy, destabilizes the former stability of a lower level. And sometimes it does the opposite, creating more sustainability as in molecules in cells, or organelles in cells, or tissues in organisms which last much longer because they are “protected” by the complexity of their surroundings (organs, organism) while necessarily surrendering some of their autonomy and independence in the process.

Len’

[Jorg Largent]

Hang in there, Jack.

Your point that "almost all systems in use are SoS’s therefore the distinction is superfluous" is well taken.  The SoS concept is a useful tool in visualization, but debate over a nuance is like picking the fly specks off the pepper corns (to borrow an old adage).  Too illustrate, it is incumbent upon the systems engineering professional to recognize that what is, to a prime contractor, a sub-system (one system in the SoS), is, to the supplier of that "sub-system" a "system" in its own right which might well have "sub-systems" of it own.  We should use the terms to facilitate communication, not to foist argument.

Also there was a comment that software is inert (not on this PC!) and therefore is not a system.  Even if we accept the argument, the creation of, development of, and production of software would benefit from the application of the systems engineering discipline.

Jorg

---

From: syss...@googlegroups.com <syss...@googlegroups.com> on behalf of Jack Ring <jri...@gmail.com>
Sent: Wednesday, November 30, 2016 1:14 PM
To: Sys Sci
Subject: Re: [SysSciWG] The User's Concerns

 

Steve,
I differ with your claim, "Code in execution is not a system that consists only of your own code.”
What other code is there?
Perhaps you are presuming that my code runs on hardware that contains code by others. Such is not the case.

As I said in a previous post, “… almost all systems in use are SoS’s therefore the distinction is superfluous…” and have earlier said, “...those who use SoS are on the verge of understanding system.”  However, Azad keeps telling me that such claims do not help them get on to understanding ‘system.”

For example, one of my goals is to help the "Maier cohort" think not only about the effect-iveness of their perceived SoS but also also about the change of effect-iveness of the constituent system in its own misson.

Jack
> On Nov 30, 2016, at 1:56 PM, Steven Krane <sk5...@gmail.com> wrote:
>
> Code in execution is not a system that consists only of your own code.
>
> Any other examples of a system that is not a system of systems?  Don’t get me wrong, I understand, I think, the paradigm shift people are attempting with the SOS moniker, but it is, for me, an unnecessary and complicating contrivance layered on the notion of System.
>
>> On Nov 29, 2016, at 8:05 PM, Jack Ring <jri...@gmail.com> wrote:
>>
>> When executed.
>>> On Nov 29, 2016, at 8:47 PM, Steven Krane <sk5...@gmail.com> wrote:
>>>
>>> Code is inert.  Not a system.
>>>
>>>> On Nov 29, 2016, at 7:21 PM, Jack Ring <jri...@gmail.com> wrote:
>>>>
>>>> Steve,
>>>> Although almost all systems in use are SoS’s therefore the distinction is superfluous, it is possible to devise a system that consists only of your own code that also flags Not System conditions if they occur.
>>>> Jack
>>>>> On Nov 29, 2016, at 6:45 PM, Steven Krane <sk5...@gmail.com> wrote:
>>>>>
>>>>> Jack,
>>>>>
>>>>> If a SOS is a system that you control which relies on interoperation with a one or more systems you do not control, can you offer an example of a system that is not a SOS?  I can’t think of one.  My other question for you is in regard to your choice of the word “control”.  Control is rarely complete.  I’m not even sure I can “control” me.  Maybe instead of “do not control”, you mean “do not have decision rights to change”.
>>>>>
>>>>> --
>>>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>>>>
>>>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>>>> ---
>>>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/syssciwg.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>>>
>>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>>> ---
>>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/syssciwg.

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>>
>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>> ---
>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/syssciwg.

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>
>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>> ---
>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/syssciwg.

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>
> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
> ---
> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
> Visit this group at https://groups.google.com/group/syssciwg.
> For more options, visit https://groups.google.com/d/optout.

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

[Michael Dee]

Does the designation SoS introduce any new fundamentals or insights in the theory of systems, or is it just renaming (re-languaging) existing concepts?   I have not seen anything to indicate the former, so I am stuck believing the latter.  In other words it seems that SoS maps completely and linearly to existing theory.  But I could be wrong... 

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>>>> Visit this group at https://groups.google.com/group/syssciwg.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>>>
>>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>>> ---
>>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>>> Visit this group at https://groups.google.com/group/syssciwg.

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>>
>>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>>> ---
>>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>>> Visit this group at https://groups.google.com/group/syssciwg.

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>>
>> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
>> ---
>> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

>> Visit this group at https://groups.google.com/group/syssciwg.

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

>
> Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
> ---
> You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/syssciwg.
> For more options, visit https://groups.google.com/d/optout.

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/. 

Systems Science Working Group - Google Sites sites.google.com Wiki Site for the Systems Science Working Group of INCOSE

Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/syssciwg.
For more options, visit https://groups.google.com/d/optout.

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
 

Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

[Aleksandar Malečić]

It's inevitable that discussions sch as this one could last forever unless people somehow achieved consensus about what is a systems and what a system does and how. Indeterminism (https://en.wikipedia.org/wiki/Indeterminism), anticipatory systems (https://en.wikipedia.org/wiki/Anticipatory_Systems;_Philosophical,_Mathematical,_and_Methodological_Foundations), incomplete nature (https://en.wikipedia.org/wiki/Incomplete_Nature), "every thing must go" (https://global.oup.com/academic/product/every-thing-must-go-9780199276196?cc=rs&lang=en&), or some other concept you could add are very specific ideas that are either right or wrong within our systems and physical reality. Hence there is something objectively existent or not out there, regardless of whether someone sees that as relevant to him/her (especially because it's about different kinds of systems and not obvious how insights from one kind of systems can contribute to others - I for instance either have or don't have free will as I'm writing this comment).

Aleksandar

[Steve Wallis]

Very good point Aleksandar - and an important reason we need to move up to a meta-level of thinking. Before starting a conversation about the definition of something, we should be in some kind of agreement around what is accepted as a valid definition. And, for bonus points, what does systems thinking bring to that definition of definition. Or, how do systems thinkers define something differently than those in normal science?

Thanks,

Steve

 - - - 
Steven E. Wallis, Ph.D.
Fulbright Specialist - Consulting on strategy, theory, and policy
Capella University
Meaningful Evidence, LLC

Use ASK MATT to improve your strategy, policy, and theory
http://meaningfulevidence.com/services/ask-matt-game 

[Jack Ring]

Good point. Seems to me (according to Webster) the definition of definition is pretty clear, that is, part of speech such as noun, verb, etc.. What confuses us is usage or what the term signifies.

This means we must address the term/concept role as an operator as well as an an operand.

Jack

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
 
Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.