Systems Engineering as an Essential Organizational Competence for Knowing and Innovating

Abstract

Systems Engineering is described as a transdisciplinary approach that integrates all disciplines and specialty groups into a team effort, developing an innovation from concept to fully operational system. However, its procedural nature has been viewed by some as inhibiting innovation. By considering the whole of the innovation cycle, we demonstrate that Systems Engineering is actually essential to overcome the so-called valley of death in terms of technology readiness. Drawing on two case studies of knowledge management in large organizations (one government and one private industry), we show the benefits of a perspective in which the organization is viewed as a system through which dispersed explicit and tacit knowledge may be integrated to support innovation. However, this relies on appreciations of the full range of different knowledge types and the importance of organizational culture in the knowing and action cycle. The importance of organizations and the individuals within them adopting systemic thinking and systematic effectiveness are essential attributes of innovation: these are embodied in the discipline of Systems Engineering.

1. Introduction

Innovation concerns the development of an initial idea through to its realization as a viable product, service, or infrastructure. The meaning of viability depends on the circumstances; for example, commercially viable, public service system viability, etc. it is a widely held view that many potentially viable ideas fail to be realized during the mid-development phase, which has been referred to as the ‘valley of death’ for innovation [1]. In this chapter, we shall argue that this phase of development concerns integration and, as such, the risk of failure can be reduced by adopting a Systems Engineering approach. We are essentially concerned with technological innovation in this chapter, which begins with some general considerations to explain our interpretation of the concept of innovation. We then describe Technology Readiness Levels [2] as a construct for measuring the maturity of an innovation. The role of Systems Engineering is explained, and the skills and mindset of a Systems Engineer is described so that their importance can be appreciated as beneficial to the process of technological innovation. We close the chapter by recognizing the significance of knowledge management in innovative organizations, which we illustrate with two briefly described case studies.

2. Innovation: process or culture?

Some years ago, I was asked to write a chapter on the ‘innovation process’ in aeronautics [3], meaning the procedural nature of innovation. I concluded that, from an organizational perspective, environment and culture were of much more significance than process, noting the view of Steve Jobs (then chairman and CEO of Apple Computers) when asked ‘How do you systemize innovation?’, he replied: ‘You don’t. You hire good people who will challenge each other every day to make the best products possible… … Our corporate culture is simple’ [4]. However, I noted that in domains such as aerospace, the future challenges are highly complex and should address not just technology, but legal, social, environmental, financial, etc. aspects as well. Indeed, a (whole) systems approach is needed.

If we set aside the notion of ‘systematic innovation’ meaning a step by step process for innovation and turn our attention to the process of technology development, then the meticulous process of development using Systems Engineering could be seen as an enabler of innovation, as will be discussed below.

Jobs’s comment above indicates that innovation is linked to both the quality of the staff and the quality of their interactions; in the discussion below, we shall consider the value an organization places on knowledge management and some of the features that make this an effective enabler of innovation.

The discipline of Systems Engineering is concerned with both the systemic (behaviour of a system as a whole and its interaction with its environment) and the systematic (concerned with the detail of how a system’s parts interact and are put together). In general, innovation requires consideration of both the systemic and the systematic and one without the other makes innovation less likely. It is an oft quoted example but consider the F117 (Nighthawk) as a highly complex, innovative capability. This was the first stealth aircraft, developed by Lockheed Martin Skunk Works in 1970s/1980s. Lockheed analyst Denys Overholser came across a paper by Russian mathematician, Pyotr Ufimtsev [5], concerned with radar detection and realized that he could use this to design an aircraft with very low radar signature. Thus the systemic nature of the F117 is that it is almost undetectable by radar, but the systematic aspect is that there are electromagnetics, aerodynamics, structures, propulsion, control, and many more individual challenges that must be overcome with appropriate technologies and integrated together to achieve this capability.

There is a tendency to think of innovation as being synonymous with invention [6], but it is really about taking an idea through to commercial success or societal benefit. It may be radical but is more usually incremental [7] and may occur at either the component or system level. Whilst it is appreciated that innovation is not solely the domain of technologists, the discussion herein will focus on technology development, the maturity of which is often described in terms of TRLs (Technology Readiness Levels).

