See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/273457341

Systems engineering: evolution and challenges

Article  in  International Journal of System of Systems Engineering · January 2014

DOI: 10.1504/IJSSE.2014.067104

CITATION READS

1 1,784

3 authors, including:

Andres Avelino Sousa-Poza Charles B. Keating

Old Dominion University Old Dominion University
79 PUBLICATIONS   1,514 CITATIONS    130 PUBLICATIONS   1,634 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

System of Systems [Engineering] View project

Complex System Governance View project

All content following this page was uploaded by Andres Avelino Sousa-Poza on 13 March 2015.

The user has requested enhancement of the downloaded file.

Int. J. System of Systems Engineering, Vol. 5, No. 4, 2014 379

Systems engineering: evolution and challenges

Andres Sousa-Poza*, Charles Keating and

Samuel Kovacic
Department of Engineering Management and Systems Engineering,
College of Engineering and Technology,
Old Dominion University,
Systems Research and Academic Building, Suite 2101,
Norfolk VA 23529, USA
Email: asousapo@odu.edu
Email: ckeating@odu.edu
Email: skovacic@odu.edu
*Corresponding author

Abstract: In this paper, we investigate the evolution of systems engineering

using a framework developed for this purpose. Systems engineering was
conceived to deal with complex problems and has evolved to address new
challenges as they have emerged. The field has made advances in design
capabilities and the process by which products are brought to realisation. It has
worked at the limits of what is possible under an engineering governed
paradigm. More challenges that involve extremely large, complex structures
and networks include problems that supersede any form of design capability.
The integration of a management-governed paradigm has become necessary. At
this point, it is critical to map the future of systems engineering as a discipline
that is capable of dealing with these new problems or can effectively limit itself
to more traditional engineering undertakings.

Keywords: systems engineering; complexity; design process; system design;

system management; system governance; design theory.

Reference to this paper should be made as follows: Sousa-Poza, A.,

Keating, C. and Kovacic, S. (2014) ‘Systems engineering: evolution and
challenges’, Int. J. System of Systems Engineering, Vol. 5, No. 4, pp.379–399.

Biographical notes: Andres Sousa-Poza is an Associate Professor in the

Department of Engineering Management and Systems Engineering at Old
Dominion University. He obtained his PhD and MS in Engineering
Management from the University of Missouri-Rolla, and BSc in Mechanical
Engineering from the University of Cape Town, South Africa. His primary
research interests lie in the study of management and engineering practice as it
pertains to complex situations, system of systems, strategic management and
organisational change. He has worked, studied and lived in North and
South America, Europe, and Southern Africa.

Charles Keating is a Professor in the Department of Engineering Management

and Systems Engineering at Old Dominion University. He received his BS in
Engineering from West Point, MA in Management from Central Michigan
University, and PhD in Engineering Management from Old Dominion
University.

Copyright © 2014 Inderscience Enterprises Ltd.

380 A. Sousa-Poza et al.

Samuel Kovacic is an Adjunct Professor in the Department of Engineering

Management and Systems Engineering at Old Dominion University and Lead
Engineer for SPAWAR, US Navy. He holds a PhD from Old Dominion
University in Engineering Management, MBA in Aviation from Embry Riddle
Aeronautical University, and BSc in Computer Science from the University of
Maryland. His primary research is in the philosophical constructs of
worldviews and the study of management and engineering practice as it
pertains to complex situations, system of systems, strategic management and
organisational change. He retired from active duty with over 22 years service in
the US Air Force.

1 Introduction

Systems engineering has shown great promise over the approximately six decades since
its inception. There has been a particularly strong growth in the field in the last two
decades. Systems engineering programmes have been established at numerous schools
throughout the USA and across the world (INCOSE, 2013). Systems engineering
specialisations have evolved in diverse areas such as in computing, software
development, power distribution, security, defence, or transportation (Blanchard and
Fabrycky, 2011). Institutes such as Bar-Yam’s (2010) New England Complex Systems
Institute (NECSI), the Santa-Fe Institute, and the University of Michigan’s Center for the
Study of Complex Systems all resonate with the diversity found in the systems field of
study. There have also been an increasing number of related fields emerge, such as
System of Systems Engineering (SOSE) (Keating et al, 2003), or Complex Systems
Engineering (CSE, or CxSE) (Bar-Yam, 2003; Norman and Kuras, 2006). Additionally,
systems is an integral thread in many centres focused on these related fields; the National
Centers of System of Systems Engineering (NCSOSE) invokes complex systems in their
mission statement, as do the System of Systems Center of Excellence (SOSECE), the
Purdue System-of-Systems Engineering signature area, and the Trans-Atlantic Research
and Education Agenda (T-AREA) on system of systems. The new capabilities that have
been provided, or will eventually be provided by all of these advances have the potential
of greatly strengthening the field. There is, however, a hidden threat that may negatively
impact the developments.
Even though systems engineering is no longer a ‘new’ field, there is a tremendous
breadth to:
1 its presumed applicability
2 the nature of the methods and ideas of what makes up systems engineering
3 the very definition of the terms that make up its name. This breadth is a
double-edged sword.
On one hand, it allows for advances that a more myopic, orthodox field would not
[Paraphrasing Keating et al. (2003) on the benefits of not having a restrictive definition
for SOSE]. On the other, it allows for developments that may be paradigmatically
incompatible with each other, that could result in major dissociations within the field
(Sousa-Poza et al., 2008).
 Systems engineering: evolution and challenges 381

Systems engineering is at a juncture where an increased understanding of its very

