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.