3. Technology readiness levels

TRLs were introduced by NASA to track the maturity of technology projects [2] and have become the de facto measure of maturity in many organizations, as generalized in [8]. Strictly they are concerned with technology projects, rather than technology per se, and indicate readiness for commercial deployment. TRLs range from 1 to 9 (Table 1) and represent the phases of research and invention (1–3), innovation (4–7), and commercial market (8–9). It is a generally held belief that many projects are terminated in the TRL 4–7 range [9], although precise figures are hard to find and it is also unclear what a reasonable level of failure at this level of maturity would be [10]. The costs associated with development increase substantially in this range, compared to TRL 1–3, and so a proportion of project termination is to be expected. The causes may be manifold, but it is noted that from TRL 6 every level involves integration in some form. If Systems Engineering has been applied from the outset of the project, then the likelihood of success is increased [11], and certainly Systems Engineering is an essential part of integration.

TRL 1	Basic principles observed and reported
TRL 2	Technology concept and/or application formulated
TRL 3	Analytical and experimental critical function and/or characteristic proof-of-concept
TRL 4	Component and/or breadboard validation in laboratory experiment
TRL 5	Component and/or breadboard validation in relevant environment
TRL 6	System/subsystem model or prototype demonstration in a relevant environment
TRL 7	System prototype demonstration in an operational environment
TRL 8	Actual system completed and qualified through test and demonstration
TRL 9	Actual system proven through successful mission operations.

Table 1.

Technology readiness levels summary [8].

4. Systems Engineering

Rechtin defines a system as ‘A set of different elements so connected or related as to perform a unique function not performable by the elements alone’ [12] and one could describe Systems Engineering as the discipline that chooses the elements and designs, plans, and implements the connections to realize the desired function in a reliable way, i.e. it is the discipline of integration. Systems Engineers must, therefore, adopt both a systemic and systematic perspective and employ systems thinking approaches and execute disciplined engineering processes.

The Systems and Software Lifecycle Standard [13] describes 30 processes needed to manage development and operationalization of a system; the processes of many systems organizations are based on this standard, though the manner in which they are procedurised may vary according to sector and internal factors. Application of these processes, with appropriate tools, should ensure good technical governance of system development. Systems Engineering is concerned with the whole life cycle of a system (from concept through to decommissioning or disposal) and provides a formal structure in which decisions relating to trade-offs between competing factors are addressed in order to manage cost, performance, and risk. Innovation can occur at any place in the life cycle, but we focus here on the development phase. As an example, we use the well-known V-model of the development life cycle (Figure 1).

Figure 1.

The V-model of a system development lifecycle (after [14]).

Figure 1 is a model of a development cycle that shows the relationship of the various life cycle activities to each other: it is not a life cycle per se. The model indicates that a user has requirements (or needs); these may be very abstract and may (often do) change as the user (or customer) learns more about the possibilities. At some point, these must be translated into systems requirements that provide sufficient detail to design a solution. The step of architectural design includes a raft of activities, including the inventiveness associated with creating a concept solution to meet the requirements. That concept must be expressed in architectural form that organizes a set of components that must be either created or acquired. These are broadly the processes through which the system is defined (left-hand side of the V). At every step verification takes place to ensure consistency between the steps and these are frequently iterations through which changes are agreed (e.g. to requirements). The right-hand side of the V concerns various stages of integration (i.e. build the system) with verification taking place to ensure that what has been built (assembled) is consistent with the design (i.e. that the system is built correctly). Finally, the system may be deployed and tested against the user’s requirements (i.e. that the correct system has been designed and built). Checking that the user’s requirements have been met is validation of the system. Verification is continually taking place to ensure correctness throughout the development. A more detailed discussion of the various stages may be found in references such as [14, 15].

