INCOSE International Symposium 2015

Twenty five years ago, Brian Mar, then professor at the University of Washington, invited a number of like-minded people to Seattle. Around thirty of them followed his invitation. This marked the official beginning of INCOSE that initially named itself the National Council on Systems Engineering (NCOSE) before it became the International Council on System Engineering five years later in 1995.

For the 25th anniversary, INCOSE returned to Seattle. From 13 to 17 July, the INCOSE community met in Bellevue to celebrate the anniversary at the INCOSE International Symposium 2015. The conference showed a lot of the usual systems engineering business with tutorials, paper presentations, an exhibition, and social gatherings.

Traditionally, various INCOSE awards are presented during the International Symposium. This year, two well-known GfSE members have got Service Awards. Rüdiger Kaffenberger who has been the GfSE treasurer since the foundation of the GfSE in 1997 was awarded due to his many contributions to GfSE. Martin Geisreiter received a Service Award for his contributions to the GfSE certification programme, and systems engineering standards. It was a pleasure to support their applications as both have deserved it. Another Service Award was received by Kevin Forsberg as he continued to be an author of the INCOSE Systems Engineering Handbook. Version 4 has been released to the public during the conference.

From the new INCOSE fellows appointed, I would like to mention three with whom I have or had a closer personal contact. Peter Brook from UK is a new fellow. I had the pleasure to work with him together when we were both lecturers of the NATO Lecture Series on Systems-of-Systems for NATO Defence Applications earlier this year. When Bohdan Oppenheim was co-chairing the INCOSE Lean Systems Engineering Working Group, he had always open ears for my comments and remarks. Finally, I would like to mention Ernst Fricke as new INCOSE Fellow who is another founding member of GfSE.

One of my good INCOSE friends claimed that nothing really new has been presented. To some extent this is not unusual for someone heavily involved for so long. To advance systems engineering you fight day by day without seeing a lot of progress. But when you widen the focus from a daily, weekly or monthly perspective to several years, some advances become apparent. For example, over the last ten years the hype about model-based systems engineering has changed from something that has been claimed a real paradigm shift in systems engineering to something that in principle has not been so new at all. Just the advances in modelling methods and corresponding tools provide opportunities for efficiency improvements.

On the other hand, there are a lot of reasons to share the view: INCOSE is somewhat reluctant to review existing systems engineering assets. Why to put things that make you strong under scrutiny again when you become more and more successful? The opening address of David Long and the presentations of some of the keynote speakers provide some insights into the current state of systems engineering at the INCOSE level. In the following paragraphs I describe my perception and interpretation. To make up your own mind, you are invited to view and to listen to the presentations that are all retrievable via Youtube.

David Long titled his keynote Building for Tomorrow: Towards 21st Century Systems Engineering. When I first entered the international scene of INCOSE in 2014, Heinz Stoewer challenged the INCOSE community for industrial outreach, going beyond the traditional systems engineering application domains of aerospace and defence. Since then, no other INCOSE president was as challenging as David now, requesting a further transformation of systems engineering.

Outlining the history of systems engineering with roots in electro-mechanical systems over the software-centric systems of today, the future challenge lies in the domain of cyber-physical systems. For evaluating the readiness of systems engineering to cope with the challenges of the future, David identified the systems engineering pain points comprehensively. Overall, he did it in a gentle way avoiding to hurt anybody. Most interesting was the criticism of systems engineering terminology. But then the reasoning took some pathways where I added some reservations to my consent. When talking about the need for improved communication, analysis and learning, he introduced the need for a systems engineering ontology and a corresponding theory of systems engineering. So far so good, but then he puts this out of reach for the foreseeable future and demands that an Einstein of systems engineering would be needed to achieve that. Later in his talk, he blamed western education to drive systems thinking out of people in favour of rather specialised knowledge. Thus, systems engineers appear as a weird group of people. He closed his opening address with defining the purpose of systems engineering as fulfilling customer and stakeholder needs in the most efficient and effective way possible.

