Reflections on the INCOSE International Symposium 2021

Reflections on the INCOSE International Symposium 2021

I have a saying, “The two best ways of spending a week on systems engineering are firstly to participate in PPI’s 5-day systems engineering class, and secondly, to attend (is that still the right word?) the annual INCOSE International Symposium (IS)”. My participation in the IS over July 19-22, 2021 has not changed that view. The symposium, delivered virtually to 741 registrants from all corners of the world, was excellent!

Some trends identified in topics of papers and panels were:

  • a further shift towards inclusion in the application of SE the engineering of socio-technical and social systems
  • realization of economies through Product Line Engineering (PLE) techniques
  • realization of the digital thread
  • the application of AI, both in terms of impacts on SE principles and methods, and also application of AI to SE.

Some very good sessions were attended related to these and other topics.

The most rewarding IS session I attended was that on the path from SysML 1.7 to SysML 2.0. The panel dealt thoroughly with how much better in a myriad of ways SysML 2.0 will be compared with SysML 1.7 – a game-changer. SysML 2.0 is coming along nicely and is scheduled to be submitted to the OMG in September 2021, with formal release likely to be early in 2023. A prototype tool exists and is being used for language validation; predictions are that commercial tool support will mature over 2023 to 2025.

An interesting panel “To Vee or not to Vee”, involved a debate on the usefulness of the Vee model. Unfortunately, however, the debate took place without defining which Vee model. The original Vee model as invented by NASA in the 1960s, repeated by Rook in 1979, then adapted to the double Vee by Fosberg and Mooz was subsequently subjected to some elaborations (for example, the German Vee model) and many mutations. The actual Vee model is not a process model at all except for its verification content, and it certainly isn’t a lifecycle model, nor was it ever intended to be. Unfortunately, the attempts to morph the Vee into a process model, producing what I have described as mutations, were behind the points of debate without the debaters acknowledging so. Iteration, stakeholder interaction, and timing relationships were concerns with the Vee expressed in the debate. These concerns are all dealt with in my Wedge Model, which applies to any development process, including agile, whilst maintaining the purity of purpose of the Vee.

The official theme of the conference was “Accelerating through Adversity”.?A more general theme that was evident throughout was recognition of the exponential increase in the complexity of systems, including socio-technical and social systems incorporating widespread interconnection to form even bigger systems, and the need to accommodate this increase in?complexity in our approaches to engineering. Whilst sharing this view, I left the INCOSE IS frustrated that the bigger problem remains that we continue to graduate engineers without even the most basic of engineering understandings, for example – that design?creates requirements on solution elements, how to write a decent requirement, how to carry out a trade-off study, the difference between control flow and item flow in functional modeling, and why they all matter.

I would describe today’s?engineering as pinnacles of excellence in?a sea of mediocrity. Those pinnacles?of excellence are the organizations and projects that are practicing systems?engineering well, not as a mindless rule book, a one-size-fits-all process, but?as a set of mainly heuristic principles and a set of process tools that are?used selectively, driven by value.??

The sea of mediocrity?to which I refer is populated by graduate engineers with education and work?experience devoid of systems engineering principles and tools. That malaise is changing, but at nowhere near the needed rate.

Preaching systems?engineering at?an INCOSE conference is preaching to the choir. But beyond the?choir are 15 million other engineers who would deliver much better results by using?systems engineering principles, heuristics,?and process tools in their work. It?is not that we don’t produce valuable products, we do, but the difference between?“what is” and “what could be” is huge. Compelling evidence of my assertion?lies?in the landmark 2012 SEI study (Elm) on the value of systems engineering, and in many?other studies. Look out for some papers in PPI SyEN on this topic soon.

Another frustration of the IS was the ongoing preoccupation with “systems engineers” rather than “systems engineering”. I rarely use the term “systems?engineer”, not because there is anything inherently wrong with the term, but because I see little reason to do so. To me, systems engineering is?an integral part of the discipline of engineering, to be practiced by all engineers.?Supporting this view is a study I carried out, looking at the set of SE?principles defined by the INCOSE Principles Action Team, which have a?scientific orientation, and my own set of SE?principles having a heuristic?orientation. For both sets of principles, there was clear, consistent?application to the engineering of large socio-technical systems such as the?country of Singapore,?complex technology items such as aircraft, simple?technology items such as an electric jug, software of any size, and even to?non-systems, unitary engineered products such as most coins.?Regarding?non-systems, only logical design did not apply.