One might justifiably assert that ‘surely such tight control must stifle innovation’. But in fact, innovation can occur at all stages; the Systems Engineering processes are designed to ensure that the risk of errors and faults is reduced through the development and that the purpose is kept in mind throughout. Referring to Table 1, the so-called valley of death (for technology projects) is TRLs 5–7, which is the assembly of the system and its testing in appropriate environments. It has been asserted by UK Government that managing the risk through these stages is a major need for technological innovation [1], and we argue that Systems Engineering is the approach to do this.

5. Systems, systems of systems, and standards

Useful systems rarely comprise a unitary system acting in isolation, but are frequently combinations of interacting systems, referred to as ‘Systems of Systems’ (SoS). Brook has provided a general definition of SoS as ‘…a system (systemic statement) which results from the coupling of a number of constituent systems at some point in their life cycles (systematic statement)’ [16]. Thus, systems that may, or may not, have been originally designed to work together may have to interoperate to deliver capabilities to a user; the constituent systems can operate outside the context of the SoS, or perhaps be constituent systems within several independent SoS. Their development histories (e.g. updates) and commitments to the SoS may be the responsibility of different organizations. The properties of operational or managerial independence are frequently defining characteristics of SoS [17] and certainly present many complex challenges for operation and control of SoS. Because of the massive increase in connectivity of systems since about 2008, Dahmann and Henshaw have suggested that all systems should now be considered to be SoS [18].

Recognizing that engineering of SoS concerns the connecting together of systems with different lifecycles, a popular development model (especially for defense systems) is the Wave Model [19], see Figure 2. This model suggests that planned introduction of new systems and retirement of old offer greater opportunities for agile innovations in the overall SoS, whilst maintaining rigorous integration of constituent systems. The process suggested by the wave model is one of identifying capability gaps with current SoS with reference to the (changing) external environment and seeking solutions that address the gap through changes to the SoS by introducing new systems, changing existing systems, or reconfiguration of the SoS.

Figure 2.

Wave model for SoS development [19].

Reconfiguration of SoS is an important component in some forms of innovation, whereby users are able to create new (or enhanced) capabilities by rapidly assembling interoperable systems to meet their needs. Some have argued that standards may stifle innovation [20], but in the case of this case, clearly innovation is only possible because of interoperability standards that enable reconfiguration.

Tidd et al. [7] mapped types of innovation to a six-box framework, depending on whether the innovation was at the component or system level and the extent to which it was incremental or radical. Based on the foregoing discussion, we can consider innovation in the context of Systems Engineering (Figure 3). The V-model includes innovation at either (or both) the system level and the component level; of particular note is the role of Systems Engineering in maturing the technology project through TRLs, 4–8 as integration proceeds within increasingly representative environments. Typically, this will of an incremental nature. For Systems of Systems, the wave model represents the inclusion of either new components, or new configurations of components, so that the technology may be at a higher level of maturity at the decision point for inclusion. Systems Engineering provides the integration capability that once more matures the project through the TRLs 4–8. In fact, for the wave model, it may operate in a purely incremental level, or include some level of radical innovation. At the radical end of the scale, the innovations have more in common with disruptive technology, which may include completely new uses of already matured technologies, or game changer technologies that may be introduced through various mechanisms, depending on the type of application and the industries involved. It may be remarked that ‘disruptive technologies’ is perhaps a misnomer, as in general they refer to ‘disruptive applications’.

Figure 3.

Types of innovation based on framework of [7].

To some extent, one might argue that the inventiveness aspect of innovation is due to systemic thinking (holistic viewpoint, consideration of problems from all angles), and the transformation of the idea to real world application is due to systematic thinking and work, that ensures orderliness of the development process. Certainly, this is true for innovation that is somewhat incremental. Inventiveness may be manifest at any point of the development lifecycles indicated schematically in Figure 3. Of course, it is the quality of the Systems Engineering in terms of choice of methods and tools, expertise in their application, and management of information that determines the effectiveness of maturing the technology project through TRLs 4–8. It is, then, appropriate to consider the attributes of good Systems Engineers in terms the innovation process.

6. The qualities of innovators and systems engineers