nature is becoming increasingly important. Such an understanding may help avoid the
separations that can take place in fields of study that provide complimentary, yet
complementary, perspectives and solutions to problems. The types of problems that this
may generate are:
• Insufficient understanding of the problem space: The formulation of multiple
solutions for the same problem (without recognising even the commonality of the
problem) (Sousa-Poza and Kovacic, 2008; Sousa-Poza, 2013a).
• [Mis]Integration of incongruent paradigms and perspectives: The integration of
incompatible methods, approaches and tools under the presumption that they should
all work together since they are part of an undifferentiated systems engineering
(Sousa-Poza et al., 2008; Sousa-Poza and Kovacic, 2008).
• Misalignment between problem and methods: Applying the same systems
engineering methods and approaches to a wide variety of problems, even though the
problems are fundamentally different, since the problems and solutions are all
definable as systems (Sousa-Poza and Kovacic, 2008; Sousa-Poza, 2013a, 2013b).
• Failure to generalise effectively: Working on very specific problems that are not
generalisable, from which methods, approaches and tools are conceived and assumed
to generalisable to a wider problem set than is effectively the case (Sousa-Poza and
Kovacic, 2008).
• Development of partial solutions: Developing methods that satisfy a single paradigm,
failing to account for its complementary pair, which may not be necessary in simple
problems, but valuable, if not necessary, in complex problems (Sousa-Poza et al.,
2008; Sousa-Poza, 2013a).
In this paper, we present the compiled results of a study of systems engineering following
the basic tenets of an historical research method. The initial purpose of the study was to
establish the lineage of the SOSE research being undertaken at the NCSOSE at
Old Dominion University (see Sousa-Poza et al., 2008; Kovacic et al., 2007). This
purpose was extended into the present work that aims to generate a comprehensive map
of the systems engineering field, including its sub-fields and related areas of research.
The expansion in the purpose took place as it became apparent that no clear basis existed
on which to trace the lineage of SOSE, and as it became clear that SOSE might have
more than one lineage.
The paper is structured to:
1 Provide a brief overview of the genesis of systems engineering.
a We present a discussion on the purpose of systems engineering, based on the
genesis of systems engineering, with a particular focus on the two terms that
form the name.
b We provide a brief elaboration of the increasing complexity of the engineering
problem space.
382 A. Sousa-Poza et al.

2 Present a framework that was developed for this study.

a The framework draws on Simon’s (1969) work on the science of the artificial,
differentiating purposeful behaviour (assumed to be a cornerstone of any
professional activity) into rationalist and naturalistic approaches.
b Three major elements are identified that become necessary for systems
engineering to effectively address complex problems.
c From the framework, we formulate hypotheses related to the development of the
field assuming that the problems being undertaken by systems engineers are
becoming increasingly complex.
3 Present a historical timeline as it relates to the development of systems engineering
and a discussion of the timeline as it relates to the expectations of the framework.
4 Identify several challenges based on this framework that systems engineering will
have to address to maintain its leadership in providing purposefully derived
solutions.

2 An overview of systems engineering

2.1 The genesis of systems engineering

In the 1930s and 1940s, great advances were being made technologically, particularly in
the use of electricity to support areas such as communications, and rudimentary
computing, and control mechanisms. These allowed for the realisation of ever larger
engineered structures; structures that were in effect made up by combining many
engineered artefacts. Schlager (1959), Ramo (1957) and Engstrom (1957) highlighted the
importance of systems engineering to address the difficulties in meeting this need. The
rationale behind the field lay in the statement that “satisfactory components do not
necessarily combine to produce a satisfactory system” (Schlager, 1959). Organisations
such as Bell Labs (Kelly, 1950), General Motors (Schlager, 1959), RCA (Engstrom,
1957) and sectors of the military industrial complex had identified the difficulties
associated with integrating realised components into larger assemblies as defined by a
design. Even though the components appeared to behave according to the designed
requirements, the assembly did not.
The focus on technology and intention that an expected outcome could be attained by
design naturally drew this activity into the larger engineering manifold of disciplines. The
complexity that arises in the interaction of large numbers of components, dissimilar
components, or components that have interactions that are difficult to define was
beginning to be recognised (e.g., in Hall, 1950; Kelly, 1950; Ramo, 1957; Morse, 1948).
The budding discipline of system theory was seen to provide the requisite know-how
that could be leveraged to address problems where it was necessary to understand the
behaviour of the system (realised assembly) as a function of the behaviour and interaction
of its constituent artefacts (components). Systems was studying increasingly complex
problems that involved nonlinear or even stochastic interactions between heterogeneous
components (Ashby, 1956) in both closed or tightly bounded problems and open or
loosely bounded problems (Von Bertalanffy, 1950).
 Systems engineering: evolution and challenges 383

Systems studies according to the principles of systems theory or systems analysis

have been undertaken in a large variety of fields. For example (from; Von Bertalanffy,
1956; Ashby, 1956):

• biology (ecological environments)

• sociology (cities)

• economics

• business and management (organisations, supply chains)

• anatomy (structures of living things, subdivided into components of ever higher

resolution)

• informatics.

These studies led to the identification of generalisable system attributes that helped
explain how complex structures operate and maintain their equilibrium. It also led to the
notion of systems thinking that helped generate higher levels of understanding of
increasingly complex problems. These systems attributes and systems thinking were
considered to be critical to help bring about the types of assemblies that were being
demanded of engineering practitioners in the 1940s and 1950s; hence, the establishment
of systems engineering.
Even though systems theory has proven valuable to help increase understanding of
complex phenomena. It is important to note that many of the areas to which systems
analysis was applied were not ‘man-made’ structures or environments. Systems
approaches were evolved to better help understand complex phenomena; particularly in
natural settings.
Many of the system attributes, such as homeostasis, morphogenesis, or requisite
variety (Von Bertalanffy, 1956) were of interest to early progenitors of systems
engineering, since these attributed were considered to be critical for the existence
complex systems. What systems did not provide is a coherent design capability that
would enable these attributes to be purposely included in designs, other than some of the
work that was being done in cybernetics (e.g., Ashby, 1958). What is not always clear is
how the attributes, or systems of attributes, such as those in Beer’s (1984) viable systems
model, evolved in the assemblies that we study. By extension, it is also not always clear
how these should be realised ‘by design’. It can be argued that some of the systems
attributes, such as emergent behaviours or system evolution, might be altogether
incompatible with the notion of design.
This has been a persistent challenge for systems engineering that has always been
strongly associated with the engineering discipline. Even though engineering
encompasses a broad set of functions, and it is not always clear how engineers execute
these functions, purposefully attaining predefined outcomes by design, seems to be a
pervasive notion. This was apparent in the definition of engineering at the time put forth
by the American Engineers Council for Professional Development (ECPD):
384 A. Sousa-Poza et al.

