Complex Systems CoP Complex System Engineering

1
Complex Systems CoP Complex System Engineering

• R. Abbott
• Corporate Chief Architect/Engineer Division
• (Rotation)
• 19 April 2007

2
Complex Systems Engineering

• Complex systems are no longer mysterious.
• We have a broad consensus about
• what we mean by a complex system,
• what their properties are, and
• how they operate.
• Its time to put complex systems to work.

3
Characteristics structure

• Multi-scalar, i.e., multiple levels of
  abstraction
• IT systems involve quantum physics, solid-state
  electronics, gates logic, software (often many
  levels), CONOPs,
• Prone to phase transitions/chaos small change ?
  big effect.
• Each level illustrates emergencesometimes
  planned sometime not.
• But each level has a (physical) feasibility
  range.
• If the system involves real physical stuff
• No useful bottom level. Quarks? Quantum waves?
  Strings?
• Hence no good models of evolutionary arms races
  or for evolving or simulating geckos, which rely
  on the van der Waals force to climb.
• The levels cannot be completely isolated from
  each other
• or we would have magic, i.e., new sources of
  causation, e.g., vitalism.
• except when implemented in software(!). But still
  have feasibility ranges.

4
Characteristics group/environment

• Intimately entangled with its environment.
• Built to interact with its environmentto do
  something in the world.
• Must adapt to a continually changing environment
• The environment continually adapts to it.
• Can often be controlled/manipulated by modifying
  its environment. (Snake story)
• Simultaneously (a) deployed and (b) under
  development and self-repair, e.g., biological
  organisms, governments, corporation, Wikipedia.
• Each level of abstraction is often a multi-sided
  platform.
• A shopping center, an operating system, a
  browser, a standard. (Plug play satellite.)
• Dynamic entities are real but not rigidly
  decomposable. (Chicken example).
• Must extract energy from its environment to
  persist. (Far from equilibrium.)
• Societies agents not monolithic structures
  system of systems .
• A new group leader selected, employees go home at
  night.
• Reductionist blind spot. Group entities exist
  even though they can be explained.
• Reductionism/decomposition not a good model.
  Components continually change.
• Requires a well thought out governance structure
  the difference between a collection and a
  functioning organization. (Wilson, Evolution for
  Everyone.)

5
Innovative (internal) environments

• Structure governance the (within-group)
  environment as a commons, e.g., the free-market
  economic system, the web. (DoD transformation)
• Encourage individual action that benefits both
  the individual and the group at the expense of
  neither.
• Minimize overhead bureaucracy, corruption,
  extortion, free-riders,
• Minimize within-group conflict and cancers
  without stifling innovation.
• Decentralized but with some centralized
  authority. A reasonable level of stability and
  continuity. A means to change when needed.
  Governance requires individual decisions. How to
  mitigate problems caused by the inevitable
  conflicts of interest.
• Infrastructures/platforms communication,
  transportation, money banking, judicial,
• Means to create new ones.
• How can a top-down command organization support
  bottom-up innovation?
• How can a leader emerge without rising through
  the ranks?
• Start a business, run for office, write a paper,
  (Whats the military equivalent?)
• How can new products/services be created and
  installed?
• Anyone can create a web site, file a patent,
  (Whats the military equivalent? DARPA.)
• How can energy aggregators emerge? (Top-down
  organizations are energy distributors.)
• How can (and when should) an organization that is
  funded top-down enable bottom-up energy
  allocation and aggregation, i.e. markets? (Whats
  the military equivalent?)

6
Our task to put these ideas to work

• To refine, clarify, and formalize them.
• To evangelize.
• To make them intuitive, commonplace, and
  everydaya part of everyones vernacular.
• To use them to conceptualize our systems.
• To make them operational.
• To adapt them to practice in building real
  systems.
• To create development processes based on them.
• To build tools that allow anyone to use them.