One important factor in innovation success is meeting customer or user expectations, and effective requirements management is the cornerstone of good Systems Engineering. A corollary of this is that technical ‘inventiveness’ at the component level may not translate into innovation success, because usually the customer is concerned with what the system (or device) can do, rather than how it does it. In his excellent book, ‘The Myths of Innovation’, Berkun draws attention to the fact that innovation does not just rely on technical prowess, but also on commercial proficiency [21]. He disagrees with the notion of the Eureka moment, arguing instead that the creative moment is not the sudden emergence of an idea, but rather the fitting of the last piece of a jigsaw that shows the inventor how a change may be achieved. This is very well illustrated by an example that I often give to undergraduate engineers, entitled: ‘How the Wright Brothers Exemplified Systems Engineering’, which I base on the biography of the brothers by Jakab [22]. These are the attributes they displayed:

• Conducted a thorough critical analysis of previous work: the brothers contacted the Smithsonian and the aviation pioneer Octave Chanute to request all the papers they could assemble, from which they learned what worked, but equally importantly what did not work.

• Critical thinking: the brothers challenged conventional wisdom; for example, the Smeaton coefficient had long been accepted as 0.005, but the Wright’s tested the theory of force due to flow and corrected the value to 0.0033.

• Re-used appropriate data: satisfied of the reliability of data, they used Leilenthal’s data sheets for aerofoil forces, rather than duplicating work.

• Employed an effective decision-making process: Orville and Wilbur Wright had many arguments, some very intense. They used a novel process to resolve these by holding a court of family members, with their father as judge, to hear their arguments and to resolve the disputes. Effective teams should have disagreements but should have mechanisms for resolving them in a positive manner.

• Holistic thinking: for any system to work, then all the individual components must work in a complementary fashion; for an heavier-than-air vehicle to fly, then the four aspects of control/stability, aerodynamics, propulsion, and structural strength must all be successfully addressed in the integrated design [23]. The Wright brothers were the first to conceive the aeroplane as a whole and complete system.

• Thoroughly understand the problem: the Wrights were the first to recognize the control/stability problem properly. Whereas others had relied on human control to restore a stable flight condition (e.g. when disrupted by a gust), they used a foreplane with a different angle of attack.

• Include humans/users in the system design: the brothers took good account of human factors; in particular, they realized that once airborne expertise in flying would be required. Thus they learned to fly and practiced using gliders prior to attempting powered flight.

• Technical knowledge: they knew the relevant laws of physics to make appropriate mathematical modeling, e.g. for sizing the vehicle.

• Visual thinking/analysis ability: Jakab [22] makes much of the brothers’ visual thinking abilities, arguing that it is an essential element of engineering genius to be able to picture a design object and how it will work physically, incorporating new features and how they will perform in the minds-eye. An example would be their appreciation of the nature of drag and decision to use a prone pilot to reduce it. I once worked with a brilliant configuration designer in aeronautics, Ian Chisholm, who without calculation cured a strange acoustic effect with the introduction of a bump on a wing, because he could somehow visualize how it would work. It is a form of non-verbal reasoning and holistic thinking [24] but, whilst the value of visual thinking is appreciated, its precise nature and origin is less-well established.

• Synergistic thinking: The Wrights were bicycle manufacturers and used their knowledge of balance and user interaction to assist their understanding with respect to the development of the aeroplane. A well-known example of their synergistic thinking was the introduction of wing warping for control. Wilbur Wright apparently devised the mechanism for wing warping after absentmindedly playing with a cardboard box and realizing that even when applying considerable torsion (twisting) it retained its lateral stiffness. Synergistic thinking is the ability to apply principles learned in one context to the solution in another.

• They had practical ability: their understanding of bicycle building enabled them to be good at making machines to appropriate quality.

• Experimentation: The Wright brothers were not the first to use wind tunnels, but their practical abilities enabled them to make precision instruments for measuring forces and through hundreds of hours of wind tunnel experiments, they determined the most efficient aerofoil.