“The creative application of scientific principles to design or develop

structures, machines, apparatus, or manufacturing processes, or works utilizing
them singly or in combination; or to construct or operate the same with full
cognizance of their design; or to forecast their behavior under specific
operating conditions; all as respects an intended function, economics of
operation or safety to life and property.” (Engineers’ Council for Professional
Development, 1947)
To make the design of systems possible, methods such as system design evolved. Other
approaches that were evolving independently of the systems engineering field, were
drawn in and adopted by systems engineers. These include, among others, control theory
and automation, process design, and modular design.

2.2 The dual functions of systems engineering

Schlager (1959) states that systems engineering was implemented in many different ways
in different organisations depending on the nature of the product. He essentially describes
two functions that governed the implementation. On one hand, the systems engineer
‘performs the complete and detailed mechanisation down to the selection of component
parameters’, or in other words, the systems engineer is responsible for the system design.
On the other hand, the systems engineer ‘serves as an adviser to specialists’. The
specialists develop the design. That is to say that systems engineering focuses on the
process by which the system is realised, not its design.
The design branch focused on advancing our knowledge of the behaviour of
structures in which intricately interdependent components interact to generate the overall
structures behaviour. The system design might incorporate multiple, embedded
hierarchical levels, with the highest level of resolution being achieved when a set of
requirements is defined that can be readily be acquired or sourced. Foundational to this
branch becomes the ability to determine how the components, as a whole, integrate,
interact, and operate with each other, to generate a common behaviour. This is
challenging with increasingly complex structures in which:
1 Small variabilities are compounded into large errors.
2 Feedback loops generate complex nonlinear behaviours.
3 High level of interdependencies between components make the impact of changes in
any one component on other components or the systems difficult to ascertain.
4 The impact to an assembly’s behaviour of a change to a component might only be
understood in situ, once the change is made to the realised artefact.
5 The structure s behaviour might only be understood in stochastic terms relating the
micro-macro emergent behaviours.
Advances in design capabilities would have extreme difficulties meeting the challenges
of the increasingly complex structures that had to be designed and realised. Systems
engineering, from its inception began to look at new ways to execute the engineering
function through new processes. These processes sought to maintain integrity between
initial expectations and the realised assembly (Kossiakoff, 1960). These processes
elaborated how expectations should be decomposed to a resolution that allowed for
requirements to be defined for individual components, and subsequently the realisation of
 Systems engineering: evolution and challenges 385

the system through integration of the acquired components. Important to these processes
was the management of the relationship between components and the groups that would
develop the individual artefacts.
The notion of managing the configuration of an assembled set of elements began to
be mentioned in management literature in the 1950s by notable theorists such as Drucker
(1959). The idea of managing configuration or the arrangement of components in a
particular manner was drawn into systems engineering activities. It followed the need to
be able to provide oversight in projects that incorporated a large number of components.
This included endeavours such as NASA s Apollo programme, shipbuilding, and the
manner in which the US Air Force was integrating computer programmes.
It is important to note that although configuration and design may have similarities,
the manner in which these are executed make them paradigmatically different. The
purpose of configuration management is to retain oversight of the structure, to be able to
trace the potential effect of changes and thereby establish requisite information channels.
Arguably, the configuration should flow from a design. The design, however, is a
prescriptive representation that not only captures the interactions, but also the nature of
those interactions allowing for an articulation of the system’s behaviour or functioning,
not only its structure.

2.3 ‘Complexification’ of engineering and systems engineering

Advances in technological know-how have provided the opportunity to generate fantastic
capabilities. The National Academy of Engineering (2014) in a survey of its members
developed a list of the 20 greatest engineering achievements of the 20th century. These
achievements include:
1 electrification
2 automobile
3 airplane
4 water supply and distribution
5 electronics
6 radio and television
7 agricultural mechanisation
8 computers
9 telephones
10 air conditioning and refrigeration
11 highways
12 spacecraft
13 internet
14 imaging
15 household appliances
386 A. Sousa-Poza et al.

16 heath technologies
17 petrochemical technologies
18 laser and fibre optics

