INCOSE International Workshop 2015

As every year, the INCOSE International Workshop has taken place end of January. For the second time in a row, the INCOSE community met in Torrance close to Los Angeles. From 24 to 27 January, business meetings and technical working group sessions provided many opportunities to gather information and to contribute to the advance of systems engineering and INCOSE. As usual, even in the days before and after the conference there were plenty of opportunities to meet with other INCOSE members.

Compared with previous International Workshops, my objectives were quite different this year. Not anymore being a representative on the INCOSE Corporate Advisory Board, I was less involved in administrative meetings. Instead I spent more time visiting several working groups on technical matters. I remained indecisive regarding a deeper engagement in any of the working groups I visited.

Indeed, I was looking for particular subjects addressing the application of systems engineering for coping with the global challenges that play such a dominant role in the INCOSE Vision 2025. Since the new INCOSE Vision 2025 has been presented at the INCOSE International Symposium 2014 in Philadelphia, I feel some discomfort with the technocratic view taken: The future contribution of systems engineering on policy is envisaged by enabling better decisions. The advance in systems engineering methods and the outreach of systems engineering in new application domains will strengthen the role of systems engineering in future.

In general, I share this vision. I am convinced that the multi-disciplinary approach taken in systems engineering and the lessons learned from applying systems engineering to the most advanced technical systems are relevant for coping with the global challenges. But I have some doubts with respect to the following two questions: Is the systems engineering community aware enough about the societal, political and economic environments to let systems engineering flourish? And, are the leading systems engineering narratives honouring those environments?

Let us start with the second question first. The response is twofold according to the adage: In theory, theory and practice are the same, in practice, they are not. As far as systems engineering narratives are theory they are based on information flow models. Information flows from a source to one or more sinks unidirectionally. These information models are very powerful. Even in my own publications, the unidirectional flow of information plays an important role for promoting value stream thinking in systems engineering. The paper titled V-Model Views written together with Kevin Forsberg considers the flow of information within a system architecture controlled by configuration baselines. The paper titled Systems Engineering Value Stream Modelling defines the value streams for generating high-quality configuration baselines as work product generation sequences.

The validity of such information flow models in systems engineering depend on the quality of the information that is distributed. The systems engineering community invested a lot in improving requirements engineering for achieving high-quality requirement statements, and sets a lot of hope into model-based systems engineering. However, severe doubts remain, whether systems engineering can be implemented as a pure top-down activity with requirements containing all the information from which technical solutions can be deduced in a one-and-only fashion. Without discussing these doubts further here in general, the limitations of information flow models in systems engineering become at least obvious when considering system interfaces. It is neither practical to define all interface details when an interface is introduced by partitioning a system into system elements. Nor, are all interface characteristics unambiguously deducible from a brief interface requirement. Complementing the two other papers, I have submitted a paper titled System Interface Engineering for this year’s INCOSE International Symposium. This third paper is necessary in order to counteract interpretations of the other two that systems engineering would be best performed top-down managed in a command and control style.

The systems engineering practice is dependent on system context considerations and on feedback, not only for detailing interfaces. Thus, systems engineering value streams have to be executed iteratively to incorporate the lessons learned downstream along the system life cycle. Systems engineering standards and textbooks consider the feed-forward paths much more than the feedback loops. For example, ISO 15288:2008 does not even consider the terms interface or system interface in the definition section. This may not be the most striking example, but there are many more.

In conclusion, the theory of systems engineering is less aware about the everyday challenges that have to be mastered, and are eventually mastered in most programmes in practicing systems engineering. For bringing the systems engineering theory closer to the systems engineering practice, a discussion about the scope of systems engineering is inevitable: What is systems engineering?

