Sheard:Principles of Complex Systems for SE
Page 1 of 17
Principles of Complex Systems
for Systems Engineering
Sarah A. Sheard
Third Millennium Systems LLC
1027 Challedon Rd. Great Falls VA 22066
sheard@3MilSys.com (703) 759-2803
Copyright ©2006 Third Millennium Systems LLC. For INCOSE review only.
Abstract. This paper shows how three systems of types well-known to systems engineers can be
understood as complex systems, and what principles can and should apply to developing and improving
them. This is important because research in complex systems sciences is vibrant and provides critical
insight, but if systems engineers do not understand the “complex systems” aspects of the systems they
work with daily, they may not be able to interpret these research results as usable.
The three examples are INCOSE, the systems engineering process (such as a company’s standard
process), and air traffic control. INCOSE can represent most volunteer organizations and social groups.
The systems engineering process for a company, while familiar to most systems engineers, is a system
that most systems engineers do not realize is a network that can be studied by complex systems methods.
Air traffic control may come closest to many systems engineers’ definition of a system.
This paper presents principles of complex systems from a variety of sources, and shows the specific
application of one set of principles to one of the examples.
PREFACE
Systems engineering has evolved without much of a formal or theoretical background for its
practices; instead it has relied on experientially developed principles and heuristics. [Defoe 1993] [Rechtin
1991] [Rechtin and Maier 1997] Fortunately, research in the world of complex systems (known to some as
complexity theory) is creating that formal theoretical underpinning that systems engineering can begin to
utilize: to explain current practices, and to help model existing systems so that predictive explorations can
be made. If mathematical models can predict, for example, holistic performance characteristics, then
parameters of the system can be optimized via modeling, rather than by trying a number of possibly
wrong answers in developed hardware and software. Early determination of good parameters can help
keep systems engineering programs on track and avoid derailment due to late “surprises” and the
consequent ripple-effect rework that many such programs experience.
This paper presents a number of Complex Systems principles, selected for their applicability to the
development and use of man-made engineering-based systems, i.e., systems engineering.
INTRODUCTION
Systems engineers face complexity in the systems they design, in the environments with which the
systems interact, and in the organizations and economies that offer them employment. Understanding
complexity can help us learn how to improve our systems by understanding how complexity underlies
and affects the environments and the systems.
The recent book Complex Engineered Systems [Braha, Minai, and Bar-Yam 2006] and the papers
collected therein serve as a broad-based yet focused introduction to complex systems for systems
engineers. As complete as it is, this book is strong on theory, rather than on practical principles of system
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 2 of 17
engineering. Principles of complex systems and complex systems engineering (CSE) are proposed in the
many papers within, but not in a way that many systems engineers have the time to decode. Individual
systems engineers have learned about complex systems engineering through their academic encounters,
but they have not found a venue to discuss the application of these ideas to day-to-day work. Furthermore,
many of the principles being stated by the academics seem overly obvious to systems engineers, who
have already discovered them experientially; changes from more typical systems engineering has not been
explained well. This paper is intended to show examples and to condense such principles into a
capsulized summary suitable for broad INCOSE distribution. The hope is that after organizational rework
and review, this can grow into a chapter in the INCOSE handbook [Haskins 2006].
Systems-of-Systems. It should be noted that Systems of Systems is a topic of great interest to systems
engineers. The topic was originally defined by [M. Maier 1998]; activity related to Systems of Systems has
increased greatly in the last three years. The Department of Defense is now working on a Systems-ofSystems Engineering Guide that presumes there is a System-of-Systems program manager and chief
engineer. [DoD AT&L 2006] The Systems of System Center of Excellence [SOSECE 2006] initiated annual
systems-of-systems engineering conferences in 2005, with the military as sponsor and primary customer.
IEEE started offering annual Systems-of-Systems conferences in 2006. [IEEE 2006]
Systems of systems issues that differ from systems issues include:
 Integration of independently operational component systems that were built for other purposes;
 Rapid evolution of both user needs and system technologies, which precludes stable requirements;
 Multiple disparate stakeholders with conflicting needs and a lack of incentives to participate in the
system of systems;
 Distributed development and its consequent communication problems, and
 Dependence on an integrated computing infrastructure that has extremely high and increasing