19 nuclear technologies
20 high-performance materials.
These accomplishments have some curious attributes. Although each of the advances is
an indelible technological wonder, their true measure of value to individuals and society
is in the manner that they have impacted daily activities. Many of these technological
advances represent advances not in a single technology, but rather in the development of
networks of advanced technological artefacts. Modern communication, transportation,
and electricity provide capabilities that define modern civilisation. For these advances,
the integration of a many different engineered artefacts into structures has leveraged
individual technological advances, into networks capable of behaviours that would not
otherwise be possible. These networks or systems provide extensive societal utility,
greatly contributing to social wellbeing (Gheorghe and Masera, 2010).
These structures have, however, grown to the extent that the structures themselves
now present challenges. This is a cycle where complexification first produced advanced,
robust solutions, have become overly complex, and the benefits derived from the
structures are often outweighed by the artefacts becoming brittle, prone to sudden failure,
incapable of dealing with change, and otherwise showing phenomena that would indicate
intrinsic instabilities.
Although these networks are arguably man-made, including man-made artefacts, the
networks are not realised ‘by design’. That is not to say that they were not purposefully
acquired, but rather that they evolved to a present state.
Over time, systems engineers have added to the challenges due to the increasing
complexity of the problems that are being addressed. There are several issues that can
complicate the system engineer’s task. These developments have given rise to a variety of
tools, methods, related fields, or forms of systems engineering.
• Legacy components: In many cases, legacy components are used. These components,
such as off-the-shelf (OTS) items, may not be reconfigurable. The systems engineer
will be required to alter the design in such a manner that the components
characteristics are taken into account. This may force changes on the requirements of
other components, and to the very nature of the structure (modular design).
• Contextual specificity: Many of the solutions presented by systems engineers are
extremely tightly bound to the context or environment into which they are to be
implemented. In many cases, the boundary between the artefact or structure that is
fielded become blurred with the social and technical elements that already exist. In
extreme cases, the operation of the realised system cannot be [effectively] tested
until it is actually fielded within its operating environment. This may be due to the
dependencies of the artefact on operator attributes, or because of interactions that
becomes necessary with other systems in the environment (concurrent design
method, socio-technical systems, and stakeholder analysis).
 Systems engineering: evolution and challenges 387

• Lack of clarity in expectations and intent: In many problems that systems engineers
address it is not uncommon to find that there is no clear set of expectations for
behaviour or other outcomes for the realised system. Particularly in areas where new
technologies are being brought to bear, or in situations where due to social, political
and other factors, many expectations exist. These expectations may vary in nature
from what might be construed as vague, to including multiple distinct sets of
expectations. The differing expectations may, or may not be reconcilable. Problems
with conflicting or incompatible expectations present exceptional difficulty that
cannot, in essence, be addressed by the design (requirements elicitation,
requirements management, requirements engineering, and spiral design method).
• Increasingly large structures: Very early in the history of systems engineering, a
value was perceived by this discipline to maintain consistency in very large
engineering undertakings. Systems engineering became popular in its ability to
provide technical oversight to space missions being developed at NASA and was
extensively used in the Apollo programme (configuration management).
• Legacy structures: (SOSE)
• Social components: (socio-technical systems, CSE, and human systems engineering).
An assessment of this increasing complexity is neither the focus nor necessary for the
arguments presented in this paper. It is difficult to say, particularly in the case of systems
engineering, whether the increasing complexity is due to fundamental changes taking
place to problems that have always been within the purview of systems engineering, or
whether the increased complexity is due an increase in the scope of the problems being
undertaken by systems engineers.
What is quite clear, however, is that the challenges of the future will make demands
not only of individual technological advances, but also increasingly of the manner in
which the technologies must work in a specific context, the manner that these artefacts
impact the environment, and their sustainability. Many of the advances will be expected
of networks, rather than single artefacts. The technological advances that will challenge
engineering (see engineering challenges; National Academy of Engineering, 2008) will
place strong demands on the systems engineering field.

3 Framework development

3.1 A perspective of systems engineering

In systems engineering, the realised artefact is made up of an assembly of components.
The features and functions that are to meet a user’s expectations are generated through
the interaction of the components. From a strict engineering perspective, the systems
engineering role would be to produce the design, which when realised, will produce an
assembly of components that exhibits satisfactory behaviour. The design must therefore
relate the structure by which the components are to be organised, as well as the nature of
the interaction that is to take place between the components, to the behaviour that the
assembly is to exhibit.
388 A. Sousa-Poza et al.

In the typical systems engineering process, the engineer is tasked with understanding
the expectations of the stakeholders, forming competing design alternatives, selecting one
of the alternatives, and then elaborating on the design (Buede, 2011; Blanchard and
Fabrycky, 2011). The design takes on the form of a ‘decomposition’ of the stakeholders’
intent and expectations. The decomposition begins by providing the structure of the
assembly, including a definition of the manner in which the components are to interact.
Depending on the scale of the problem, multiple layers of resolution might be provided
with each assembly being decomposed recursively into sub-assemblies until a level of
decomposition is generated that includes only components. A component in this case is
an artefact that will be acquired through means other than the design and realisation by
the systems engineer. Each component will be defined by requirements that it will need
to meet to effectively function within the designed and eventually realised structure.
In this sense, the system engineering process follows the guideline of the Engineers’
Council for Professional Development (1947) definition of engineering and provides
mean to “to construct or operate the same with full cognizance of their design”.

3.2 Criticality – confidence of designs

Depending on the criticality of the design, a varying degree of confidence will be
required that a design will predictably result in a desired outcome may. The criticality is
proportional to the engineering risk posed by failure (likelihood and consequence), and
inversely proportional to the intransigence of the design (Figure 1). The intransigence of
the design is dependent on whether or not actions can be taken to adjust the design
throughout the process, including after the production and implementation of components
has started.
Where the criticality increases, demanding ever-higher levels of confidence in the
design, improved design capabilities will be needed. Design is improved through better
understanding of the nature of the problem, often as more advanced systems. Criticality is
therefore addressed through increasingly robust design approaches.

Figure 1 Required confidence as a function of criticality

3.3 Complexity – fidelity of designs

The fidelity of the design will depend on its complexity. The complexity of a system is
typically stated to be a function of the size of the structure, the form of the structure, the
nature of the interaction between components, and the degree to which the structure can
be isolated from environmental influences (Bar-Yam, 1997). As complexity increases,
 Systems engineering: evolution and challenges 389