I?see the greatest opportunity for improvement in engineering outcomes arises not?from system?science or complexity theory or digital engineering information?exchange, but from engineers,?junior and senior, understanding and applying the?foundation principles of systems engineering.?Of course, we would like to have all of these simultaneously, but if we must prioritize, competencies must come first.?It is not that we don’t produce valuable?products,?we do, but the difference between “what is” and “what could and?should be” is huge.

I also concluded that the battle to distinguish between System of Systems (literal interpretation) and System of Systems (system of autonomously managed systems) has been lost. The victim of an incredibly unwise use of language in the first?place. About 95% of references to System of Systems at the IS had the literal intent, not the intent of a system comprising subsystems, each of which possesses the additional properties:

(a) Operational Independence of the subsystems: If the system-of-systems is disassembled into its component subsystems the component subsystems must be able to usefully operate independently.?That is, the subsystems serve user purposes on their own.

(b) Managerial Independence of the subsystems: The component systems not only can operate independently, they do operate and are used independently. The component subsystems are separately acquired?and managed and maintain a continuing operational existence independent of the system-of-systems.?(after Maier 1998)

Other news and views from the IS 2021 are in this edition and more will appear in the September and October editions of PPI SyEN.

Regards to all who are trying to make the world a better place through better?problem definition?and better?problem solving?using a systems approach.

Nikhil Joshi

Researcher - Systems Engineering Expert, MBSE, Agent Based Modeling, System Dynamics, New product development

3 年

Nice article... Agree on the confusion on "System of Systems" usage. I think the "control flow" idea also conflicts with what people know in control systems as control signals. "ConOps" and "OpsCon" also cause quite a debate sometimes.

要查看或添加评论,请登录

Robert Halligan的更多文章

  • Integrating PM and SE: Summary of Articles Originally

    Integrating PM and SE: Summary of Articles Originally

    SyEN 54 – June 21, 2017 Main challenge of the book: how to successfully bring together two established and valued…

    7 条评论
  • Form Follows Function - A Gem of Wisdom?

    Form Follows Function - A Gem of Wisdom?

    Often I hear professionals from various technology and application domains and of different experience levels…

    6 条评论
  • Making sense of the OCD, CONUSE, OpsCon, CONOPS alphabet soup

    Making sense of the OCD, CONUSE, OpsCon, CONOPS alphabet soup

    Making sense of the OCD, CONUSE, OpsCon, CONOPS alphabet soup Understandably, a great deal of uncertainty and confusion…

    5 条评论
  • Avoiding Unintended Interactions Between Elements of a System Solution

    Avoiding Unintended Interactions Between Elements of a System Solution

    A client this week asked me a question along the following lines (I’ve edited the question a little to protect the…

    7 条评论
  • What is Systems Engineering?

    What is Systems Engineering?

    I am often asked “what is systems engineering?”. My detailed reply if called for is along the lines: Systems…

    75 条评论
  • Why should risk never be weighted?

    Why should risk never be weighted?

    In engineering and in life, level of risk often differs between solution alternatives, so we need to factor risk into…

    5 条评论
  • Reflections on the INCOSE IW2021

    Reflections on the INCOSE IW2021

    By any criteria, the INCOSE International Workshop 2021 (IW), delivered virtually, was a great success for the 689…

    6 条评论
  • Systems Engineers or Systems Engineering, Part 2

    Systems Engineers or Systems Engineering, Part 2

    In June 2020 I posted a brief article questioning the distinction between systems engineers and other engineers. In…

    23 条评论
  • Q&A From my Webinar: V&V and the Wedge Model(TM)

    Q&A From my Webinar: V&V and the Wedge Model(TM)

    Q1? Are there legitimate opportunities to use Model-Based Systems Engineering (MBSE) to reduce the Verification &…

    7 条评论
  • VOC is Great! QFD is not!

    VOC is Great! QFD is not!

    A client asked me during the week why I do not advocate the use of Quality Function Deployment (QFD). I feel the answer…

    4 条评论

社区洞察

其他会员也浏览了