complexity and therefore possibilities of unintended consequences.
Are systems of systems complex systems? The answer is yes and no. A system that has a program
manager and a chief engineer is by definition not a complex system. (See below: complex systems are
built of many independent interacting parts that are not managed by a central integrating body.)
However, many systems-of-systems issues are similar to complex systems issues. Ad hoc systems-ofsystems are pulled together at the last minute by operational personnel and do not have chief system
integrators nor a specific development period [Ferris 2006]. Most of these do qualify as complex systems.
BACKGROUND: COMPLEX SYSTEMS
Complex systems is a field of study that is rife with “overloaded” vocabulary. Words like Enterprise and
Architecture are given new meanings [Bredemeyer 2006] as understanding and technology evolve, and
each new meaning develops a following. Eventually the followers collide in an interdisciplinary task or
meeting. Those who hear other people using the same words tend to assume everyone means the same
thing, but in this case, since it isn’t true, each group ends up thinking the other side is being stupid (or has
a hidden agenda). It is unfortunately rare that such problems are headed off by a close examination of
vocabulary and meanings.
As an example, let us look at a use of the term “complex systems”: “All systems that systems engineers work on are complex. If they weren’t, they wouldn’t need to be systems engineered. Why are you
making such a big deal out of complexity when we all have worked with it forever? You must be trying to
make money.” The answer is that this paper is using a very specific meaning, that developed by scientists
doing research in the area of complexity theory and its follow-ons. This paper uses the word “complex
systems” as follows:
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 3 of 17
Complex systems are systems that do not have a centralizing authority and are not
designed from a known specification, but instead involve disparate stakeholders creating
systems that are functional for other purposes and are only brought together in the
complex system because the individual “agents” of the system see such cooperation as
being beneficial for them.
A reasonable and short background in chaos and complexity theory for the systems engineer can be
found in [Sheard 2005]. Other material from the INCOSE Systems Science Enabler Group, such as [Sheard
2006], is also supportive.
DETAILED DEFINITION OF COMPLEX SYSTEMS
The following detailed definition collates ingredients of definitions from INCOSE [Sheard 2006]
and [Haskins 2006], University of Michigan [UMich 2006], Clemson University [J. Maier 2006],
Mitre Corporation [Norman and Kuras 2006], and the New England Complex Systems Institute
[Bar-Yam TBD].
Definition of Complex Systems
1. Complex systems have many autonomous components, i.e., the basic building blocks are
the individual agents of the system
o
There are a large number of useful potential arrangements of their elements
o
The elements are heterogeneous (differ in important characteristics), i.e. have variety
o
The system boundary is often hard to pin down
2. The structure and behavior of a complex system is not deducible, nor may it be inferred,
from the structure and behavior of its component parts
o
Generally the behavior involves nonlinear dynamics, sometimes chaos, and rarely any
long-run equilibrium
o
Often the agents are organized into groups or hierarchies; in which case the structure
influences the evolution of the system (See Figure 1, from [Bar-Yam TBD]).
o
Such structures tend to highlight a number of different scales, any of which can affect
the behavior of the complex system.
3. Complex systems are self-organizing (show a decrease in entropy due to utilizing energy
from the environment)
4. Complex systems adapt to their environment as they evolve
o
In particular, as they evolve they continually increase their own complexity, given a steady influx
of energy (raw resources) and feedback among elements
o
Their elements change in response to imposed “pressures” from neighboring elements
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 4 of 17
5. Complex systems are non-deterministic, i.e., exhibit unpredictable behavior, including
chaotic behavior under certain conditions
6. Complex systems display emergent macro-level behavior that emerges from the actions and
interactions of the individual agents
7. Complex systems can be said to encompass not only one or more system “artifacts” but also
the designers and users of the artifacts, in an open DAU system. Figure 2, from [J. Maier
2006] (used with permission), shows this Designer-Artifact-User system and the relationships
among components.
Figure 1. Complex Systems, from Bar-Yam [Bar-Yam TBD]
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 5 of 17
Figure 2. Generic Designer-Artifact-User (DAU) system in context
DEFINITIONS APPLIED TO EXAMPLES OF COMPLEX SYSTEMS
We will look at the following three examples of complex systems and compare them to the definition of
complex system and the principles for engineering complex systems.
 INCOSE
 The systems engineering process within a company
 The National Airspace System (air traffic control system)