the probability of attaining a required level of fidelity will decrease, resulting in a loss of
confidence in the design (Figure 2). A loss of confidence below some minimal threshold
will put the notion of design or designing in question.
In situations of high complexity, the fidelity of any design will drop, and the
probability that the realised assembly with match the intent and expectations driving the
design are highly unlikely. Using adaptive approaches is not uncommon where complex
problems are concerned. The adaptation allows for corrections to be made to the design
as the assembly begins to be realised. Such approaches are possible where the problem
criticality will allow for changes to be made and extremely high levels of confidence that
the design will accurately define future outcomes is not needed.

Figure 2 Fidelity as function of complexity

3.4 Infeasible design environments

Attaining a satisfactory outcome of the execution of a design-based approach where
higher levels of confidence are required and complex conditions exist that will not allow
for the requisite fidelity is unlikely. If it is critical that the realised assembly closely
resemble the designed intent due to the nature of the problem, it becomes imperative that
the problem or solution, and how it is to be attained be rethought. High complexity/high
criticality conditions fundamentally define an infeasible design environment. Design of
artefacts, as well as sub-assemblies may be possible. The full assembly will, however,
very likely have to be ‘evolved’. Approaches are needed that do not rely on predefined
structures, elaboration of interactions, and prediction of emerging behaviours that is
necessary for designs. A governance structure may allow for management of the evolving
networked assembly. Such a structure would be responsible for ensuring that
sub-assemblies or artefacts that must be designed are buffered from the surrounding
complexity. It would also be responsible for establishing policy that governs the
development of the networked assembly and making or arbitrating decisions that have an
impact beyond single artefacts or sub-assemblies.
Such as governance or management structure would rely on concepts related to
evolution rather than design as defined by Simon (1969). Being able to distinguish the
difference between what is feasibly a designed outcome [even if the design only
encompasses a part of a solution] and a purely evolved outcome may differentiate the
task as one demanding a professional engineering capability, and one that will require a
professional management capability (see Figure 3).
390 A. Sousa-Poza et al.

Figure 3 Design criticality and complexity matrix

3.5 Framework for evaluation of methods

In simple problems, the fidelity of a design that is possible is quite capable of meeting the
confidence demanded by the criticality that the assembly perform exactly as designed.
Initial challenges to designs can be managed along two dimensions (or a combination of
both):

1 Improved design robustness: Increasing criticality will demand ever-greater

assurance that the realised assembly will perform as is intended by the design. The
robustness of the design activity will have to increase to ensure that expectations can
be met for a given level of complexity. In other words, advances are required in how
systems are designed.

2 Improved/changed process: Increasing complexity will require processes that are

more adaptive and allow for greater responsiveness to changing conditions and
emerging outcomes for a given level of criticality. In other words, advances are
required in the processes by which systems are realised.

As long as the improved design robustness, and adaptations to the processes,

independently or in some combination result in a state where the required confidence can
be provided by a fidelity promised by a design, a feasible design environment is
maintained. The design environment will shift from being simple to increasingly difficult.
Eventually, due to increases in criticality or complexity, a condition is established
where requisite confidence cannot be provided by the fidelity of a design. A complex or
infeasible design environment is generated. A shift from engineering or design-governed
approaches to management-governed approaches is required (see Figure 4).
 Systems engineering: evolution and challenges 391

Figure 4 Criticality and complexity: compensation strategies

3.6 Engineering vs. management governed approaches

Systems engineering grew from two efforts; one that emphasised design, and how to
integrate fundamental system attributes ‘by design’, and another that emphasised process,
potentially recognising the evolutionary nature by which complex assemblies are often
realised. Although these are often viewed as two sides of the same coin, they do not
necessarily share the same underlying paradigm, and cannot, or should not, always be
combined.
Typical of engineering governed approaches (which includes design- or
process-based approaches) is that the purpose of the intended artefact or assembly is
given to it by design. In other words, the purpose of the system is stated in the design
(POSISID). In complex problems, where the limits of design are challenged or even
overstepped, there is a high likelihood that the emergent assembly will not function as ‘as
intended’ by an engineering approach. Limits of design are reached, and adaptation
exceeds the bounds of what any one design might allow. This would indicate an inherent
failure in these approaches.
From a naturalistic point of view, the purpose will be the resultant of bringing
together a set of components in a structure that is imperfectly understood, within a
context or environment that may act on the assembly (or use it) in ways that could not be
foreseen. Theorists in systems engineering propose that the purpose is derived not from
the design but ultimately by what the assembly actually does. In other words, the purpose
of the system is what it does (POSIWID) (Ring and Madni, 2005).
392 A. Sousa-Poza et al.

A process that governs the evolution of the assembly would most likely be more
congruent with the notion of POSIWID (Lockton, 2012). Within this structure there may
be components, or parts of the assembly, that are designed artefacts. These may exist
within such a structure without forcing an inconsistency, as long as one also recognises
that engineering within such an evolving environment poses its own challenges to ensure
that the artefact meets expectations, does not become obsolescent, thus ultimately
contributing to the overall assembly beneficially.
As the complexity of problems and designs increase it becomes increasingly difficult
to maintain a clear understanding of design and eventual behaviour. By the same token, it
becomes increasingly difficult, and ultimately impossible, to ascertain how a specific
individual component, by design, should contribute to the purpose or mission of the
assembly as a whole.
The framework differentiates engineering-based approaches into the two major
thrusts of systems engineering, namely design and process. As complexity increases
design must become more robust, and process more adaptable. A point is reached,
however, when the complexity and criticality increase to the point that an
engineering-based approach can no longer be warranted. Development of the assembly is
governed not by an inherently engineering/design centric approach, but rather by a
management centric approach that emphasises the evolution of the assembly as an
adaptive/responsive network.
If we accept the premise that complexity of engineering undertaking has increased
since the first inception of systems engineering, we should see development of the field
along three dimensions, firstly design and process, and more recently an ever increasing
focus on management governed approaches.

