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. • It’s 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 “emergence”—sometimes 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 environment—to 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 butnot 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, … (What’s the military equivalent?) • How can new products/services be created and installed? • Anyone can create a web site, file a patent, … (What’s the military equivalent? DARPA.) • How can energy aggregators emerge? (Top-down organizations are energy distributors.) • How can (and when should) an organization that isfunded top-down enable bottom-up energy allocation and aggregation, i.e. markets? (What’s 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 everyday—a part of everyone’s 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.