Regarding my first concern, the presentation of Linda Katehi introduced the law of reachable optimality. Her keynote The Importance of a Systems Approach followed directly after David Long’s opening address. Linda Katehi is Chancellor of the University of California, Davis. She discussed many aspects regarding the law of reachable optimality in detail. The wording of the law itself indicates why this could be taken as an advice to the systems engineering community.

I do not think that an Einstein of systems engineering is needed to overcome some misconceptions and shortfalls in systems engineering. A good example is the term stakeholder need that seems so essential for understanding the purpose of systems engineering according to David Long’s speech. There is no clear definition what a stakeholder need is. Even the newest version of ISO 15288 does not contain a definition in the definition section. Instead, the practice of using the terms stakeholder need and stakeholder requirement synonymously has not been fully abandoned in systems engineering standards and textbooks. It does not need an Einstein to tackle issues like that. A self-critical review of the traditional systems engineering narratives would be sufficient.

By the way, like David I have some reservations against ontologies in general, and especially when applied to systems engineering. A perfect ontology would be something static. In contrast, languages are evolving continuously. Old terms and semantical expressions become out of fashion. The understanding of existing terms and semantics is changing reflecting new knowledge and experience. And, new terms and semantics are defined over time expressing new knowledge and experience. Furthermore, there is more than one language with no single language to claim precedence over others in all aspects of life. From semiotics, systems engineers may take over the insight that translations between different languages force the further evolution of individual languages (see for example Yuri Lotman: On the Semiosphere). Isn’t that indeed what describes the role of the systems engineer in multidisciplinary systems engineering in more general terms?

The second concern about specialisation instead of understanding wholes is not just a result of western education. The dualism of the human cognitive capabilities to perceive wholes on one hand, and specialisation on the other is as external as internal to systems engineering. That the generation of knowledge means to go into details and to make new distinctions, is a basic principle in the evolution of languages. In turn, that only setting terms into their context generates meaning, is valid in systems engineering as in any other aspect of life. Thus, it is a challenge for every human in any discipline. Of course, systems engineering has to concentrate on this dualism in especially. On one hand, systems engineering is a specialty discipline on its own with specific terms and semantics. On the other hand, systems engineering subordinates all technical solutions to superordinated purposes.

When systems thinking is traced back to Aristotle’s Metaphysics, the dualism that the Whole as well as each Part it consists of may be interpreted as a One is built in into systems engineering. The reference to the popular adage The whole is more than the sum of its parts is originated by this dualism. Please, note that there is no evidence that Aristotle has ever used these words, and not only in the sense that he has not spoken English.

On Tuesday, the keynote speaker was Jan Bosch from Sweden. Having a background in software engineering he painted a software-centric future. His presentation is titled From Opinion to Facts: Building Products Customers Actually Use. He identified the following key take-away points by himself:

• Innovating new systems, solutions and services at an unprecedented rate is critical for survival – this requires speed in systems engineering
• Embracing data-driven (instead of opinion-based) decision making decision making accelerates innovation
• Systems engineering needs to shift focus from “built to last” to “built to evolve”

The speed of Jan Bosch’s talk was as impressive as the cascade of arguments. One day later, Ronny McKenzie draw his conclusions in his own keynote and earned some laughter from the audience. This provides already some hints about the controversial reception of Jan Bosch’s keynote. According to my understanding, Jan Bosch demanded from systems engineering solutions for a market-opportunistic approach when he asked at the end of his presentation: “Who is going to make it a reality in the systems engineering community?” According to my interpretation of his appeal, I think he is right to demand solutions from the systems engineering community how to behave in saturated markets – like in automotive - where some basic technologies are at hand and could be employed for product differentiation. Systems engineering provides indeed little guidance only for transferring the knowledge and experience gained from traditional systems engineering applications to scenarios like this.

