Proceedings of the IFSR Conversation 2012, St. Magdalena, Linz, Austria
Comparison of Team 4
Position Paper Themes and Concepts
Duane Hybertson
Themes that emerged from the Team 4 position papers submitted pre-conference:
- Goal of Team 4 not clear or not consistent among group members
- Single common language is historically problematic [but single common ontology is also historically problematic]
- Contrast single common language with domain specific languages; systems praxis is ultilingual, multi-domain (even within a given system)
- Suggest focus on concepts or ontology, not language
- Suggest shared understanding, shared knowledge, shared vision
- Importance of views; models
From these themes we can pose possible goals for the Conversation:
| No. | Ultimate goal | Conversation goal this week |
| 1. | Define and adopt one common language | Clarify the attributes of one common language |
| 2. | Define and adopt one common ontology | Clarify the attributes of one common ontology |
| 3. | Define and adopt a small core common language | Clarify the attributes of a small core common language |
| 4. | Define and adopt a small core common ontology | Clarify the attributes of a small core common ontology |
| 5. | Define and adopt a set of common ontology views | Clarify the attributes of a set of common ontology views |
The table below selects excerpts from position papers of Team 4 members and relates them to a common set of systems science and systems engineering concepts described in the book Model- Oriented Systems Engineering Science1, referred to here as MOSES. The purpose of the book is to define a science foundation for an envisioned systems engineering of the future that expands beyond its traditional scope of application domains to include more complex problem areas such as social systems and public policy issues. This science foundation is built substantially from general systems science and complex systems theory, but also from other disciplines including physics, biology, psychology, sociology, economics, law, and organizational theory. The book describes the general relation between science and engineering, and then focuses on the elements of the sciences that are useful for the practice of systems engineering. The model-oriented treatment of these topics in the book revolves around the position that it is useful and clarifying to regard the artifacts of science (such as theories) and engineering (such as requirements and design) as forms of models, and that these models can be organized in a multi- dimensional model space. The model space not only facilitates the understanding of the models and their relations and interactions, but also in a larger sense serves as a large virtual structured container of the body of knowledge of the relevant systems science and engineering disciplines.
This Team 4 Conversation, and the mapping table below, focused less on the model-oriented aspects of the book and more on the basic concepts of the sciences and systems engineering, and the relations between them. The first two columns of the table represent a selective synopsis of the position papers, while the third column provides a MOSES perspective on each position concept.
| Person | Position concept or facet | Concept or response from MOSES view |
| Bendz | a holistic approach to enterprise development and governance was required | Agree. Systems science; model space; collective actualization space |
| Bendz | poorly reflected notions of systems and architecture hamper the development of both technologies and skills | Agree. Concepts of system, mosaic, world; relation of architecture to internal model |
| Bendz | the way to go about achieving such an increase in the precision and formalism of the use of system concepts is through an ontological approach, ultimately shaping a consensus-based belief-system which would provide a “lingua franca” for systems theorists and practitioners alike | Agree. system and connection concepts; shared understanding as specification; belief system as view or defined world |
| Bendz | there is a suboptimal understanding of the potentially important role of architecture … the core contribution of architecture is the understanding of the fundamental principles of the system … a.k.a the system concerns | Architecture as general internal model; concerns as views |
| Bendz | Incentives | Big factor in (purposeful) complex systems |
| Chroust | One of the keys to a successful systems engineering project is an orderly process to conceptualize, design and build the intended system. This process has to be defined, enacted and often even enforced. | Partially disagree. Agree that certain elements have to be controlled and enforced (e.g., configuration management). But it is important to distinguish between controlled aspects and the actual problem solving (design, engineering…)—which is opportunistic, messy, and disorderly. Keys to problem-solving are allowing the disorderly process and using knowledge of systems and system patterns acquired in a domain (as opposed to knowledge of processes and process patterns beyond the controlled aspects) |
| Chroust | Iterative, opportunistic, incremental; human aspects of process models | Yes, agree: these are more natural problem-solving concepts. But we need to allow them to happen, not prescribe them; the focus is still on the system and system artifacts and patterns |
| Chroust | Formal – exposed inconsistencies | Precise |
| Hybertson | The statement of the problem indicates a belief that a common language would improve systems praxis. Do we assume we need a common language or a common ontology? I suggest we need a common shared set of concepts, and we need to pay some attention to a common ontology as a basis for a common language. | Conceptualization of systems: language, ontology |
| Hybertson | The scope of the common language or ontology benefits from being limited to systems of interest to systems engineering (“SE systems”), not all systems. The field whose province is all systems is general systems science. I suggest the field whose province is all SE systems is SE science. | Scope of MOSES is systems engineering science |
| Hybertson | Position: Our IFSR Theme 4 group activity is supporting Systems Engineering Problem-Solving System (SE PSS, which is Systems praxis) by doing Systems Engineering Science Problem-Solving System (SES PSS) and producing—or at least working towards—a common language or ontology (the SE Science Solution System or SES SS) that is the language/ontology of SE Solution Systems (SE SS). |
The SES PSS and SE PSS occur in the (MOSES) Collective Actualization Space, and the SE SS exists in the model space, solution space, and is ultimately deployed in the problem space. |
| Hybertson | Position: the language we are producing is (or should be) the language of SE solution systems, more than the language of SE PSS (systems praxis). Stated differently, the position is that the best way to help the SE process is not by focusing on (languaging) the SE process, but by focusing on (languaging) what that process produces, i.e., solution systems. | Conceptualization of systems: language, ontology |
| Hybertson | Position: we need to expand from the traditional mechanistic models of solution systems to include the organic models of complex solution systems. The language or ontology that we produce needs to reflect that expansion. | The focus of MOSES is on defining a science that supports this expansion of SE. |
| Hybertson | offer an interrelated collection of concepts and definitions [based substantially on concepts expressed in the book Model- Oriented Systems Engineering Science] that include the following: 1. Core SE concepts in the form of an informal but reasonably precise set of terms and definitions for the language: a. Primary concepts of things: world, system, mosaic, model, region… b. Primary concepts of connections among things: interaction, action, party, activity, service, disservice, effect… 2. Concept of process and its environment: SE world, defined as collective actualization space (position paper Figure 2) 3. Organizing construct for capturing the most important knowledge for systems praxis: multi-dimensional model space of solution systems (Figure 2) 4. Characteristics of solution system models that go beyond mechanistic to organic 5. For those who need some process assistance: Characteristics of SE process models that go beyond mechanistic to organic. |
Core system concepts; Collective actualization space |
| Lawson | one can question what is meant by “language”? Are we talking about an ontology of concepts expressed as terms and relationships? | I have the same question and suggestion |
| Lawson | development of mental models and shared vision is related to the usage of paradigms (defining this as patterns based upon models) that express central concepts | Agree. Mental models and shared vision matches MOSES concept of shared understanding and the relation between model and specification (p.67-70 of book). Paradigm matches MOSES concepts of pattern and defined world |
| Lawson | How are paradigms that relate concepts and principles expressed as models? Models have several forms (textual, mathematical or graphical). Every form of model is an abstraction of some part of portraying reality from a perspective as well indicated in the ISO/IEC 42010 standard. It is this plurality that establishes the basis for discussion and dialogue that leads to understanding (individually and collectively). | Agree. Plurality of perspective matches MOSES concept of view (Chapter 10 of book) |
| Lawson | … the title of this Theme 4 … should be something like: Towards paradigms for improving systems praxis or Towards establishing a shared vision of systems praxis. … focus on multiple, but a small number of paradigms in the form of understandable and applicable system related models | Agree. |
| Lawson | Complexity… | Essential vs accidental complexity |
| Martin J | Since there are an infinite number of variables and constants associated with any one thing or collection of things, then it does not make sense that the “system” is all of these attributes. You must choose which attributes are of interest, which is another way of saying that we have a “system of interest.” | MOSES view: A system of interest to an observer is a system designated, and under consideration, by the observer. There are an infinite number of variables and constants associated with any one thing or collection of things; it makes sense that the “system” is all of these attributes. But most of them we do not know about, or care about. You must choose which attributes are of interest for your system of interest. |
| Martin J | PICARD: parts, interactions, context, actions, relationships, and destiny | These are very similar to MOSES concepts of system and especially connection in Chapter 3. |
| Martin J | 7 samurai–systems: context, intervention, realization, deployed, collaborating, sustainment, competing | Similar to MOSES collective actualization space (problem space, model space, solution space…) |
| Martin J | PMTE: process, methods, tools, environment | Related to MOSES actualization. But MOSES emphasizes system information (common problems, common solutions, patterns, models, conventional designs, body of system knowledge…) over engineering process information. In 7 samurai terms: MOSES emphasizes intervention system (and context system) patterns over realization system. In terms of Hybertson position paper: It emphasizes solution system over problem solving system |
| Martin J | Knowledge pyramid: signals, data, information, knowledge, wisdom | Agree, useful structure for information systems, including solution systems that process information, and describing problem-solving systems such as SE praxis |
| Martin J | “Systems are Imaginary” | Agree in the following sense: Systems may be physical or conceptual; but no system exists inherently as a system. A car, or tree, or atom, or solar system, or company, may exist; but whether any of these is a system is a designation made by an observer or group of observers. |
| Martin J | Metaphors [Mac as toaster; Bud: software circuit (as hardware)] | Story, interpretation, machine vs organism metaphor |
| Martin, R | Two aspects of these [previous] efforts are revealing: 1) none appear to be used by authors or editors of new works to actually reuse definitions across domains with few providing reuse even within domains; and, 2) most terms have several, sometimes conflicting, definitions. Given these observations, why might we expect that an effort to understand “the attributes of a language that most interested parties could adopt and employ … in the system praxis field” may yield substantive results? | Good question. Response: Are the prospects any better if we aim for a set of concepts or an ontology of systems that could be used in system praxis? |
| Martin, R | However, we should be able to focus on those ‘attributes of language’ that do enable more productive communication and yet provide for suitable contextualization of use for specific terms and phrase. Toward that end, we have examined several efforts to formalize expressions of ontology associated with both an “upper level” for use across all domains and domain specific works. | 1. Agree – more focus on concepts and ontology 2. Distinction between general (“upper level”) and domain-specific concepts is important. Suggestion: We need a range of concepts from most general to narrowly defined domain-specific— perhaps a concept pyramid. |
| Martin, R | Process Specification Language (PSL); Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE); ISO 15926 Industrial automation systems and integration; WordNet. … Are these taxonomies already over-specialized for the breadth of the SE domain? Does adding more terms and relations among them move us toward more general application of the terms to SE and SS or toward more specialized use of the terms where selected portions of the taxonomy can be applied to sub-domains? To move toward a Unified Ontology of any kind, we must focus not on the uses of terms common to our discourse but rather we must focus on the qualities we want those terms to bring to that discourse. | Agree. |
| Ring | Praxis prescribes system implementation from Day 1 and continual improvement through Year N. | Both for an individual person, and for a community, improvement [maturation] dominates initially, then adaptation |
| Ring | Praxis prescribes system implementation from Day 1 and continual improvement through Year N. Praxis must provide for continual assessment and adaptation of praxis as knowledge occurs. | Both for an individual person, and for a community, improvement [maturation] dominates initially, then adaptation [evolution] dominates |
| Ring | Praxis must be consistent with the extent, variety and ambiguity of both the problem system and the competencies of those who develop the intervention system. Praxis consists of a fusion of an algorithm and the human activities that execute it. Praxis must foster quality, parsimony and beauty in the resulting system. |
Agree on desired qualities of an intervention system. But those qualities are achieved more by understanding and applying system patterns than by understanding and applying praxis algorithms |
| Ring | Praxis produces errors both obvious and unobvious and unintended consequences. | Agree. But the errors and (negative) unintended consequences can be reduced significantly by understanding and applying system patterns (more than by improving and applying a praxis algorithm) |
| Ring | People are key. The language of praxis will consist of many local dialects whose users are both purposeful and adept at interoperability. | Agree. But again, a language of (intervention) systems is more useful for engineering intervention systems than is a language of praxis. |
| Sillitto | systems science as an objective “science of systems” | Yes, agree. |
| Sillitto | systems thinking as concerned with “understanding systems in a human context” – so ST establishes the “purpose” and “value” that drive systems engineering | Understanding is part of SS; all science is a human activity Establishing purpose is part of SE. |
| Sillitto | systems engineering as “creating, adjusting and configuring systems for a purpose” | Yes, SE – assuming “creating” includes analyzing problem situations, defining capabilities, conducting tradeoffs, modeling, developing/applying architectures… |
| Sillitto | the “correct” choice of system boundary for a particular purpose depends on the property of interest. This choice seems to belong in the domain of “systems thinking” | Deciding the most useful boundary for a designated system of interest is part of SE; not necessarily an issue of “correct” |
| Singer J | gain insight into modeling as an activity that generates knowledge, and into models as the contexts within which knowledge is interpreted and used…. implications for the design and use of modeling tools and knowledge bases | Agree. Matches MOSES concept of model space as capturing and organizing the explicit aspects of a body of knowledge—in our case, the SE and SS body of knowledge |
| Singer M | Caution: “System” can be hyped to where it comes to mean everything; we want to aim for a mature bounded concept/definition | … that is what happened to “architecture”. It is a pattern very much like the Gartner hype cycle. |
| Takaku | Zipf’s law, Pareto Principle: Applying power law distributions to language word usage | This analysis might be of interest in analyzing and comparing different system or praxis languages—for example, to find key terms and how they differ in frequency of use in different communities. But would it be useful if we focus on concepts or ontology more than language? Not sure; the approach seems limited in that it does not address relations between entities (other than frequency order) or context of |
Footnotes
1 D. Hybertson, Model-Oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications, 2009.