4 Historical evolution of systems engineering

A variety of systems engineering methods, as well as related methods from engineering

and management were reviewed based on whether their contribution emphasises
engineering-governed or management-governed approaches, and whether the
engineering-governed approaches focus on improving design practices, or the realisation
process. Select results are presented in Figure 5.
While the results are not quantitatively studied, there may be a pattern that would
imply that as complexity (or complexification of assemblies) has increased over time, a
gradual shift in emphasis has taken place from engineering/design-governed methods to
management-governed methods (Figure 6).
Advances in design and process in engineering-governed approaches seem to have
matched each other, although at present there seems to be a stronger focus on process
than design.
While these developments would seem to be natural for systems engineering, the
advances that are being made do present some challenges.
 Systems engineering: evolution and challenges 393

Figure 5 Timeline of select system engineering-related developments (see online version

for colours)

Notes: Systems engineering; modular engineering approach (Mead, 1947); system design
theory (Van Der Velde, 1968); process engineering (Kovan, 1959); systems
engineering process (Kossiakoff, 1960); modular design theory (Evans, 1963);
configuration management; rapid prototyping; software engineering design (White and
Booth, 1976); requirements engineering (Alford, 1977); systems engineering increasing
growth, INCOSE has first national conference jointly with the American Society of
Engineering Management in 1991 which rapidly grows into the INCOSE International
Symposium; SOSE (Sage and Cuppan, 2001; Keating et al., 2003; Jamshidi, 2011);
complex system engineering (Bar-Yam, 2003; Sheard and Mostashari, 2009);
enterprise systems engineering (Carlock and Fenton, 2001; Pyster et al., 2012);
complex adaptive systems engineering (Sage and Rouse, 2009; White, 2009).
394 A. Sousa-Poza et al.

Figure 6 Emphasis on management-governed development? (see online version for colours)

5 Challenges to systems engineering

5.1 Understanding its scope and domain

From Cook and Ferris (2006), Koen (2003) and de Weck et al. (2011), it can be inferred
that for systems engineering to be used in a viable manner, four conditions must be met.
1 there is a system or service with a well-defined boundary that will fulfil a purpose
2 the stakeholders’ needs for the system or service can be articulated
3 a significant technical component is expected as part of the solution
4 there is a deliberate application of engineering methods/processes to address the
problem posed by the stakeholders.
These requirements are essentially applicable to most engineering-governed approaches.
Although some loosening of the conditions may be possible through the application of
advanced processes, this can only be done in a limited manner. For example, through the
use of spiral development approaches, it has been possible to allow for stakeholder needs
and expectations to be elaborated over the course of the design-development cycle. This
is, however, limited to the elaboration of relatively static (yet not initially articulate)
needs, not needs that change in any extreme manner.
Systems engineering must become more aware of the domains in which it is applied
and recognise that different domains may require different approaches to be effective.
Given the trends in the type of problems that systems engineering is seeking to address,
which includes ever more advanced networks of artefacts; such as, smart grids, modern
transportation networks, or the internet of things, it is imperative that systems engineering
either:
 Systems engineering: evolution and challenges 395

1 develop formal management-governed approaches to deal with evolving, highly

responsive systems
2 identify and formalise the limitations of engineering-governed approaches as the
limits of systems engineering and elaborate how these will integrate with external
management and governance capabilities.
Of course, this decision may already have been overcome by events, as many recent
initiatives do focus on management-governed principles. The approaches following these
principles include many system-of-systems engineering efforts, CSE, and enterprise
systems engineering among others.

5.2 Integration of new developments

An overarching guidance is needed that is better able to distinguish the different nuances
between methods, approaches, tools and other items that are developed under the banner
of systems engineering. Systems engineering is not a single, orthodox field, other than
maybe in its purpose. This paper provides a framework to study some of the distinctions
between different methods that have been and continue to be developed and may provide
some utility in identify difference in new methods that are developed. It was, however,
not intended for this purpose and further research is sorely needed in this area. Without it,
systems engineering advances risk becoming increasing disjointed and possibly
ineffective.

5.3 Integrity of design, process and governance

It is possible to identify work and advances being made in both engineering-governed as
well as management-governed methods, there seems to be a particular focus on the more
management-oriented process side of the engineering methods, and on the
management-governed approaches. The exception to this might lie with model-based
systems engineering that might evolve greater design capabilities.
Where there seems to be a gap is in how these thrusts integrate with each other. It
would appear that there is a ‘stovepipe’ effect that is taking place in which different
regions, different researcher groups, or different academic programmes place an
emphasis on one area, with very little consideration or recognition of the others.
It is important to recognise that for systems engineering to be effective, it must
minimally be able to balance the design- and process-based branches of engineering
governed methods. These two branches play off each other to overcome difficulties that
might be encountered by either one of them. Furthermore, changes to one might
necessitate changes to the other. For example, advances in an engineering process, such
as the use of the spiral development approach, requires changes to the manner in which
an artefact or assembly is designed.
Ensuring that integrity is maintained between different methods is particularly
important in the implementation of management-governed approaches. It is critical to
understand the boundary between engineering activities that take place for artefacts and
possibly subassemblies within a network, and the evolving nature of the network itself.
This may include ensuring that engineering activities are buffered from the constantly
evolving environment, managing the constantly changing structure of artefacts, making
396 A. Sousa-Poza et al.

decisions/judgments pertaining to the network or parts of the network, as well as

establishing the policies, rules, methods, and environment that will allow for the
purposeful evolution/development of the network.

6 Conclusions