His understanding of systems engineering remained somewhat vague. Only, when he challenged the belief in taking requirements as the Archimedean points in systems engineering he referred in more detail to systems engineering principles and methods. His view of taking requirements more as hypotheses for which the validity has to be proven in the course of development gets my full support.

However, his arguments were mainly based on some stereotypes that gained some popularity today, and were, for good reasons, perceived by many systems engineers with some reservations, including me. His reasoning consisted of some piecemeal considerations that were sometimes contradictory to each other, and sometimes less convincing than claimed. In the following, I focus on a number of issues that played an essential role in Jan Bosch’s reasoning. These considerations do not claim to follow the exact sequence of the speech, to use the same terminology, or to be complete.

In the introduction, he presented a statistic that only a smaller number of software-provided functionality is actually used by the majority of customers. In turn, forty five percent of features and functions are never used according to a Standish Group Report from 2002. Indeed this is not surprising to happen in the absence of a sound understanding of systems engineering. Software engineers tend to assume that we would live in a better world, if all people would behave like software technology geeks. What software engineering should learn from systems engineering is to start with an operational analysis of the customer needs. Of course, this may lead to a number of painful insights. Most customers do not want to be the A and B testers of the products they use, and they do not want to be surprised by undemanded new features and functions every morning they start their cars.

Over several decades, I have observed that engineers, mostly software engineers, who are committed to entrepreneurship have difficulties to accept these facts. Once, I tried to bring the precedence of operational needs over technological capabilities closer to engineers from the automotive industry. Fly-by-Wire did not evolve due to some technological advances. Instead, the operational needs demanded fly-by-wire, and then investments in maturing the appropriate technologies were done. After the talk, I had neither the impression that the majority of the audience had been interested in the message, nor that it would have made a lot of impact on those recognising such a strange idea.

Rather popular today is the propagation of the transition from personal product ownership to a sharing economy. In the traditional systems engineering application domains, service-oriented customer/supplier relationships have developed primarily for aircraft equipment. With the advent of airlines with limited own maintenance capabilities, service contracts with suppliers freed the airlines from considering the number of spares, the logistics for deploying the spares where they are needed, and a number of further related issues. This drove the supplier industry into the direction of achieving system life cycle efficiency in reality.

Before, the industrial maintenance and repair had generated extra profit on the suppliers’ side. Now, suppliers have to consider the impact of both in conjunction: the development effort spent initially and the maintenance effort to be spent later, not at least as a function of the previous development effort. Thus, this created a win-win situation. The airlines do have to bother less on technical aircraft issues, and internal conflicts of interests within supplier organisations had to be resolved, making the suppliers more efficient and more competitive eventually.

I have some doubts that this particular solution could be really a blueprint in all other product areas relying on procuring services instead of products. In the airline and aircraft industry, the whole aircraft life cycle is highly regulated: The aircraft are operated and maintained according to world-wide unique standards. Aircraft equipment suppliers are well aware of these standards. Thus, the knowledge and awareness of the needs along the complete system life cycle is widely present in the equipment supplier organisations. And, the confidence that all stakeholders operate according to their operating procedures is justified by the discipline all stakeholders have to commit to.

The advocates of a sharing economy propagate the transfer of service-oriented business-to-business relations to the business-to-consumer sector. If you do not have the budget to invest in product ownership, renting the product is an alternative. For business-to-business relations, this provides every enterprise with opportunities to leverage their capital concentrating on spending their own money on their own product portfolio. On the consumers’ side, sharing is a constant feature in any society. Even in industrialised countries, sharing has ever been a solution for young and less wealthy people to mutually satisfy more of their needs without overstressing their personal income. Who will profit more when sharing is extended to business-to-consumer relations applying business-to-business rules, is not an open question.