Systems engineers should be familiar with most of these.
Table 1 shows that all three examples have all attributes listed above and therefore that these are
complex systems as defined above.
Table 1. Complex System Examples
Autonomous
interacting
parts (agents)
INCOSE
Members, CAB companies,
working groups, chapters
SE Process
Process activities, SE
artifacts
National Airspace System
Airlines, airplanes, airports, air
traffic controllers, databases, flying
public, navigation aids, pilots,
transportation security, towers, etc.
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Fuzzy
Boundaries
Structure
Selforganization
(emergent
order)
Can’t design
or run topdown
because...
Nonlinearity
Structure not
deducible
from
structure of
component
parts
Energy in and
out
(examples)
Adaptation to
surroundings
(environment)
Become more
complex with
time;
increasingly
specialized
Page 6 of 17
INCOSE
Who in CAB does it include?
What about various crossorganizational joint efforts?
SE Process
Interfaces with
program management
and with software are
particularly fuzzy.
Also, company vs.
customer process;
many more.
Hierarchical formal
governance, plus informal
Members form interest groups
and chapters; also groups of
friends
Policies, auditing,
change boards
Process activities slip
until another activity
frees up a resource to
perform them
Interactions with
other changing
processes; no one
group understands all
the activities or
rationales.
Small errors in
requirements can
destroy program
progress, particularly
when discovered late.
How activities are
laid out in a process
is not related to the
structure of the
activities or how they
are documented
Process change
boards eliminate lowvalue activities
Volunteer organization; SEs
don’t try to fit into
predetermined boxes;
technology and competitors
evolve (e.g. software-intensive
systems, SOSs)
Number of attendees at a
conference varies significantly from year to year for
reasons not linearly related to
conference price.
As with any social institution,
structure is not tied to human
bodies
Member dues and fees paid by
members from personal or
company funds. Members
bring energy to INCOSE
cause.
INCOSE meetings compete
for members with IEEE,
AIAA, and other groups, for
example by creating
certification program.
Multiplying and specializing
working groups; governance
structure includes positions
not imagined 10 years ago;
certification and certification
preparation courses
SE process takes up
the slack where other
processes fall short;
adapt to changing
standards (CMMI).
Create specialized
processes for various
kinds of programs
(large, small, ITintensive, military,
fixed-price).
National Airspace System
Rules for handoffs and sharing of
passenger data among various
countries; relationship to airlines, e.g.
can the NAS require airlines to put
equipment such as data transceivers
on airplanes so that air traffic control
can be more reliable? Frequent flier
programs involve hotels, etc.
Regulations, certification, laws
Airlines prefer hubs for maintenance
and operational economies;
competition forces fares to similar
structures
Airlines can go out of business, buy
each other, or go bankrupt. Airlines
compete on flight routes. Oil prices
are essentially uncontrollable. Potential passengers respond differently to
various ticket pricing schemes.
Reducing the flight time between
cities (or ticket price) a small amount
(to below competitors’) can increase
an airline’s number of passengers
greatly.
Patterns of jet flight (air routes,
VFR/IFR rules, hubs, weather
delays) are not determinable from the
structure of aircraft or even airports.
Jet fuel, public demand for
transportation, stockholders fund
airlines, fees fund government;
military supplies trained pilots, pilots
retire...
Take new security measures in the
face of terror threats. Build new
airports with environmental safeguards. Airplanes bought from
competing airplane manufacturers.
Rapid evolution to stay ahead of
terrorists. Choose bigger airplanes
for popular routes. Offer new
frequent-flyer privileges; airline
personnel specialize jobs, e-tickets,
passenger data requirements...
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Elements
change in
response to
imposed
pressures
from
neighboring
elements
DeveloperArtifact-User
(DAU) system
components
Page 7 of 17
INCOSE
Members may change their
working group participation
depending on who else is in it;
chapters improve to earn
chapter awards, members
write papers using previous
papers as sources.
SE Process
Later activities must
shorten if earlier
activities run long.
SEs delay new steps
if earlier steps are not
resolved or anomalies
are found.
D: Members (same as users)
A: Working group structures,
processes for submitting and
reviewing symposium papers;
U: Members, paper presenters,
participants in working
groups, elected and appointed
officials.
D: Systems
Engineering process
group (at least , the
description of the
process)
A: Process
descriptions (usually
on-line, can be paper)
U: Those who enact
the process. Also,
managers and
receivers of metrics.
National Airspace System
Airports designated as hubs by
airlines can build new terminals and
even runways. Airlines adjust prices
depending on other airlines’ pricing
structures. Flying public adjusts
travel plans or ticketing procedures
(e.g. back-to-back tickets take
advantage of supersaver fares for
work trips).
D: Companies who build systems to
be used for air traffic control.. FAA
acquisition organizations.
A: Air traffic control software and
hardware systems. Data recorders,
navigational aids, communications
devices, airplanes, jetways, baggage
loaders, runways, runway
information.
U: Flying public, pilots, homeowners
(noise levels), employees of airlines
and FAA, many others.
COMPLEX SYSTEMS SCIENCE
Key concepts of Complex Systems science are: [Sheard 2006]
1. Emergence: Emergence is related to the dependence of the whole on parts, the
interdependence of parts, and specialization of parts. While studying the parts in isolation
does not work, the nature of complex systems can be probed by investigating how changes
in one part affect the others, and the behavior of the whole.
2. Pattern formation: simple mathematical models capture pattern formation such as local
activation / long range inhibition.
3. Multiple (meta-) stable states: Small displacements (perturbations) lead to recovery, and
larger ones can lead to radical changes of properties. Dynamics do not average simply.
4. Multi-scale descriptions are needed to understand complex systems. Fine scales
influence large scale behavior.
5. It is difficult but not impossible to answer the question "How complex is it?"
6. Behavior (response) complexity: To describe the behavior of a system we try to describe
the response function: actions as a function of the environment. However, unless simplifying
assumptions are made, this requires an amount of information that grows exponentially with
the complexity of the environment.
7. Contrasts. Complex systems often exhibit contrasting characteristics, including simplicity
and complexity, order and disorder, random and predictable behavior, repeating patterns
and change
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 8 of 17
8. We cannot predict what a complex system will evolve into.
The complex adaptive systems cycle is shown in the first column of Table 2. [Gell-Mann 1994] The other
three columns show how our example systems evolve in accordance with this cycle.
Table 2. Complex Adaptive Systems Cycle Applied to Examples
Example:
CAS Cycle:
I. Coarse graining of
information from the
real world
II. Identification of
perceived regularities
INCOSE
Understand systems
engineering as practiced,
and abstracting enough to
create principles and
advice
Identify repeated patterns
in SE work
III. Compression into a
schema
Create principles and
guidance, possibly as
standards
IV. Variation of
schemata
V. Use of the schema
Seek review of guidance
from multiple places
Communicate guidance
and standards to members
CAB member companies
choose which activities to
include in their systems
engineering and choose
which standards to use and
support.
VI. Consequences in the
real world exerting
selection pressures that
affect the competition
among schemata
SE Process
Understand what is being
done on projects
Note similar activities
done by systems engineers
to engineer systems
Document practices as
activities, and order
abstracted versions into a
typical process
Programs tailor
standardized processes
Programs use tailored
processes
Programs do better or
worse depending in part on
how much SE is done and
how well...this gets back
to the SE process group
and successes are captured
National Airspace
System
Extract needs from
multiple ATC customers
Identify requirements for
the next generation ATC
system.
Write operational and
requirements documents
Use multiple systems, at
least old and new
Put new systems in action
alongside old systems
Only go to new system if
controllers can manage it
and it’s better, or at least
not obsolete and not
worse.
DIFFERENCES BETWEEN SE AND COMPLEX SYSTEMS
ENGINEERING
[Norman and Kuras 2006] provides the following table (what this paper calls systems engineering they
call “traditional systems engineering,” and they call complex systems “enterprises”). Table 3 is completely consistent with the concepts used in this paper and should be considered part of the paper’s
premises.
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 9 of 17
Table 3. Comparing Traditional SE (TSE) and Complex Systems Engineering (CSE)
TSE
CSE
Products are reproducible
Products are realized to meet pre-conceived
specification
Products have well-defined boundaries
Unwanted possibilities are removed during the
realizations of products
External agents integrate products
Development always ends for each instance of product
realization
Product development ends when unwanted possibilities
are removed and sources of internal friction (competition
for resources, differing interpretations of the same
inputs, etc.) are removed
No two enterprises are alike
Enterprises continually evolve so as to increase their
own complexity
Enterprises have ambiguous boundaries
New possibilities are constantly assessed for utility and
feasibility in the evolution of an enterprise
Enterprises are self-integrating and re-integrating
Enterprise development never ends – enterprises evolve
Enterprises depend on both internal cooperation and
internal competition to stimulate their evolution
PRINCIPLES OF COMPLEX SYSTEMS ENGINEERING
Complex Systems Engineering. This section looks at what principles apply to the engineering
of complex systems. First, it is important to note that systems engineering, which traditionally
looks at solving a specified problem with a design and then a solution, has many overlaps with
complex systems engineering, which looks primarily at identifying complex systems that already
exist and their ongoing evolutionary trends, and then affecting those trends in a way that will
provide more useful results. Figure 3, adapted from [Hybertson 2006], shows three types of
principles that apply to [traditional] systems engineering and complex systems engineering:
1. Different in kind
2. Different in degree
3. Common to all
1a
1b
SE
CSE
2a
2b
SE
CSE
3
Unified Foundation: Common characteristics
Figure 3. Principles of SE vs. Complex Sytems Engineering
adapted from [Hybertson 2006]
In the bottom block (3. Common to all) fall the basic principles of systems engineering that can
be used as-is in the development of complex systems. In the middle block (2. Different in
degree) are principles of systems engineering that can be used only with extension when
looking at complex systems. The DOD SOSE guide mentioned above [DoD AT&L 2006] focuses
on this block, in that its scope is only the adaptations of general systems engineering guidance
for single large programs developing systems of systems. Another good guide to such practices
is a cost model for systems of systems, called COSOSIMO; see [Boehm 2006].
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 10 of 17
The top block (1. Different in kind) addresses those principles that are not common between systems
engineering and complex systems. For the systems described in this paper, it can be argued that block 1a
(the left block) is the null set; i.e. all of the principles of systems engineering apply to these complex
systems, since the complex systems are composed of systems that are described by systems engineering.
However, block 1b (the right block) is not the null set. There are principles of complex systems
engineering that are different in essence from systems engineering.
This may seem to cast aspersions on systems engineering. Some people, including the author, have
long seen systems engineering as the theory of everything; therefore there is nothing that does not fall into
its purview. However, it is not a negative reflection on systems engineering at all. Mark Maier’s argument
over ten years ago for denoting certain systems “systems of systems” was that the principles that apply
differ, between systems and systems of systems [M. Maier 1998]. Using the same argument, which is
additionally appropriate since those systems-of-systems principles are for the most part applicable to
complex systems, the difference in name between “systems engineering” and “complex systems
engineering” is justified because of the principles that do fall into block 1b.
The existence of block 1b should be considered good news. The industry is currently suffering from
too-consistent failure of programs created to develop large systems, systems of systems, or complex
systems. Principles in block 1b present hope: hope that there are more things we can learn and
institutionalize so that we can approach these large systems differently and now begin to succeed.
Without this block we would be restricted to doing more of the same, perhaps with more control and more
discipline; yet there is no indication that such an approach would be successful. With this block we can at
least look to additional principles and see what else there is to combine with what we are already doing.
Regimen for Complex Systems Engineering. The most succinct description of the principles for
complex systems engineering is called the Regimen for Complex Systems Engineering [White 2005],
[Norman and Kuras 2006]. The regimen consists of eight CSE activities:
A. Pay explicit and conscious attention to the development environment
B. Shape development during operations
C. Identify outcome spaces, not specific outcomes
D. Establish rewards (and penalties)—incentives for components to make decisions that
cause the complex system to enter the targeted outcome spaces
E. Judge actual results
F. Apply developmental stimulants
G. Characterize continuously (measure current condition; but be careful not to result in
removal of variety)
H. Enforce safety regulations (police the complex system via vetting, processes that ensure
offline/online/inline, etc.)
(Note: the letters A-J are this author’s and are for identification only; these 8 steps are not sequential.)
Additional points made in [Norman and Kuras 2006] include:
I. Developmental precepts (Establish business rules of interactions)
J. Duality (Understand that development and operations are never entirely separate for complex
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 11 of 17
systems: manage the relationship among developers, artifacts, and operators).
This regimen requires one to the system as a complex system, as in the three previous examples.
However, in a workshop to assess whether this regimen would have applied to programs previously not
seen as complex systems, all of the regimen principles would have applied, or might have applied, to most
of the programs, in a manner that varied from strongly applicable (items A, B, C, F, G, H) to moderately
applicable (D and E). (I and J were not included in the first version.)
Other principles. Other principles for systems engineering follow; some principles are implicit
in statements of challenges. First are given six sets of principles copied or adapted from single
sources; last is a collation of individual principles from one source each.
1. Challenges of engineering complex systems (INCOSE SSEG): [Sheard 2006]