Systems engineering has been quite adaptive; managing to evolve with changing
conditions and increasingly complex challenges. Systems engineering, from its onset
established the need for a balanced development of design capabilities, but also of the
process of realisation. In this sense, it acts as an integrator of the different functions of
engineering (as defined by the Engineers’ Council for Professional Development, 1947).
It ensures that the process of realising a system integrates design activities:
• “The creative application of scientific principles to design or develop structures,
machines, apparatus, or manufacturing processes, or works utilising them singly or
in combination” (Engineers’ Council for Professional Development, 1947).
With those activities necessary to realise the design into a ‘real’ assembly of artefacts:
• “To construct [···] the same with full cognizance of their design” (Engineers’ Council
for Professional Development, 1947).
Very important in this development has been that the design activity and the realisation
activity can occur concurrently, making changes to the design possible even as
components begin to be integrated into a system.
More recent developments extend the design and realisation activities beyond the
boundaries of engineering governed approaches to integrate management-governed
approaches. These developments become crucial to address the extremely complex
problems engineers face integrating society and technology (Rhodes, 2002). Here too,
one of the challenges is to be able to do this in parallel with other engineering functions.
As is the case with system-of-systems type problems, that address issues such as
infrastructures or military capabilities, an ever-evolving structure or artefacts typically
already exists in the form of a ‘legacy system’. It is therefore not only crucial that there
be advances in design and the process of realisation, but how these are undertaken while
in an environment where a constantly evolving network already exists. From an
engineering perspective this implies that we have a capability o
• “To [···] operate the [network] with full cognizance of [the] design [functions taking
place]” (Engineers’ Council for Professional Development, 1947).
The systems engineer, in an engineering role, will have to be someone that can draw on
their expertise to articulate and derive a robust and credible propositional solution
[design] that is justified by the coherent combination of disciplinary skills and theories,
and knowledge in and of a field, as well as the understanding of how such a propositional
solution may be realised.
The systems engineer, in a management role, will have to be someone that can draw
on their intuition, artistry, empathy, and technical skills honed through participation in a
situation and its systematic observation to efficaciously gets things done. This will have
to be an individual that is able to balance the specificities demanded by an artefact or part
 Systems engineering: evolution and challenges 397

of an assembly, with those of demand that must be met for the assembly as a whole,
recognising that no ideal or optimal solution or decision will be known in advance.
In other words, the skilled systems engineer, or engineering manager is the person
demanded when the propositional skills of the engineer must be integrated with the
pragmatic skills of the manager:
• To deal with the technicalities and technologies that make modern civilisation
possible.
• Within the context of rapidly evolving, highly uncertain societal structures.
This is the person that will have the highest potential to attain a desirable outcome no
matter what the conditions or environment that are encountered.

References
Alford, M.W. (1997) ‘A requirements engineering methodology for real-time processing
requirements’, IEEE Transactions of Software Engineering, Vol. 3, No. 1, pp.60–69.
Ashby, W.R. (1956) An Introduction to Cybernetics, Vol. 2, Chapman & Hall, London.
Ashby, W.R. (1958) ‘Requisite variety and its implications for the control of complex systems’,
Cybernetica, Vol. 1, No. 2, pp.83–99.
Bar-Yam, Y. (1997) Dynamics of Complex Systems, Vol. 213, Addison-Wesley, Reading, MA.
Bar-Yam, Y. (2003) ‘When systems engineering fails-toward complex systems engineering’, IEEE
International Conference on Systems, Man and Cybernetics, 2003, IEEE, Vol. 2.
Bar-Yam, Y. (2010) New England Complex Systems Institute [online] http://necsi.edu/ (accessed
12 May 2014).
Beer, S. (1984) ‘The viable system model: its provenance, development, methodology and
pathology’, Journal of the Operational Research Society, Vol. 35, No. 1, pp.7–25.
Blanchard, B. and Fabrycky, W. (2011) Systems Engineering and Analysis, 4th ed., Prentice Hall,
Englewood Cliffs, New Jersey.
Buede, D.M. (2011) The Engineering Design of Systems: Models and Methods, Vol. 55,
John Wiley & Sons, New York, New York.
Carlock, P.G. and Fenton, R.E. (2001) ‘System of systems (SoS) enterprise systems engineering for
information-intensive organizations’, Systems Engineering, Vol. 4, No. 4, pp.242–261.
Cook, S.C. and Ferris, T.L.J. (2006) ‘The bounds of systems engineering’, Proceedings of the 12th
ANZSYS Conference – Sustaining Our Social and Natural Capital, Katoomba, NSW,
Australia, Paper 81, 3–6 December, pp.432–449.
de Weck, O.L., Roos, D. and Magee, C.L. (2011) Engineering Systems: Meeting Human Needs in a
Complex Technological World, MIT Press, Cambridge, Massachusetts.
Drucker, P. (1959) ‘Long-range planning – challenge to management science’, Management
Science, April, Vol. 5, No. 3, pp.238–249.
Engineers’ Council for Professional Development (1947) Canons of Ethics for Engineers,
New York.
Engstrom, E.W. (1957) ‘Systems engineering: a growing concept’, Electrical Engineering, Vol. 76,
No. 2, pp.113–116.
Evans, D.H. (1963) ‘Modular design – a special case in nonlinear programming’, Operations
Research, Vol. 11, No. 4, pp.637–647.
Gheorghe, A.V. and Masera, M. (2010) ‘Infranomics’, International Journal of Critical
Infrastructures, Vol. 6, No. 4, pp.421–427.
398 A. Sousa-Poza et al.