However, there are further reasons for consumers to prefer renting a service instead of owning the product providing the service. In general, the comfort not to bother with the potential adverse impacts of ownership is a major motivation. For example, car sharing is an alternative preferable to many people living in cities with a shortage of parking spaces and annoying parking management rules. However, outside dense populated cities ownership still provides a favourable level of comfort. The reason is not only that service deployment is less comfortable and more expensive. Car ownership provides the advantage of acting in an accustomed environment. The perceptions regarding all our senses demand less cognitive activity, especially in the area of thinking consciously about many perceptions in detail. This reasoning is not valid only for sharing cars, but of general importance. Therefore, I have doubts that service orientation in business-to-consumer relations will succeed whenever product ownership provides the same service for competitive costs.

There are even more subtle reasons why particular industries foster service deliveries over selling products. More and more general purpose software tools are marketed as services: Adobe started it with the Creative Suite. Microsoft and others now try the same way to convert their customers to license the software for a monthly or yearly rate instead of buying a license valid for an unlimited period of time – but actually limited by the end of support of the tool itself, or of the necessary underlying hardware and software operating environment. For the customers, some advantages result. Being provided with continuous updates is one. But on the other hand, the customer has less control over the update process. Personally, my experience is mixed. The advantages are fine, but sometimes the updated versions show behaviours that surprise me, and sometimes I have to wait for further updates before a bug is corrected. If a feature or function is affected that I use regularly, this is an annoying experience. Unfortunately, the license terms exclude to be refunded for the stress, additional effort, and delays caused by the imperfections of immature updates.

Overall, I have got the impression that customers have some advantages, but also some major disadvantages. For industry, the advantages clearly prevail:

• No older software configurations have to be maintained anymore.
• A lack of configuration management capabilities in order to maintain multiple older configurations and variants of fielded products has not to be resolved.
• Where applied, monthly or yearly payment rates makes the flow of income more predictable.
• And finally, opportunities open up to undermine the laws protecting consumer rights related exclusively to product ownership.

The need for speed in systems engineering is the first key take-away point Jan Bosch has mentioned. Reduced market penetration cycles would demand a need for speed. Customers would like to see continuous improvement of the services provided to them. In a numeric example he then claims that spending ten percent for development efficiency improvement may pay off less than a ten percent reduction in cycle time. According to the example, a reduction of cycle time leads to additional revenues. Consequently, the choice would be between ten million dollar in development cost reduction and hundred million dollar additional revenues.

I have to admit that I was not able to follow the reasoning in all aspects when I tried putting the different pieces together in context. Predominantly, market penetration cycles are considered with the evolution of major technologies requiring some technology innovation depth. But the further reasoning concentrates on continuous improvement of existing features and functions. To my understanding, this is more related to the exploitation of existing technologies in order to satisfy stakeholder needs even better. Both scenarios deviate from each other significantly, and demand quite different development approaches based on the same systems engineering principles.

The numerical example about additional revenues by reducing the time-to-market is less convincing as the stated numbers would suggest. At first, the resulting figures are not directly comparable. Second, I have no idea what the term development efficiency improvement is standing for. To my experience, any successful development efficiency improvement contributes to a reduction of the development cycle duration as well. As a rule of thumb, the development budget spending is proportional to the product of the number of development engineers employed multiplied by the development duration. Theoretically, reducing the number of engineers could have an impact on the development effort without impacting the duration. My experience is that a reduction of engineers has also an impact on the cycle time, not at least due to simplifying the communication between the engineers involved. The only what I admit is that sometimes development process changes fail to lead to any improvement measurable in terms of time and budget savings at all. Third, I have not understood why a continuous improvement of a service leads necessarily to an increase of revenues. When provided as an update for no fee, it may not generate any additional revenues at all. Or, it just may replace an older product that is not at the end of its life-cycle yet. This would not lead to significant additional revenues either. Or, in cut-throat competition, improvements may just be needed to maintain the current market share. Only in case of a growing market, additional revenues will materialise for the company being the first on the market with innovative features and functions. I have some doubts that this describes the current status of the automotive industry in general as implied by the presentation.

