The presentation may be downloaded by clicking the PDF navigation button on the top or bottom of this page. The content of this page contains a prose version that is an extended transcript of the presentation. It follows the flow of thoughts as outlined by the presentation slides and contains all figures shown on the slides.
A good theory captures a domain to provide reasonable explanations, and to allow reliable predictions. A good theory satisfies the principle There is nothing more practical than a good theory. The philosopher Immanuel Kant is cited as the first who have stated this sentence. Others followed. For example, Kurt Levin ‒ Gestalt psychologist and a founding figure of social psychology ‒ has emphasised it over and over again. Thus, I feel to be in good company. However, I like to amend Nothing is worse than taking an inappropriate theory for guidance. Someone who is an expert in hammers and nails may make little use of a screw, even when trying the best by developing new hammering techniques and hammers for improving the outcome.
Formalisation of a theory leads to definitions, basic laws, and derived laws. The term law is most appropriate in the natural sciences. In mathematics axioms and theorems are synonyms for basic laws, and derived laws respectively. As systems engineering means to engineer systems for people by people social aspects are important. For this reason, basic and extended narratives may be a reasonable substitute.
To become culturally effective, a good theory needs to be teachable and learnable. That does not only mean that a theory is convincing by itself. The theory must also be relevant to the recipients. Not just an open mind is needed for the acceptance of novel or improved theories. They need a mind that is prepared.
Based on these criteria, the question is, what makes up a good theory of systems engineering? In a first step, we will evaluate the current status of systems engineering as a theory and examine to what extent the current body of knowledge of systems engineering already satisfies the criteria above. In a second step, we will identify the elements of a good theory of systems engineering, identifying especially the scope of systems engineering, and the basic narratives of systems engineering from which extended narratives may be derived.
All reasoning is well-grounded in science because most engineers are educated scientifically. They have the right to expect a theory of systems engineering not derived just from heuristics, but well grounded in scientific thinking. For this reason, the presentation includes two excursions in addition to the two steps defined above. The first excursion concentrates on a brief review of the philosophy of science for clarifying to what extent engineers and natural scientists have a prepared mind for understanding and adopting systems engineering.
A second excursion is concerned with a model of semantic memory. Semantic memory is of interest for two reasons. First, semantic memory is of paramount importance in perception, decision making, and action. Second, semantic memory plays an essential role in learning. In the course of this presentation, the second aspect justifies the excursion on semantic memory.
In this section, the quality of systems engineering as a theory is evaluated. The evaluation is guided by the criteria identified in the introductory section above for characterizing a good theory. In particular, we start with the discussion of the domain to which systems engineering is applied. Then, the quality of explanations, predictions, and definitions are investigated on an exemplary basis. Finally, teachability and learnability of systems engineering are considered.
Please, note, the discussion focusses here on systems engineering as a whole. The manifold detailed theories on systems engineering processes and methods are of secondary importance. They remain out of scope within this presentation. It is the role of a good theory of systems engineering to establish a sound framework as a prerequisite for further analyses of the quality of individual systems engineering processes and methods.
The origins of systems engineering go back to the time after World War II. Among all other evolving system oriented disciplines ‒ like operations research, or sociological system theory ‒ systems engineering became concerned with product development, and later also service development.
In the early decades, systems engineering was less applied in general product development explicitly. Systems engineering evolved in large complex and innovative governmental programs, most prominently in aerospace and nuclear technologies. These products were developed on demand. Coordination of the concurrent development of advanced products and supporting new technologies followed a planned economy approach.
The government operated as the customer and as global stakeholder in multiple roles. Due to the nature of the products, governments were involved over the complete product life cycle. As the tax payer has to bear all costs finally, the demand for optimizing costs over the whole system life cycle was a reasonable step. Systems engineering became a necessity to address the challenges regarding stakeholder orientation capturing the complete system life cycle, and multi-disciplinary engineering.
The success of aerospace and defense programs generated an industrial base for advanced technologies ‒ most notably sensor technologies, electronics including microelectronics, and information technology. The aerospace and defense sectors lost their exclusive role as applicants of these technologies since these technologies became affordable for many other applications as well.
With some delay, the demand for systems engineering followed to master the challenges of multi-disciplinary engineering. In parallel, the increasing perception of the limitations of our biosphere regarding natural resources and environmental pollution tolerance led to a growing demand for balancing multiple stakeholder needs.
In this context, it is not surprising that INCOSE and many national chapters have been founded in the 1990s. Systems engineering knowledge had to leave the military environment with its specific needs and habits to keep information and know-how undisclosed. INCOSE took the mission to disseminate systems engineering knowledge. Thereby, INCOSE positioned itself predominantly as the guardian of the inherited systems engineering orthodoxy.
INCOSE started to promote industrial outreach programmatically since 2004. However, INCOSE did not change the attitude to favor planned economic approaches. The wider range of business models in a market economy was not really perceived. The codification of systems engineering continues to concentrate on on-demand development models with little considerations on more market-opportunistic behaviors. In consequence, systems engineering fosters a management by command and control style. The challenges imposed by pluralism and open societies are widely externalized in stakeholder concepts. Worrisome is the failure to value and to exploit the opportunities arising from pluralism and open societies in performing systems engineering itself.
In conclusion, the context in which systems engineering is applied today deviates from the domain considered by the codification of systems engineering. Striving for a good theory of systems engineering, the demands arising from the full spectrum of business models in a market economy need to be considered comprehensively.
Systems engineering is especially employed for explanation before a project is commenced, and in case of project crisis or failure. In the first case, the systems engineering processes have to be defined. Following just systems engineering standards and textbooks, some common weaknesses are inherited in addition to all the great stuff to be learnt from systems engineering standards and textbooks. The most predominant weaknesses comprise the deficient guidance regarding system interface engineering, and regarding the linkage between the left leg and the right leg of the V. In consequence, project success is sometimes more surprising than project failure.
In the latter case, two causes are usually identified among others explaining project mishap or failure. Late requirement changes are observed, and subsequent system life cycle phases have been entered with immature inputs. If systems engineering would be primarily employed in the case of developing a slightly different product variant by the same engineers with the same engineering environment, these would be unexpected deficiencies indeed. In all other cases, continuous learning throughout development is a common characteristic. Then, it is very likely to identify late requirement changes, and immature system life cycle phase inputs based from a-posteriori knowledge. Instead of blaming requirement changes and immature inputs, managing the learning efficiently is an important success factor ‒ despite from the point in time or occasion a new lesson is learnt.
The non-trivial case is more likely in real systems engineering endeavors. It is not really helpful for promoting systems engineering by deeming the real case in normal life as abnormal. Instead, systems engineering processes not suited to manage a reasonable high number of lessons learnt efficiently are inadequate, and need improvement.
Most systems engineering programs and projects are successful. However, when it comes to technical goal achievement, cost limit observance, and time schedule adherence in detail, the records show mixed results at most. Even in the traditional systems engineering domain of aerospace, some recent military aircraft procurement programs have their severe issues.
Figure 1 shows a typical cumulative effort curve summarizing a development project. At a certain point in time, no further effort is generated. Obviously, the project is completed successful, or ‒ not considered here further ‒ has been terminated unsuccessfully. Two phases may be easily distinguished. Before the identified point in time, development has been in work. Afterwards, it is completed.
Figure 1: Cummulative Effort and Phase Transition.
But this is not all to be learnt from Figure 1. A significant change of the slope is observable during the in-work phase. From project start onwards, engineering teams work on the requirements allocated to them following plans and procedures. In Figure 1, this stage is called Normal Systems Engineering. Closer to completion, the mode of operation changes. Intense team internal discussions and discussions between the engineering teams take place to sort out all the issues missed to be tackled earlier. This generates some additional effort, but the main reason for the slope increase are massive correction costs. The effort for corrective actions is increasing exponentially with the time delay before corrective actions are taken.
To some extent, the cumulative effort curve is reminding to the phase transition of water changing from the fluid to the gaseous state. There is an extra amount of energy needed for the phase transition like there is additional effort for systems engineering project completion. As long as this extra effort remains significant, the predictive capabilities of systems engineering are questionable.
By the way, the success of the mode of operation during phase transition is remarkable. Could it be that normal systems engineering should better integrate some of the applied methods for improvement? Especially, the intense intra-team and inter-team communication are reasonable candidates for consideration. The INCOSE lean and agile initiatives are steps in the right direction. If they are successful, the main key performance indicator will be the disappearance of extra phase transition efforts in engineering projects.
Each knowledge domain establishes its own terminology and specific semantics forming a discipline specific language. Despite any possible mathematization or formalization, a discipline specific language is based on a natural language. In the discipline specific language, terms may be redefined, and new terms ‒ partly composed by stringing several natural language terms together ‒ may be invented.
Discipline specific language definitions are motivated by adding precision with respect to the particular knowledge domain. Compared with term usage in the corresponding natural language, discipline specific language definitions may impose constraints neither visible nor applicable in the natural language. For example, think about the term complex and its various usages. In extreme cases, discipline specific language may become misleading for someone approaching a field just with knowledge of the common natural language. A translation between discipline specific languages and common natural language is always required to some extent.
In systems engineering, the challenge is even more demanding. As an integrative discipline, systems engineering has to mediate not only between a systems engineering specific language and common natural language, but also between all discipline specific languages of the knowledge domains involved and considered in the systems engineering endeavor. It would be inappropriate to expect from systems engineering absorption or seamless integration of all other discipline specific languages. However, systems engineering terminology needs to be comprehensive and consistent by itself. Comprehensiveness lets systems engineering fulfil its mediating role without restrictions. Consistency is required in order not to induce extra confusion into multi-disciplinary communication.
Systems engineering has not completely developed a new terminology for its specific purposes. It borrows from other disciplines. Enterprises performing systems engineering are usually obliged to establish a quality management system. Quality management terminology as defined by ISO 9000 is therefore a reasonable main source for systems engineering. The main objectives of quality management and systems engineering are closely related, but are not fully congruent. This is not without impact for using quality management terms in systems engineering. Two examples are chosen here to illustrate the challenges with respect to both, comprehensiveness and consistency.
The first example is concerned with the three terms requirement, validation, and verification. Quality management aims for customer satisfaction. For achieving this goal, a requirement is defined as need or expectation that is stated, generally implied or obligatory (ISO 9000:2015). In systems engineering, the term requirement is defined differently: statement that translates or expresses a need and its associated constraints and conditions (ISO 29148:2011). In systems engineering, the meaning of requirement is reduced to the first of the three meanings defined for quality management. The other two meanings of a requirement according to ISO 9000 are only included as far as they are also stated. Regarding the command and control management style prevailing in the traditional systems engineering domains, the wording of ISO 29148 provides a better fit at the expense of applying systems engineering in a market economic context.
The definitions for validation and verification are copied from quality management without changes. Both terms are defined with respect to requirements. Verification is the confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. Applied to systems engineering, the definition remains meaningful. Only the attribution as specified requirements seems to be redundant. In systems engineering terminology, requirements are always specified, e.g. stated.
Validation is defined as the confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled. From a systems engineering perspective, the definitions of validation and verification differ literally, but resolve to the same meaning. It is left to the reader to investigate the confusion induced into organizations that are aiming for compliance with both, quality management standards and systems engineering standards.
Most authors try to circumvent the problem by defining auxiliary rules. Verification is concerned with the question: Did we built the system right? Validation provides the proof for the question: Do we build the right system? Since the recent issue published in 2015, ISO 15288 refers to these auxiliary rules in corresponding notes to the original definitions. That the phrase regarding validation is expressed in past tense, provides some evidence for not exploiting the full potential of validation as an integral part of systems engineering performed continuously throughout system development.
The second example is concerned with the missing concept of an enterprise in systems engineering. Following quality management again, systems engineering uses the term organization from ISO 9000: person or group of people that has its own functions with responsibilities, authorities and relationships to achieve its objectives. Of course, there are many purposes for using the term organization in accordance with this definition in systems engineering, and an enterprise may be subsumed as an organization in compliance with this definition. However, the important characteristics and obligations of an enterprise as a legal entity and their impact on systems engineering justifies to introduce the concept of an enterprise into systems engineering in addition. With the concept of an enterprise, considerations on the role of systems engineering in conjunction with marketing and product portfolio strategy development could lead to better guidance on the various roles of systems engineering roles and functions within an enterprise. There are further opportunities for improvement arising as well.
By the way, there is a reason why the quality management standards opted for the term organization and waived the concept of enterprise. Thirty years ago, a colleague of mine represented the German DIN for negotiating the new ISO 9000 series of quality management standards. When we had issues how to implement a compliant company-wide quality management system, he argued that the concept of an enterprise was intentionally missed. It would have had an adverse impact on the business model of quality management certification based on the ISO standards, if certification would be limited to an enterprise level. Especially for large companies, the approach to certify individual organizational units of any reasonable size lowered the barrier to entry.
More worrisome than the described issues themselves is the lacking motivation to resolve them. Attitudes and habits of systems engineers have adopted to tolerate incompleteness and inconsistency in systems engineering terminology. After long-term exposure to these deficiencies, they seem not even to notice them anymore. A good theory of systems engineering is needed as a regulative function to challenge the systems engineering body of knowledge continuously for fostering continuous improvement.
Figure 2: At the Edge of Systems Engineering.
Figure 3: From Problem to System.
Figure 4: The System Control Loop.
Figure 5: System Integrity in the PDCA Cycle.
Figure 6: The Scope of Systems Engineering.
Figure 7: The Dual Role of Systems Engineering.
Figure 8: The Problem Processing Cycle.
Figure 9: The Overall Systems Engineering Value Stream.
Figure 10: The System Life Cycle.