Hall, A.C. (1950) ‘A generalized analogue computer for flight simulation’, Transactions of the
American Institute of Electrical Engineers, Vol. 69, No. 1, pp.308–320.
INCOSE (2013) Directory of Systems Engineering Academic Programs [online]
http://www.incose.org/educationcareers/academicprogramdirectory.aspx
(accessed 15 June 2014).
Jamshidi, M. (Ed.) (2011) System of Systems Engineering: Innovations for the Twenty First
Century, Vol. 58, John Wiley & Sons, Hoboken, New Jersey.
Keating, C., Ralph, R., Unal, R., Dryer, D., Sousa-Poza, A., Safford, R., Peterson, W. and
Rabadi, G. (2003) ‘System of systems engineering’, Engineering Management Journal,
Vol. 15, No. 3, pp.35–44.
Kelly, M.J. (1950) ‘The Bell Telephone laboratories – an example of an institute of creative
technology’, Proceedings of the Royal Society of London. Series A, Mathematical and
Physical Sciences, pp.287–301.
Koen, B.V. (2003) Discussion of the Method: Conducting the Engineer’s Approach to Problem
Solving, Oxford University Press, Oxford, UK.
Kossiakoff, A. (1960) ‘The systems engineering process’, in C.D. Flagle, W.H. Huggins and
R.R. Roy (Eds.): Operations Research and Systems Engineering, pp.82–118, Johns Hpkins
Press, Baltimore.
Kovacic, S., Sousa-Poza, A. and Keating, C. (2007) ‘The National Centers for System of Systems
Engineering: a case study on shifting the paradigm for system of systems’, Systems Research
Forum, Vol. 2, pp.52–58.
Kovan, V.M. (1959) Fundamentals of Process Engineering, Foreign Languages Pub. House,
Moscow, Russia.
Lockton, D. (2012) POSIWID and Determinism in Design for Behaviour Change, Social Science
Working Paper Series [online] http://dx.doi.org/10.2139/ssrn.2033231 (accessed 12 May
2014).
Mead, L.C. (1947) Human Factors in Engineering Design, SAE Technical Paper, No. 470086.
Morse, P.M. (1948) ‘Mathematical problems in operations research’, Bulletin of the American
Mathematical Society, Vol. 54, No. 7, pp.602–621.
National Academy of Engineering (2008) Engineering Challenges [online]
http://www8.nationalacademies.org/onpinews/newsitem.aspx?RecordID=02152008
(accessed 15 June 2014).
National Academy of Engineering (2014) Greatest Engineering Achievements of the 20th Century
[online] http://www.greatachievements.org/ (accessed 15 June 2014).
Norman, D.O. and Kuras, M.L. (2006) ‘Engineering complex systems’, in Complex Engineered
Systems, pp.206–245, Springer, Berlin, Heidelberg.
Pyster, A., Olwell, D., Hutchison, N., Enck, S., Anthony Jr., J.F. and Henry, D. (2012) ‘Enterprise
systems engineering’, Guide to the Systems Engineering Body of Knowledge (SEBoK).
Ramo, S. (1957) ‘The new emphasis on systems engineering’, Aeronautical Engineering Review,
Vol. 16, No. 4, pp.40–44.
Rhodes, D.H. (2002) ‘Systems Engineering an essential discipline for the 21st century’,
Proceedings of the 24th Conference on Software Engineering, ICSE.
Ring, J. and Madni, A.M. (2005) ‘Key challenges and opportunities in ‘system of systems’
engineering’, 2005 IEEE International Conference on Systems, Man and Cybernetics, IEEE,
Vol. 1.
Sage, A.P. and Cuppan, C.D. (2001) ‘On the systems engineering and management of systems of
systems and federations of systems’, Information, Knowledge, Systems Management, Vol. 2,
No. 4, pp.325–345.
Sage, A.P. and Rouse, W.B. (Eds.) (2009) Handbook of Systems Engineering and Management,
John Wiley & Sons, New York, New York.
 Systems engineering: evolution and challenges 399

Schlager, K. (1959) ‘Systems engineering – a key to modern development’, IRE Transactions on

Engineering Management, Vol. EM 3, No. 3, pp.64–67.
Sheard, S.A. and Mostashari, A. (2009) ‘Principles of complex systems for systems engineering’,
Systems Engineering, Vol. 12, No. 4, pp.295–311.
Simon, H.A. (1969) The Sciences of the Artificial, Vol. 136, MIT Press, Cambridge, Massachusetts.
Sousa-Poza, A. (2013a) ‘Narrative of [complex] situations and situations theory’, in Kovacic, S.
and Sousa-Poza, A. (Eds.): Managing and Engineering in Complex Situations, Springer
Science and Business Media, Dordrecht.
Sousa-Poza, A. (2013b) ‘Introduction and overview’, in Kovacic, S. and Sousa-Poza, A. (Eds.):
Managing and Engineering in Complex Situations, Springer Science and Business Media,
Dordrecht.
Sousa-Poza, A. and Kovacic, S. (2008) ‘A research agenda for complex situations’, Engineering
Management Journal, Vol. 20, No. 4, pp.32–39.
Sousa-Poza, A., Kovacic, S. and Keating, C. (2008) ‘System of systems engineering: an emerging
multidiscipline’, International Journal of System of Systems Engineering, Vol. 1, Nos. 1/2,
pp.1–17.
Van Der Velde, W.E. (1968) Multiple-input Describing Functions and Nonlinear System Design,
McGraw-Hill, New York.
Von Bertalanffy, L. (1950) ‘The theory of open systems in physics and biology’, Science, Vol. 111,
No. 2872, pp.23–29.
Von Bertalanffy, L. (1956) ‘General system theory’, General Systems, Vol. 1, No. 1, pp.11–17.
White, B.E. (2009) ‘Complex adaptive systems engineering (CASE)’, Systems Conference, 3rd
Annual IEEE, IEEE.
White, J.R. and Booth, T.L. (1976) ‘Towards an engineering approach to software design’, in
Proceedings Second International Conference Software Engineering, IEEE Catalog No. 76,
Ch1125-4C.

View publication stats