Loosely-structured organization. Complex systems are coalitions of entities that can
be neither commanded nor controlled, needing new management paradigms for
incentives, allocation, monitoring, and adapting in systems where those working
together may never have met.
Multiple stakeholders.
Information and knowledge management.
Distributive and collaborative environments.
2. Challenges of complex systems of systems (INCOSE) (adapted from [Haskins 2006])

System elements operate independently; System elements have different life cycles;
SoS engineering is never finished (due to evolution and changes); Fuzzy boundaries
cause confusion...no one controls the definition of the external interfaces; and
Complexity is a major issue. Answer: These are standard complex systems
descriptions, but hard to handle with traditional systems engineering

The initial requirements are likely to be ambiguous; and SOS Engineering is never
finished. Answer: Both are true, so the system will have to evolve.

Management can overshadow engineering. Since each system element has its own
product/project office, the coordination of requirements, budget constraints,
schedules, interfaces, and technology upgrades further complicate the development
of SOS. Answer: this is a major problem if you try to run the engineering of complex
systems with traditional, efficient, control-oriented systems engineering.
3. The Logic of Complex Systems Engineering, from [Minai 2006]

Local action, global consequences: Determine [and then exploit] local interactions
that lead to a desired global behavior via self-organization.

Expect the unexpected.
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 12 of 17