• Manufacturability: design for manufacture is a key competence within engineering, though not one that is always given sufficient priority. It is a part of lifecycle planning that should be valued; the Wrights built their vehicles in modular parts for easy construction onsite (also appreciating the logistics challenges of moving the vehicle to the test site).

• Prototyping: they used kites to understand forces and behaviours and, indeed, when they were struggling to achieve the control behaviours they desired, experimented with different foreplane angles using kites.

• Documentation: the brothers kept log books and recorded detailed information, although it would appear that some was recorded afterwards and not all the records are clear to others [22].

These iconic innovators used both systemic and systematic thinking, which is the quality of good systems engineers. The extent to which the qualities listed above are due to nature or nurture may be the subject of another analysis, and we express no view on that here; they provide a sketch of the abilities and behaviours that one would wish to see in a practicing Systems Engineer and appear to represent the qualities of innovators. Having focused on the behaviours of individual innovators, we now turn our attention to organizations in which innovation will thrive.

7. Knowledge management in innovative enterprises

The foregoing discussion on Systems Engineering has indicated that it is an essential discipline for complex systems projects; it probably offers less benefit for simple projects, where a systems approach, rather than the full weight of Systems Engineering is sufficient. Complex projects generally involve many people and it is often the case that contributions must be integrated across an enterprise of many collaborating organizations. One can legitimately ask how innovation can thrive in a complex enterprise. It may be stretching the simile a bit far, but Berkun’s notion of inventiveness being the last piece of the jigsaw [21] implies that one must know all the other pieces and, most importantly, how they all fit together. Within the enterprise there must be an understanding of all the parts and how they interact, which is the task of systems engineers. We consider now the role of knowledge management in the context of complex systems and enterprises.

Blackler introduced a notion of knowledge belonging to one of five categories [25]:

• Embrained—abstract knowledge that is reliant on cognitive competence and conceptual abilities

• Embodied—knowledge that is oriented toward action, ‘know how’, skill. ‘Practical thinking’ that depends on understanding of the situation rather than abstract rules.

• Encultured—socially constructed knowledge that is manifested in a shared understanding. This knowledge is closely connected with language.

• Embedded—knowledge that is set in general routines, technologies, roles and procedures.

• Encoded—knowledge that communicated through symbols in paper and electronic formats such as books, manuals, handbooks, drawings, etc.

These clearly divide into knowledge that is mostly explicit (embedded and encoded) or mostly tacit (embrained, embodied, and encultured), and it is argued that all forms are important in effective organizational knowledge management. To these five, Ahlberg Pilfold [26] has added a sixth category, that of knowing where to find information or knowledge. This is an organizational knowledge skill. Put simply, the ability of an enterprise to put an idea into practice relies on the ability to assemble all the necessary knowledge effectively. The distinction between information and knowledge is important, here, as a contrast between ‘know what’ and ‘know how’.

Cilliers has considered knowledge in the context of complexity [27] and argued that whereas fundamentalists believe that formal knowledge (facts, formulae, etc.) can be used to describe systems, in the case of complex systems they cannot be separated from their context and that it is not possible to know all aspects objectively and it is only possible to know about the complex system from a cultural or personal perspective: hence the knowledge is relative. He goes on to consider the problem of boundaries: that a complex system is made up of non-linear relationships that cannot be reliably reduced, in terms of its complexity so that ‘there is no accurate representation of the system, which is simpler than the system itself’ [27]. Nevertheless, Cilliers criticizes relativism as an unsustainable position, and concludes that ‘the notion of scientific knowledge should be developed beyond abstract objectivity without falling prey to relativism’. This suggests that the knowledge to create and develop complex systems should include the dynamics of the relationships within those complex system that may (for instance) include emotional, non-deterministic, or changeable interactions between system elements.

We have argued above that innovation requires both systematic and systemic thinking. The knowledge of systematic thinking is objective, but it may be that systemic thinking may include relativistic knowledge, in which the individual parts and their interactions are not completely known, but the overall behaviour of the system is appreciated. Thus the five knowledge Es of Blackler [25] should all be appreciated in effective innovative enterprises and the sixth knowledge category of knowing where to find the required knowledge within the enterprise (or indeed outside it) provides the knowledge resources needed for collective innovation.