Now turning to the first question: Is the systems engineering community aware enough about the societal, political and economic environments to let systems engineering flourish? Since the INCOSE International Symposium 2007 held in San Diego I have some doubts. There, Pao Chuen Lui from the Singaporean Ministry of Defence talked about “Singapore: An Example of a Large Scale System”. Yes, the keynote was really impressive. Even more impressive was the personal experience two years later at the INCOSE International Symposium 2009 that took place in Singapore itself. At the end of the conference in Singapore, I joined the technical tour on water management. The comprehensive considerations for ensuring the continued supply of drinking water after the foreseeable expiration of long-lasting supply contracts with Malaysia were impressive. The generation of drinking water from salt and waste water was evenly remarkable as the water reservoirs for storing drinking water, especially the Marina Bay converted to a freshwater resource and used for flood control. The replacement of older sewage treatment plants by two new closed system sewage treatment plants with integrated drinking water recycling at both ends of a new main underground sewage channel provided evidence for the integrated planning approach applied by the Singaporean government.

When I asked a young member of the Singaporean delegation in San Diego after the keynote, whether he thinks that what has been proven successful in Singapore could also work on a larger scale, for example by systems-engineering China, the answer was yes. I do not know how many systems engineers would give a similar response, but the INCOSE Vision 2025 is written in a rather optimistic fashion, not bothering about the additional challenges when trying to apply the Singaporean model on a global scale.

My doubts are based on two considerations. The first one is caused by the systems engineering theory, the second by own personal experience in critical situations. The decomposition of a system into system elements is an unchallenged axiomatic principle of systems engineering. But is it possible to describe the social, economic and political reality of a large industrialised country by a single system architecture? I would say no, as a network topology provides a more adequate model of a modern society than a hierarchical architecture. If this is accepted, the role of systems engineering in society needs more elaboration.

History provides ample evidence of catastrophic failures of planned economies with centralised decision making and hierarchically managed implementation of decisions. The planning authorities never understood the consequences of their decisions completely as they were far away from the places and communities that had to deal with the consequences of their decisions. The famines at least partly caused by the collectivisation in the Soviet Union or decades later in China by the great leap forward provide some hints regarding the limits of systems engineering as it is recorded and taught today.

It is part of the heritage of systems engineering that it emerged in democratic and pluralistic societies. When systems engineering was initially applied in aerospace and nuclear technology applications, the innovation challenge was high and the value generation depth was remarkable. Thus, central control played an important role to make things happen. Nevertheless, those programmes applying systems engineering relied also heavily on the environment of a market driven economy. The market provided many existing technologies and products that the sophisticated systems-engineered products exploited.

The conventions of the societal discourse play a similarly important role, maybe even a more essential one. I do not believe that nobody in the planning bureaucracies of the Soviet Union or of China was aware about the catastrophic consequences of the decisions of the central planning authorities. But speaking up was dangerous.

Even in open and pluralistic societies, taking dissenting opinions comes with some social costs. Usually, it is much easier to comply with the majority view. Several times I was exposed to situations asking myself, whether I might be the fool lacking the wider understanding of the other people and organisations around me, or not. Only reliance on rational processing of all issues without being banned in any way ensures that problems are brought up on the table and may be tackled successfully. This includes to find the problems that need to be found, to understand those problems, to scope them, to generate alternative solutions and to make the appropriate decisions. Especially, problem finding is in many cases an important individual creative achievement, and it may take time before others start to understand the relevance of a newly detected problem.

Requesting from systems engineers some soft skills, e.g. social skills, in addition to the hard skills of the systems engineering processes and methods, falls short to cope with the dependence of practical systems engineering process definitions from psychological considerations. Those considerations are dealt with in systems engineering in a heuristic manner instead of systematically considering findings from the different fields of the social sciences.

Traditionally, systems thinking is intended to fill the gap. But systems thinking appears often more as the esoteric branch of systems engineering. Sometimes I cannot close the gap between systems thinking and systems engineering. Instead I see a lot of contradictions of promoting wholeness on one hand side with the piecemeal definition of systems engineering methods on the other.

At the INCOSE International Workshop I have got the impression that there are other INCOSE members with similar concerns, but this has obviously little impact on the directions INCOSE is actually taking. At the same time in Torrance, I learned from Sven-Olaf Schulze, the president of GfSE, that my proposal to start a working group in the German Chapter on investigating the relationship between systems engineering and market driven economies found no followers for attending a corresponding meeting at the upcoming GfSE Workshop. This was not raising my mood either.