As members of the Systems Sciences Working Group are organizing for an IFSR Conversation in April 2018, the group focusing on “What is systems science?” will be revisiting a question that has emerged before.
On a message on the Systems Sciences Discussion List, James N. Martin abridged and reposted an e-mail from Gerald Midgely.
Here is the abridged writing by James Martin, dated Dec. 29, 2017:
— begin paste —
Here is a bit of useful wisdom with respect to the question of “what is systems science?” Gerald has given me permission to post this on our Sys Sci discussion list. He was responding to the proposal from Gary Smith to conduct a workshop at the IFSR Conversation in April to address this question
Here are his key points. His full message is enclosed at the end of this email.
- First, don’t ever be under the illusion that you can break systems science down into its constituent components, agree on them all, and therefore gain agreement on the whole. That’s approaching systems science through reductionist analysis, and it won’t work.
- Second, … do not expect that achieving consensus in a small group will generalise to a wider community without (a) a strong message of utility and (b) co-ordinated and strategic action to connect to what matters to other people.
- Third, and linked to the above, be aware that ideas gain currency, not because they are truthful and beautiful in themselves, but because of their utility (the value of the inferences that can be made from them).
- Fourth, and this is probably the hardest thing of all for Systems Scientists to hear – it means that the Systems Science that is of relevance to Systems Engineering might be different from the Systems Science of relevance to systems biology, politics and family therapy.
- A foundational idea in Systems Science is that we can define some generic theory that is relevant across the board.
- I still do think that this is the case, in the sense that there are some concepts (like how parts combine in systems to create emergent properties from the perspectives of observer-participants) that can be defined independently from the receiving discipline.
- However, these relatively abstract conceptualizations, because they are not communicated in the context that the receiving discipline understands, may appear to the engineer to involve too much work for too little value.
- Fifth, … the interactions with the problems of Systems Engineering will change the theory.
- It may be that Systems Science explains some things, but not others, so there is a need for integration with other theory;
- or it could even be that the particularities of Systems Engineering contexts lead people to conclude that an evolution of systems theory is needed in a new direction.
- Systems Engineers can learn a lot from both the science of whole systems (Systems Science) AND thinking through the use of systems concepts that have been abstracted from their original theoretical context (Systems Thinking).
Best Regards, James
— end paste —
Here is the original e-mail from Gerald Midgely addressed to Gary Smith, dated Nov. 20, 2017.
— begin paste —
Hi Gary, Jennifer et al,
Thanks for looping me into this conversation. I know this is a long email, but I really hope it is a helpful one that can prevent the group going down some blind alleys. Below are some suggestions, purely based on my own understanding and experience, having seen people aiming for and failing to achieve a consensual definition of systems science for as long as I have been in the systems community (my first ISSS conference was 1989).
First, don’t ever be under the illusion that you can break systems science down into its constituent components, agree on them all, and therefore gain agreement on the whole. That’s approaching systems science through reductionist analysis, and it won’t work. Jennifer Wilby will remember a workshop at an ISSS conference back in the early 90s where people sought to define common terms. They started with ‘hierarchy’, because they thought it would be the easiest, and 3 hours later they abandoned the attempt, as there were so many different perspectives. The exercise didn’t even get past the first concept because the part (in this case hierarchy) was connected in so many ways to different systems philosophies, and the meaning was subtly different in each case.
Second, and this is really important in the context of a group pursuit exercise such as the one you are planning, do not expect that achieving consensus in a small group will generalise to a wider community without (a) a strong message of utility and (b) co-ordinated and strategic action to connect to what matters to other people. The systems community (along with every other scientific community) is full of groups suffering from “the tragedy of enlightenment” – saying, “we have done so much work to get this far, so why won’t anyone listen to us?” There is a neat little idea called Relevance Theory from the discipline of linguistics that explains why. Relevance to others is a function of the value of the inferences that those others can make from the new idea (i.e., its utility) minus the amount of work it takes to integrate that idea into their conceptual framework. Therefore, ideas may fail to disseminate because they generate a “so what?” reaction (which can be because they really don’t offer much added value to others, even though they do to you, or because they do not connect sufficiently with the worldviews of those you want to influence). They may also fail because they are too complex, and if it means internalising 50 new concepts, and understanding the contributions of 100 researchers over 70 years, people will see the mountain of work as enormous and will not yet have experienced the value of it, so will be dismissive. I used to get really angry when the Systems wheel got reinvented every generation or so (see, for instance, how complexity theory and systems biology failed to acknowledge their roots in GST), but now I realize that insistence on acknowledging the history of ideas actually prevents access to them. That’s hard for us to hear, but remember we are the affictionados who already see the value, so for us the work is worth it – others haven’t got to that point.
Third, and linked to the above, be aware that ideas gain currency, not because they are truthful and beautiful in themselves, but because of their utility (the value of the inferences that can be made from them). Therefore, for your project, the connection with Systems Engineering is actually more important than Systems Science itself! Again, for systems scientists this might be hard to hear – our tendency is first to work out what Systems Science is, and then to look at how Systems Engineers can gain inferences from it. However, the huge risk of doing this is the construction of a fine-tuned and intricately self-referencing and self-reinforcing set of concepts (Systems Science) that obstructs take-up in three ways: (1) it offers inferences that are relevant to systems theorists in domains other than engineering, and neglects the inferences that will be of value for Systems Engineers; (2) it does not dovetail with the language of Systems Engineers, so the value is not immediately obvious, and (3) it takes too much work to learn the subtlety. If it does any of these things, it risks failure.
Fourth, and this is probably the hardest thing of all for Systems Scientists to hear – it means that the Systems Science that is of relevance to Systems Engineering might be different from the Systems Science of relevance to systems biology, politics and family therapy. A foundational idea in Systems Science is that we can define some generic theory that is relevant across the board. I still do think that this is the case, in the sense that there are some concepts (like how parts combine in systems to create emergent properties from the perspectives of observer-participants) that can be defined independently from the receiving discipline. However, these relatively abstract conceptualizations, because they are not communicated in the context that the receiving discipline understands, may appear to the engineer to involve too much work for too little value. Again, the connection with the discipline matters more than Systems Science itself (how many times have you heard that the connections between the parts are as important, or even more so, than the parts themselves?), and the way Systems Science gets presented (the emphasis on some concepts rather than others, with particular examples) will be different from the Systems Science that gets presented to another audience, even if there are some common reference concepts.
Fifth, and this will also be hard to hear – the interactions with the problems of Systems Engineering will change the theory. It may be that Systems Science explains some things, but not others, so there is a need for integration with other theory; or it could even be that the particularities of Systems Engineering contexts lead people to conclude that an evolution of systems theory is needed in a new direction. If Systems Scientists then resist this, because it is a breach of the ideal of generality, then there will be a split in the research community, and the consensus you started out with will be broken. Here I am reminded of Kurt Richardson’s insightful complexity theory of language: as conceptual formations meet new contexts, bifurcations of meaning happen. This is why there is so much variety in systems theory in the first place. Disciplines narrow the contexts of meaning that their theory is designed to address, and therefore they can maintain more coherence and consensus than Systems Science, which self-consciously seeks to address ALL contexts. I actually did my PhD on this problem (1988 to 1992), and argued that we need a theory to EXPLAIN the pluralism (thus giving a different kind of coherence than a single systems theory), not a once-and-for-all theory to eliminate it. In this situation, we should expect diversity, not rebel against it and try to reduce it. The task of the Systems Scientist is therefore not to produce the best possible, fully worked-out systems theory, which will (of course) be relevant to systems scientists and nobody else! Rather, our task is to define the leanest possible theory, or set of concepts, which maximises value by being easily translatable into multiple, diverse contexts (such as Systems Engineering), while causing the people in those contexts very little work to internalise the concepts. This can be done with the Systems Engineering link (and other links) in mind, so the desire for purity is always countered by the need for communication with others.
Just one other thing I would like to add, which is not an outcome of the above reasoning, but also important. I think some clarity is needed about the difference and connections between Systems Science and Systems Thinking in this context. It seems to me that Systems Engineers can learn a lot from both the science of whole systems (Systems Science) AND thinking through the use of systems concepts that have been abstracted from their original theoretical context (Systems Thinking). If you are in any doubt about the difference, think about how ‘boundary’ is used in Systems Science as a reference to the edge of a real-world system (seen from the perspective of an observer, of course). However, when the boundary concept is moved into the domain of Systems Thinking, we can suddenly talk about boundaries defining what OUGHT to happen, etc. The concept has been abstracted from its original meaning and is deployed more widely. I am pointing this out, not to state the obvious, but to make it clear that defining Systems Science for use in Systems Engineering is only part of what the systems community can offer the engineering world. There are three risks here: (1) failing to notice Systems Thinking, and the Systems Engineering community getting confused between two competing claims of benefit (it is too much work for Engineers to sort this out, and both Systems Science and Systems Thinking will fail to deliver); (2) imperialistically presenting Systems Science as if it is both Systems Science and Systems Thinking, which will spark a paradigm war in our own research community; and (3) saying that Systems Science is right and Systems Thinking wrong, or a pale immitation, which risks both a paradigm war in our own community AND failure to deliver because we are expecting engineers to discriminate between competing claims! Please can we build clarity on the science/thinking distinction into our offering, without saying that either is less worthy than the other?
Thanks for listening, if I have not caused you too much work and you have read this far!
Best wishes, Gerald
— end paste —
These responses may not satisfy those looking for “simple answers”
Systems Community of Inquiry 