The inherent uniqueness of individual systems: Conformity is not often a virtue, and
novelty is not at all a vice.

Ensure redundancy and degeneracy at all levels

Allow for off-label utilization of modules

Opportunistically leverage the combinatorial explosion

Provide robustness-by-structure
4. Improving the rate of innovation (adapted from [Norman and Kuras 2006])


Entities (components of complex systems) should be in touch with one another for extended
periods of time
Entities’ pulse time should be reduced as much as possible

Value must be assessed correctly, and by appropriate parties



Assessed value must impose selective pressure
Layers should be established based on likely rate of change
Set up playgrounds where innovation can follow Discovery, Competition (Game), Codification, and Practice phases.
Nurture collaborative environments
Encourage partnerships
Encourage voluntary participation in the complex system
Allow “rice bowls” in the technical approach
Create opportunities for small-world phenomena to emerge: loose connections; advertising
and discovery
Permit “value-add” business models (as opposed to employer/contractor and sale of engineering hours), e.g. payment by use: money flows to those who produce demonstrated value
to the user.
Coopetition: create a marketplace. Creating value is inherently cooperative; capturing value
is inherently competitive.







5. Approaches for engineering complex engineered systems [Anderson 2006]
o Bottom-up simulation (bottom-up design)
o Top-down engineering (top-down design)
o Analogy and mimicry (archetypal, prototypal, inspirational)
o Interactive evolution (evolution, only with specific humans evaluating fitness)
Anderson suggests the following decision tree for selecting among these methods:
1. Is it possible to define an objective/fitness function mathematically? (In other
words, do you know what you are looking for?
 Yes: Go to Question 3
 No: Go to Question 2
2. Can system-level behavior be realized in real time?
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 13 of 17


Yes: Interactive evolution is a strong possibility
Either a slow, probably frustrating process of hand-tuning parameters or
systematic search through state space is likely involved, or a technique such
as open-ended search.
3. Is there a known analogous system?
 Yes: Emulate known system, tweaking and modifying as necessary, possibly
using evolutionary computation to parameterize system
 No: Go to Question 4.
4. Does the system involve or require multiple hierarchical levels, or is amenable to
their introduction? (in other words, can we chunk?)
 Yes: some element of top-down engineering may be possible; likely, in
conjunction with bottom-up modeling
 No: bottom-up modeling, adopting some of the general principles
expounded in the literature may work.
6. Project management principles to mitigate problem-solving oscillations [Mihm 2006]

Stop and re-start after system has diverged (reviews and quality gates)

Freeze the specification of second-priority components

Satisfice (forgo last bit of local component performance improvement)

Design components for partial system optimization (optimize bigger system chunks)

Immediate communications broadcasts of specific component change information to
specific areas with strong dependence

Exchange preliminary information

Introduce a coordinating hierarchy
Other principles


Build on sociological knowledge (INCOSE panel discussion).
The smarter our systems get, the more models of SOS collaboration are likely to be, or should
be, based on sociological and group dynamics constructs. “...thinking that traditional SE methods
and techniques are sufficient to meet SOS development and evolution challenges is naïve at best,
definitely risky, and probably dangerous. [Pohlmann 2006]
Building a system of systems is not that different from managing an organization, formal or
informal. Recruit support from existing systems. Acknowledge that every system has its own
motivations and goals. Study management and political science to learn how to do it right. [Abbott
2006]
Ashby’s Law of Requisite Variety: In order to achieve complete control, the variety of actions a
control system can execute must be at least as great as the variety of environmental perturbations
that need to be compensated. ... “For example, in order to make a choice between two
alternatives, [a control system] must be able to represent at least two possibilities, and thus one
distinction. From an alternative perspective, the quantity of variety that the model system or
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 14 of 17
controller possesses provides an upper bound for the quantity of variety that can be controlled or
modeled.” (based on [Heylighen 2006] and links therein)
Analyze man-made networks (e.g., SE process networks) using network analysis tools in order
to determine how to tweak them to advantage. (based on [Braha and Bar-Yam 2006] and [Valnerde
2006]).
Simulate multi-agent behavior to determine the best set of rules for your system of systems.
Explicitly impose variety on the system (this is the opposite of standardization and efficiency).
(based on [Kennedy 2003])
Establish the right kind of coordination. Coordination should be on a big enough scale to
perform the task, but not so big that you damage the independence of too many smaller-scale
elements. (based on [Bar-Yam 2006])
Focus engineering efforts and resources on (e.g., provide funding and technology support for),
and develop appropriate control and management strategies for, central product development
tasks. [Braha and Bar-Yam 2006]





CONCLUSIONS
It should be clear from the examples that the practice of systems engineering has many of the
characteristics of complex systems. Consequently, SE will evolve, and the goal of theorists and process
improvers should be to guide the evolution to a state of higher capability, which means more variety from
which to choose and therefore more complexity. To make use of one last principle:

To transition from doing SE to doing CSE (based on [Bar-Yam 2006])
1. Continually build on what already exists [It’s a complex system after all; it must
evolve] Evolution from scratch is slow; start from something close to what you want.
2. Focus on creating an environment and process rather than a product
3. Individual components must be modifiable in situ
4. Operational systems include multiple versions of functional components
5. Utilize multiple parallel development processes
6. Evaluate experimentally in situ
7. Gradually increase utilization of more effective components
Note: Effective solutions to specific problems cannot be anticipated
Of course, in building upon the systems engineering practices that already exist, systems engineers
should become more aware of the details and results of complex system (#1). INCOSE can contribute by
modifying itself to become the environment where systems engineers learn to use complex systems ideas,
and by reaching out deliberately to the complex systems research world (#2). It would be ideal if
processes for modifying SE practices, as captured by INCOSE (for example, [Haskins 2006] and
[INCOSE 2006]) were easy to update (such as a wiki) and frequently employed (#3).
#4 essentially means that multiple versions of good SE practices should be available and thus
compete against each other during the course of normal systems engineering practice. One way to enact
this is to build a set of complex systems practices, along the lines of [DOD AT&L 2006] but addressing
complex systems as “in scope,” make systems engineers familiar with them, and then see whether they
“win out” in the actual use scenarios compared to current systems engineering practices: Do they have
use? Are they more fit than non-CS practices? This last question is #6; #5 is actually a given, as we
already have many independent instances of systems engineering being performed simultaneously. Those
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 15 of 17
instances that are the most useful will then be performed most often, with the resulting increase in
capability of the systems engineering “system” (#7).
In this way we will be able to improve the effectiveness of systems engineering in ways we cannot
now anticipate.
REFERENCES
Abbott, Russ. “Systems of Systems: Whatever are we talking about?” Presentation to System of System
panel discussion, INCOSE symposium, 2006. [Abbott 2006]
Anderson, Carl, “Creation of desirable complexity: strategies for designing self-organized systems” in
Braha, Dan, Ali A. Minai, and Yaneer Bar-Yam. Complex Engineered Systems. Cambridge,
Massachusetts: Springer, 2006 [Anderson 2006]
Bar-Yam, Yaneer. Making Things Work. Boston, Massachusetts: NECSI Knowledge Press, 2004.
Bar-Yam, Yaneer. Figure. [Bar-Yam TBD]
Bar-Yam, Yaneer, “Engineering complex systems: multiscale analysis and evolutionary engineering,” in
Braha, Dan, Ali A. Minai, and Yaneer Bar-Yam. Complex Engineered Systems. Cambridge,
Massachusetts: Springer, 2006 [Bar-Yam 2006]
Boehm, Barry. “SoS vs. Systems Engineering: Activity Differences and Cost Drivers”, Presentation to
System of Systems Engineering Panel, INCOSE symposium, 2006. [Boehm 2006]
Bredemeyer, Dana and Ruth Malan. “Architecture Definitions.” Bredemeyer Consulting, 2006. Available
from http://www.bredemeyer.com/pdf_files/Definitions.pdf, 2006 [Bredemeyer 2006]
Braha, Dan, Ali A. Minai, and Yaneer Bar-Yam, eds. Complex Engineered Systems: Science Meets
Technology. Cambridge, Massachusetts: Springer NECSI, 2006.
Braha, Dan, Ali A. Minai, and Yaneer Bar-Yam, eds. Complex Engineered Systems: Science Meets
Technology. Cambridge, Massachusetts: Springer NECSI, 2006. [Braha, Minai, and Bar-Yam 2006]
Braha, Dan and Yaneer Bar-Yam, “The Structure and Dynamics of Complex Product Design,” in Braha,
Dan, Ali A. Minai, and Yaneer Bar-Yam. Complex Engineered Systems. Cambridge, Massachusetts:
Springer, 2006. [Braha and Bar-Yam 2006]
Defoe, J. C. “An Identification of Pragmatic Principles-Final Report, Version 0”. Seattle, Washington:
International Council on System Engineering, 1993. [Defoe 1993]
DOD AT&L. System of Systems Engineering Guide: Considerations for Systems Engineering in a
Systems of Systems Environment, Director, Systems and Software Engineering, Deputy
Undersecretary of Defense (Acquisition and Technology), Office of the Undersecretary of Defense
(Acquisition, Technology, and Logistics), Draft October 17, 2006. [DoD AT&L 2006]
duPreez, Lukas Johannes and Abraham Johannes Smith. “The Application of Complexity Theory in the
Development of Large-scale ICT Systems,” Proceedings of the Fourteenth International Council on
Systems Engineering Annual Symposium, Toulouse France, 2004.
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 16 of 17
Ferris, Timothy L. J. “Systems of systems engineering requires new methods if you are talking about new
kinds of systems of systems,” Presentation to System of System panel discussion, INCOSE
symposium, 2006. [Ferris 2006]
Gell-Man, M., “Complex Adaptive Systems”, in Cowan et al., Complexity, Metaphors, Models, and
Reality,” SFI studies in the Sciences of Complexity, New York: Addison-Wesley, 1994. Cited in [J.
Maier 2006], p. 134. [Gell-Mann 1994]
Haskins, Cecilia (ed.). Systems Engineering Handbook: A Guide for System Life Cycle Processes and
Activities. International Council on Systems Engineering, 2006. [Haskins 2006]
Heylighen, F. The Growth of Complexity. Available at http://pespmc1.vub.ac.be/COMPGROW.html.
[Heylighen 2006]
Hybertson, Duane, “What concepts of systems science support systems engineering?” Presentation to
INCOSE SSEG meeting, July 2006. [Hybertson 2006]
IEEE,
“2006 International Conference on Systems of Systems
http://ieeesose2006.ece.unm.edu/sose_2006_cfp.pdf. [IEEE 2006]
Engineering,”
INCOSE,
Guide
to
the
Systems
Engineering
Body
of
Knowledge,
http://www.incose.org/practice/guidetosebodyofknow.aspx [INCOSE 2006].
website
available
at
at
Kennedy, Michael N. Product Development in the Lean Enterprise: Why Toyota’s System is Four Times
More Productive and How You Can Implement It. Richmond, Virginia: The Oaklea Press, 2003.
[Kennedy 2003]
Klein, Mark, Hiroki Sayama, Peyman Faratin, and Yaneer Bar-Yam, in Braha, Dan, Ali A. Minai, and
Yaneer Bar-Yam, eds. Complex Engineered Systems: Science Meets Technology. Cambridge,
Massachusetts: Springer NECSI, 2006 [Klein 2006]
Maier, Jonathan R. A. and Georges M. Fadel. “Understanding the Complexity of Design.” in Braha, Dan,
Ali A. Minai, and Yaneer Bar-Yam, eds. Complex Engineered Systems: Science Meets Technology.
Cambridge, Massachusetts: Springer NECSI, 2006. [J. Maier 2006]
Maier, M. W., Architecting Principles for Systems-of-Systems, Systems Engineering, 1:4, pp 267-284,
1998.
Mihm, Jürgen and Christoph H. Loch, “Spiraling out of control: Problem-solving dynamics in complex
distributed engineering projects,” in Complex Engineered Systems, Braha, Dan, Ali A. Minai, and
Yaneer Bar-Yam. Cambridge, Massachusetts: Springer, 2006. [Mihm 2006]
Minai, Ali A., Dan Braha, and Yaneer Bar-Yam. “Complex Engineered Systems: A New Paradigm,” in
Complex Engineered Systems, Braha, Dan, Ali A. Minai, and Yaneer Bar-Yam. Cambridge,
Massachusetts: Springer, 2006. [Minai 2006]
Norman, Douglas O. and Michael L. Kuras. “Engineering Complex Systems.” in Braha, Dan, Ali A. Minai,
and Yaneer Bar-Yam, eds. Complex Engineered Systems: Science Meets Technology. Cambridge,
Massachusetts: Springer NECSI, 2006. [Norman and Kuras 2006]
Pohlmann, Lawrence D. “Is SE for SOSs Really Any Different? – Yes!! Qualitatively & Quantitatively.”
Presentation to System of System panel discussion, INCOSE symposium, 2006. [Pohlmann 2006]
Rechtin, Eberhardt. Systems Architecting: Creating & Building Complex Systems. Englewood Cliffs, New
Jersey: Prentice Hall, 1991. [Rechtin 1991]
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.
Sheard:Principles of Complex Systems for SE
Page 17 of 17
Rechtin, Eberhardt and Mark W. Maier. The Art of Systems Architecting. New York: CRC Press, 1997.
[Rechtin and Maier 1997]
Sheard, Sarah. “Practical Applications of Complexity Theory for Systems Engineers”. Proceedings of the
Fifteenth Annual International Council on Systems Engineering. (cd). International Council on
Systems Engineering, 2005. [Sheard 2005]
Sheard, Sarah. “Definition of the Sciences of Complex Systems.” INSIGHT (volume 9 #1). Seattle,
Washington: International Council on Systems Engineering, October 2006, p. 25. [Sheard 2006]
Systems of Systems Engineering Center of Excellence website at www.sosece.org. [SOSECE 2006]
University
of
Michigan.
“About
the
Science
of
Complexity”.
http://www.cscs.umich.edu/about/complexity.html, 2006. [UMich 2006]
Website
at
Valnerde, Sergi and Ricard V. Sole, “On the Nature of Design,” in Braha, Dan, Ali A. Minai, and Yaneer
Bar-Yam. Complex Engineered Systems. Cambridge, Massachusetts: Springer, 2006 [Valnerde
2006]
White, Brian E. “Engineering Enterprises Using Complex Systems Engineering.” Presentation at First
Annual Systems of Systems Engineering Conference, Johnstown PA, June 2005. [White 2005]
BIOGRAPHY
Sarah A. Sheard is the Principal of Third Millennium Systems LLC, in Great Falls, Virginia. In this
capacity she develops courses and other materials to help bring together the sciences of complex systems
with systems engineering. Ms. Sheard, an INCOSE Fellow, received the 2002 Founder’s Award for a
variety of INCOSE’s contributions, including publishing over 30 papers, chairing the Measurement
technical committee and the Communications committee, and serving as program chair and director of the
Washington Metropolitan Area chapter. Ms. Sheard has worked in systems engineering and process
improvement for 25 years, including satellite systems and air traffic control software systems.
Copyright ©Third Millennium Systems LLC; Draft Version for Review Only.