I was impressed and concerned concurrently when Jan Bosch claimed that in a software update cycle of one to five days all verification and validation activities are included. My concerns were related to the impression that Jan Bosch’s understanding of verification and validation may differ from my understanding gained during the long years I dealt with safety critical and high-integrity technical systems. Nevertheless, having integrated continuous unit testing, and maybe low level integration testing, into the software development on such a large organisational scale is a remarkable achievement. But I am not convinced that the verification and validation activities performed in these time scales really cover the full scope of mutual impacts with all other product features and functions, the search for unintended functions, and the evaluation of the impact on the distribution of the driver’s attention.

For integrating customers as A and B testers into the development process, or for continuous experimentation with customers, I feel no sympathy at all. For good reasons, there is no disclaimer within the European regulations on product liability and product safety and corresponding national laws that product features and functions implemented by software would not fall under the paragraphs of these laws.

Regarding the second key take-away point, acting data-driven instead of opinion-based decision making are less clearly distinguishable alternatives as it sounds. To gain information out of the data, it has to be defined what sort of information should be searched for. Like the blamed opinion-based decision making, data mining performed according to self-defined objectives of the software engineer does not solve the issue of understanding stakeholder needs better. It just proves whether a prejudice of the software engineer finds some supportive evidence in the data, or not. There is no work-around to the good old systems engineering principle of understanding the stakeholder domains and the stakeholder needs first. For avoiding the effort of communicating with stakeholders upfront, it is a poor argument to claim that stakeholders are unaware about all their needs. It is the purpose of the communication process to identify stakeholder needs for which innovative solutions may be possible satisfying the need for the first time at all, or in a better way than before. To designate the communication process as part of the feedback resulting from experimentation with customers as described by Jan Bosch is no good replacement for the upfront communication either. First, it is bounded already to the feature or function proposed by the software engineer. Second, it does not comply with the legal situation as discussed above. A company delivering immature products to their customers accepts rather high risks due to dependencies from the future evolution of interpreting the laws.

Some further content of Jan Bosch’s presentation irritated me as no substantial points are added to the main arguments. First, what was the reminder on the exponential growth of the lines of embedded code good for? To my interpretation this is partly an indicator for inventing features and functions that do not really correspond to stakeholder needs. Second, I cannot fully agree to the view that software is the differentiating factor, and the physical product is even losing its value as a commodity over time. There are differences in the physical designs of a car that influence customers' decisions indeed. According to the existing legislation regarding the business-to-customer relations, a customer has not to specify basic needs as they can be taken for granted. Thus, an impression may arise that the details of the iPhone integration into the car’s comfort electronics would be more important to the customer than the transport function of a car. If there would be issues with the delivered car to drive on European roads due to a large turn radius, the favourable characteristics of the comfort electronics would not outweigh the dissatisfaction with an unusable car. Third, the fact that innovation cycles of software are remarkably smaller than the car platform life cycles does not mean that all innovation comes out of software, or that software drives innovation in general.

Ronnie McKenzie delivered his keynote System Modelling of South Africa’s Water Resources with an even increased sense of humour compared to his presentation at the EMEA Systems Engineering Conference in Cape Town last year. I really recommend to view the video. Unfortunately, he spent less time on the explanation of dynamic programming that was so splendid before. At the closing plenary, Rieks Jager talked about the Challenges on Chajnator. Was it because I was a little bit tired from the conference already, I remind only two things from his keynote. Traditional systems engineering is still interesting and may become challenging. And, the Atacama Desert must be a real dry place.

To the conference programme I contributed a paper titled System Interface Engineering. This paper complements two others, V-Model Views and Systems Engineering Value Stream Modelling. This third paper clarifies that systems engineering is not just a deductive exercise managed best in a command and control fashion. I have got some interesting reactions from the audience, but nothing that goes beyond the content of the paper itself.

I would like to conclude with a scene from the panel discussion titled The Direction of Systems Engineering: Ten Years from Now moderated by David Long. When a comment was made that it would be so hard to answer the why questions of systems engineering, I complemented the sentence in my mind with the association: That is true, especially if you have mainly responses to the what and how questions of systems engineering at hand.