Ahlberg Pilfold [27]studied two large organizations, one in the private sector and the other a part of government, considering their ability to manage knowledge for the purposes of maintaining capability. The private company, ‘ServiceCo’ employs nearly 90,000 people worldwide, divided into six business units, and has private, corporate and government customers. ServiceCo relies on the products and services provided by a large number of suppliers, partners and external technical experts.

ServiceCo operates in a field where technology has a lifecycle ranging from 5 to 30 years, with infrastructure dating back to the 1970s. There is a risk that ServiceCo is unable to support the legacy systems because many employees who had worked with the implementation, design, operation and maintenance of the existing infrastructure were retired and/or chose voluntary redundancy.

At the time of the study, the government organization had approximately 3900 fulltime employees, of which around 2900 were professional and technical staff who manage and deliver a Science and Technology Programme. Whenever possible, work was placed with external providers such as academia and the private sector.

In both cases, management of knowledge is challenging because many of the complex systems that must be maintained and operated include substantial levels of legacy components (tangible and intangible), and the organizations rely strongly on expertise outside of their organization to deliver the capabilities for which they are contracted and responsible. Data was collected on knowledge management through organization documents and interviews with employees. The enquiry did not focus on innovation explicitly, but in both cases, the organization had to adapt and introduce new systems to meet the changing circumstances in which their capabilities must remain effective. Hence, the level of innovation directly impacts the competence of the organization. In both cases, the organizations are concerned with the development of new complex systems and apply Systems Engineering to achieve this.

Ahlberg Pilfold identified the following six matters for effective knowledge management (either because the organizations practiced them, or because they did not):

• Succession planning—management of complex systems requires knowledge to be passed on effectively as people retire.

• Maintaining state of the art knowledge (usually through research)

• Corporate values should include recognition that knowledge is a key attribute of the organization

• The need for slack—this means that there needs to be time for learning and consolidating knowledge

• Co-location: her findings indicated that knowledge was better managed with participants in the enterprise are co-located

• Trust and openness across the enterprise is required to achieve effective interoperability of either organizations in the enterprise or the systems they produce.

• Use models as receptacles for knowledge. This speaks strongly to the Systems Engineering agenda and its current move toward model-based Systems Engineering (MBSE) [28].

These areas of good practice include management of the knowledge in heads (human aspects) and the explicit knowledge captured in models [26].

8. Conclusions

We have considered innovation in the context of complex systems and argued that Systems Engineering is an essential organizational skillset of an innovative organization. We identified a number of abilities and behaviours of exemplar innovators (the Wright brothers) and argued that these are the abilities and behaviours that Systems Engineers should practice. We further argued that for complex systems, the development and operation of which are necessarily the endeavour of enterprises rather than individuals, knowledge management is crucial to success. We adopted the five knowledge categories of Blackler [25], but also added the knowledge of where to find knowledge [26] as an attribute of innovative organizations. The knowledge categories include both explicit and tacit knowledge.

Innovation comprises the creativity to invent new ways of doing things, or to identify new opportunities for existing systems, but crucially, the ability to operationalize those ideas. Many technology projects flounder at the range of technology readiness levels between 4 and 7; this is sometimes referred to as the valley of death [1]. These levels are associated with integration, which is the realm of Systems Engineering. We agree with the assertion of Bessant [6], that ‘Successful innovation management is not about doing one thing well, but rather organizing and managing a variety of different elements in an integrated and strategically coherent fashion’. To achieve this a systemic view must be retained throughout, but a systematic approach is needed for delivery. Thus, innovation requires individuals and organizations that can adopt systemic thinking and systematic effectiveness: Systems Engineering in terms of both the skills of an organization’s employees, and the quality of its procedures, is an essential organizational competence for knowing and innovating.

Acknowledgments

The case studies referenced in this chapter were carried out in a CASE studentship supported by EPSRC, Dstl, and Loughborough University.

Conflict of interest

The authors declare no conflict of interest.