anystyle 1.0.0

data/res/finder/bd040gx5718.ttx

@@ -0,0 +1,4271 @@
+title         | CULTIVATING THE GROWTH OF COMPLEX ENGINEERED SYSTEMS
+              |                            USING
+              |     EMERGENT BEHAVIOURS OF ENGINEERING PROCESSES
+blank         | 
+              | 
+              | 
+              | 
+text          |                       A DISSERTATION
+              |    SUBMITTED TO THE DEPARTMENT OF MECHANICAL ENGINEERING
+              |           AND THE COMMITTEE ON GRADUATE STUDIES
+              |                   OF STANFORD UNIVERSITY
+              |          IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
+              |                      FOR THE DEGREE OF
+              |                    DOCTOR OF PHILOSOPHY
+              |                               IN
+              |                   MECHANICAL ENGINEERING
+blank         | 
+              | 
+              | 
+              | 
+text          |                         Eric Alan Byler
+              |                          March 2014
+              |                    © 2014 by Eric Alan Byler. All Rights Reserved.
+              |          Re-distributed by Stanford University under license with the author.
+blank         | 
+              | 
+              | 
+text          |                          This work is licensed under a Creative Commons Attribution-
+              |                          Noncommercial 3.0 United States License.
+              |                          http://creativecommons.org/licenses/by-nc/3.0/us/
+blank         | 
+              | 
+              | 
+              | 
+text          | This dissertation is online at: http://purl.stanford.edu/bd040gx5718
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                           ii
+text          | I certify that I have read this dissertation and that, in my opinion, it is fully adequate
+              | in scope and quality as a dissertation for the degree of Doctor of Philosophy.
+blank         | 
+text          |                                                               Larry Leifer, Primary Adviser
+blank         | 
+              | 
+              | 
+text          | I certify that I have read this dissertation and that, in my opinion, it is fully adequate
+              | in scope and quality as a dissertation for the degree of Doctor of Philosophy.
+blank         | 
+text          |                                                                                Mark Cutkosky
+blank         | 
+              | 
+              | 
+text          | I certify that I have read this dissertation and that, in my opinion, it is fully adequate
+              | in scope and quality as a dissertation for the degree of Doctor of Philosophy.
+blank         | 
+text          |                                                                                Friedrich Prinz
+blank         | 
+              | 
+              | 
+              | 
+text          | Approved for the Stanford University Committee on Graduate Studies.
+              |                              Patricia J. Gumport, Vice Provost for Graduate Education
+blank         | 
+              | 
+              | 
+              | 
+text          | This signature page was generated electronically upon submission of this dissertation in
+              | electronic format. An original signed hard copy of the signature page is on file in
+              | University Archives.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                           iii
+title         |                                    ABSTRACT
+blank         | 
+              | 
+text          |       Design, construction, and operation of very large, complex aerospace systems
+              | (mega-systems) is challenging, with potential cost and schedule over-runs and with
+              | awkward upgrade issues. These challenges are amplified when the engineering
+              | organization is producing multiple mega-systems in parallel. This dissertation applies
+              | information theory, genetic computing, and chaos theory to product development within a
+              | large distributed organization. The goal is design environments that efficiently produce
+              | mega-systems that are better able to evolve within the changing world context.
+              |       Complex systems are composed of dynamically interacting pieces that exhibit
+              | emergent behaviours as a result of their growth and/or the passage of time. Modern large
+              | engineered systems (~10,000+ man-years of design time), such as the American Air
+              | Traffic Control System and International Space Station, exhibit complex behaviour over
+              | their life, including design, installation, operation, and growth. The desired capability of
+              | the systems is so complex that it is difficult and time consuming to consistently specify
+              | detail for what is desired. The installation and operation of the complex systems changes
+              | the environment in which they are installed, creating a continuously changing context for
+              | follow-on and adjunct system requirements. Finally, maintenance and growth
+              | characteristics for complex systems, including new adjunct systems, exhibit various
+              | levels of brittleness.
+              |       This dissertation develops a new type of model to analyze the design and
+              | construction of mega-systems, based on combining an organization network-model with
+              | an information-transfer link-model. Analysis of previous efforts within the Design
+              | Research and the System Engineering communities shows three major shortcomings:
+              | they assume efficient network connectivity, they assume static networks, and they
+              | assume loss-less data transfer. A new model type is developed and exercised to examine
+              | methods and techniques to improve mega-system design and construction, and then
+              | validated in a three-year experiment implementing an enterprise product delivery process.
+              | Model development is based on data from US aerospace companies and programs
+              | spanning the last 30 years.
+blank         | 
+              | 
+              | 
+meta          |                                              iv
+text          |      The design of complex systems is not a linear, mechanistic process, but rather a
+              | multi-dimensional, growth process that can be cultivated over and above the analytical
+              | disciplines of design and optimization. The duality of a complex system designing a
+              | complex system reduces determinism. This dissertation identifies parameters of
+              | information exchange activities that can be adjusted to produce an efficient, successful
+              | outcome, albeit a non-deterministic outcome. This adjustment or shaping is similar to
+              | guided genetic evolution of organizations that produce mega-systems as the product of
+              | their computation, but within a restricted context of specified, but evolving, goals and
+              | constraints.
+              |      This new analytical framework shows how to match information flow
+              | characteristics to emergent engineering activities to improve the efficiency and quality of
+              | the design process, and to improve the efficiency and coupling of research and
+              | development activities within the larger organization. Information flow must not be
+              | confused with data transfer. Information flow parameters include information resolution,
+              | variability, time scale, compression, link bandwidth, connectivity maps, and more. For
+              | instance, simply avoiding information aliasing in chaotic channels by matching the flow
+              | to the information aging rate can improve design efficiency 80% and product delivery
+              | efficiency 50% in the overall steady state.
+              |      The implication of these results is a radical improvement in procurement of large
+              | systems. However, inherent linkages to government organizations that typically fund
+              | these large scale projects require a dual adaptation approach similar to meta-norms in
+              | game theory. Otherwise, the emergent properties of efficient engineering management
+              | will cause a reversion to a lower level of capability per status quo. Also, in order to
+              | support the greater output rate, mega-system specifications will become somewhat non-
+              | deterministic and delivery will rely inherently on product engineering, requiring a change
+              | in perspective of program management. This is beneficial evolution of the organization
+              | to improve delivery, and the total value delivered to society will accrue at higher
+              | compound growth rates.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                               v
+title         |                            ACKNOWLEDGEMENTS
+blank         | 
+              | 
+              | 
+text          |        I would like to thank Professor Larry Leifer for his support of this effort as
+              | it evolved over time, and for his enthusiasm and generosity sharing the breadth of
+              | the design experience.
+blank         | 
+              | 
+text          |        I would like to thank Tess for her commitment, support, and enjoyment of
+              | the roving, rambling path to get here and beyond.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              vi
+title         |                                                TABLE OF CONTENTS
+text          | 1     Introduction ................................................................................................................. 1
+              |     1.1     Problem ................................................................................................................ 1
+              |     1.2     Mega Design Communities and Design Organization Model ............................. 3
+              |     1.3     Information Transfer and Link Model ................................................................. 4
+              |     1.4     Results .................................................................................................................. 9
+              |     1.5     Conclusions ........................................................................................................ 13
+              |       1.5.1        Design of Individual Mega-Systems ........................................................... 13
+              |       1.5.2        Company and Design-Organization Implications ....................................... 14
+              |       1.5.3        Government and Societal Implications ....................................................... 15
+              | 2     Network Model Development and Mega-Organizations .......................................... 17
+              |     2.1     Structure of Very Large Aerospace Design Communities ................................. 17
+              |     2.2     Network Characteristics ..................................................................................... 21
+              |     2.3     Abstraction to Meta-Network Model ................................................................. 27
+              | 3     Link Model Development ......................................................................................... 28
+              |     3.1     Model Overview ................................................................................................. 28
+              |     3.2     Design Information ............................................................................................ 31
+              |       3.2.1        Information in Design Communities .......................................................... 31
+              |       3.2.2        Information Modeling ................................................................................. 34
+              |       3.2.3        Product Entropy and Information Packages ............................................... 36
+              |       3.2.4        Information Growth, and Product Evolution .............................................. 39
+              |     3.3     Task Variety ....................................................................................................... 42
+              |       3.3.1        Variety and Information Processing ........................................................... 42
+              |       3.3.2        Variety in Distributed Product Development ............................................. 44
+              |     3.4     Information Transfer in Chaotic Channels ......................................................... 46
+              |       3.4.1        Dynamical Systems and the Logistics Map ................................................ 46
+              |       3.4.2        Information Transfer in Chaotic Channels ................................................. 48
+              |       3.4.3        Multi-scale Information Transfer ................................................................ 51
+              |       3.4.4        Combined Varietal, Organizational, and Temporal Aliasing ..................... 57
+              |       3.4.5        Noise in Chaotic Channels .......................................................................... 59
+              |       3.4.6        Synchronization .......................................................................................... 59
+blank         | 
+meta          |                                                                 vii
+              | 4     Application of Integrated Link/Network Model ....................................................... 60
+text          |     4.1     Matching Scale Dispersion to Time Regimes .................................................... 60
+              |     4.2     Identification of Candidate Links, Nodes, and Chains....................................... 63
+              |     4.3     Network Improvements ...................................................................................... 66
+              |       4.3.1        Link Discontinuity Adjustment................................................................... 67
+              |       4.3.2        Link-Chain Improvement............................................................................ 69
+              |     4.4     Cultivated Changes and Observed Emergent Side-Effects ................................ 72
+              | 5     Performance Observations and Implications ............................................................ 75
+              |     5.1     R&D Applicability Performance ........................................................................ 75
+              |     5.2     Estimating the Amount of Communication you Should Afford ........................ 76
+              |     5.3     Expected Product Changes ................................................................................. 77
+              |       5.3.1        Exporting Products at Delivery Dates......................................................... 78
+              |       5.3.2        Incremental Technology Incorporation....................................................... 79
+              |       5.3.3        Coupled Efficiency ..................................................................................... 80
+              |       5.3.4        Company and Product Goals ...................................................................... 80
+              |     5.4     Limits to Change ................................................................................................ 81
+              |     5.5     Applicability ....................................................................................................... 82
+              | 6     Conclusions ............................................................................................................... 85
+              |     6.1     More Efficient Design of Mega-Systems ........................................................... 85
+              |     6.2     Relying on Emergence and Organizational Computation .................................. 86
+              |     6.3     Government Aerospace, Low-Price Procurement, and Overhead Rates ........... 87
+              |     6.4     Additional Research Vectors .............................................................................. 89
+              |       6.4.1        Organizational Memory .............................................................................. 89
+              |       6.4.2        Engineering Tools ....................................................................................... 89
+              |       6.4.3        Long-Scale Neural Training of Sub-Networks ........................................... 89
+              | 7     Appendix A – Research Background........................................................................ 90
+              |     7.1     Evolutionary Design ........................................................................................... 90
+              |     7.2     Engineering Systems .......................................................................................... 91
+              |     7.3     Flow-Service-Quality Engineering .................................................................... 92
+              |     7.4     Engineering Tools .............................................................................................. 93
+              | 8     References ................................................................................................................. 95
+blank         | 
+meta          |                                                                viii
+title         |                                             LIST OF FIGURES
+blank         | 
+              | 
+text          | Figure 1-1 Examples of Mega-Systems ............................................................................. 2
+              | Figure 1-2 Development of Abstracted Design Organization Model ................................ 3
+              | Figure 1-3 Link Information Transfer Model underpins all node connections ................. 5
+              | Figure 1-4 Link Information Transfer Model .................................................................... 6
+              | Figure 1-5 Information Exchange Resonances .................................................................. 8
+              | Figure 1-6 Information Transfer Regimes and Amplification Factors .............................. 9
+              | Figure 1-7 Set of Consistent Guides to Repair Discontinuity ......................................... 10
+              | Figure 1-8 Link-chain Paths of Interest ........................................................................... 12
+blank         | 
+              | 
+text          | Figure 2-1 Geographic Distribution ................................................................................. 18
+              | Figure 2-2 Conceptual Organizational Structure, Staffing Levels, and Characteristics .. 19
+              | Figure 2-3 Organizational Size Characteristics ............................................................... 20
+              | Figure 2-4 Overlapping Hierarchies ................................................................................ 21
+              | Figure 2-5 Typical Hierarchical Organization ................................................................. 22
+              | Figure 2-6 Control Stability for Various Organizations .................................................. 23
+              | Figure 2-7 Organizational Performance........................................................................... 23
+              | Figure 2-8 Typical and Combined Network Characteristics ........................................... 24
+              | Figure 2-9 Abstracted Organizational Model .................................................................. 27
+blank         | 
+              | 
+text          | Figure 3-1 Parameters of Link Transfer Model ............................................................... 29
+              | Figure 3-2 Organizations, Information Products, and Time Epochs ............................... 32
+              | Figure 3-3 Product Entropy Flexibility for Related Designs ........................................... 36
+              | Figure 3-4 Product Entropy Levels for different rates of Growth ................................... 38
+              | Figure 3-5 Mutual and Conditional Information ............................................................. 39
+              | Figure 3-6 Design Process Models and Networks ........................................................... 44
+              | Figure 3-7 Meta-Performance Measures of Distributed Product Development .............. 45
+              | Figure 3-8 Bifurcation Diagram....................................................................................... 47
+              | Figure 3-9 Conditional, mutual, and total information for two and three time steps ...... 49
+              | Figure 3-10 Mutual information for larger iterations of time .......................................... 50
+blank         | 
+meta          |                                                           ix
+text          | Figure 3-11 Values for Combined Organization (OAF) and Variety (VAF) Aliasing .... 55
+              | Figure 3-12 Values for Time Aliasing Factor (TAF)....................................................... 56
+              | Figure 3-13 Network with total Product Information Aliasing Factors (p) ..................... 58
+blank         | 
+              | 
+text          | Figure 4-1 Mutual, Conditional, and Postdicted (I(y)) Information ................................ 61
+              | Figure 4-2 Mutual information for larger numbers of iterations ..................................... 62
+              | Figure 4-3 Information Transfer Regimes and Amplification Factors ............................ 64
+              | Figure 4-4 Set of Consistent Guides to Repair Discontinuity ......................................... 67
+              | Figure 4-5 Link-chain Paths of Interest ........................................................................... 70
+              | Figure 4-6 Cultivated Organizational Change ................................................................. 74
+blank         | 
+              | 
+text          | Figure 5-1 Improved Value Over Time ........................................................................... 78
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                           x
+title         |                                       GLOSSARY
+blank         | 
+              | 
+              | 
+text          | Agent – an actor that undertakes an action in a design chain, here including individuals,
+              |        design groups, project teams, discipline departments, support functions, small
+              |        businesses, etc. A node with variety.
+              | Aliasing – loss of understanding of some detail within a set of information. Similar to
+              |        straight-line aliasing in graphics or image analysis.
+              | Chaotic channel – an information exchange channel or link, that is susceptible to
+              |        dynamic evolution with the ensuing noise injection and dissipation.
+              | Communicativity - is related to the number, speed, and bandwidth of connections between
+              |        agents, spanning multiple scales (individual, group, organization) with different
+              |        parameters at each scale.
+              | Context Variety– variety needed to acquire contextual information from an external
+              |        source to connect the design to external detail.
+              | Directed links – a directed link in graph theory, or here a link through which information
+              |        flows only one way.
+              | Encoded – packaged information such that it can be understood by an undefined recipient
+              |        at an undefined time in the future.
+              | Evolutionary computing organisms – complex systems that evolve overtime including
+              |        genetic populations.
+              | Exchange resonances – states where information package format and timing is consistent
+              |        with environmental transmission characteristics.
+              | External norms – in game theory, externally applied forces that affect the pareto solution.
+              | Information content – the amount of information being exchanged.
+              | Information resolution – the resolution or scale of the information similar to image
+              |        resolution and engineering tolerances.
+              | Information theoretic – Information modeled in a manner similar to entropy, statistical
+              |        mechanics, and/or quantum physics.
+blank         | 
+              | 
+meta          |                                              xi
+text          | Link – a link on a graph or network connecting two nodes, here especially connections
+              |        between groups to exchange information.
+              | Link chains - sets of directed links corresponding to control paths required to focus the
+              |        organization on particular future goal states.
+              | Mega-systems - systems whose design and production efforts span on the order of 10
+              |        years of development time and require on the order of 10,000 man-years of effort.
+              | Mega-organizations – organizations that have tens of thousands of engineers spread
+              |        widely across a large geographic area. Not necessarily with singular control.
+              | Niche construction – in biology or genetics, an internal adjustment to better fit the local
+              |        environment for improved performance.
+              | Node – a node on a graph or network, here including individuals, design groups, project
+              |        teams, discipline departments, support functions, small businesses, etc.
+              | Non-directed graph – in graph theory having multi-directional links, here especially bi-
+              |        directional links connecting two separate nodes.
+              | Post diction - the forward use of information to increase the knowledge of another actor
+              |        in a strictly subsequent time state. The inverse of prediction in an information
+              |        theory sense.
+              | Resolution Variety – variety needed to add more detailed design information to increase
+              |        the fidelity or resolution of the design.
+              | Scale-free network – in network theory, a random network with a degree distribution that
+              |        follows a power law, at least asymptotically.
+              | Translation Variety – variety needed to translate or extract information from the current
+              |        design to further the design in an additional dimension.
+              | Transmitted – delivering information such that it reaches additional recipients.
+              | Task-bits – quantum information of a task, similar to data bits or letters in a document.
+              | Variety – the diverse set of capabilities needed by an actor or group to execute an
+              |        activity. The variety represents the set of capabilities and functionality.
+blank         | 
+              | 
+              | 
+              | 
+text          |                                              xii
+              |         …complex products
+              |  produced by complex organizations
+              | become fragments of complex systems
+blank         | 
+              | 
+              | 
+              | 
+meta          |                 xiii
+title         | 1 Introduction
+text          | Engineers propose to understand canonical mechanisms and prototypical behaviours to
+              | better control the systems development effort. But you cannot control a complex system
+              | in which you are immersed, and within an environmental context that changes before
+              | your controls can respond. You must cultivate and guide these systems at various and
+              | appropriate time scales.
+blank         | 
+              | 
+text          | This dissertation develops a new type of model to analyze the design and construction of
+              | mega-systems, based on combining an organization network-model with an information-
+              | transfer link-model. This combined model is exercised to examine methods and
+              | techniques to improve mega-system design and construction, and then validated in a
+              | three-year experiment implementing an enterprise product delivery process. Model
+              | development is based on data from US aerospace companies and programs spanning the
+              | last 30 years.
+blank         | 
+              | 
+text          | Previous efforts within the Design Research and the System Engineering communities to
+              | analyze and improve Engineering Processes that are used to design mega-systems are
+              | summarized in Appendix A. Analysis of these recent efforts shows three major
+              | shortcomings: they assume efficient network connectivity, they assume static networks,
+              | and they assume loss-less data transfer. This dissertation is a first step toward correcting
+              | these deficiencies, and accounting for these very real constraints.
+blank         | 
+title         | 1.1 Problem
+text          | Large Complex Mega-Systems are defined here as efforts that span 10 years of
+              | development time (design and production) and require 10,000 man-years of effort.
+              | Typically engineers are drawn from a wide supply chain spanning a large geographic
+              | area. These systems include the NASA Space Shuttle, the International Space Station
+              | (ISS), and planned Mars and asteroid missions (Figure 1-1). Terrestrial examples include
+              | the Air Traffic Control Systems (ATCS), missile defense systems, nuclear power plants,
+              | and others.
+blank         | 
+              | 
+              | 
+meta          |                                              1
+text          |                             Figure 1-1 Examples of Mega-Systems
+              | (A) Space shuttles Atlantis and Endeavor at Kennedy Space Center launch complexes 39A and 39B.
+              |                    (B) Artist’s concept of exploration of Mars’s moon Phobos.
+blank         | 
+              | 
+text          | Problems arise when developing these systems, likely caused by their immense scale.
+              | Some systems are never built, or take a much longer time than planned before the design
+              | is finalized for production: this is sometimes caused by requirements churn such as for
+              | the ISS and its precursors. Other systems exhibit upgrade brittleness such as the ATCS:
+              | here, because of either the safety requirements, distributed nature, or necessary
+              | incremental approach to upgrades, the follow-on replacement design was unable to close
+              | and had to be restarted several times at great expense. Some products collide with
+              | obsolescence issues since their design process takes so long that some of the originally
+              | included components are no longer available.
+blank         | 
+              | 
+text          | “About one in three major U.S. Defense Department programs since 1997 have had cost
+              | overruns of as much as 50 percent over their original projections. The overruns, found in
+              | 47 of 134 programs included in a study by the U.S. Government Accountability Office,
+              | were enough to trigger a law [Nunn-McCurdy Act] that requires congressional
+              | notifications and potential termination” [Capaccio 2011].
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                2
+text          |                         1.2 Mega Design Communities and Design Organization Model
+              |                         Mega-Systems are designed by Mega-Organizations that have tens of thousands of
+              |                         engineers spread widely across a large geographic area. Organizations are treated here as
+              |                         evolutionary computing organisms that evolve as they compute. An abstract
+              |                         organizational network model is developed in Section 2.0 as summarized in Figure 1-2.
+              |                         Subsequent discussion in Sections 3.0 and 4.0 will add measures of emergent parameters.
+blank         | 
+text          |                                            Louisville, CO
+              |                Bangor, WA                                     Denver, CO                            Newtown, PA
+              |                                            • Coherent
+              |                • FBM IA&T
+              |                                              Technologies                                           • Navigation Systems                                           Sector
+              |                                                                                                                                                                    Coord
+              |                                                                                                                                                                                                   Sector
+              |                                                                                                                                                                                                   Coord
+              |                                                                                                                                                                                                                               Major
+              |                                                                                                                                                                                                                                                                      Sector
+              |                                                                                                                                                                                                                                                                      Coord
+blank         | 
+text          |      Palo Alto, CA                                                                                  • Commercial Space                                                                                                      Teammates
+blank         | 
+              | 
+text          |     • ATC                                                                                                                                                                    BD                          PROG
+              |                                                                                                                                                                                                           PROG
+              |                                                                                                                                                                                                                                                            R&D
+              |                                                                                                                                                                                                            PROG
+              |                                                                                                                                                      Sector
+              |                                                                                                                                                                                                             PROG
+              |                                                                                                                                                                                                              PROG
+              |                                                                                                                                                      Coord
+              |                                                                                                                                                                              Exec                             Exec                                         Exec
+              |   Sunnyvale, CA
+              |                                                                                                    Valley Forge, PA
+              |     Santa Cruz, CA                                                                                 • Reentry Systems                                Adjacent
+              |                                                                                                                                                      Adjacent
+              |                                                                                                                                                                               BD                         Executive                             Senior                  Adjacent
+              |     • Test Support                                                                                                                                  Markets
+              |                                                                                                                                                        Adjacent
+              |                                                                                                                                                      Markets
+              |                                                                                                                                                         Adjacent
+              |                                                                                                                                                        Markets
+              |                                                                                                                                                          Markets
+              |                                                                                                                                                                             Director                       Staff                               Support               Technologies
+blank         | 
+              | 
+text          |                                                                                                    Washington, DC
+              |                                                                                                    • FBM Liaison                                                              BD                                                Advanced                  Senior
+blank         | 
+text          |                                                                                   Business         • Washington Ops              Program                                Research
+              |                                                                                                                                                                              Staff
+              |                                                                                                                                                                                                          Program
+              |                                                                                                                                                                                                           Program
+              |                                                                                                                                                                                                             Program              Develop
+              |                                                                                                                                                                                                                                                            Senior
+              |                                                                                                                                                                                                                                                              Senior
+              |                                                                                                                                                                                                                                                          Manager
+              |                                                                                                                                                                                                                                                               Senior
+              |                                                                                                                                                                                                                                                           ManagerSenior
+              |                                                                                                                                                                                                                                                             Manager
+              |                                                                                                                                                                                                                                                                   Senior
+              |                                                                                                                                                                                                                                                              ManagerSenior
+              |                                                                                                                                                                                                                                                                Manager
+              |                                                                                                                                                                                                                                                                  Manager
+blank         | 
+text          |                                                                            Development                                             Management
+              |                                                                                                                                                                                                                                                                    Manager
+              |                                                                                                    Arlington, VA                                                         Senior                                                                           Senior
+              |    Edwards AFB, CA                                                                                   BD
+              |                                                                                                    • Targets Prime            PROG                                    R&D
+              |                                                                                                                                                                         Engineer
+              |                                                                                                                                                                                                         Subsystem
+              |                                                                                                                                                                                                          Subsystem
+              |                                                                                                                                                                                                           Subsystem
+              |                                                                                                                                                                                                             Subsystem
+              |                                                                                                                                                                                                              Subsystem
+              |                                                                                                                                                                                                                                   CRAD
+              |                                                                                                                                                                                                                                    CRAD
+              |                                                                                                                                                                                                                                     CRAD
+              |                                                                                                                                                                                                                                      CRAD
+              |                                                                                                                                                                                                                                        CRAD
+              |                                                                                                                                                                                                                                                          Scientist
+              |                                                                                                                                                                                                                Subsystem                CRAD
+              |    • ABL
+              |                                                                                                                                                                                                                 Subsystem
+              |                                                                                                    Huntsville, AL
+              |                                                                                                    • Strategic & Missile Defense                     Tools              Engineer                        Engineers                Engineer
+              |                                                                                                                                                                                                                                                           Staff
+              |    El Segundo, CA                                                                                  • Ares Support
+              |                                                                                                                                                                                                                                                          Scientist
+blank         | 
+text          |    • MILSATCOM                                                                                       Exec                      Exec                                   Exec
+              |                                      Albuquerque, NM                                               Kings Bay, GA                                                        Discipline
+              |                                      • ATC                                                         • FBM IA&T                                                             Discipline
+              |                                                                                                                                                                          Director
+              |                                                                                                                                                                             Discipline
+              |                                                                                                                                                                            Director
+              |                                                                                                                                                                              Discipline
+              |                                                                                                                                                                                                   Suppliers                  Small               Universities
+              |                                                                                                                                                                              Director
+              |    Kauai, HI         White Sands, NM • ATK
+              |                                                                                                                                                                                Discipline
+              |                                                                                                                                                                               Director
+              |                                                                                                                                                                                  Discipline
+              |                                                                                                                                                                                 Director
+              |                                                                                                                                                                                                                             Business
+blank         | 
+              | 
+text          |    • PMRF                                                                      Courtland,   AL   Cape     Canaveral, FL                                                            Discipline
+              |                                                                                                                                                                                   Director
+              |                      • Missile Range • Targets &                                     Adjacent
+              |                                                                                • Targets &
+              |                                                                                                    BD
+              |                                                                                                  Eastern    Range
+              |                                                                                                                             Executive                 Senior
+              |                                                                                                                                                     Sector
+              |                                                                                                                                                                                      Discipline
+              |                                                                                                                                                                                        Adjacent
+              |                                                                                                                                                                                     Director
+              |                                                                                                                                                                                       Director
+              |                                                                 Stennis, MS          Markets     Director                     Staff                 Coord
+              |                                                                                                                                                      Support
+              |                                                                                                                                                                           ENG
+              |                                                                                                                                                                                        Technologies
+              |                                        Countermeasures                           Countermeasures • Launch Operations
+              |                                                                 • Propulsion
+              |                                                  Houston, TX      Center
+              |                           ~19,500 employees • Orion
+              |                                                                            New Orleans, LA           BD                                  Advanced                    Senior
+              |                             •   ~ 8,700 in Silicon Valley
+              |                                                                            • External Tank          Staff
+              |                                                                                                                             Program
+              |                                                                                                                                           Develop                   Manager
+              |                             •   ~ 4,700 in Denver area
+              |                             •   ~ 2,000 in New Orleans                     • Orion
+              |                             •   ~ 1,500 in Cape and V
+              |                             •   ~ 1,100 in Delaware Valley
+              |                                                                                                    Senior
+              |                                                                                                   Engineer
+              |                                                                                                                            Subsystem      CRAD
+              |                                                                                                                                                                      Senior
+              |                                                                                                                                                                     Scientist
+              | 009_03.18.08
+              |                             •   ~ 500 in Alabama
+blank         | 
+text          |                                                                                                                                                                      Staff
+              |                                                                                       Tools       Engineer                  Engineer     Engineer
+              |                                                                                                                                                                     Scientist
+blank         | 
+              | 
+              | 
+text          |                                                                                                   Discipline
+              |                                                                                                    Director
+              |                                                                                                                Operational              Prototype
+              |                                                                                                                   Systems               Systems
+              |                                                                                                    ENG
+              |                                                                                Engineering
+blank         | 
+text          |                                                              Figure 1-2 Development of Abstracted Design Organization Model
+              |                         (A) A large mega-organization (design community) of 100,000 people is spread across the wide range
+              |                         of North America in different cities. (B) Organizational groups (nodes) and major relations between
+              |                         them (links) are identified. (C) The nodes and links are then simplified into a two-dimensional
+              |                         structure to highlight parameters associated with activity duration, organization hierarchies, and
+              |                         different engineering capabilities and products.
+blank         | 
+              | 
+text          |                         The design-organization network model represents a distributed mega-design-community
+              |                         of 100,000 people producing a set of mega-systems over time. These people are
+              |                         assembled into various organizations including design groups, project teams, discipline
+              |                         departments, support functions, small businesses, etc. Each organizational group, or
+              |                         node, is composed of many people, and there may be multiple instances of any one
+              |                         group. The variety of people within each node provides a diverse set of capabilities to
+              |                         execute the group’s higher level function (see Section 3.3).
+blank         | 
+              | 
+meta          |                                                                                                                              3
+text          | Multiple nodes (groups) may connect to a single node performing a coordinative
+              | function, but each link conveys separate information in different contexts (sections 1.3
+              | and 3.0). Groups may be linked to multiple sets of groups in different fashions for
+              | different purposes such as product design, tool development, financial control, etc. These
+              | overlapping sets represent various sub-groups or sub-functions within the design
+              | community and within the abstract organizational network model.
+blank         | 
+              | 
+text          | The resulting organizational network model is neither fully-connected nor hierarchically
+              | connected nor even efficiently connected, but rather has scale-free connectivity such that
+              | nodes can have several possible connection paths, even for the same information transfer
+              | activity, but with different efficiencies and restrictions (see Section 2.2).
+blank         | 
+title         | 1.3 Information Transfer and Link Model
+text          | Earlier efforts in modeling multi-scale organizations with emergent properties [Byler
+              | 2000] showed the critical nature of multi-scale communications. Following an Adaptive
+              | Non-linear Testing technique [Miller 2007], the modeling validation and verification
+              | indicated massive instability around the parameters defining “communicativity”. This
+              | defined a critical area of investigation explored further in this dissertation.
+blank         | 
+              | 
+text          | “Communicativity” is related to the number, speed, and bandwidth of connections
+              | between agents. For individual design agents this is related, for example, to the number
+              | of emails sent per day, the number of addressees in an agents personal address book,
+              | number of off-site web-page accesses, typical phone usage, etc. For design groups, this is
+              | related to frequency and size of design reviews, availability and type of online design
+              | storage, geographic separation (bull-pen vs. cubicles), etc. For project swarms (groups,
+              | departments, small businesses), “communicativity” is rate of engineer reassignment, size
+              | and quality of information system network, frequency of training, and whether the project
+              | is owned by the company or someone else (which implies internalization of requirements
+              | and operations).
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                4
+text          | To address the importance of communicativity, an underpinning information transfer
+              | model for the network links was developed to better include factors addressing
+              | communications parameters as well as organization parameters, functional activities, and
+              | environmental constraints (Figure 1-3).
+blank         | 
+              | 
+              | 
+text          |                                                  Agent X                                                                          Agent Y
+blank         | 
+              | 
+text          |                                                                                                           Information Transfer
+blank         | 
+text          |         Business                          Program                          Research
+              |  Development BD                       PROG
+              |                                             Management                   R&D
+blank         | 
+text          |                                                                                                    Chaotic Channel (non-linear)
+              |                    Exec                Exec                              Exec
+blank         | 
+              | 
+              | 
+              | 
+text          |       Adjacent     BD                Executive                Senior                  Adjacent
+              |       Markets    Director              Staff                  Support               Technologies
+blank         | 
+              | 
+              | 
+text          |                     BD                             Advanced              Senior
+              |                                       Program
+              |                    Staff                            Develop             Manager
+blank         | 
+              | 
+              | 
+text          |                   Senior                                                 Senior
+              |                                      Subsystem      CRAD
+              |                  Engineer                                               Scientist
+blank         | 
+              | 
+              | 
+text          |                                                                          Staff
+              |        Tools     Engineer            Engineer      Engineer
+              |                                                                         Scientist
+blank         | 
+              | 
+              | 
+text          |                  Discipline
+              |                   Director
+              |                               Operational         Prototype
+              |                                  Systems          Systems
+              |                   ENG
+              |   Engineering
+blank         | 
+              | 
+text          |                               Figure 1-3 Link Information Transfer Model underpins all node connections
+              | Each link in the network model incorporates a detailed model of a chaotic communications channel.
+blank         | 
+              | 
+              | 
+text          | This link information transfer model applies to all connections in the network model, and
+              | is shown in additional detail in Figure 1-4.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                                                       5
+text          |  Link Information Transfer Model
+              |              “Node” parameters
+              |              defined by information encoding and transmitting activities
+              |              and by design information content, resolution, & processing
+              |                                             “Link” parameters
+              |                                             defined by relative design role
+              |     Agent X                                 and by organizational activities               Agent Y
+              |     w/ Variety 7                                                                           w/ Variety 9
+              |                             Encoder V6
+              |                                                                                                      Transmitter Vn
+              |                               Transmitter V7
+blank         | 
+text          |                                                environment, tools, time
+blank         | 
+              | 
+text          |                                                  Information Transfer
+blank         | 
+              | 
+              | 
+text          |                                        Chaotic Channel (non-linear)
+              |  Machining V1                                                             Receiver V1
+              |    Cost Analysis V2                                                           Decoder V2
+              |            Programmer V3
+blank         | 
+              | 
+text          |   Variety = a set of capabilities                                    when
+              |                and functionality                 Information Parameters (node + info package)
+              |                                                              are incompatible with
+              |   Agents = can be individuals,                 Transmission Line Parameters (link + environment)
+              |        groups, organizations,                               “aliasing” effects occur
+              |           or other complices
+blank         | 
+text          |                              Figure 1-4 Link Information Transfer Model
+blank         | 
+              | 
+text          | For the organization model developed here (Section 1.2 and 2.0), each node is an agent
+              | composed of many people (design groups, project swarms, etc.) in the sense defined by
+              | [Petrie 1996]. Agents can be individuals, groups, organizations, or other complices.
+blank         | 
+              | 
+text          | Each agent performs its function using a variety of people or skills. Producing a
+              | controller card, for instance, may require a machinist, a programmer, and a financial
+              | analyst. Then the product must be packaged and delivered. If one considers the
+              | controller card as inherently containing the design and product information, then the
+              | output could be termed to be encoded and transmitted, similar to packaged and delivered.
+blank         | 
+              | 
+text          | Depending on the complexity of the product or output of the Agent, it may require more
+              | or less variety of sub-tasks. The complexity of the product and/or of the agent is
+blank         | 
+              | 
+meta          |                                                            6
+text          | represented by the Variety (Vi) of internal skills. The variety represents the set of
+              | capabilities and functionality.
+blank         | 
+              | 
+text          | The incremental task executed (item produced) by an agent can be a physical or
+              | ephemeral addition. In any event, information was imposed on the inputs (machining,
+              | assembly sequence, tuning) to increase its usefulness and reduce the entropy of the parts.
+              | The type of information imposed on the inputs, and representing the final product (piece-
+              | part), is modeled by information content, resolution, and processing.
+blank         | 
+              | 
+text          | The node parameters include the information content and resolution, as well as the
+              | information encoding and transmission. Information is modeled in an information
+              | theoretic sense after [Shannon 1948] and [Bais 2010]
+blank         | 
+              | 
+text          |                   I() = -ipilogpi
+blank         | 
+              | 
+text          | Any new (conditional) information received by agent y from the information sent by
+              | agent x will be
+blank         | 
+              | 
+text          |                   I(y|x) = -iPx(xi)jPy|x(yj|xi)log2Py|x(yj|xj)
+blank         | 
+              | 
+text          | which expresses the fact that the receiver must interpret (decode) the information he
+              | receives based on their previous mutual understanding. Note that information data-bits
+              | can be interpreted similarly with design “task-bits”.
+blank         | 
+              | 
+text          | The Link parameters are defined both by the relative design roles of the attached nodes
+              | within the organizational activities, and by the environment within which the products
+              | pass and exist. The effect of relative design roles is driven not so much by the different
+              | activities, but rather by how much work must be done to understand or incorporate
+              | (receive and decode) the material being transmitted by the input agent. The effect of the
+              | design environment includes how the information is stored (transmission is not
+              | instantaneous), the amount of time delay between production and use, the types of tools
+blank         | 
+              | 
+meta          |                                                    7
+text          | used to decode or process the intermediate product, etc. Because of the dynamic nature
+              | of the information and the link, this model is a chaotic channel.
+blank         | 
+              | 
+text          | Information production, coding, aging, and obsolescence is modeled with the logistic
+              | growth curve [Verhulst 1838]
+blank         | 
+              | 
+text          |                                          xt+1 = axt (1 - xt)
+blank         | 
+              | 
+text          | such that information is subject to dynamic effects over time. Iteration of mutual
+              | information over time shows “exchange resonances” (Figure 1-5).
+blank         | 
+              | 
+text          | When the Information parameters (node and product information package) are
+              | incompatible with Transmission Link parameters (link and environment), aliasing occurs.
+              | The information or product is not completely usable, or has become corrupted, and
+              | additional work will be needed to adapt or understand it. In fact even minor mismatches
+              | create observable aliasing; it is a matter of scale.
+blank         | 
+              | 
+text          |                                7
+              |                                                                                       B
+              |                                6
+              |                                                           A                                      C
+              |    Mutual Information I(x^y)
+blank         | 
+              | 
+              | 
+              | 
+text          |                                5
+blank         | 
+text          |                                4
+              |                                                                                                            t = 10
+              |                                3                                                                           t = 20
+              |                                                                                                            t = 40
+              |                                2
+blank         | 
+text          |                                1
+blank         | 
+text          |                                0
+              |                                    0.0              1.0              2.0              3.0            4.0
+              |                                                                       a
+blank         | 
+              | 
+text          |                                                     Figure 1-5 Information Exchange Resonances
+              | Information can be exchanged more completely at certain periods of time at the “resonant” nodes A,
+              | B, and C on the graph where a = 1, 3, and 3.5.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                            8
+title         | 1.4 Results
+text          | Model parameters were developed for each link in the organization model. Multiple
+              | parameters are summarized into a value for product information characteristics ‘p’, and
+              | for transmission characteristics ‘a’, for each link. Several of these are shown in Figure
+              | 1-6 to highlight cases of interest. The product information aliasing factor ‘p’, has been
+              | placed into three bins: (s) small (1-2), (m) medium (3), and (l) large (4-6). The
+              | environmental transmission/transfer rate is represented by ‘a’. (Note that ‘a’ is non-
+              | continuous, and has a reverse scale compared to ‘p’ (see Sections 3.4.2 and 4.2).)
+blank         | 
+              | 
+text          |                        BD                                        PROG                                          R&D
+blank         | 
+              | 
+              | 
+text          |                        Exec                                          Exec                                      Exec
+blank         | 
+text          |                                                                                                m=3
+              |             Adjacent            BD
+              |                                                    m=3
+              |                                                    a=3   √       Executive
+              |                                                                                               a=1
+              |                                                                                                     Senior                  Adjacent
+              |             Markets           Director                             Staff                            Support               Technologies
+blank         | 
+              | 
+text          |                                                                  l=5 m=3
+              |                                 BD
+              |                                                       Program    a=1 a=1        Advanced                       Senior
+              |                                Staff     m=3                                     Develop                      Manager
+              |                                          a=3   √                  √         
+              |                                                                                                    s=2
+              |                                Senior
+              |                                                      Subsystem                   CRAD
+              |                                                                                                √   a=4         Senior
+              |              Tools            Engineer   m=3                                                                  Scientist
+              |                                          a=3   √
+              |                                                                                                    s=2
+              |                                                                                                √   a=4         Staff
+              |            s=2                Engineer   m=3         Engineer                   Engineer
+              |                                                                                                               Scientist
+              |            a=1                           a=3   √
+              |                 Discipline
+              |                   Director
+blank         | 
+              | 
+              | 
+              | 
+text          |                      ENG
+blank         | 
+              | 
+              | 
+text          |                  Figure 1-6 Information Transfer Regimes and Amplification Factors
+              | Network performance is evaluated by looking for link/information mismatch. The red circles are
+              | points of interest that have been evaluated for consistency. The checkmarks indicate consistent link
+              | parameters and information formatting. The sad-faces indicate mismatches that will be discussed in
+              | subsequent sections.
+blank         | 
+              | 
+              | 
+text          | Potential network improvements can be assessed both at the individual links and nodes,
+              | and over “link-chains”. Between individual nodes, mismatches of Link parameters (p, a)
+              | indicate a discontinuity, or a mismatch of Lyupanov exponents (Section 3.4.1). Two
+              | nodes can improve their combined performance by exchanging information more
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                  9
+text          |              efficiently. However, improving information transfer at one link may or may not
+              |              improve overall system performance, although there will certainly be local effects.
+blank         | 
+              | 
+text          |              Figure 1-7 shows an analysis of an individual link for the transfer and insertion of
+              |              research information into a new mega-system. In this case, new research was not being
+              |              efficiently delivered into new system. Analysis of the information transfer characteristics
+              |   BD                        PROG
+              |              indicated potential for a five-fold increase in productivity. A complete description R&D
+              |                                                                                                   and
+              |              analysis is developed in section 4.3.1.
+blank         | 
+              | 
+text          |   Exec                          Exec                                                                         Exec
+blank         | 
+              | 
+              | 
+text          |                                                                     t=m
+              |   BD
+              |                         B    Executive                              a= 1                       Senior                     Adjacent
+              |                                                           A
+              | Director                       Staff                                                           Support                  Technologies
+              |                                                             t=m                                        D
+              |                                                      A      a= 1                      C
+              |    BD           C                                                  Advanced                                 Senior
+              |                               Program
+              |   Staff                                                             Develop                                Manager
+              |                                                 C                              D
+              |                             D
+blank         | 
+text          |  Senior                                                                                                     Senior
+              |                             Subsystem                                CRAD
+              | Engineer                                                                                                   Scientist
+              |                                   Figure 1-7 Set of Consistent Guides to Repair Discontinuity
+              |              This figure zooms into our design community network to focus on two identified discontinuities
+              |                                                                                                     Staff is
+              |              labeled A. In both of these cases, p = m and a = 1. So although the communication timeframe
+              | Engineer                      Engineer                              Engineer
+              |                                                                                                      Scientist
+              |              “medium”, the information delivered is in the wrong form for direct consumption. Also variety was
+              |              expended at some cost to transform the original information. So the resources used to produce the
+              |              original information are not being exploited efficiently. For steps B, C, and D, please refer to section
+              | Discipline   4.3.1.
+              |  Director
+blank         | 
+text          |              Our mega-organization is not independent. Rather it is given particular direction and
+              |              goals in order to achieve the design and production of mega-systems. For instance, some
+              |  ENG         information flows only a certain direction, and some information is tightly controlled.
+              |              Therefore the network is only a quasi, scale-free network. Imposing external goals and
+blank         | 
+              | 
+              | 
+meta          |                                                                10
+text          | specifications onto our scale-free, multi-hierarchical control structure, creates sets of
+              | directed links (link-chains) corresponding to control paths required to focus the
+              | community on our particular future goal states. These directed link-chains need to be
+              | evaluated to make sure the information arrives timely and with minimal (acceptable)
+              | corruption.
+blank         | 
+              | 
+text          | Link-chains of interest focus on particular extended pathways that execute higher level
+              | functions, such as translating customer product requirements into research needs.
+              | Evaluation of various link chains can be analyzed both from an a priori interest as well as
+              | from evaluating the scale-free network for paths of overall poor quality.
+blank         | 
+              | 
+text          | Case (2) in Figure 1-8 shows the delivery of new Research products into large Programs.
+              | This was part of the same analysis of the transfer and insertion of research information
+              | into a new mega-system, but at a larger scale to examine total flow and also to look for
+              | side-effects. This path has a Total Aliasing Factor (TAF) of 15 (see Section 3.4).
+              | Changes from annealing the discontinuities from Figure 1-7 (discussed in Section 4.3.1)
+              | will reduce the link values (aliasing factors) of 5 and 3 to 2 and 2, and improve the
+              | efficiency of incorporating current (and appropriate) technology into the new mega-
+              | system.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                               11
+text          |                              BD                         PROG                                                  R&D
+blank         | 
+              | 
+              | 
+text          |                              Exec     3                    Exec                                               Exec
+blank         | 
+text          |                        1    2                                                                        1                         1
+              |             Adjacent         BD                        Executive
+              |                                                                                 3                  Senior                  Adjacent
+              |             Markets        Director                      Staff                                     Support               Technologies
+              |                                                                             3                                      2
+              |                             2                          2      5
+              |                               BD
+              |                              Staff
+              |                                             3           Program
+              |                                                                    5
+              |                                                                                     Advanced
+              |                                                                                      Develop
+              |                                                                                                               Senior
+              |                                                                                                              Manager
+blank         | 
+text          |                                                               2                     2                              2
+              |                             Senior          3          Subsystem                     CRAD
+              |                                                                                                2              Senior       3
+              |                            Engineer                                                                          Scientist
+blank         | 
+text          |                        2    2                                 3                     2                              22
+              |              Tools         Engineer
+              |                                             3      1
+              |                                                        Engineer                     Engineer
+              |                                                                                                2              Staff
+              |                                                                                                       5      Scientist
+              |             1
+              |                        2   Discipline
+              |                             Director
+blank         | 
+              | 
+              | 
+              | 
+text          |                             ENG
+blank         | 
+              | 
+text          |                                           Figure 1-8 Link-chain Paths of Interest
+              | External goals and specifications, combined with our quasi, scale-free network, create directed links
+              | corresponding to control paths required to focus the community on the particular future goal states.
+              | Numbered blue lines are directed link paths; red numbers are total aliasing factors (TAF) (section
+              | 3.4.4). These link-chains need to be evaluated to make sure the information arrives timely and un-
+              | corrupted. Corruption can be caused by aliasing, occurring either during variety compression /
+              | decoding, or from multi-scale time-aliasing. Case (2), the delivery of new Research products into
+              | large Programs, has the highest TAF corruption factor of 15.
+blank         | 
+              | 
+text          | In fact, a case study addressing the delivery of new research products into large programs
+              | was monitored in parallel wherein the delivery path of design products was adjusted.
+              | Several interesting behaviours emerged around design ownership, as reflected within
+              | changed design variety and program variety (section 4.4).
+blank         | 
+              | 
+text          | While emergent engineering behaviours are interesting, another question is whether this
+              | improved the value to the company and/or the value delivered to the environment
+              | (society). These questions might not be definitively answerable, but one metric – the
+              | inserted value of R&D efforts – rose from less than 5% to almost 80% as measured by
+              | the number of research projects being fully used in operational programs. The research
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                        12
+text          | projects themselves can be quite successful, but information transfer into a development
+              | program runs into the problems indicated in terms of time synchronization.
+blank         | 
+title         | 1.5 Conclusions
+text          | This dissertation developed a new type of model for extremely large design organizations
+              | and their environment by combining perspectives from:
+              |         -   evolutionary genetic computing organisms,
+              |         -   information theoretic (quantum) information production, and
+              |         -   non-linear dynamics and chaos theory for information exchange.
+              | to study some of the behaviours of complex organizations, especially information
+              | transfer, to show how organizations can be guided to more efficiently and quickly
+              | produce complex mega-systems.
+blank         | 
+              | 
+text          | A three-year experiment was performed within a large design organization to see what
+              | level and type of improvements would actually manifest.
+blank         | 
+              | 
+text          | The results fall into three categories:
+              |         -   production of individual mega-systems,
+              |         -   improvement in organizations that develop mega-systems, and
+              |         -   extraction of societal benefits from government funded mega-systems.
+              | These are addressed separately below.
+blank         | 
+title         | 1.5.1 Design of Individual Mega-Systems
+text          | Mismatched quality of information transfer among organizational elements causes
+              | significant inefficiencies. The transfer quality includes time synchronization, method of
+              | transfer, and other variables. It is not that anything is currently wrong, just that a lot of
+              | time is wasted waiting for information, translating information, or re-developing the
+              | context to understand the information. Also, additional time (and resources) may be
+              | spent waiting for task convergence at a higher level. Matching the characteristics of the
+              | product design information to the characteristics of the transfer path minimizes aliasing
+              | effects (dissipation and noise), creating many benefits including:
+blank         | 
+              | 
+              | 
+meta          |                                               13
+text          |        -   More efficient design and design execution,
+              |        -   Improved design agility / currency, and
+              |        -   Enablement / easing of “Evolutionary Design” ([Bobinis 2006], [Bar-Yam
+              |            2003], [Sangiovanni 2006]) at the upper, large-scale limit.
+blank         | 
+              | 
+text          | Results from a three-year experiment showed that the inserted value of R&D efforts rose
+              | from less than 5% to almost 80% as measured by the number of research projects being
+              | fully used in operational programs. The research projects themselves can be quite
+              | successful, but information transfer into a development program runs into the problems
+              | indicated in terms of time synchronization.
+blank         | 
+title         | 1.5.2 Company and Design-Organization Implications
+text          | Improvements in the performance of the organization will incrementally emerge, given
+              | the inertia of large organizations and of engineering processes, and will initially manifest
+              | as quicker mega-system deliveries and an accelerating ability to innovate ahead of other
+              | companies.
+blank         | 
+              | 
+text          | “One consequence of encoding information as statistical and time-varying patterns of
+              | low-level components is that no individual component of the system can perceive or
+              | communicate the ‘big-picture’ of the state of the system. Instead, information must be
+              | communicated via spatial and temporal sampling.” [Mitchell 2009] Dynamically, the
+              | mega-design process is progressing, and any snapshot is an incomplete view in a
+              | changing context. This implies that the product directors exert little real control on where
+              | the company is going. Their actual role is simply to monitor the outputs and nascent
+              | products, and to guide the output (and rate of new product introduction and of upgrades)
+              | to match the funding (requirements) source.
+blank         | 
+              | 
+text          | This dynamic perspective implies that design communities can, and should, “construct
+              | their own [evolutionary] selective constructs designed toward increasing mutual
+              | information [within itself, and] between the organism and the environment” [Krakauer
+              | 2011], for better computability or production of designs (cf. niche construction). In this
+blank         | 
+              | 
+              | 
+meta          |                                               14
+text          | case, the management structure ought to also look at higher level abstractions, such as
+              | information transfer efficiencies, in addition to process control (like design reviews),
+              | because looking at static variables will not improve the evolutionary adaptation rate.
+blank         | 
+title         | 1.5.3 Government and Societal Implications
+text          | The stability of any implemented improvements is somewhat problematic given the
+              | evolving environment, but especially given the counter-acting efforts of government
+              | acquisition regulations and nominal management tendencies.
+blank         | 
+              | 
+text          | Scale, synchronization, and economic nudges may be appropriate for personal scale
+              | complices such as smartPhone apps, but the economic and scale factors are different from
+              | government “apps”. A focus on lowest cost procurement, for government “apps” (mega-
+              | systems), has side effects on the engineering design process. Financially speaking, and
+              | for more effective mega-system development, the government should modify cost-
+              | selection constraints to avoid extra effort to achieve a particular instance when any of a
+              | set of instances is all that is needed. This would necessarily become somewhat non-
+              | deterministic.
+blank         | 
+              | 
+text          | Individual program managers will avoid this because it is locally inefficient and also
+              | uncontrollable. However, according to game theory (prisoner’s dilemma [Morrow
+              | 1994]), a Pareto optimal solution is better, and can be achieved with “external norms”
+              | [Mitchell 2009]. The external norms could either be via company processes and
+              | procedures or, better, by the government’s Federal Acquisition Regulations (FAR).
+blank         | 
+              | 
+text          | For instance, implementation at the government FAR level could be to assign 1% - 2% of
+              | the value of programs over a certain size to internal efforts supporting adaptability and
+              | risk reduction. For instance the Orion spacecraft program internally allocated $100M
+              | (for a $4B program) to reduce schedule risk occurring from software integration. This is
+              | the same scale as proposed, and was considered and approved as the correct engineering
+              | approach. However, it was implemented without adjusting the encompassing process, so
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              15
+text          | savings could never be recaptured, nor future transitions eased. This fund would reduce
+              | risk on the delivery of the initial system, and reduce cost of subsequent systems.
+blank         | 
+              | 
+text          | Such a fund could also be allocated for application to follow-on project development, and
+              | coordination of supporting technology and product development. Note that this would
+              | avoid aliasing effects from Federally Funded Research and Development Companies
+              | (FFRDCs) in their information transfer efforts, and would greatly improve technology
+              | transfer from government labs to industry and society.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             16
+title         | 2 Network Model Development and Mega-Organizations
+text          | In order to design, integrate, and deliver a mega-system, the organizational unit must
+              | itself be very large and thus inherently complex, especially when efficient use of capital
+              | and labor indicate (out of phase) development of multiple mega-systems.
+blank         | 
+              | 
+              | 
+title         | 2.1 Structure of Very Large Aerospace Design Communities
+text          | Large aerospace companies typically have on the order of (100,000) employees, of whom
+              | (50%) are engineers and scientists of various sorts. These organizations typically have a
+              | large number of entwined organizations to produce and deliver their platforms.
+              | (Numbers in parentheses refer to the notional parameter values in our abstracted model.)
+              | (Capitalized terms are symbolic names.)
+blank         | 
+              | 
+text          | Aerospace companies might be divided into (five) business areas or sectors to address
+              | different market areas. An upper-level corporate organization might provide common
+              | resources for business development, common research, common engineering tools and
+              | process, and other functions.
+blank         | 
+              | 
+text          | For our purposes we will discuss a medium sized space company (sector) of ($10B)
+              | annual sales. Companies are divided into lines of business or business units on the scale
+              | of ($1B) annual sales. The (10) business units are the major components of the company
+              | and are responsible for producing and delivering the output of the organization.
+blank         | 
+              | 
+text          | Geographically, the organization will be spread across the nation (Figure 2-1) [courtesy
+              | of Lockheed Martin Space Systems Company]. Some locations have large numbers of
+              | people; other sites have smaller numbers. The business units may or may not be
+              | geographically centralized. If not, there is some communications overhead to coordinate
+              | the pieces.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             17
+text          |                                              Louisville, CO
+              |                  Bangor, WA                                    Denver, CO                           Newtown, PA
+              |                                              • Coherent
+              |                  • FBM IA&T
+              |                                                Technologies                                         • Navigation Systems
+              |        Palo Alto, CA                                                                                • Commercial Space
+              |       • ATC
+blank         | 
+              | 
+text          |     Sunnyvale, CA
+              |                                                                                                   Valley Forge, PA
+              |       Santa Cruz, CA                                                                              • Reentry Systems
+              |       • Test Support
+              |                                                                                                   Washington, DC
+              |                                                                                                   • FBM Liaison
+              |                                                                                                   • Washington Ops
+              |                                                                                                   Arlington, VA
+              |      Edwards AFB, CA                                                                              • Targets Prime
+              |      • ABL                                                                                        Huntsville, AL
+              |                                                                                                   • Strategic & Missile Defense
+              |      El Segundo, CA                                                                               • Ares Support
+              |      • MILSATCOM
+              |                                        Albuquerque, NM                                            Kings Bay, GA
+              |                                        • ATC                                                      • FBM IA&T
+              |      Kauai, HI         White Sands, NM • ATK
+              |      • PMRF                                                                     Courtland, AL     Cape Canaveral, FL
+              |                        • Missile Range • Targets &                              • Targets &       Eastern Range
+              |                                                                  Stennis, MS
+              |                                          Countermeasures                          Countermeasures • Launch Operations
+              |                                                                  • Propulsion
+              |                                                    Houston, TX     Center
+              |                             ~19,500 employees • Orion
+              |                                                                             New Orleans, LA
+              |                               •   ~ 8,700 in Silicon Valley
+              |                                                                             • External Tank
+              |                               •   ~ 4,700 in Denver area
+              |                               •   ~ 2,000 in New Orleans                    • Orion
+              |                               •   ~ 1,500 in Cape and V
+              |                               •   ~ 1,100 in Delaware Valley
+              |   009_03.18.08
+              |                               •   ~ 500 in Alabama
+blank         | 
+text          |                                                  Figure 2-1 Geographic Distribution
+blank         | 
+              | 
+              | 
+text          | Our prototypical medium sized space company has on the order of (20,000) employees.
+              | The (10,000) engineers frequently reside in an Engineering home-shop organization that
+              | may span (10) disciplines, each with a Discipline Director. The goal of the Engineering
+              | home-shops is to have 99.9% of their staff assigned to a Program where they are
+              | developing deliverable products and profit. Each business unit would then have about
+              | (1000) engineers and (2000) total staff. Engineering frequently has some small number
+              | of senior engineering staff who coordinates Tools and processes.
+blank         | 
+              | 
+text          | Business Development coordinates all the business units to coordinate their outputs to
+              | optimally take advantage of resources while delivering to the customer requirements.
+blank         | 
+              | 
+text          | Our typical company will have a Research group which may have (1000) scientists. Of
+              | these we will assume that (400) work on advanced or specialized products, and (600)
+              | advance the state of the art in (6) different technical areas. Hopefully their research is
+              | applied to the next generation products being developed by the business units.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                   18
+text          | (Figure 2-2) abstracts our model community into a non-directed graph. (Figure 2-3)
+              | shows typically sized organizational parameters.
+blank         | 
+              | 
+text          |                              Sector                         Sector                                                             Sector
+              |                              Coord                          Coord                                                              Coord
+              |                                                                                         Major
+              |                                                                                       Teammates
+blank         | 
+text          |                                        BD                          PROG                                              R&D
+              |                                                                     PROG
+              |                                                                      PROG
+              |               Sector
+              |                                                                       PROG
+              |                                                                        PROG
+              |               Coord
+              |                                        Exec                             Exec                                         Exec
+blank         | 
+              | 
+              | 
+              | 
+text          |               Adjacent                  BD                         Executive                             Senior                  Adjacent
+              |                Adjacent
+              |               Markets
+              |                  Adjacent             Director                       Staff                               Support               Technologies
+              |                Markets
+              |                   Adjacent
+              |                  Markets
+              |                    Markets
+blank         | 
+              | 
+text          |                                         BD                                                Advanced                  Senior
+              |                                                                                                                      Senior
+              |                                                                    Program
+              |                                                                     Program                                            Senior
+              |                                        Staff                          Program              Develop                 Manager
+              |                                                                                                                         Senior
+              |                                                                                                                     ManagerSenior
+              |                                                                                                                       Manager
+              |                                                                                                                             Senior
+              |                                                                                                                        ManagerSenior
+              |                                                                                                                          Manager
+              |                                                                                                                            Manager
+              |                                                                                                                              Manager
+blank         | 
+text          |                                    Senior                                                                           Senior
+              |                                                                   Subsystem
+              |                                                                    Subsystem                CRAD
+              |                                                                                              CRAD
+              |                                   Engineer                          Subsystem
+              |                                                                       Subsystem               CRAD
+              |                                                                                                CRAD                Scientist
+              |                                                                        Subsystem
+              |                                                                          Subsystem               CRAD
+              |                                                                                                   CRAD
+              |                                                                           Subsystem
+blank         | 
+              | 
+text          |                                                                                                                     Staff
+              |                Tools              Engineer                        Engineers                Engineer
+              |                                                                                                                    Scientist
+blank         | 
+              | 
+              | 
+text          |                                   Discipline
+              |                                     Discipline
+              |                                    Director
+              |                                       Discipline
+              |                                      Director               Suppliers                  Small               Universities
+              |                                        Discipline
+              |                                        Director                                       Business
+              |                                          Discipline
+              |                                         Director
+              |                                            Discipline
+              |                                           Director
+              |                                              Discipline
+              |                                             Director
+              |                                                Discipline
+              |                                               Director
+              |              Sector
+              |                                     ENG         Director
+              |              Coord
+blank         | 
+              | 
+              | 
+text          |        Figure 2-2 Conceptual Organizational Structure, Staffing Levels, and Characteristics
+              | “Sector Coord” (green arrows) maps to the other five Business Areas as additional, similar layers.
+              | “Clouds” map to other complex communities such as university research networks, small businesses
+              | and suppliers, etc.          The linkages cross-connect at many places.                                  “Major teammates” represent
+              | another similar aerospace company of similar size (20,000 employees).
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                                 19
+title         |                      Sector                               Sector                                                                           Sector
+text          |                      Coord                                Coord                                                                            Coord
+              |                                                                                        Major
+              |                                                                                      Teammates
+blank         | 
+text          |                               BD                                 PROG                                                            R&D
+              |                                                                   PROG
+              |                                                                    PROG
+              |      Sector
+              |                                                                     PROG
+              |                                                                      PROG
+              |      Coord
+              |                               Exec                                    Exec                                                        Exec
+              |                                                                                                                             1              1
+              |                               1                                       1                                                          1
+              |                                   8                                       5                                         3       3                     2
+              |      Adjacent                 BD        1                  1    Executive 1                                3       Senior                    Adjacent
+              |        Adjacent
+              |       Markets
+              |         Adjacent            Director                              Staff                                            Support                 Technologies
+              |        Markets
+              |           Adjacent                                                         1                                                                          240
+              |          Markets
+              |           Markets             1                                   1
+              |    4 markets                      5                                  3                  1
+              |                                                                                                                                        6
+              |                                                                          3 progs
+              |                                BD       5                  1                                Advanced                             Senior
+              |                                                                                                                                   Senior        6 techs
+              |                                                                  Program
+              |                                                                   Program                                                           Senior
+              |                               Staff                                 Program                  Develop                            Manager
+              |                                                                                                                                       Senior
+              |                                                                                                                                  Manager
+              |                                                                                                                                        Senior
+              |                                                                                                                                    Manager
+              |                                                                                                                                          Senior
+              |                                                                                               1                                     Manager
+              |                                                                                                                                           Senior
+              |                                                                                                                                       Manager
+              |                                                                       1                                                          1      Manager
+              |                                                                      10                         7    7 CRADS                         10 Manager
+              |                                                                            10 subs
+              |                              Senior           // 1/discipline   Subsystem                    CRAD                  //            Senior
+              |                             Engineer                             Subsystem
+              |                                                                   Subsystem                   CRAD
+              |                                                                                                CRAD                             Scientist
+              |                                                                     Subsystem
+              |                                                                      Subsystem                  CRAD
+              |                                                                                                   CRAD         1                               10/tech
+              |                        10                                             Subsystem
+              |                                                                         Subsystem                  CRAD
+              |                               1                                   1                          1                                    1
+              |   5/discipline
+              |                                   100                                100                       10                                   7
+              |                                              // 100/discipline Engineers                                       // 3              Staff
+              |       Tools                 Engineer                                     1000               Engineer                                           70/tech
+              |                                                                                                                                 Scientist
+              |                  5                    1000                                                         10
+              |                               1
+              |                        1
+              |                             Discipline
+              |                              Discipline
+              |                             Director
+              |                                Discipline
+              |                               Director                    Suppliers                   Small                             Universities
+              |                                 Discipline
+              |                                Director                                              Business
+              |                                   Discipline
+              |                                  Director
+              |                                     Discipline
+              |                                    Director
+              |                                      Discipline
+              |                                      Director
+              |                                        Discipline
+              |                                        Director       10 disciplines
+              |     Sector
+              |                              ENG        Director
+              |     Coord
+blank         | 
+              | 
+text          |                                              Figure 2-3 Organizational Size Characteristics
+              | Numbers in red by ovals indicate typical number of similar groups. Double slashes indicate multiple
+              | connections. Numbers in black near lines indicate the communications I/O dispersion.
+blank         | 
+              | 
+              | 
+              | 
+text          | Most Engineering Design research focuses on performance developing a single, limited
+              | product. We want to look both at a larger product and at the overall organizational
+              | combination and the integrated product evolution.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                               20
+title         | 2.2 Network Characteristics
+text          | In our model of this aerospace organization or community, there are many overlapping
+              | hierarchies. First there are the five different Business Units that are controlled by upper-
+              | level corporate organization that supplies common resources. In parallel, there are also
+              | functional hierarchies such as for Engineering disciplines, Finance, Research, Quality
+              | Control, etc. Finally, there are additional parallel hierarchies for business management,
+              | Program control and engineering process control.
+blank         | 
+              | 
+text          | This amalgamation of connections is entwined with the central corporate organizations to
+              | support related market efforts. A simple two-level, overlapping hierarchy is shown in
+              | Figure 2-4. Note that priorities, sequencing, and control issues may arise with multiple
+              | different control staff.
+blank         | 
+              | 
+              | 
+              | 
+text          |                              Figure 2-4 Overlapping Hierarchies
+blank         | 
+              | 
+text          | In terms of task and staffing control, a simplistic hierarchical organization is shown in
+              | Figure 2-5. Each level coordinates multiple activities of the level below.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              21
+text          |                                                                System
+blank         | 
+              | 
+text          |                                     {
+              |                                   Design
+              |                          Process Type
+              |                      (Connectivity)
+              |                                                      SubSystem
+              |                                                                           ...
+blank         | 
+              | 
+text          |                                       Requirements   Product
+              |                                                                      ...
+              |                                            SubSubSystem
+              |                                                                    Design Coordination ?
+              |                                Specifications   Components
+blank         | 
+text          |                                                              ...
+              |                            Figure 2-5 Typical Hierarchical Organization
+              |    Types of connectivity, both vertical and horizontal, vary by type of engineering design process.
+              |                                                 [Byler 2001]
+blank         | 
+              | 
+              | 
+              | 
+text          | Hierarchical systems are difficult to scale. Single points of control can’t digest enough
+              | information to quickly process the next step in the organization’s computation. You need
+              | more information and more coordination among the larger team for goal-oriented, “feed-
+              | forward” information to achieve timely efficiency. Also, hierarchies tend to create walls,
+              | and by creating separate groups, you create (evolutionary) sub-populations which both
+              | cannot process as much as the whole, but also compete with each other internally.
+              | Finally, when the sub-populations ‘die’, they lose their knowledge/information; and when
+              | larger groups “die”, they even lose their assets (like the international space station).
+blank         | 
+              | 
+text          | For single systems with limited levels of control, both efficient performance and task
+              | execution stability can be achieved. For larger systems, both stability and performance
+              | degrade with scale (Figure 2-6 and Figure 2-7). In very large product development
+              | networks (see section 3.3.2) networks can lose convergence, and tasks never complete.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                      22
+text          |                        Figure 2-6 Control Stability for Various Organizations
+              | Scaling of the norm of the minimal control matrix required to achieve stability for various
+              | organizations: global (solid, black), local (dashed, black), hierarchy (solid, gray) and multi-hierarchy
+              | (dashed, gray) as a function of N. The hierarchical organizations are chosen with r = 0:5 and
+              | branching ratio 2. [Hogg 2001]
+blank         | 
+              | 
+              | 
+              | 
+text          |                                Figure 2-7 Organizational Performance
+              | Effect of noise on the expected value of the largest eigenvalue, for N = 8, _ = 1, f = 0:8 and controls
+              | with s = 0:7 as a function of _ for asymmetric multiplicative noise with zero mean and standard
+              | deviation _. The organizations are global (solid, black), local (dashed, black), hierarchy (solid, gray)
+              | and multi-hierarchy (dashed, gray). For the hierarchical cases, we have r = 0:5 and a branching ratio
+              | of two. The error bars give the standard error estimate of the mean, based on 1000 samples.
+              | Eigenvalues above zero indicate situations where the noise makes the system unstable, on average.
+              | [Hogg 2001]
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                   23
+text          | Cross connections within social systems are natural, and engineering design communities
+              | have also evolved into ‘neural’ communities. Intuitively, this is good because they are
+              | better able to compute their products. This is because of the extra information available
+              | from peer groups (related to ‘a’ as defined in Section 3.0). The quicker computation rates
+              | let the group/community evolve better because of broader scope and more agility. Thus
+              | the community organism competes better.
+blank         | 
+              | 
+text          | For our complex mega-design organization, these networks, in fact, have so much
+              | secondary interconnections that they approach the connectedness of scale free networks.
+              | Figure 2-8 shows several network types that underpin our organizational network model.
+blank         | 
+text          |  Scale Free Network
+              |                                                                       Abstracted Example of                         D
+              |  A
+              |                                                                     Design Community
+              |                                                                          Network
+              |                                                            Sector                         Sector                                                             Sector
+              |                                                            Coord                          Coord                                                              Coord
+              |                                                                                                                       Major
+              |                                                                                                                     Teammates
+blank         | 
+text          |                                                                      BD                          PROG                                              R&D
+              |                                                                                                   PROG
+              |                                                                                                    PROG
+              |                                                                                                     PROG
+              |  Multi-Dimensional                          Sector
+              |                                             Coord
+              |                                                                                                      PROG
+blank         | 
+text          |  Scale Free Network                                                  Exec                             Exec                                         Exec
+blank         | 
+              | 
+              | 
+              | 
+text          |  B                                          Adjacent
+              |                                              Adjacent
+              |                                             Markets
+              |                                                Adjacent
+              |                                                                       BD
+              |                                                                     Director
+              |                                                                                                  Executive
+              |                                                                                                    Staff
+              |                                                                                                                                        Senior
+              |                                                                                                                                        Support
+              |                                                                                                                                                                Adjacent
+              |                                                                                                                                                              Technologies
+              |                                              Markets
+              |                                                 Adjacent
+              |                                                Markets
+              |                                                  Markets
+blank         | 
+              | 
+text          |                                                                       BD                                                Advanced                  Senior
+              |                                                                                                                                                    Senior
+              |                                                                                                  Program
+              |                                                                                                   Program                                            Senior
+              |                                                                      Staff                          Program              Develop                 Manager
+              |                                                                                                                                                       Senior
+              |                                                                                                                                                   ManagerSenior
+              |                                                                                                                                                     Manager
+              |                                                                                                                                                           Senior
+              |                                                                                                                                                      ManagerSenior
+              |                                                                                                                                                        Manager
+              |                                                                                                                                                          Manager
+              |                                                                                                                                                            Manager
+blank         | 
+text          |                                                                  Senior                                                                           Senior
+              |                                                                                                 Subsystem
+              |                                                                                                  Subsystem                CRAD
+              |                                                                                                                            CRAD
+              |                                                                 Engineer                          Subsystem
+              |                                                                                                     Subsystem               CRAD
+              |                                                                                                                              CRAD                Scientist
+              |                                                                                                      Subsystem
+              |                                                                                                        Subsystem               CRAD
+              |                                                                                                                                 CRAD
+              |                                                                                                         Subsystem
+blank         | 
+              | 
+text          |                                                                                                                                                   Staff
+              |                                              Tools              Engineer                        Engineers                Engineer
+              |                                                                                                                                                  Scientist
+blank         | 
+              | 
+              | 
+text          |  Hierarchical Cluster Network                                   Discipline
+              |                                                                   Discipline
+              |                                                                  Director
+              |                                                                     Discipline
+              |                                                                    Director               Suppliers                  Small               Universities
+              |                                                                      Discipline
+              |                                                                      Director                                       Business
+              |                                                                        Discipline
+              |                                                                       Director
+              |                                                                          Discipline
+              |   C                                                                     Director
+              |                                                                            Discipline
+              |                                                                           Director
+              |                                                                              Discipline
+              |                                            Sector                           Director
+              |                                                                   ENG         Director
+              |                                            Coord
+blank         | 
+              | 
+              | 
+              | 
+text          |                                                                                     Multi-Dimensional
+              |                                                                                 Information Transfer Links
+              |                                                                                   (details in section 3.0)
+blank         | 
+              | 
+              | 
+              | 
+text          |                     Figure 2-8 Typical and Combined Network Characteristics
+              | (A) shows a simple scale free network that spans the continental United States. Central nodes (red)
+              | connect to leaf nodes (green) but there are multiple paths available between any two nodes. (B)
+              | shows a much larger network, within which there are several types of connectivity among the nodes.
+              | (C) is a hierarchical cluster network within which the hierarchies are not linear, but rather clusters
+              | themselves. (D) Our organization has communication connectivity like a scale-free network, but also
+              | includes directed links and geographic bandwidth restrictions like a cluster hierarchy. The multi-
+              | dimensional transfer links are discussed in section 3.0
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                        24
+text          | In the context of network theory a scale-free ideal network is a random network with a
+              | degree distribution a power law, at least asymptotically. That is, the fraction P(k) of
+              | nodes in the network having k connections to other nodes goes for large values of k as
+blank         | 
+              | 
+text          |        P(k) ~ k -
+blank         | 
+              | 
+text          | where  is a parameter whose value is typically in the range 2 <  < 3.
+blank         | 
+              | 
+text          | The most notable characteristic in a scale-free network is the relative commonness of
+              | vertices with a degree that greatly exceeds the average. The highest-degree nodes are
+              | often called "hubs". The scale-free property also strongly correlates with the network's
+              | robustness to failure.
+blank         | 
+              | 
+text          | Another important characteristic of scale-free networks is the clustering coefficient
+              | distribution, which decreases as the node degree increases. This distribution also follows
+              | a power law. This implies that the low-degree nodes belong to very dense sub-graphs and
+              | those sub-graphs are connected to each other through hubs.
+blank         | 
+              | 
+text          | Consider a social network in which nodes are people and links are acquaintance
+              | relationships between people. It is easy to see that people tend to form communities, i.e.,
+              | small groups in which everyone knows everyone (one can think of such community as a
+              | complete graph). In addition, the members of a community also have a few acquaintance
+              | relationships to people outside that community. Some people, however, are connected to
+              | a large number of communities (e.g., celebrities, politicians). Those people may be
+              | considered the hubs responsible for the small-world phenomenon. [Wikkipedia]
+blank         | 
+              | 
+text          | Our mega-organization is not independent and therefore not completely scale-free.
+              | Rather it is given particular direction and goals in order to achieve the design and
+              | production of mega-systems. For instance, some information paths flow only a certain
+              | direction, and some information is tightly controlled. Therefore the network is only a
+              | quasi, scale-free network. Imposing external goals and specifications onto our scale-free,
+blank         | 
+              | 
+meta          |                                              25
+text          | multi-hierarchical control structure, creates sets of directed links (link-chains)
+              | corresponding to control paths required to focus the community on our particular future
+              | goal states. These directed link-chains need to be correctly addressed.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                               26
+title         | 2.3 Abstraction to Meta-Network Model
+text          | (Figure 2-9) has abstracted the many actors from Section 2.1 into a simplified model to
+              | which we will attach our organizational parameters in Section 3.0.
+blank         | 
+              | 
+              | 
+text          |          Business                                  Program                                Research
+              |    Development BD                               PROG
+              |                                                      Management                         R&D
+blank         | 
+              | 
+              | 
+text          |                         Exec                     Exec                                   Exec
+blank         | 
+              | 
+              | 
+              | 
+text          |            Adjacent     BD                     Executive                     Senior                  Adjacent
+              |            Markets    Director                   Staff                       Support               Technologies
+blank         | 
+              | 
+              | 
+text          |                          BD                                     Advanced                Senior
+              |                                                 Program
+              |                         Staff                                    Develop               Manager
+blank         | 
+              | 
+              | 
+text          |                        Senior                                                           Senior
+              |                                                Subsystem         CRAD
+              |                       Engineer                                                         Scientist
+blank         | 
+              | 
+              | 
+text          |                                                                                         Staff
+              |             Tools     Engineer                 Engineer         Engineer
+              |                                                                                        Scientist
+blank         | 
+              | 
+              | 
+text          |                       Discipline
+              |                        Director
+              |                                     Operational               Prototype
+              |                                        Systems                Systems
+              |                        ENG
+              |      Engineering
+              |                                 Figure 2-9 Abstracted Organizational Model
+blank         | 
+              | 
+text          | In our abstracted organizational model, the information from Figure 2-3 has been
+              | collapsed into two dimensions for display clarity and in order to focus on the
+              | multidimensional parameters. The links are multi-dimensional themselves, including
+              | characteristics on communication I/O dispersion, types of information carried, etc.
+              | Likewise, the links are not necessarily singular stages, but can encompass multiple steps.
+              | Extraction and development of these organizational parameters and link characteristics
+              | are discussed in detail in Section 3.0.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                         27
+title         | 3 Link Model Development
+blank         | 
+title         | 3.1 Model Overview
+text          | For the organization model developed here (Section 2.0), each node is an agent composed
+              | of many people. Agents can be individuals, design groups, project swarms, or other
+              | complices. These agents are peer-to-peer agents in a weak sense as defined by Petrie
+              | [Petrie 1996]. In this sense they are true agents that provide generation of new
+              | information, but they are weak in that they do not use standard protocols for
+              | communication. Each agent’s protocols (methods) are particular to that set of agents.
+blank         | 
+              | 
+text          | Each agent performs its function using a variety of people or skills. Producing a
+              | controller card, for instance, may require a machinist, a programmer, and a financial
+              | analyst. Then the product must be packaged and delivered. If one considers the
+              | controller card as inherently containing the design and product information, then the
+              | output could be termed to be encoded and transmitted, similar to packaged and delivered.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             28
+text          |  Link Information Transfer Model
+              |              “Node” parameters
+              |              defined by information encoding and transmitting activities
+              |              and by design information content, resolution, & processing
+              |                                             “Link” parameters
+              |                                             defined by relative design role
+              |     Agent X                                 and by organizational activities                Agent Y
+              |     w/ Variety 7                                                                            w/ Variety 9
+              |                              Encoder V6
+              |                                                                                                       Transmitter Vn
+              |                                Transmitter V7
+blank         | 
+text          |                                                 environment, tools, time
+blank         | 
+              | 
+text          |                                                   Information Transfer
+blank         | 
+              | 
+              | 
+text          |                                         Chaotic Channel (non-linear)
+              |  Machining V1                                                              Receiver V1
+              |    Cost Analysis V2                                                            Decoder V2
+              |            Programmer V3
+blank         | 
+              | 
+text          |    Variety = a set of capabilities                                    when
+              |                 and functionality                 Information Parameters (node + info package)
+              |                                                               are incompatible with
+              |    Agents = can be individuals,                 Transmission Line Parameters (link + environment)
+              |         groups, organizations,                               “aliasing” effects occur
+              |            or other complices
+blank         | 
+text          |                              Figure 3-1 Parameters of Link Transfer Model
+blank         | 
+              | 
+text          | Depending on the complexity of the product or output of the Agent, it may require more
+              | or less variety of sub-tasks. Thus the complexity of the product and/or of the agent can
+              | be represented by the Variety (Vi) of internal skills. The variety represents the set of
+              | capabilities and functionality.
+blank         | 
+              | 
+text          | The item produced by an agent can be a physical or ephemeral item. In any event
+              | information was imposed on the inputs (machining, assembly sequence, tuning) to
+              | increase its usefulness and reduce the entropy of the parts. The type of information
+              | imposed on the inputs, and representing the final product (piece-part), can be modeled by
+              | information content, resolution, and processing.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                            29
+text          | The node parameters include the information content and resolution, as well as the
+              | information encoding and transmission. Information is modeled in an information
+              | theoretic sense after [Shannon 1948] and [Bais 2010]
+blank         | 
+              | 
+text          |                   I() = -ipilogpi
+blank         | 
+              | 
+text          | Any new (conditional) information received by agent y from the information sent by
+              | agent x will be
+blank         | 
+              | 
+text          |                   I(y|x) = -iPx(xi)jPy|x(yj|xi)log2Py|x(yj|xj)
+blank         | 
+              | 
+text          | which expresses the fact that the receiver must interpret (decode) the information he
+              | receives based on their previous mutual understanding. Note that information data-bits
+              | can be interpreted similarly with design “task-bits”.
+blank         | 
+              | 
+text          | The Link parameters are defined both by the relative design roles of the attached nodes
+              | within the organizational activities, and by the environment within which the products
+              | pass and exist. The effect of relative design roles is driven not so much by the different
+              | activities, but rather by how much work must be done to understand or incorporate
+              | (receive and decode) the material being transmitted by the input agent. The effect of the
+              | design environment includes how the information is stored (transmission is not
+              | instantaneous), the amount of time delay between production and use, the types of tools
+              | used to decode or process the intermediate product, etc. Because of the dynamic nature
+              | of the information and the link, this model is a chaotic channel.
+blank         | 
+              | 
+text          | Information production, aging, and obsolescence is modeled with the logistic growth
+              | curve [Verhulst 1838]
+blank         | 
+              | 
+text          |                   xt+1 = axt (1 - xt)
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                   30
+text          | such that information is subject to dynamic effects over time. Iteration of conditional
+              | information over time shows “exchange resonances” (see Section 3.4.2).
+blank         | 
+              | 
+text          | When the Information parameters (node and product information package) are
+              | incompatible with Transmission Link parameters (link and environment), aliasing occurs.
+              | The information or product is not completely usable or has become corrupted, and
+              | additional work will be needed to adapt or understand it. In fact even minor mismatches
+              | create observable aliasing; it is a matter of scale.
+blank         | 
+              | 
+              | 
+title         | 3.2 Design Information
+blank         | 
+title         | 3.2.1 Information in Design Communities
+text          | For our quasi-scale-free engineering design community (Section 2.0), “information”
+              | includes the material acquired and developed to further the knowledge base, the product
+              | design, and the integration, assembly and test of the output products. This includes point
+              | design descriptions, experimental results, performance measurements, reports,
+              | spreadsheets, technologies, CNC tapes, test sequences, manufacturing tolerances,
+              | fabrication techniques, etc.
+blank         | 
+              | 
+text          | This “information” accumulates over time and is applied to design and produce new
+              | products. Our engineering community actually produces a portfolio of products
+              | including evolutionary products, new products in current markets, current products in
+              | new markets, and occasionally new products for new markets. There is an ongoing,
+              | evolving set of core competencies within each design community that, when infused with
+              | new information, allow the product stream to adapt to the changing market
+              | (environment). This design community produces some number of mega-systems in
+              | parallel efforts (but offset in time).
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                               31
+text          |                      Business                                Program                                  Research
+              |                Development BD                             PROG
+              |                                                                Management                           R&D
+blank         | 
+              | 
+              | 
+              | 
+text          |                     1 year         Exec                    Exec                                     Exec
+blank         | 
+text          |                                                                      3 years
+              |                       Adjacent     BD                    Executive                       Senior                  Adjacent
+              |                       Markets    Director                  Staff                         Support               Technologies
+blank         | 
+              | 
+              | 
+text          |                                     BD                                    Advanced                  Senior
+              |                                                           Program
+              |                                    Staff                                   Develop                 Manager
+blank         | 
+text          |                                                                                      2 years
+              |                                   Senior                                                            Senior
+              |                                                          Subsystem         CRAD
+              |                                  Engineer                                                          Scientist
+blank         | 
+              | 
+text          |                                               12 years
+              |                                                                                                     Staff
+              |                        Tools     Engineer                Engineer         Engineer
+              |                                                                                                    Scientist
+blank         | 
+              | 
+              | 
+              | 
+text          |                     4 years      Discipline   Operational                Prototype                             1 year
+              |                                   Director
+blank         | 
+              | 
+              | 
+              | 
+text          |                                   ENG
+              |                                                               Systems
+              |                  Engineering
+blank         | 
+text          |                Figure 3-2 Organizations, Information Products, and Time Epochs
+blank         | 
+              | 
+text          | In Figure 3-2, there are several major groups whose development products are roughly
+              | summarized below (capitalized terms symbolically represent their definition). Programs
+              | create the major output of our design community – an Operational System that takes 12
+              | years to design, produce, integrate and test. Programs are controlled by Program
+              | Management; this group coordinates several large projects, and is driven by a (typical)
+              | three-year Long Range Plan (LRP). The internal information packages within Program
+              | Management support the activity around successfully executing LRPs (not the program).
+              | Creation of LRPs is guided by Business Development who operates on a one-year cycle,
+              | based on accounting cycles including the government budgetary process. Research
+              | groups typically operate on one-year cycles also, based on an internal budget allocation
+              | cycle. Research reports are published and filed annually, and other internal information
+              | products support these efforts. Research groups frequently develop new Prototype
+              | Systems to demonstrate new capabilities to Program Management. These might take two
+              | years to develop.
+blank         | 
+              | 
+text          | To produce the product stream, the actors within the engineering community must
+              | exchange information in a timely and focused manner. (Note that faster information
+              | exchange is frequently better for quicker growth, unless the information transfer is so
+              | quick it is misunderstood, or not yet broadly applicable.)
+blank         | 
+              | 
+meta          |                                                                32
+text          | Actors (and groups of actors) within our design community also transfer part of the
+              | evolving context, in addition to official design documents or drawings, as a broad
+              | synchronization method. Thus, the information exchanged within the community is the
+              | combination of newly created technology pieces and components, and the updated
+              | pointers/relations to additional sources/actors.
+blank         | 
+              | 
+text          | “In larger organizations, the complexity is vastly different and the chance for deep
+              | personal co-commitment is diminished. Ad hoc exchanges within one’s personal
+              | network do happen, but systematic knowledge sharing usually requires brokering through
+              | people or technology. Along with brokering come issues such as knowledge
+              | identification, verification, and validation [Leifer 1999].”
+blank         | 
+              | 
+text          | “[All organizations] can benefit from the implementation of a central knowledge capture
+              | and re-use infrastructure, a core technology for sharing and learning from each other,
+              | peer-to-peer. In large institutions (greater than 500 people) this infrastructure will have to
+              | be explicit and managed separately from the design team support infrastructure.” [Leifer]
+blank         | 
+              | 
+text          | A separate explicit infrastructure however becomes problematic, especially on projects
+              | with long time scales (~10 years). Issues arise that interfere with having a consistent
+              | structure. The portfolio of projects across a large organization use different engineering
+              | tools. This will always be true because of a mismatch of time frequencies between new
+              | tools and new projects, and the fact you can’t and don’t want to update your tools all at
+              | once on a preordained schedule. Also actors bring different sets of tool knowledge with
+              | them to each activity. It actually takes some finite time for a team to get synchronized on
+              | common tools and data structures. Much training is completed on the job, with no
+              | separate time allotment and no separate instructors, with the result that tools are not
+              | always used as they were designed, nor to their full potential. Finally, retrieval of old
+              | knowledge becomes problematic and time consuming, and may become moot as different
+              | technologies advance at different rates, opening up new solution spaces for consideration.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              33
+text          | Another issue arising from large organizations that affects knowledge retention and
+              | retrieval is that engineering team members do not always follow a project from
+              | conception through design, manufacture, production, maintenance, and growth.
+              | Typically, engineers focus on one stage of design. As a result the information associated
+              | with a project bifurcates, with one instance progressing with the product as the product
+              | “design” and “context”, and the other instance going with the engineer or data base to a
+              | new product at a similar stage as “knowledge”.
+blank         | 
+              | 
+              | 
+title         | 3.2.2 Information Modeling
+text          | Information is modeled similarly to entropy, and transcends its basis in statistical
+              | mechanics “to describe any system with states {i} and a given probability distribution
+              | {pi}. Credit for realizing this is usually given to Shannon [Shannon 1948], although
+              | antecedents include Szilard, Nyquist, and Hartley.”[Bais 2010] Treating information this
+              | way is useful to analyze and design communication and encryption systems.
+blank         | 
+              | 
+text          | Shannon proposed that by analogy to the entropy S, information can be defined as
+blank         | 
+              | 
+text          |                H = -ipilogpi
+blank         | 
+              | 
+text          | A microstate pi is one particular instantiation of all the degrees of freedom of our system.
+              | If there are N particles (or bits of information), and each bit can have 2 values, then there
+              | are 2N possible microstates. The space of possible microstates is called the phase space.
+blank         | 
+              | 
+text          | Information is usually written as I() to emphasize its dependence on the scale of
+              | resolution of the measurements (and without the Boltzman constant)
+blank         | 
+              | 
+text          |                I() = -ipilogpi
+blank         | 
+              | 
+text          | This () can be used to define the information dimension
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              34
+text          |                  D = lim( ->0) ( I() / |log | )
+blank         | 
+              | 
+text          | which becomes the fractal dimension with sufficient resolution.
+blank         | 
+              | 
+text          | In information theory it is common to take logarithms in base two. Units of information
+              | are called bits as opposed to ‘nats’ for entropy with the conversion that 1 nat = 1.443 bits.
+blank         | 
+              | 
+text          | Each information package can have its information content “I” measured. The
+              | information content is a higher level abstraction from the data contained in the package.
+blank         | 
+              | 
+text          | Information exchange between actors can be modeled with information theory. Here we
+              | will distinguish information transfer from information acquisition or creation (as in a lab
+              | or designer’s mind).
+blank         | 
+              | 
+text          | If we assume the information being transferred can be represented with i bits of
+              | resolution r, then the piece of information being transferred by actor x, I(x), can be
+              | represented as
+              |                  I(x) = -iPx(xi)log2Px(xi)                (1)
+blank         | 
+              | 
+text          | The new (conditional) information received by actor y from the information sent by actor
+              | x will be
+              |                  I(y|x) = -iPx(xi)jPy|x(yj|xi)log2Py|x(yj|xj)       (2)
+blank         | 
+              | 
+text          | This equation expresses the fact that the receiver must interpret (decode) the information
+              | he receives based on their previous mutual understanding.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                  35
+title         | 3.2.3 Product Entropy and Information Packages
+text          | In discussing information content (I(x)) as opposed to information transfer, the entropy
+              | (information) level of a possible conceptual design is very high in that there are a very
+              | large number of ways the design could be implemented; different functions included;
+              | different materials used; different reliabilities; etc. The entropy level of a completed
+              | product is close to zero in that the design is frozen. This “zero” entropy is a relative
+              | value since there is still myriad flexibility in subsequent product use, in product
+              | combinations, etc. (Figure 3-3).
+blank         | 
+              | 
+              | 
+              | 
+text          |                     Figure 3-3 Product Entropy Flexibility for Related Designs
+              | Entropy (s) is very large when a design problem starts. As decisions are made, materials chosen,
+              | and functionality included, entropy is reduced until there is no flexibility (s = 0) in the final
+              | product. At an earlier preliminary design stage (s > 0), there is flexibility in the design to create
+              | different possible variants. The set of possible variants is a Hilbert space.
+blank         | 
+              | 
+              | 
+              | 
+text          | Likewise the entropy of a new technology or technique is very large. This new material
+              | or new processor could be used in thousands of different products; the process could be
+              | refined through cost reduction, or not, which would drive how and where it would be
+              | used. Of course, in this sense the entropy will likely grow as the ideas expand.
+blank         | 
+              | 
+              | 
+meta          |                                                    36
+text          | The entropy evolution of a product over the design life is an interesting phenomenon. If
+              | you have a product that you want to incrementally improve, you would need to step back
+              | some number of “computation” steps to find a sufficiently flexible design space (with
+              | more entropy) that allows you to move forward with a slightly different instantiation
+              | using other technology for your new product.
+blank         | 
+              | 
+text          | In quantum information theory, the physical state is described by a wave function that
+              | can be thought of as a vector in an abstract, multi-dimensional state, called a Hilbert
+              | space. Hilbert space replaces the concept of phase space in classical mechanics. An
+              | important difference is that many quantum information quantities cannot be measured
+              | simultaneously. Also, as time passes and the q-bits become less deterministic, the Hilbert
+              | space rapidly diverges away from what you have earlier defined.
+blank         | 
+              | 
+text          | Note that another interesting phenomenon is observed in product families. Here you
+              | would like to have an intermediate shelf (stage) that has enough flexibility to be able to
+              | evolve in several directions, or allows a time-phased introduction corresponding to a
+              | time-phased improvement of your particular core technology. The essential conundrum
+              | is to have the right amount of breadth so that you can easily arrive at your next step, but
+              | not too much breadth which can be confusing and hard to consider (Figure 3-4). This
+              | “shelf” stage must be stored and documented.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              37
+text          |                               ln(x)
+blank         | 
+text          |                                               t2
+blank         | 
+text          |               Design Space
+              |                                                       t1
+              |                                                                      Q = f(Mt)
+blank         | 
+text          |                                              S>f
+              |                                    S >> f                   S = f (relative)
+blank         | 
+              | 
+              | 
+              | 
+text          |                              Figure 3-4 Product Entropy Levels for different rates of Growth
+              | Intermediate shelves (stages) have design flexibility (s > 0) to be able to evolve in several directions, or
+              | allow a time-phased introduction corresponding to a time-phased improvement of your particular
+              | core technology. Since the Hilbert space rapidly diverges away from what you have earlier defined,
+              | the essential conundrum is to have the right amount of breadth so that you can easily arrive at your
+              | next step, but not too much breadth which can be confusing and hard to consider
+blank         | 
+              | 
+              | 
+              | 
+text          | Controlling the entropy level (information level) is one of the functions of organizational
+              | computation.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                            38
+title         | 3.2.4 Information Growth, and Product Evolution
+blank         | 
+              | 
+text          | The degree to which the state of an actor (or group) at one point in time determines the
+              | state of a different actor at a subsequent point in time is driven by the mutual information
+              | between these observations, and the conditional information between them. The mutual
+              | information I(x/\y) = I(x) intersect I(y) is the common set of knowledge that allows them
+              | to understand each other and includes the range from basic engineering equations to
+              | current catalog numbers. When Actor X discovers new information I(xi+1) > I(xi) and
+              | wants to transfer this information to Actor Y, he will encode it for transfer based on
+              | mutual information I(xi/\y) and conditional information I(y|xi).
+blank         | 
+              | 
+text          | For two correlated events x and y, the relations between the information I(x), conditional
+              | information I(x|y), joint information I(x,y), and mutual information I(x/\y) are illustrated
+              | in (Figure 3-5) [Metzler 2003].
+blank         | 
+              | 
+              | 
+              | 
+text          |                         Figure 3-5 Mutual and Conditional Information
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              39
+text          | For engineering design we are interested mainly in post-diction. Post-diction is the
+              | forward use of information to increase the knowledge of another actor in a strictly
+              | subsequent time state. The initiator’s message is based on his current state, and the
+              | receiver interprets it according to what the receiver knows. (Note that this is the inverse
+              | direction to prediction (coding) wherein one could compute the desired resolution or
+              | scale that the sender should use.) The mutual information I(y/\x) is simply the difference
+              | between input information I(x) and the conditional information I(x|y) or I(y) and I(y|x).
+              | The quality of the information received by Actor Y (at a subsequent time i + n) will be a
+              | function of the accuracy of coding I(x|y) given I(x/\y). Thus
+blank         | 
+              | 
+text          |                I(yi+1) = I(xi/\y) + I(xi+1|y)f(I(xi/\y)) (3)
+blank         | 
+              | 
+text          | Mutual information I(xi/\yi) is not static, and actors’ mutual information will decrease
+              | over time if not refreshed or synchronized. This can be thought of as the actors evolving
+              | separately, starting to use different materials, using different design lingo [Leifer 1999],
+              | or even working on different programs or products.
+blank         | 
+              | 
+text          | Given our logarithmic definition of information, we note that mutual information decays
+              | to zero on the order(log r) time steps, where r is the resolution of the information.
+              | Statically, without refresh, I(x/\y) will naturally approach 0 on orders similar to product
+              | life, material life, and/or component life. This is similar to having a design use a
+              | particular Digital Signal Processor (DSP) that goes out of production and must now be
+              | replaced with a different technology. For our community, this is on the order of 5 to 12
+              | years for aerospace type products. This will be discussed more later.
+blank         | 
+              | 
+text          | When I(x/\y) reaches zero, it creates a wall within the complex (design community)
+              | where information is not flowing. This has several effects. For one, it reduces the
+              | computational efficiency of the organization. For another, it effectively creates separate,
+              | competing sub-complexes. In a small scale industry this could be good as it maintains a
+              | vibrant population of new small businesses. For our very large systems within our
+              | constrained resources, this is not good. A third side effect that may occur as a result of
+blank         | 
+              | 
+              | 
+meta          |                                                40
+text          | losing mutual information coherence is that the group that is cut off may die (or become
+              | irrelevant). At this point it would be consuming resources without a useful output or, if
+              | recognized, it would have to be reabsorbed with the concomitant costs of re-training.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             41
+title         | 3.3 Task Variety
+blank         | 
+title         | 3.3.1 Variety and Information Processing
+text          | Variety is defined as the set of actions needed by an actor to execute an activity, where an
+              | actor can be an individual, a group of individuals, or a group of groups. The set of
+              | actions includes information gathering, information creation and processing, distribution
+              | of resultant information, self control, and environmental interaction with other actors.
+              | Executing a task requires an actor to have sufficient variety to perform all of the
+              | component activity required to execute the task.
+blank         | 
+              | 
+text          | It is conventional to measure variety, like information, in logarithmic units so that the
+              | total variety of a set of independent components V=log(M) is the sum of the variety of
+              | the components, V=Nv, where v=log(m).
+blank         | 
+              | 
+text          | The key to task analysis of the variety of any system is that each of the actors has a limit
+              | on its variety – the logarithm of the number of distinguishable states. Components can be
+              | individuals that act in performing tasks, or individuals that manage or coordinate tasks or
+              | serve as communications channels. [Bar-Yam 2004b]
+blank         | 
+              | 
+text          | Assume that the design system is composed of a number of subsystems, N, that are
+              | variously coordinated to respond to external contexts. The number of possible actions
+              | that the system can take, M, is not more than mN, the product of the possible actions of
+              | each part, m. We further constrain the problem of effective function by assuming that
+              | effective actions require a sufficient variety at each scale of action corresponding to the
+              | requirements for action at that scale. At every scale the variety of the system must be
+              | larger than the variety necessary for the task. [Bar-Yam 2004b]
+blank         | 
+              | 
+text          | Assuming a simple coordination mechanism such that the system is partitioned into
+              | groups that are fully coordinated and that different groups are independent of each other,
+              | then the variety of actions of each group is the same as the variety of actions of any
+              | individual of that group, and the scale of action is just the number of individuals in that
+blank         | 
+              | 
+meta          |                                              42
+text          | group. For the entire system the variety at scale k is D(k)=vn(k) where n(k) is the
+              | number of different k-member fully coordinated groups needed to perform the entire task,
+              | which therefore at a minimum requires N=kn(k) components to perform. The total
+              | variety of the task is proportional to the total number of subsets of any scale V=D(k).
+              | [Bar-Yam 2004b]
+blank         | 
+              | 
+text          | With these assumptions, given a predetermined number of components N, the system
+              | can, in the extreme, perform a task of scale N, with variety equal to that of one
+              | component, or a task of scale one with variety N times as great.
+blank         | 
+              | 
+text          | More generally the equation Nv=kD(k) can be considered a constraint on the possible
+              | behaviour patterns (sum rule) of a system due to different mechanisms of organization. It
+              | is often convenient to think about the variety of a system, V(k), that has a scale k or
+              | larger, as this is the set of possible actions that can have at least that scale,
+blank         | 
+text          |                 V(k) = Σ D(k’) (summed for k’ = k,N and 1 < k < N)
+blank         | 
+              | 
+text          | Then the total variety of the system is V(1), and the sum rule can be written as:
+blank         | 
+text          |                 Σ V(k) = Nv     (summed for k = 1,N)
+blank         | 
+              | 
+text          | This equation “describes the existence of a tradeoff between variety at different scales.
+              | Increasing the variety at one scale by changing the organizational form must come at the
+              | expense of variety at other scales.” [Bar-Yam 2004 p.19]
+blank         | 
+              | 
+text          | Hierarchical systems have performance limits. Scale-free organizations avoid these
+              | limits by adding (essentially) communication paths which avoid variety limits, but the
+              | price is loss of controllability. The balance of controllability and efficiency is important,
+              | especially for Mega-Systems, and provides a distinguishing characteristic from
+              | Evolutionary Engineering which has been primarily developed for larger populations
+              | without considering costs of scale, or even availability at scale.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                43
+title         | 3.3.2 Variety in Distributed Product Development
+text          | Performance of distributed complex product development networks has been analyzed to
+              | discover the role of various types and mixes of variety in system development. For
+              | instance [Braha 2007] studied relations between input and output tasks, design iterations,
+              | and convergence in large distributed task networks for product design of complex
+              | systems such as vehicles, hospitals, and pharmaceutical facilities. This analysis was
+              | based on detailed design process models and task networks as shown in Figure 3-6.
+blank         | 
+              | 
+              | 
+              | 
+text          |                           Figure 3-6 Design Process Models and Networks
+              | This PD task network consists of 1,245 directed information flows between 466 development tasks.
+              | Each task is assigned to one or more actors (“design teams” or “engineers”) who are responsible for
+              | it. [Braha 2007] Input information can be ‘external’, intra-disciplinary’, or ‘cross-disciplinary’.
+              | Output information moves toward the right. The primary diagram shows a closeup of three tasks
+              | with 17 information streams; the inset shows the overall (quasi-scale-free) network.
+blank         | 
+              | 
+              | 
+meta          |                                                  44
+text          | Some of the interesting results from these studies showed that limits on input versus
+              | output variety had emergent effects on design convergence (Figure 3-7). In this case, one
+              | would apply special attention to tasks with a large number of outputs.
+blank         | 
+              | 
+              | 
+              | 
+text          |            Figure 3-7 Meta-Performance Measures of Distributed Product Development
+              | Research results show that limits on input versus output variety has emergent effects on design
+              | convergence. In this case, one would apply special attention to tasks with a large number of outputs.
+              | [Braha 2007]
+blank         | 
+              | 
+text          | However, a major limit on these types of analysis is an assumption of homogenous
+              | communication channels. Also these links are directed and have a single defined
+              | information package. Another limit is that the transfer of information was assumed to be
+              | 100% complete so there was no degradation due to scale. These limits will be addressed
+              | in Section 4.0.
+blank         | 
+              | 
+              | 
+meta          |                                                  45
+title         | 3.4 Information Transfer in Chaotic Channels
+blank         | 
+title         | 3.4.1 Dynamical Systems and the Logistics Map
+text          | Dynamical systems evolve over time. The composition/capabilities evolve as a function
+              | of the previous state. One model of interest representing this behaviour is the logistic
+              | equation. “The logistic equation (sometimes called the Verhulst model, logistic map, or
+              | logistic growth curve) is a model of population growth first published by Pierre Verhulst
+              | [Verhulst 1838]. The Verhulst model is continuous in time, but a modification of the
+              | continuous equation to a discrete quadratic recurrence equation is also known as the
+              | logistic model.” [http://mathworld.wolfram.com/LogisticEquation.html] The logistic
+              | map is the name given to one particularly useful way of expressing the logistic model:
+blank         | 
+              | 
+text          |                nt+1 = (birthrate – deathrate)[knt – nt2]/k
+blank         | 
+              | 
+text          | where nt is the population at the current generation and k is the carrying capacity. To
+              | derive the logistic map from this model, let
+              |                xt = nt/k, and
+              |                a = (information creation rate – information annihilation rate)
+              | to get the map posed as a simple iteration:
+blank         | 
+              | 
+text          |                xt+1 = axt (1 - xt)                     (4)
+blank         | 
+              | 
+text          | Note that xt is a fraction of the carrying capacity (from the population model). For us,
+              | this is the amount of the original information that is still understandable over the passage
+              | of time as t --> t + 1. The variable ‘a’ represents the rate of net information production.
+blank         | 
+              | 
+text          | The logistic map can be used to study the behaviour of complex systems over time as
+              | they evolve. For our model of mega-design communities, the link performance between
+              | two groups will evolve over time, causing the relationship of the two groups to evolve in
+              | response. As each link in our quasi-scale-free community evolves according to its own
+              | characteristics, the overall design community will evolve in a doubly complex fashion.
+blank         | 
+              | 
+meta          |                                                46
+text          | The logistic map is frequently called the chaos model, and discussions of information
+              | transfer in complex systems are sometimes discussed as information transfer in chaotic
+              | channels.
+blank         | 
+              | 
+text          | One representation of the behaviour of our dynamical system is shown in (Figure 3-8)
+              | [Mitchell 1992], which shows how the output in these systems quickly become
+              | unpredictable (chaotic). The bifurcation points, where one path expands into two, are
+              | strange attractors and represent areas of local stability.
+blank         | 
+              | 
+              | 
+text          |                                                                  B C
+              |                                                A
+blank         | 
+              | 
+              | 
+              | 
+text          |                                     Figure 3-8 Bifurcation Diagram
+              | The bifurcation points, where one path expands into two, are strange attractors and represent
+              | areas of local stability. In this diagram the areas of local stability are (A) 3.0, (B) 3.45, and (C) 3.55.
+blank         | 
+              | 
+              | 
+              | 
+text          | “Note that for an N dimensional dynamical system there are N Lyapunov exponents. The
+              | positive Lyapunov exponents + measure the rates of exponential divergence, and the
+              | negative ones - the rates of convergence.” [Bais 2010] The sum of the positive
+              | Lyapunov exponents (the metric entropy) and the information dimension can be used to
+              | estimate the amount of time that postdictions remain valid.
+blank         | 
+              | 
+              | 
+meta          |                                                      47
+title         | 3.4.2 Information Transfer in Chaotic Channels
+blank         | 
+              | 
+text          | Earlier (Section 3.2), information was modeled in a general, bi-directional sense. Now
+              | we want to look at the time sequence of information and how it behaves as it moves into
+              | subsequent states. Conditional information transfer was defined in equation (2). Actor X
+              | starts with some particular, local information iPx(xi), so that our local conditional
+              | information becomes
+blank         | 
+              | 
+text          |                Il(y|x) = jPy|x(yj|xi)log2Py|x(yj|xj)         (5)
+blank         | 
+              | 
+text          | We can define a variable for the rate of information change d = dy/dx which represents
+              | how the information is changed by the environment during a transfer (or over time). This
+              | includes both to the dissipation rate and to the divergence rate.
+blank         | 
+              | 
+text          | Assuming sufficiently fine resolution, the conditional information at a subsequent time
+              | from a given initial state can be solved to be:
+blank         | 
+              | 
+text          |                < Il(y|x)>o = log2d + 1/(2dln2)                (6)
+blank         | 
+              | 
+text          | Now we subject the conditional information (equation (6)) to evolution in the logistics
+              | map (equation (4)). This can be computed by numerical integration (avoiding the
+              | singularity at d = 1). Results are shown in Figure 3-9 (note a = d). Even after only 3
+              | iterations, it can be seen that I(y/\x) is no longer monotonic in a – several maxima of
+              | conserved information can be seen. I(y|x) does not depend strongly on r, whereas the
+              | other quantities include an additive term of log2r [Metzler 2003].
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                 48
+text          |                      t=2                                                   t=3
+blank         | 
+              | 
+              | 
+              | 
+text          |          Figure 3-9 Conditional, mutual, and total information for two and three time steps
+              | “Here, I(y|x) represents the uncertainty generated by stretching and compressing; I(x) – I(y)
+              | represents the uncertainty through shrinking of phase space; and I(x) – I(y/\x) is the average
+              | information necessary to reconstruct x from knowledge of y. The mutual information I(y/\x) is the
+              | amount of information about the initial state retained after the mapping [Metzler 2003].
+blank         | 
+              | 
+              | 
+              | 
+text          | For intermediate time iterations (3 < t < 100), Figure 3-10 shows the mutual information
+              | at various intermediate times (note a = d). Several large peaks are apparent. The wider
+              | peaks in Figure 3-10 at a = 1, 3, and 3.54 correspond to the bifurcation points. There, the
+              | Lyapunov exponent is 0 and deviations from the fixed point or cycle decay like a power
+              | law rather than exponentially. These broader peaks indicate information transfer regimes
+              | that are still working effectively, as long as you can choose the correct formatting.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                  49
+text          |                                                                       B               C
+              |                                    A
+blank         | 
+              | 
+              | 
+              | 
+text          |                   Figure 3-10 Mutual information for larger iterations of time
+              | The wider peaks at a = 1, 3, and 3.54 correspond to the bifurcation points. There, the Lyapunov
+              | exponent is 0 and deviations from the fixed point or cycle decay like a power law rather than
+              | exponentially [Metzler 2003]. These broader peaks (A, B, and C) indicate information transfer
+              | regimes that are still working effectively, as long as you can choose the correct formatting.
+blank         | 
+              | 
+text          | “The narrow peaks (e.g. near a = 1.3, 1.6, and 2.5) occur when the fixed point is very
+              | close to the boundary between two bins, such that small deviations from the fixed point
+              | lead to ambiguities in the outcome. They change positions if the binning [resolution] is
+              | chosen differently.” [Metzler 2003] This is similar to data aliasing caused by information
+              | transfer between groups within our design community. These effects will be described in
+              | Section 4.3 - Section 4.6.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                   50
+title         | 3.4.3 Multi-scale Information Transfer
+blank         | 
+              | 
+text          | Regarding information transfer between two actors, if the message received is completely
+              | uncertain, the message is lost – this is often the case in chaotic systems. On the other
+              | hand if all received messages appear to be the same, the recipient cannot determine what
+              | message he was supposed to receive – this can occur in dissipative systems.
+blank         | 
+              | 
+text          | “Dissipation and chaos have a common aspect: in both cases the dynamics makes a
+              | connection between large and small scales. Chaotic dynamics amplify small differences
+              | in the initial states until they reach macroscopic proportions, whereas dissipative
+              | dynamics shrink differences until they vanish below the threshold of perception.” [Bais
+              | 2010]
+blank         | 
+              | 
+text          | For our discussion, we will customize the following definitions of variables:
+blank         | 
+              | 
+text          |         a = = the (designed) spread rate of information. (Too high and too much non-
+              |         synchronized information results in chaos; too low and dissipation (friction)
+              |         slows information exchange so much that there is no growth from synergy.) (This
+              |         is similar to the amplification parameter in logistics map terminology which is a
+              |         combination of growth rate and death rate.) “a” is a controllable or cultivatable
+              |         parameter.
+blank         | 
+              | 
+text          |         r = = resolution. Information packets have behaviors related to their size divided
+              |         by the resolution of the information. Packetization of the information at some
+              |         resolution is related to the size of the producing group: individual researchers or
+              |         other producers that have high r create so much information that the channel
+              |         becomes clogged. Clumping the information (to a higher scale) lets it spread
+              |         better because it rejects noise.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              51
+text          |        t = = time. We will calculate the individual time scales based on a static
+              |        dissipation time of 5 years, or 60 months or 250 weeks. In order for our scale to
+              |        span orders of magnitude, we will work in weeks.
+blank         | 
+              | 
+text          |        X = = Sender.
+              |        Y = = Receiver.
+blank         | 
+              | 
+text          | Organizations have both peer and hierarchical levels of “production” that affect
+              | information transfer and consumption. We will next define multi-scale, and then three
+              | types of multi-scale parameters: organizational, task, and time scales.
+blank         | 
+              | 
+text          | A) Multi-scale Defined [Bar-Yam 2004b]
+              | Multi-scale effects can be pictured by imagining information at different scales
+              | analogously to multi-scale real numbers. “On one hand, each real number can be
+              | represented by one point on the real axis – it is a one-dimensional quantity. On the other
+              | hand, in the usual descriptions (decimal, binary, etc.), real numbers are represented by a
+              | set of integers that stand for different scales – the scales of 1s, 10s, 100s, etc. This makes
+              | sense because it reflects what happens when some x is added to x: the digits of x are
+              | strongly affected for all scales finer than the scale of x, and weakly affected for coarser
+              | scales. There are two [aspects] with the usual representations: first, they are
+              | discontinuous: a small change on a fine scale will have no effect at all on coarser scales
+              | most of the time, but a dramatic effect in rare cases (such as when 0.001 is added to
+              | 0.999). This is a necessary side effect of using discrete (integer) representations on each
+              | scale. Second, they do not lend themselves to simple modification under multiplication:
+              | multiplication is basically a convolution of the representations of the two factors.
+              | Whereas multiplications with numbers that have a simple representation in the chosen
+              | base gives a shift (e.g. multiplication with 10 in the decimal representation just shifts the
+              | decimal point), all other factors lead to changes throughout the scales.”
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              52
+title         | B) Organization Scales
+text          | For our engineering community, one instantiation of scale that can be easily recognized is
+              | levels in an organizational hierarchy. Information being passed up and down the chain
+              | gets compressed or expanded for delivery. Months’ worth of testing is compressed into a
+              | report that the group delivers to their manager. The manager uses certain meta-aspects at
+              | his level (budget spent, Intellectual Property (IP) filed, etc.) but has no visceral under-
+              | standing of whether the new component is easy or hard to use, and whether it provides
+              | the improved performance easily or only with great tweaking. The report may be filed in
+              | an IP repository. Later, a design group looking for a new component accesses the reports
+              | and tries to understand it enough to determine if they should use it in their product.
+blank         | 
+              | 
+text          | So vertical-organization information-transfer either dissipates information (upward), or it
+              | adds noise (chaos) (downward) (unless accompanied by additional (decompression)
+              | information).
+blank         | 
+              | 
+text          | An Organizational Aliasing Factor (OAF) is defined, and estimated to be on the order of
+              | the relative sizes of the hierarchical groups. For instance, if a manager has ten
+              | subordinates, then:
+              |        OAF      = O( scale)
+              |                 = O(10) – O(1)
+              |                 =1
+              | This factor is similar to limits on organizational controllability [Hogg 2001].
+blank         | 
+              | 
+text          | C) Variety Scales
+              | Cross-organization information transfer can ostensibly retain the information scale and
+              | relay information at very high bandwidths without loss, although again the transfers are
+              | subject to transmission effects. Cross-organization transfers are often not peer to peer,
+              | and are frequently dis-intermediated by other functional groups.
+blank         | 
+              | 
+text          | These agents are peer-to-peer agents in a weak sense as defined by Petrie [Petrie 1996].
+              | In this sense they are true agents that provide generation of new information, but they are
+blank         | 
+              | 
+meta          |                                               53
+text          | weak in that they do not use standard protocols for communication. Each agent’s
+              | protocols (methods) are particular to that set of agents.
+              | Variety scale differences in peer to peer relations involve the definition of mutual
+              | information needed for the information transfer. These scale differences can arise from
+              | three variables: resolution, translation, and context.
+blank         | 
+              | 
+text          | Resolution effects occur when the information needs to be further developed to add more
+              | detailed design information.
+blank         | 
+              | 
+text          | Translation effects occur when the type of information needs to be transformed. For
+              | example, when a prototype’s key development focus was improving and characterizing a
+              | new control system possibly using new lightweight components, and it now needs to be
+              | characterized for material properties for reliability and radiation effects. The original
+              | (controls) engineers may not have documented the reference information needed to start
+              | to collect the information and samples for material environmental testing.
+blank         | 
+              | 
+text          | Context effects involve the environmental linkages and might include introducing
+              | subcontractors and transferring between points of contact within the subcontractors
+              | organization.
+blank         | 
+              | 
+text          | We define a Variety Aliasing Factor VAF = ln(V1/V2). Here Variety Vi is estimated to be
+              | linear with the number of people in the group, although other studies [BarYam 2004a]
+              | have addressed fractional variety with non-linear additive effects. VAF has been
+              | computed for each link in our scale-free design community as shown in (Figure 3-11).
+              | Organizational aliasing factors (OAF) are included with variety aliasing factors (VAF)
+              | since each half of an explicit organizational hierarchy should be designed to have the
+              | correct agents to compress / decode the information packages.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              54
+text          |         Figure 3-11 Values for Combined Organization (OAF) and Variety (VAF) Aliasing
+              | Values in red are the combined OAF and VAF based on the measured organizational values shown
+              | in the Mega-Organization model in Section 2.1
+blank         | 
+              | 
+              | 
+text          | At this level of modeling, we can ignore actor interactions as interposed by variety
+              | [BarYam 2004a] regarding whether they are simply coordinated, fully coordinated, or
+              | independent.
+blank         | 
+              | 
+title         | D) Time Scales
+text          | Information in our mega-design community is produced by certain groups for certain
+              | purposes. Information can be produced quickly or it may take quite some time.
+              | Consumption rates will be different for different groups and, within groups, will be
+              | different for different types of information. Information exchanges may be scheduled
+              | processes (like quarterly reports), they may be continuous (as may occur within a lab), or
+              | they may be ad hoc.
+blank         | 
+              | 
+text          | During the early stages of design of a very large product, the design engineers may talk
+              | with laboratory staff frequently to discover the possible span of solutions that are
+blank         | 
+              | 
+              | 
+meta          |                                                 55
+text          | implementable. However, after the PDR (Preliminary Design Review), the design point
+              | has become conceptually fixed and the designers switch from talking with scientists to
+              | talking with component vendors in order to develop a detailed design. The product team
+              | will not talk with the laboratory scientists until after detailed design, manufacturing,
+              | integration, test, launch, and initial operations. There may be a 12 year gap before the
+              | design engineers again talk with the research team. Now, assuming the laboratory is not
+              | lazy, they have been producing research reports for each of the last 12 years (600 weeks)
+              | which have been ignored by the engineers. This is multi-scale aliasing (Figure 3-12).
+blank         | 
+              | 
+text          |                          BD                     PROG                                            R&D
+blank         | 
+              | 
+              | 
+              | 
+text          |          1 year          Exec                    Exec                                           Exec
+blank         | 
+text          |                                                             3 years
+              |             Adjacent     BD              3     Executive
+              |                                                                                  3   Senior                  Adjacent
+              |             Markets    Director                  Staff                               Support               Technologies
+              |                                                                 1.5
+              |                           BD
+              |                                     12          4                     Advanced                  Senior
+              |                                                 Program
+              |                          Staff                                         Develop                 Manager
+blank         | 
+text          |                                                                                  2 years
+              |                         Senior       3         Subsystem               CRAD
+              |                                                                                                 Senior
+              |                        Engineer                                                                Scientist
+blank         | 
+              | 
+text          |                                     12 years                                             2
+              |                                                                                                 Staff
+              |              Tools     Engineer                Engineer               Engineer
+              |                                                                                                Scientist
+              |                                      3
+              |          4 years       Discipline
+              |                                                                                                            1 year
+              |                         Director
+blank         | 
+              | 
+              | 
+              | 
+text          |                         ENG
+blank         | 
+              | 
+text          |                           Figure 3-12 Values for Time Aliasing Factor (TAF)
+              | Numbers in black are the event lifetimes for each of the red-boxed major organizational elements.
+              | For instance, ‘Programs’ take 12 years to develop their mega-system; ‘Advanced Development’ takes
+              | 2 years to develop a prototype. TAFs (red numbers), are calculated on links that cross major
+              | boundaries, and are based on the relative values of the two intersecting time epochs.
+blank         | 
+              | 
+text          | Of course the situation is not quite so simple as there are other mega-products within the
+              | design community that are at different stages of development. So assuming a reasonably
+              | large set of programs, there are likely other efforts that were listening during the
+              | intervening 12 years. But unfortunately with large systems we do not have a normal
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                            56
+text          | distribution of programs, and, operating within a quasi-scale-free organization, there are
+              | other timing constraints.
+blank         | 
+              | 
+text          | So the opportunity for multi-scale time aliasing is large for organizations dealing with
+              | large products. There are dis-intermediating organizations that are set up to overcome
+              | this time aliasing such as groups that create annual research reports from the continuous
+              | science production, and groups that match business requirements to technical capabilities.
+              | These groups have been inserted onto information transfer paths to reduce multi-scale
+              | aliasing. Balance and effectiveness of these anti-aliasing functions can be analyzed
+              | within our network.
+blank         | 
+              | 
+              | 
+title         | 3.4.4 Combined Varietal, Organizational, and Temporal Aliasing
+text          | The aliasing factors (AF) from individual scale parameters:
+              |        TAF = t1/t2
+              |        OAF = O(scale)
+              |        VAF = ln(V1/V2)
+              | are combined according to an efficiency equation for combined link activity. The total
+              | product information aliasing factor ‘p’, for each link, becomes:
+              |        p = π(T,O,V) = (t1/t2)*(O(scale))*(ln(v1/v2))
+blank         | 
+              | 
+text          | Reference (Figure 3-13). These values will be used in subsequent performance analyses.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             57
+text          | Figure 3-13 Network with total Product Information Aliasing Factors (p)
+              |         for combined Time, Organization, and Variety Factors
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                   58
+title         | 3.4.5 Noise in Chaotic Channels
+text          | Scale factors cause received/stored information to not equal transmitted/produced
+              | information. Is it noise or is it compression or aliasing? At the level of abstraction we
+              | are discussing here, it does not really matter. What matters is that we have a measure of
+              | the turbulence structure in the link so we can smoothly elide.
+blank         | 
+              | 
+text          | For individual link smoothing (improvement), there are questions about what kind of
+              | noise and dissipation is injected, and how can it be controlled, reduced, or avoided?
+              | Inversely, how can we amplify “good” information exchange? For example, synthesizing
+              | information into a report or a meeting format compresses it. In order to decompress the
+              | report properly, or at least better, we may want to add the engineer’s names and phone
+              | numbers, or add more hotlinks to the supporting sources.
+blank         | 
+              | 
+text          | The time length between preparation and consumption also causes dissipation. For
+              | instance, a lab engineer currently remembers how to debug his system, but 6 months later
+              | he would have to refer to his documentation and think for a while and re-analyze his
+              | system. This may not be adjustable, except possibly by deciding whether to use the
+              | prototype system before the inventor has time to forget.
+blank         | 
+title         | 3.4.6 Synchronization
+text          | Organizations are kept internally synchronized according to communication among the
+              | actors. The rate, scale, and granularity of synchronization create a characteristic that is
+              | similar to the evolution rate in a computing organism. A tightly coupled organization can
+              | steer more quickly to adapt to changes. One could imagine that steering a big ship is not
+              | as hard as steering a line of barges with a tug at one-end through as s-curve. Despite the
+              | inertia, at least it is tightly coupled.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              59
+title         | 4 Application of Integrated Link/Network Model
+blank         | 
+title         | 4.1 Matching Scale Dispersion to Time Regimes
+text          | We now interpret and expand the results of previous sections with a view to the problem
+              | of optimal computation (communication) within our organization network. Given the
+              | time scales of product delivery, tool evolution, and staff relocations defined earlier, how
+              | do we select the size of groups, their relationships, and the type of information transfer
+              | and storage (memory), such that we get “low-noise” information spread and growth
+              | within the time frame of evolutionary design?
+blank         | 
+              | 
+text          | Our goal is to foster a system whose dynamics are somewhat stable to perturbations and
+              | slow compared to the time t. Remember that we are solving the problem of post diction,
+              | not prediction, which is what gives us flexibility for genetic evolution and emergence
+              | within this design organization. This is very significant. Prediction implies accurately
+              | arriving at a predetermined optimal point. Determining the future specification is time-
+              | consuming, and arriving at the point requires extra (control) resources. Post diction
+              | implies efficiently using your (past) resources to move generally toward your goal.
+blank         | 
+              | 
+text          | The information being received by agent Y (I(y)) is less than the original information I(x)
+              | because of the dynamics of the information carrying capacity of the channel (Figure 4-1).
+              | The received information is a function of I(x^y) and I(x|y). There are certain exchange
+              | resonances where the information scale matches the transmission scale, and the
+              | information is not distorted.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              60
+              |                         7
+blank         | 
+text          |                         6                                        Good Information
+              |                         5
+              |                                                                    Postdiction
+              |    Information (bits)
+blank         | 
+text          |                         4                                                                              I(x)
+blank         | 
+text          |                         3                                                                              I(y)
+              |                                                                                                        I(y^x)
+              |                         2
+              |                                                                                                        I(y|x)
+              |                         1
+blank         | 
+text          |                         0
+              |                             0.0           1.0                2.0               3.0               4.0
+              |                                                              aa
+blank         | 
+text          |                                   Figure 4-1 Mutual, Conditional, and Postdicted (I(y)) Information
+              | Information evolution after three time steps. Despite the rapid loss of mutual information I(y^x)
+              | within the first several time steps, there is still enough conditional information I(y|x) in the higher ‘a’
+              | regions to allow good information postdiction I(y) near a=4.
+blank         | 
+text          | “For very short times (t < 3), Figure 4-1 shows that agent Y has the best chances of
+              | postdicting the initial state in the chaotic regime near a = 4. “The loss of information
+              | through chaos is not as significant as that through phase space shrinking in the low-a-
+              | regime.” [Metzler 2003] These activities are similar to a technical symposium, where the
+              | information exchange benefits are a massive (iconic) exchange of new techniques and
+              | results. Information transfer is better when a range of engineers attend a conference
+              | rather than ordering a copy of the proceedings and mailing it around to a distribution list
+              | (given that cost is a separate variable).
+blank         | 
+              | 
+text          | “In the limit of very long times, when the system has converged to its attractors, the only
+              | regime where information about the initial state persists is the bifurcation regimes. What
+              | value of “a” gives optimal transmission depends on the resolution: the recipient has to be
+              | able to resolve all branches of the cycle to make full use of the remaining information.”
+              | [Metzler 2003] This implies the information to be transferred must be completely
+              | defined in a static form with all assumptions and requirements documented; with the
+              | trade space documented; performance results parameterized; and consistent with future
+              | engineering and IT tools. Thus for large t (t > 100), we need to have a = 1. In other
+blank         | 
+              | 
+              | 
+meta          |                                                                    61
+text          | words, all details need to be documented in long-term memory as otherwise there will be
+              | insufficient knowledge to interpret the information.
+blank         | 
+              | 
+text          | The Saturn V rocket used to launch the moon missions is an excellent example. Even
+              | though the rocket was produced for ten years during the 1960s, some items were not
+              | documented, such that when the space program was being restarted in the 1980s and
+              | large lift capacity was needed again, the Saturn V could not be reproduced, and a whole
+              | new design cycle had to be started anew. In fact, forty years later, we are still in the
+              | midst of a ten-year process to design and qualify the new Space Launch System (SLS).
+blank         | 
+              | 
+text          | For intermediate times (10 < t < 80)), at high “a”, chaotic dynamics eliminates all
+              | information about the initial state; so does fast convergence to a single fixed point for
+              | small “a”. As (Figure 4-2) shows, the quality of agent Y’s mutual information I(x/\y) is
+              | greatest if “a” is close to one of the bifurcation points ( approximately 3 or 3.5), where
+              | convergence follows a power law rather than an exponential. (Remember from Section
+              | 3.4.1 that this is where the solutions change form.)
+blank         | 
+              | 
+text          | Available/current link transfer rates must match information package delivery type
+              | (resolution), delivery rate, and decoding capability.
+              |                                7
+              |                                                                                          B
+              |                                6
+              |                                                          A                                         C
+              |    Mutual Information I(x^y)
+blank         | 
+              | 
+              | 
+              | 
+text          |                                5
+blank         | 
+text          |                                4
+              |                                                                                                                 t = 10
+              |                                3                                                                                t = 20
+              |                                                                                                                 t = 40
+              |                                2
+blank         | 
+text          |                                1
+blank         | 
+text          |                                0
+              |                                    0.0             1.0                2.0                3.0              4.0
+              |                                                                        a
+blank         | 
+              | 
+              | 
+text          |                                          Figure 4-2 Mutual information for larger numbers of iterations
+              | The loss of mutual information I(x^y) becomes so significant over longer times that there are only
+              | a few “resonant” regions that allow good information transfer. Information can be exchanged
+              | more completely at certain periods of time in certain formats at the resonant nodes B and C on the
+              | graph where a = 3, and 3.5. Node A has low conditional information, and is unrecoverable despite
+              | reasonable mutual information.
+blank         | 
+meta          |                                                                             62
+title         | 4.2 Identification of Candidate Links, Nodes, and Chains
+text          | Network performance is evaluated by looking for link/information mismatch. In (Figure
+              | 4-3), the red circles are evaluated for consistency. The checkmarks indicate consistent
+              | link parameters and information formatting. The sad-faces indicate mismatches that will
+              | be discussed in subsequent sections.
+blank         | 
+              | 
+text          | The product information aliasing factor ‘p’, related to the combination of all the time and
+              | variety scale factors (Figure 3-13), can be placed into three bins:
+              |                s – small (1-2)         (chaotic)
+              |                m – medium (3)
+              |                l – large (4-6)         (dissipative)
+blank         | 
+              | 
+text          | These time regimes address the rate of change of I(x/\y) which is essentially the
+              | differential growth rate (in different directions as well as vector magnitudes) of I(x) and
+              | I(y). See (Figure 4-3). The ‘small’ total-aliasing region should be in the broadband
+              | transfer regime (a=4). ‘Large’ (l) and ‘medium’ (m) total-aliasing factors represent
+              | dissipative regions that require defined communications.
+blank         | 
+              | 
+text          | To modify or adjust the aliasing, you could change the number of people on the link, or
+              | change the percent of people in the transceivers (delta variety ‘receivers’) (V).
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              63
+text          |                        BD                                        PROG                                       R&D
+blank         | 
+              | 
+              | 
+text          |                        Exec                                        Exec                                     Exec
+blank         | 
+text          |                                                                                            m=3
+              |             Adjacent            BD
+              |                                                    m=3
+              |                                                    a=3   √       Executive
+              |                                                                                           a=1   Senior                  Adjacent
+              |             Markets           Director                             Staff                         Support               Technologies
+blank         | 
+              | 
+text          |                                                                  l=5 m=3
+              |                                 BD
+              |                                                       Program    a=1 a=1      Advanced                      Senior
+              |                                Staff     m=3                                   Develop                     Manager
+              |                                          a=3   √                  √       
+              |                                                                                               s=2
+              |                                Senior
+              |                                                      Subsystem                 CRAD
+              |                                                                                           √   a=4           Senior
+              |              Tools            Engineer   m=3                                                               Scientist
+              |                                          a=3   √
+              |                                                                                               s=2
+              |                                                                                           √   a=4           Staff
+              |            s=2                Engineer   m=3         Engineer                 Engineer
+              |                                                                                                            Scientist
+              |            a=1                           a=3   √
+              |                 Discipline
+              |                   Director
+blank         | 
+              | 
+              | 
+              | 
+text          |                      ENG
+blank         | 
+              | 
+              | 
+text          |                  Figure 4-3 Information Transfer Regimes and Amplification Factors
+              | Network performance is evaluated by looking for link/information mismatch. The red circles are
+              | points of interest that have been evaluated for consistency. The checkmarks indicate consistent link
+              | parameters and information formatting. The sad-faces indicate mismatches that will be discussed in
+              | subsequent sections.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                                  64
+text          | The (environmental) transmission/transfer rate of information is represented by ‘a’. This
+              | is proportional to f(birthrate – deathrate), and is similar to the net information creation
+              | rate or circulation rate (recall section 3.4.1).
+blank         | 
+              | 
+text          | The birthrate could be about 1 month in lab; or about 2 years in contracted research and
+              | development (CR&D) if you assume information is transferred only when the prototype
+              | is delivered. This also implies 3months for technology management reports and one year
+              | for internal research and development (IR&D) management planning. The deathrate is
+              | somewhat constant and could be proportional to engineering re-training rate (~5yrs).
+              | Here, retraining might imply new tools, etc.
+blank         | 
+              | 
+text          | In (Figure 4-3), on the link between “BD Director” and “Prog Executive Staff”, a = 3 as
+              | there are monthly program coordination meetings and customer meetings every four
+              | weeks. Between “R&D Senior Support” and “Prog Executive Staff”, a = 1 representing
+              | the annual funding cycle, and the annual report. On the two links between “R&D” and
+              | “CR&D Prototyping”, the teams are working shoulder to shoulder with constant
+              | information exchange and a = 4. The “Operational design team” has monthly design
+              | reviews with the “Engineering process control staff” for a = 3; in “Engineering Tool
+              | Development”, it is rare to have a faster update rate than once per year or 50 weeks, so a
+              | = 1. Finally, the delivery of the “CR&D Prototype” to the “Prog Executive Staff” only
+              | occurs every 100 weeks, so a = 1.
+blank         | 
+              | 
+text          | The resolution ‘r’ which represents the granularity of the information package, whether
+              | delivered face-to-face or in a document, is not a driver. There is only the requirement
+              | that you need a larger ‘r’ for larger ‘a’.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                65
+title         | 4.3 Network Improvements
+text          | Network improvements can be assessed both at the individual links and nodes, and over
+              | “link-chains”. Between individual nodes, mismatches of Link parameters (p, a) indicate
+              | a discontinuity, or a mismatch of Lyupanov exponents. Two nodes can improve their
+              | combined performance by exchanging information more efficiently. However, fixing one
+              | link may or may not improve overall system performance, although there will certainly
+              | be local effects.
+blank         | 
+              | 
+text          | Link-chains of interest focus on particular extended pathways that execute higher level
+              | functions such as translating customer product requirements into research needs.
+              | Evaluation of various link chains can be analyzed both from an a priori interest as well as
+              | from evaluating the scale-free network for paths of poor quality.
+blank         | 
+              | 
+text          | We will first address Link improvements, then Chain improvements in Section 4.3.1 and
+              | Section 4.3.2, respectively.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             66
+title         |              4.3.1 Link Discontinuity Adjustment
+text          |              (Figure 4-4) zooms into our design community network to focus on two identified
+              |              discontinuities labeled A (sad faces in Figure 4-3). In both of these cases, t = m and a =
+              |              1. The communication timeframe is “medium”, but the information delivered is in the
+              |   BD                       PROG
+              |              wrong form (a=1) for direct consumption. Also variety was expended at some costR&D
+              |                                                                                             to
+              |              transform the original information (through ‘Executive Staff’ at B), so the resources used
+              |              to produce the original information are not being exploited efficiently.
+              |   Exec                          Exec                                                                  Exec
+blank         | 
+              | 
+              | 
+text          |                                                                   t=m
+              |   BD
+              |                         B   Executive                             a= 1                     Senior                  Adjacent
+              |                                                         A
+              | Director                      Staff                                                        Support               Technologies
+              |                                                           t=m                                   D
+              |                                                    A      a= 1                     C
+              |    BD          C                                                 Advanced                             Senior
+              |                              Program
+              |   Staff                                                           Develop                            Manager
+              |                                               C                              D
+              |                             D
+blank         | 
+text          |  Senior                                                                                               Senior
+              |                             Subsystem                              CRAD
+              | Engineer                                                                                             Scientist
+              |                                  Figure 4-4 Set of Consistent Guides to Repair Discontinuity
+              |              This figure zooms into our design community network to focus on two identified discontinuities
+              |                                                                                                     Staff is
+              |              labeled A. In both of these cases, p = m and a = 1. So although the communication timeframe
+              | Engineer                     Engineer                             Engineer
+              |              “medium”, the information delivered is in the wrong form for direct consumption.        Scientist
+blank         | 
+text          |              Adjusting the information transfer regime ‘a’ to 3 for the two links labeled A would
+              | Discipline   improve the performance of this system by matching the link parameters. However, this
+              |  Director    increase in bandwidth (changing ‘a’ from 1 to 3 on two links) must be absorbed by the
+              |              consuming agent B in order to maintain overall continuity.
+blank         | 
+              | 
+text          |  ENG         The potential information overload at B (from increasing the bandwidth handled) must be
+              |              digested by appropriately increasing the Variety (to decode, process, and re-encode).
+              |              This could be managed by adding more staff within agent B (Executive Staff), but this is
+blank         | 
+              | 
+              | 
+meta          |                                                              67
+text          | bad for several reasons: first, there are two links so you would need to add two additional
+              | sets; second, the difference in variety is 2 (ln[v1/v2]) which would require significant
+              | additional staff to overcome those magnitudes; and third, the overall link chain would
+              | still be problematic (see section 4.3.2).
+blank         | 
+              | 
+text          | A better adjustment would be to reconnect the “Advanced Development Group” D with
+              | two new links at C . This matches the agent’s time scales (t = m), has a smaller change in
+              | variety (∆V = O(1)), and addresses overall link chain performance.
+blank         | 
+              | 
+text          | The final step is to add more Variety at all three D so that the new information flow paths
+              | can be absorbed.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              68
+title         | 4.3.2 Link-Chain Improvement
+text          | Link-chains within the extended design community organization can be arbitrarily long.
+              | This is not necessarily an adverse condition, as long as the information is not corrupted
+              | and as long as the information arrives in a timely fashion. In fact, having a quasi-free
+              | scale organization implies some limits on chain lengths (because of the cross
+              | connections).
+blank         | 
+              | 
+text          | However, by having imposed our external goals/specifications, and our multi-hierarchical
+              | control structure, there are directed links corresponding to control paths required to focus
+              | the community on our particular future goal states. These link-chains need to be
+              | evaluated to make sure the information arrives timely and un-corrupted.
+blank         | 
+              | 
+text          | Five link chains of interest are computed below. The link-chain “performance” value is a
+              | linear sum of the included links, each of which is composed of variety and other multi-
+              | scale terms. For labeling, the start- and end- Agents are listed, and a representative name
+              | is added in between. Higher values imply more chances for information corruption.
+blank         | 
+              | 
+text          |    (1) ENG -> tools selection and deployment -> PROG
+              |                 2 + 2 + 3 + 3 = 10
+              |    (2) RES -> technology development -> PROG
+              |                 2 + 2 + 2 + 1 + 3 + 5 = 15
+              |    (3) BD -> customer requested research -> RES
+              |                 2 + 3 + 3 + 1 + 2 + 2 = 13
+              |    (4) PROG -> follow-on platforms -> PROG
+              |                 12 + 3 = 15
+              |    (5) RES -> prototype development and deployment -> LOB
+              |                 2 + 2 + 2 + 3 + 5 = 15
+blank         | 
+              | 
+text          | (Figure 4-5) shows these link-chain paths (directed graphs) within our scale-free design
+              | community network.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              69
+text          |                              BD                         PROG                                                  R&D
+blank         | 
+              | 
+              | 
+text          |                              Exec     3                    Exec                                               Exec
+blank         | 
+text          |                        1    2                                                                        1                         1
+              |             Adjacent         BD                        Executive
+              |                                                                                 3                  Senior                  Adjacent
+              |             Markets        Director                      Staff                                     Support               Technologies
+              |                                                                             3                                      2
+              |                             2                          2      5
+              |                               BD
+              |                              Staff
+              |                                             3           Program
+              |                                                                    5
+              |                                                                                     Advanced
+              |                                                                                      Develop
+              |                                                                                                               Senior
+              |                                                                                                              Manager
+blank         | 
+text          |                                                               2                     2                              2
+              |                             Senior          3          Subsystem                     CRAD
+              |                                                                                                2              Senior       3
+              |                            Engineer                                                                          Scientist
+blank         | 
+text          |                        2    2                                 3                     2                              22
+              |              Tools         Engineer
+              |                                             3      1
+              |                                                        Engineer                     Engineer
+              |                                                                                                2              Staff
+              |                                                                                                       5      Scientist
+              |             1
+              |                        2   Discipline
+              |                             Director
+blank         | 
+              | 
+              | 
+              | 
+text          |                             ENG
+blank         | 
+              | 
+text          |                                           Figure 4-5 Link-chain Paths of Interest
+              | External goals and specifications, combined with our quasi, scale-free network, create directed links
+              | corresponding to control paths required to focus the community on the particular future goal states.
+              | Numbered blue lines are directed link paths; red numbers are total aliasing factors (TAF) (section
+              | 3.4.4). These link-chains need to be evaluated to make sure the information arrives timely and un-
+              | corrupted. Corruption can be caused by aliasing, occurring either during variety compression /
+              | decoding, or from multi-scale time-aliasing. Case (2), the delivery of new Research products into
+              | large Programs, has the highest TAF corruption factor of 15.
+blank         | 
+              | 
+text          | Case (2), the delivery of new Research products into large Programs, has the highest
+              | corruption factor of 15. Changes from annealing the discontinuities discussed earlier in
+              | Section 4.3.1 will reduce the link values (aliasing factors) of 5 and 3 to 2 and 2.
+blank         | 
+              | 
+text          | In addition to making links more efficient, one can also remove links entirely by
+              | implementing organizational or process changes. An example of this, with emergent side
+              | effects, will be discussed in Section 4.4.
+blank         | 
+              | 
+text          | Another perspective, when looking at an extended chain as opposed to an individual link,
+              | is to adjust link transfer rates (p * a) to all be similar. This similarity indicates similar
+              | efficiencies through the process so that one poor link doesn’t downgrade the values of the
+blank         | 
+              | 
+              | 
+meta          |                                                                        70
+text          | attached links. This can be thought of as ensuring the transfer rate of the program staff
+              | (variety providers) is on the same order as the learning rate of the program engineers who
+              | are applying the information to the product, although this doesn’t address whether “V” is
+              | correct.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             71
+title         | 4.4 Cultivated Changes and Observed Emergent Side-Effects
+text          | One limit in many organizations is how internal and external research is incorporated into
+              | defined programs delivering products. Delivering major products that are pre-specified
+              | in contracts does not need any new research, so program managers would rather control
+              | internal technology resources to solve contract problems rather than create more new
+              | technologies.
+blank         | 
+              | 
+text          | This is exactly what is seen comparing a 90/5/5 portfolio to a 50/30/20 portfolio in the
+              | time distribution of R&D allocation. Here, the numbers represent the percent of funds
+              | devoted to “current-technology” / “product-development&qualification-efforts” /
+              | “research-efforts”.
+blank         | 
+              | 
+text          | Because program managers are not receiving any immediate value from the longer term
+              | investments they try to reallocate all (90%) the R&D money internal to their product
+              | development and production. Since the program managers control the source of income,
+              | they have a large say in how internal funds are allocated. This is more efficient for their
+              | individual program, but puts the company into a weaker long-term competitive posture
+              | (slower evolution rate).
+blank         | 
+              | 
+text          | A 50/30/20 distribution places more emphasis on research and development and enables a
+              | more forward-leaning product offering that adapts more quickly and takes advantage of
+              | recent advances in technology and new lower cost methods.
+blank         | 
+              | 
+text          | For the network model of our particular design community, looking at product
+              | development, the organization had evolved into a 60/5/35 investment position; value-
+              | delivery of research into programs was close to zero (separate from experiential
+              | development side-effects); and product evolution was stale. The significant research
+              | effort was not being transferred anyplace.
+blank         | 
+              | 
+text          | In this particular case we discover:
+blank         | 
+              | 
+              | 
+meta          |                                              72
+text          |    (6) LOB -> product development -> PROG
+meta          |                2 + 3 + 5 = 10
+text          | This implies there are some impediments to transition new technologies into qualified
+              | products for the new mega-systems.
+blank         | 
+              | 
+text          | To increase innovation of the income-producing product stream, the investment position
+              | was changed to 60/30/10 to increase product transition (30%), with the understanding (or
+              | assumption) that many of the side-benefits accruing from a robust R&D program would
+              | be lost (amount of research reduced from 35% to 10%). The implementation method was
+              | to supply internal development funds directly to the Engineering subsystems to improve
+              | their products for the set of Programs that were being developed.
+blank         | 
+              | 
+text          | To maintain organizational coherence, new communication pathways had to be
+              | developed. Allocation of the development funds to subsystem engineering groups was
+              | equivalent to doubling their task diversity. There were now two roles for these
+              | engineering groups: subassembly improvement with links to Research, and subassembly
+              | integration with links to the Programs.
+blank         | 
+              | 
+text          | A snapshot of the new information flow network is shown in (Figure 4-6) on the left.
+              | The right side shows the diagram with an updated arrangement. This evolved version can
+              | now be evaluated for future cultivation (the blue portion is new).
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             73
+text          |                            Figure 4-6 Cultivated Organizational Change
+              | Adding resources and responsibility to ‘Engineering’ (Senior Engineers and Engineers) allowed them
+              | to increase their variety both to expand their design work, and also to work the transitions into the
+              | Program and from Research. Allocation of the development funds to subsystem engineering groups
+              | was equivalent to doubling their task diversity. Two new links for these engineering groups were
+              | required: subassembly improvement with links to Research, and subassembly integration with links
+              | to the Programs. A second equivalent diagram is shown on the right. Either can be used depending
+              | on the purpose and resolution of the subsequent analysis.
+blank         | 
+              | 
+              | 
+              | 
+text          | Two interesting side-effects emerged. One of these might have been predicted in that the
+              | Program Subsystem actor now had fewer responsibilities. In essence, the actor could
+              | discard the variety needed to lead a new design effort, and focus on system integration.
+blank         | 
+              | 
+text          | Another more interesting result was the effect this had on the Engineering Subsystem
+              | teams. Previously they had no responsibility for their products other than to deliver their
+              | design within the particular program requirements. Now, as they were tasked to improve
+              | the status quo and coordinate its insertion into the program, their engineering behaviors
+              | emerged into product ownership with the related activity that they desired to see ‘their’
+              | product evolve and get inserted into additional programs. This was a significant
+              | evolution of the company engineering culture which might be subsequently applied to
+              | other evolutionary threads as indicated by the many variations of product strategy.
+blank         | 
+              | 
+text          | Note that the resulting information transfer formats are still evolving.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                  74
+title         | 5 Performance Observations and Implications
+text          | A large corporation was modeled as an adaptive computing organism that creates new
+              | assets (mega-platforms). We are trying to make this (organizational) computing more
+              | efficient so we can get more output so we can achieve better survivability (for the
+              | organization) and better social value (for the environment). This section identifies areas
+              | of potential benefits and changes.
+blank         | 
+              | 
+              | 
+title         | 5.1 R&D Applicability Performance
+text          | While emergent engineering behaviours are interesting, another question is whether this
+              | improved the value to the company and/or the value delivered to the environment
+              | (society). These questions may not be answerable, but one metric – the inserted value of
+              | R&D efforts – rose from less than 5% to almost 80% as measured by the number of
+              | research projects being fully used in an operational program.
+blank         | 
+              | 
+text          | How well are typical research-expenditures used? This is a good question since there are
+              | currently no good metrics and there is currently no generally accepted technique. People
+              | have been looking for a long time, but nothing seems to work. This may be because the
+              | desired answer doesn’t match the computed answer. Common methods of calculation
+              | give extremely low values (<5% (?!)), indicating very low rates of return on invested
+              | funds.
+blank         | 
+              | 
+text          | In fact, it is very hard to discover any direct relation between research investments and
+              | new product delivery. Many people would agree that the return on investment is mostly
+              | in the experience gained by the engineers.
+blank         | 
+              | 
+text          | Following the framework developed in Section 2.0 through Section 4.0 indicates that less
+              | than 20% of R&D is directly useful (in the aerospace community). The research projects
+              | themselves can be quite successful, but information transfer to a development program
+              | runs into the problems indicated in terms of time synchronization. Reports may be
+blank         | 
+              | 
+              | 
+meta          |                                              75
+text          | prepared every year at the end of each research project, but the program engineers only
+              | look to see what new technologies are available at the start of a new program. A
+              | particular system and/or upgrade may start anew once every fifteen years (twelve years
+              | development, plus three years of initial operations). Even within a business or product
+              | area that averages three large systems in concurrent development, the average time
+              | between new starts would be five years. Thus the research results for four years are put
+              | on the shelf, and only in the fifth year do application engineers research new approaches
+              | for their program (1/5 = 20%).
+blank         | 
+              | 
+              | 
+text          | 5.2 Estimating the Amount of Communication you Should Afford
+              | When you change the information transfer rate a, you must also adjust the variety at both
+              | the receiving and transmitting agents. Otherwise the agents will suffer an information
+              | overload, and you will still have inefficient information transfer. It may be that the cost
+              | of the extra staff needed to increase the variety of the agent is more than the value of the
+              | improved information transfer.
+blank         | 
+              | 
+text          | The value of the improved information transfer is the benefit minus the cost.
+              |        Value = Benefit – Cost = Benefit – (changes in variety at all nodes)
+blank         | 
+              | 
+text          | In the simplest example, when passing information from one peer actor to another,
+              | instead of vertical information transfers (up and down) through a common management
+              | actor, you should simply arrange a peer transfer link. Here you wouldn’t have to pay for
+              | a compression and a decompression task – you would simply pay for the variety to make
+              | the original product understandable to the new actor. Assuming all encoding/decoding
+              | tasks are the same and equal V, you would delete an up-link (2V) (one encode, one
+              | receive) and a down-link (2V) (one transmit, and one decode), and replace it with a single
+              | peer link (2V) (one transmit, one receive). So the change in value would be - (- 4 + 2)
+              | which equals +2, or a 50% improvement.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              76
+text          | For the earlier example in Section 4.4.1, for the short term evaluation, the amount (cost)
+              | of variety added at D (three places) must be less than or equal to the value of recovered
+              | resources at A (2x) and D (two places) minus some inefficiencies and overhead costs.
+              | Here the value would be +3 that is, again, about a 50% improvement. This value change
+              | may be different for “translation” and “context” effects (cf. Section 3.4.3). More detail
+              | could be developed by using a fine-grained organizational model with fractional values
+              | for all actors and all types of variety.
+blank         | 
+              | 
+text          | Average adjustments of variety will be close to a net-zero effect, compared to the goal
+              | benefit, so variety cost savings will neither help nor hinder the justification for any
+              | planned improvement in communication. This is reasonable since the improvements are
+              | designed to improve a meta-level of activity for the organization.
+blank         | 
+              | 
+              | 
+title         | 5.3 Expected Product Changes
+text          | Increased information transfer regarding new technologies and validated prototypes will
+              | enable more rapid design of aerospace products and a more rapid growth of the aerospace
+              | environment through two pathways: Delivery Date Export, and Incremental Technology
+              | Incorporation. A representative cumulative effect is shown in (Figure 5-1). The x-axis is
+              | time, measured in years, and the y-axis is capacity or social value, measured in some
+              | combination of dollars, performance, quality, or similar metric. The bottom curve is the
+              | status quo showing growth in social value in 12 year steps. A current system of this type
+              | might be the GPS satellite network or the Air Traffic Control system. The top curve
+              | shows the potential value of a system evolution using system engineering methods such
+              | as evolutionary design [Bobinis 2006] or flow-service-quality engineering [Linger 2002]
+              | to improve the efficiency and rate of delivery. Methods to cultivate the incremental
+              | pathways (within these methods) are discussed below. This is consistent with
+              | Evolutionary Design practices.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              77
+text          |                                                           Accelerates
+              |                                                           because of
+              |              Value                                        synergistic
+              |              {Performance,                                benefits
+              |              Quality, $}
+              |                                                                Larger benefits under
+              |                                                                the curve when
+              |                                                                integrated over time
+blank         | 
+text          |                  Can pull out instantiations of
+              |                  current version as                                                     Keeps getting
+              |                  requirements dictate                                                   slower because
+              |                                                                                         complexity of
+              |                                                                                         upfront
+              |                                                                      Performance Slip   requirements
+              |                                                           Schedule
+              |                                                             Slip
+blank         | 
+text          |                   3yrs
+blank         | 
+              | 
+text          |                                                   12yrs
+blank         | 
+              | 
+              | 
+text          |                                                                                         Time (years)
+blank         | 
+              | 
+text          |                                    Figure 5-1 Improved Value Over Time
+              | The x-axis is time, measured in years, and the y-axis is capacity or social value, measured in some
+              | combination of dollars, performance, quality, or similar metric. The bottom curve is the status quo
+              | showing growth in social value in 12 year steps. The top curve shows the potential value of a system
+              | evolution when smaller time steps are enabled due to greater efficiency and agility. This is similar to
+              | compound interest.
+blank         | 
+              | 
+              | 
+              | 
+title         | 5.3.1 Exporting Products at Delivery Dates
+text          | Exporting products at predefined delivery dates is similar to design-to-schedule and
+              | design-to-cost efforts. However, instead of pre-defining a goal and then forcing your
+              | design to achieve it, you define a set of interfaces and boundary conditions, and deliver
+              | within those constraints. This requires some inefficient margins (initially), but as you
+              | reuse the base design for subsequent products, you can focus on improving the various
+              | performance parameters without spending time on the interface. So within a couple of
+              | iterations you will have improved total performance with less cost.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                                      78
+text          | These ideas have been incorporated into chip design in the electronics industry. Chip
+              | automated design tools had to use inefficient circuit designs to enable automated layout
+              | and automated test. But the lower cost, compared to hand layouts, enabled greater sales,
+              | and with subsequent miniaturization outgrew the pre-allocated “inefficient” margins.
+blank         | 
+              | 
+text          | Engineers can, and will, allow for design growth with exported products at delivery dates,
+              | and can incorporate the same testing protocols and support equipment, so it will be easy
+              | to integrate. This decouples a lot of the simultaneous development and feedback
+              | otherwise required to ensure everything fits, as in Section 3.3.2.
+blank         | 
+              | 
+text          | Allowing engineers to apply half their time to looking for new technologies and
+              | implementation methods, instead of optimizing their current design, allows for this
+              | quicker growth, despite the initial margins needed.
+blank         | 
+              | 
+text          | In (Figure 5-1), this increases the step height of subsequent deliveries, and improves even
+              | further the compound growth curve.
+blank         | 
+              | 
+              | 
+title         | 5.3.2 Incremental Technology Incorporation
+text          | Program managers and senior engineers, if they use this same technique of improved
+              | information flow, will have a more current understanding of related systems and can
+              | define, and more quickly incorporate, consistent and grow-able requirements. Also they
+              | will have a current understanding of current subsystems from related efforts where they
+              | could modify an on-the-shelf design and integrate it into their system.
+blank         | 
+              | 
+text          | There will be some overhead associated with incremental/evolutionary systems, but since
+              | the subsequent new technologies will likely use less power and weight, they can be
+              | inserted on the second platform and actually increase performance past the design margin
+              | on the first vehicle.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              79
+title         | 5.3.3 Coupled Efficiency
+text          | These two effects (Delivery Date Export, and Incremental Technology Incorporation)
+              | improve the overall Evolutionary Design approach , as compared to classic centralized
+              | (computed) control, by avoiding large inefficiencies associated with unitary hardware
+              | instantiation (primary, and 2nd and 3rd tier suppliers) by multiple organizations.
+blank         | 
+              | 
+              | 
+title         | 5.3.4 Company and Product Goals
+text          | Design of organizations and processes can affect the growth vector of the larger
+              | community by emplacing the proper “a” factor in desired areas. For instance, if one
+              | believes robotic exploration will be a driver of aerospace systems (instead of human
+              | exploration), then the laboratories/groups associated with autonomy activities need new
+              | channels formed and trained.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              80
+title         | 5.4 Limits to Change
+text          | Given this new perspective, and the apparent small scale of individual changes, how far
+              | can you go? There are certainly limits to improvement, most basically from the external
+              | environment’s ability to incorporate changes at a stable rate.
+blank         | 
+              | 
+text          | Another restriction, or basic conceptual limit, is that there is no right answer and no
+              | optimal solution. In fact trying to find an overall solution is diametrically opposite from
+              | the direction taken here: that you try to improve the organization to more easily
+              | incorporate engineer’s capabilities. And, although many engineers say that “better is the
+              | enemy of good enough”, here you are not waiting to become perfect before you move
+              | forward, you are independently improving engineering efficiency in parallel with
+              | delivering your products.
+blank         | 
+              | 
+text          | Likewise, there are costs associated with change. Changes in organizations and in
+              | policies and procedures take time and effort to implement. You probably can only
+              | change one link at a time. Also, if you change all the links at once, you would lose
+              | ‘communicativity’ and your organization would collapse.
+blank         | 
+              | 
+text          | Finally, you don’t want to change too fast. In this case you will have incurred the costs
+              | of change without having looked ahead to see where external changes (and your changes)
+              | have affected the environment in which you are working. You may want to reprioritize
+              | your cultivation so you don’t overshoot.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              81
+title         | 5.5 Applicability
+text          | At what scale does this dissonant behaviour manifest? It was stated earlier that mega-
+              | systems require on the order of 10,000 man-years of design time; that the total involved
+              | set of people may number toward 100,000; and that the company size is around $10B
+              | orders per year.
+blank         | 
+              | 
+text          | Depending on the resolution, our proto-typical example organization has 22 nodes at the
+              | top, virtual-lens level, at least 480 major agents at the composed summary level, and over
+              | 5,000 working groups at the various individual program levels. From a bottom-up
+              | perspective, there could be 200,000 information pathways given the number of people
+              | involved and the required task variety. The exact number is problematic, both to actually
+              | measure or record people, but also to identify intermediate groups and information
+              | transfer paths.
+blank         | 
+              | 
+text          | The work of [Braha 2007] indicates that 460 nodes and 1200 information transfer
+              | activities is at the top end of what is currently analyzable, but is already at a statistically
+              | significant population scale to quantify extracted behaviours with reasonable statistical
+              | validity.
+blank         | 
+              | 
+text          | From a control theory perspective, one could calculate stability metrics based on
+              | feedback loops, task duration, measurement delays, etc. [Hogg 2001] showed that
+              | hierarchies with more than 6 levels and/or with a span greater than 8 have limited
+              | throughput, but of course this runs into the same analytic limits as the detailed task
+              | analysis methods. [Park 1995] showed problematic convergence without additional
+              | ‘parallel’ activities; no size values were given, but current computational limits were
+              | listed even on cabling tasks.
+blank         | 
+              | 
+text          | A different approach to defining applicability is to analyze where and why the aliasing
+              | effects enter the design and production process, and then see how these accumulate into
+              | increasing levels of significance.
+blank         | 
+              | 
+meta          |                                                82
+text          | Simple organizations and simple activity networks have high ‘a’ (3.5 – 4.0). Information
+              | transfer is chaotic in the sense that it is immediate, complete, and very high bandwidth.
+              | Imagine a very small company with a team of 5 working in a single room to design and
+              | produce a single part for a machine. Each knows what the other is doing, they can
+              | communicate verbally, and all the information is in the room including the supplier
+              | catalogs, CNC settings, account ledger, etc. So development and production is straight
+              | forward. The major risk for information loss is if one of the people is sick for a day:
+              | since nothing was documented, you would have to wait for his return, or simply
+              | regenerate the information.
+blank         | 
+              | 
+text          | As the company size increases, there are more people, more rooms, and even more
+              | buildings. Task assignments must be better planned and information flow must be better
+              | documented. Things are less chaotic and more structured. Information is becoming
+              | somewhat static, and must now be delivered explicitly. ‘a’ is approaching 3.0 or less.
+              | Depending on how busy the shop is, some production tasks may get temporarily lost; or
+              | possibly an invoice not given to finance to be paid. But these are small effects, and given
+              | that the teams are well organized, have good processes, and understand the overall effort,
+              | no big problems arise. It is not quite as efficient as before since now you need design
+              | reviews, manufacturing readiness reviews, quality control, etc., but now you can address
+              | larger efforts, delivering entire machines and getting the higher profits due the extra
+              | complexity.
+blank         | 
+              | 
+text          | At some point the time synchronization becomes problematic. Possibly because the next
+              | use of information is indeterminate at the time of production, possibly because of
+              | physical separation, or because of a number of reasons. Efforts to not lose information
+              | become important: documenting fabrication improvements to feedback to design;
+              | creating reusable components and product families; transferring consistent customer
+              | requirements to different sub-organizations. This is the dissipative zone (a ~1.5) and care
+              | must be taken to avoid slowing the design and production process, and becoming a
+              | lethargic organization.
+blank         | 
+              | 
+              | 
+meta          |                                              83
+text          | So as you move from right to left in Figure 4-2 (high ‘a’ to low ‘a’), the growth of the
+              | organization and processes provides more opportunities for information aliasing – both
+              | from noise injection and from dissipation. Any organization, no matter what its size, sees
+              | these effects. The bigger the organization, the bigger the size of the effects, and the more
+              | valuable it is to adjust for smoother dynamics.
+blank         | 
+              | 
+text          | Note that the longer time dynamics (low ‘a’) occur when trying to use resources across
+              | individual mega-systems. In trying to even out the use of product resources (knowledge,
+              | capital equipment), problems can be injected. This implies there is (at least) one, or a set
+              | of activities that are single use within the design of a mega-system. When these are
+              | applied to the next megasystem, their system context is essentially not cleared. This
+              | might imply an additional type of aliasing, sort of like a feed-forward echo.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              84
+title         | 6 Conclusions
+text          | This dissertation developed a new type of model for extremely large design organizations
+              | and their environment by combining perspectives from:
+              |         -   evolutionary genetic computing organisms,
+              |         -   information theoretic (quantum) information production, and
+              |         -   non-linear dynamics and chaos theory for information exchange.
+              | to study some of the behaviours of complex organizations, especially information
+              | transfer, to show how organizations can be guided to more efficiently and quickly
+              | produce complex mega-systems.
+blank         | 
+              | 
+text          | A three-year experiment was performed within a large design organization to see what
+              | level and type of improvements would actually manifest.
+blank         | 
+              | 
+text          | The results fall into three categories:
+              |         -   production of individual mega-systems,
+              |         -   improvement in organizations that develop mega-systems, and
+              |         -   extraction of societal benefits from government funded mega-systems.
+              | These are addressed separately below.
+blank         | 
+              | 
+              | 
+title         | 6.1 More Efficient Design of Mega-Systems
+text          | Ignoring the quality of information transfer among organizational elements causes
+              | significant inefficiencies. The transfer quality includes time synchronization, method of
+              | transfer, and other variables. It is not that anything is currently wrong, just that a lot of
+              | time is wasted waiting for information, translating information, or re-developing the
+              | context to understand the information, and additional time (and resources) may be spent
+              | waiting for task convergence. Matching the characteristics of the product design
+              | information to the characteristics of the transfer path minimizes aliasing effects
+              | (dissipation and noise), creating many benefits including:
+              |         -   More efficient design and design execution,
+blank         | 
+              | 
+              | 
+meta          |                                               85
+text          |        -   Improved design agility / currency, and
+              |        -   Enablement / easing of “Evolutionary Design” ([Bobinis 2006], [Bar-Yam
+              |            2003], [Sangiovanni 2006]) at the upper, large-scale limit.
+blank         | 
+              | 
+text          | Results from a three-year experiment showed that the inserted value of R&D efforts rose
+              | from less than 5% to almost 80% as measured by the number of research projects being
+              | fully used in operational programs. The research projects themselves can be quite
+              | successful, but information transfer into a development program runs into the problems
+              | indicated in terms of time synchronization.
+blank         | 
+              | 
+              | 
+title         | 6.2 Relying on Emergence and Organizational Computation
+text          | Improvements in the performance of the organization will incrementally emerge, given
+              | the inertia of large organizations and of engineering processes, and will initially manifest
+              | as quicker deliveries and an accelerating ability to innovate ahead of other companies.
+blank         | 
+              | 
+text          | “One consequence of encoding information as statistical and time-varying patterns of
+              | low-level components is that no individual component of the system can perceive or
+              | communicate the ‘big-picture’ of the state of the system. Instead, information must be
+              | communicated via spatial and temporal sampling.” [Mitchell 2009] Dynamically, the
+              | mega-design process is progressing, and any snapshot is an incomplete view in a
+              | changing context. This implies that the product directors can’t really direct or control
+              | where the company is going: their role should only be to monitor the outputs and nascent
+              | products, and guide the output (and rate of new product introduction and of upgrades) to
+              | match the funding (requirements) source. This would balance control and efficiency.
+blank         | 
+              | 
+text          | “Recently [in the field of biology] there has been a renewed effort to provide a
+              | macroscopic theory for the origins of selection mechanisms. … This effort goes under
+              | the name of niche construction. … [Here], the selective filter is partially constructed by
+              | the organism itself, and exerts an influence over a locally reproducing population. … In
+              | this way, adaptations lift themselves up by their own bootstraps.” [Krakauer 2011].
+blank         | 
+              | 
+              | 
+meta          |                                               86
+text          | This dynamic perspective implies that design communities can, and should, “construct
+              | their own [evolutionary] selective constructs designed toward increasing mutual
+              | information [within itself, and] between the organism and the environment” [Krakauer
+              | 2011], for better computability or production of designs. In this case, the management
+              | structure ought to also look at higher level abstractions, such as information transfer
+              | efficiencies, in addition to process control (like design reviews), because looking at static
+              | variables will not improve the evolutionary adaptation rate.
+blank         | 
+title         | 6.3 Government Aerospace, Low-Price Procurement, and
+text          |       Overhead Rates
+              | The stability of any implemented improvements is somewhat problematic given the
+              | evolving environment, but especially given the counter-acting efforts of government
+              | acquisition regulations and nominal management tendencies.
+blank         | 
+              | 
+text          | Scale, synchronization, and economic nudges may be appropriate for personal scale
+              | complices such as smartPhone apps, but the economic and scale factors are different from
+              | government “apps”. A focus on lowest cost procurement, for government “apps” (mega-
+              | systems), has side effects on the engineering design process. Financially speaking, and
+              | for more effective mega-system development, the government should modify cost-
+              | selection constraints to avoid extra effort to achieve a particular instance when any of a
+              | set of instances is all that is needed. This would necessarily become somewhat non-
+              | deterministic.
+blank         | 
+              | 
+text          | Individual program managers will avoid this because it is locally inefficient and also
+              | uncontrollable. However, according to game theory (prisoner’s dilemma [Morrow
+              | 1994]), a Pareto optimal solution is better, and can be achieved with “external norms”
+              | [Mitchell 2009]. The external norms could either be via company processes and
+              | procedures or, better, by the government’s Federal Acquisition Regulations (FAR).
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              87
+text          | For instance, implementation at the government FAR level could be to assign 1% - 2% of
+              | the value of programs over a certain size to internal efforts supporting adaptability and
+              | risk reduction. For instance the Orion spacecraft program internally allocated $100M
+              | (for a $4B program) to reduce schedule risk occurring from software integration. This is
+              | the same scale as proposed, and was considered and approved as the correct engineering
+              | approach. However, it was implemented without adjusting the encompassing process, so
+              | savings could never be recaptured, nor future transitions eased. This fund would reduce
+              | risk on the delivery of the initial system, and reduce cost of subsequent systems.
+blank         | 
+              | 
+text          | Such a fund could also be allocated for application to follow-on project development, and
+              | coordination of supporting technology and product development. Note that this would
+              | avoid aliasing effects from Federally Funded Research and Development Companies
+              | (FFRDCs) in their information transfer efforts, and would greatly improve technology
+              | transfer from government labs to industry and society.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              88
+title         | 6.4 Additional Research Vectors
+text          | Several areas of this model could be extended based on related supporting theoretical
+              | areas, including organizational memory, the effects of different engineering tools, and
+              | evaluation of sub-networks in large communities. These are briefly discussed below.
+blank         | 
+title         | 6.4.1 Organizational Memory
+text          | Including memory as a communication channel with a “long” time constant is a straight-
+              | forward addition. Efficient internal communication is similar to having some global
+              | memory with time constant t0. This provides our organism (design community) the best
+              | combination of a Von Neumann architecture and a cellular automata.
+blank         | 
+title         | 6.4.2 Engineering Tools
+text          | An area for future investigation as it is indicated by this analysis. Engineering design
+              | tools play a large role in communicating knowledge and techniques.
+blank         | 
+title         | 6.4.3 Long-Scale Neural Training of Sub-Networks
+text          | Adjusting variety takes time like a single neuron in a network with different time
+              | constants. The existence of Bifurcative channels in large communities needs additional
+              | structure as the evolutionary time scale of the channels does not match that of the actors.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             89
+title         | 7      Appendix A – Research Background
+text          | Design Community Responses to Recognition of Complexity
+              | There are two inter-twined facets of large scale engineering organizations: the large
+              | organization itself, required to design, build, and operate the product, and the processes
+              | they follow to produce their mega-products. Mega-organizations were covered in
+              | Section 1. Here we address the internal design processes that guide the organizational
+              | information development and transfer.
+blank         | 
+title         | 7.1 Evolutionary Design
+text          | Evolutionary design includes functions of complex systems that allow us to discover,
+              | measure, and implement design activities during the entire life cycle of a system. It
+              | assumes that we cannot know all the functions of deployed complex systems, and that an
+              | evolutionary approach to design, is required. Several unique design methods were added
+              | to the system engineering repertoire, including incremental engineering by which
+              | portions of the system are redesigned and operate in parallel to other parts of the system.
+              | Bar-Yam suggests that spiral development is an instantiation, (although simplified), of
+              | evolutionary acquisition and design. “Recent extensions that adopt some complex
+              | systems ideas include spiral development and evolutionary acquisition and adaptive
+              | programming. A complex systems perspective provides a large conceptual framework –
+              | evolution-from which to understand how incremental change can enable rapid
+              | innovation.” [Bar-Yam 2003].
+blank         | 
+              | 
+text          | Evolutionary design implies that since we cannot iteratively account for all functions and
+              | processes of complex systems, we must provide a design process which allows us to
+              | inductively determine system behaviors and processes, after the system is fielded. Spiral
+              | design engineering, is really just a traditional design methodology which is repeated
+              | recursively over the entire life cycle of the system. But it does account for all the
+              | interfaces, transactions, and controls of a complex system that cannot be known during
+              | initial design. Through this process, we can apply traditional methods in changing small
+              | parts of complex systems, during its life cycle, rather than trying to change the “whole
+blank         | 
+              | 
+              | 
+meta          |                                              90
+text          | system”. And, that through the process of acquiring knowledge of self-organizing
+              | systems, parts of the system may be known and tested, and replaced through traditional
+              | planning, specification and implementation. Evolutionary design implies that on-going
+              | discovery and re-design is a life cycle function of the system. The system must have a
+              | means of monitoring its own “state”. An example of this, might be the modern
+              | application of prognostics in complex platforms, where system states can be collected,
+              | analyzed, and understood to the extent that we are provided the “patterns of system
+              | behavior” to be able to predict and/or design out system failures, failure modes, and use
+              | cases that the system may not have been designed for [sic]. [Bobinis 2006]
+blank         | 
+title         | 7.2 Engineering Systems
+text          | Rhodes and Hasting, in their paper The Case for Evolving Systems Engineering as a
+              | Field within Engineering Systems, propose a more holistic systems engineering practice
+              | which not only encompasses the boundaries of the system under development, but also a
+              | broader context which includes the environment the system must co-exist in, including
+              | the evolution of the system in the broader context.
+              | “When taking the classical view, a major fault cited with Systems engineering is that it
+              | does not take an adequate holistic perspective and is too introspective. Additionally, it is
+              | often viewed as taking too much of a top-down approach…Further, Systems Engineering
+              | is sometimes criticized for focusing too extensively on requirements and not enough on
+              | system properties and behaviors.” [Rhodes 2004]. It recognizes that the Systems
+              | Engineering discipline, ontology, and associated epistemology must be revised to account
+              | for increasingly complex and self-organizing systems. It alludes to a process which
+              | includes not only traditional engineering disciplines, but also a cross disciplinary
+              | approach that includes the ability to understand the “human system”, the “environment”,
+              | and the “community” as part of the context of the overall system, as “determinate
+              | interfaces”.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              91
+title         | 7.3 Flow-Service-Quality Engineering
+text          | Carnegie Mellon, in response to study commissioned by the U.S. Air Force, has
+              | developed a methodology to address large scale network centric systems design. “These
+              | systems are characterized by changing and often unknown boundaries and components,
+              | constantly varying function and usage, and complexities of pervasive asynchronous
+              | operations. Their complexity challenges human intellectual control…”[Linger 2002 p.v].
+blank         | 
+              | 
+text          | They attack the problem through the design of a “system services” function for these
+              | types of systems as the “unifying”, and specifiable “function” of any system of systems.
+              | It is the function wherein the myriad of users, systems, and subsystems interact, and
+              | perform their unique transactions (interfaces).
+blank         | 
+              | 
+text          | System Services is the primary hub for their analysis and methodology of control. It
+              | directs, analyzes, stores, and measures all the transactional processes of the complex
+              | system. It starts at a functional analysis of user based operations and interfaces the
+              | system services function needs to support all users (human or other systems). By
+              | mapping the interchanges with the supported “users”, the system services function can
+              | analyze system, as well as sub-system, states. It also defines the standards and protocols
+              | for the entire system and serves as the “super hub”.
+blank         | 
+              | 
+text          | What is important here is not the architecture promoted in this study, but the fact that
+              | there is both the recognition that all subsystem functions cannot be accounted for in the
+              | design, and that the primary hub “system services” has specific sub-functions that
+              | account for growth (new nodes), and reorganization (once added, the types of information
+              | shared across nodes). It’s ability to account for nodes as they are added, the type of
+              | requests of these unique nodes, the mapping and storage of system topology, in near real-
+              | time, and the realization that as unique functional nodes are added to the system, they
+              | must be accounted for, monitored, and measured, as they function within the system.
+blank         | 
+              | 
+text          | “FSQ engineering provides systematic, scale-free semantic structures for requirements,
+              | specification, design, verification and implementation…User flows of services and
+blank         | 
+              | 
+meta          |                                              92
+text          | quality attributes permit system development in terms of user views of services, as
+              | opposed to strictly functional decomposition or object-based composition.” [Linger 2002
+              | p.37]
+blank         | 
+              | 
+              | 
+title         | 7.4 Engineering Tools
+text          | Some studies that examined the engineering process have focused on tools developed to
+              | improve product design by engineering teams [Leifer 1999]. Here the tools fall into three
+              | classes: interpersonal communication, knowledge capture, and knowledge retrieval.
+              | Productivity gains have been shown when design teams can begin from a better starting
+              | point as a result of having access to learned information from previous designs.
+              | “In larger organizations, the complexity is vastly different and the chance for deep
+              | personal co-commitment is diminished. Ad hoc exchanges within one’s personal
+              | network do happen, but systematic knowledge sharing usually requires brokering through
+              | people or technology. Along with brokering come issues such as knowledge
+              | identification, verification, and validation [Leifer 1999].”
+blank         | 
+              | 
+text          | “[All organizations] can benefit from the implementation of a central knowledge capture
+              | and re-use infrastructure, a core technology for sharing and learning from each other,
+              | peer-to-peer. In large institutions (greater that 500 people) this infrastructure will have to
+              | be explicit and managed separately from the design team support infrastructure [Leifer
+              | 1999].”
+blank         | 
+              | 
+text          | A separate explicit infrastructure however becomes problematic, especially on projects
+              | with long time scales (~10 years). Issues arise that interfere with having a consistent
+              | structure. The portfolio of projects across a large organization use different engineering
+              | tools. This will always be true because of a mismatch of time frequencies between new
+              | tools and new projects, and the fact you can’t and don’t want to update your tools all at
+              | once on a preordained schedule. Also engineers bring different sets of tool knowledge
+              | with them to new projects. It actually takes some finite time for a team to get
+              | synchronized on common tools and data structures. Also most training is done on the job
+blank         | 
+              | 
+              | 
+meta          |                                              93
+text          | with no separate time allotment and no separate instructors, with the result that tools are
+              | not always used as they were designed, nor to their full potential. Finally, retrieval of old
+              | knowledge becomes problematic and time consuming, and may become moot as different
+              | technologies advance at different rates, opening up new solution spaces for consideration.
+blank         | 
+              | 
+text          | Another issue arising from large organizations that affects knowledge retention and
+              | retrieval is that engineering team members do not usually follow a project from
+              | conception through design, manufacture, production, maintenance, and growth.
+              | Typically, engineers focus on one stage of design. Therefore the information associated
+              | with a project bifurcates, with one instance progressing with the product as the product
+              | “design” and “context”, and the other instance going with the engineer or data base to a
+              | new product at a similar stage as “knowledge”.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                              94
+title         | 8 References
+ref           | [Bais 2010] “The Physics of Information”, F. Alexander Bais and J. Doyne Farmer, SFI
+              |        Working Paper 07-08-029 to be included in “The Handbook on the Philosophy of
+              |        Information, to be published by Elsevier.
+blank         | 
+ref           | [Barabasi 2003] Linked, Albert-Laszlo Barabasi, Plume, 2003.
+blank         | 
+ref           | [Bar-Yam 2002] “Large Scale Engineering and Evolutionary Change: Useful Concepts
+              |        for Implementation of FORCEnet,” Bar-Yam, Yaneer, FORCEnet and the 21st
+              |        Century Warrior, USN Strategic Studies Group, Contract F30602-02-C-0158,
+              |        2002.
+blank         | 
+ref           | [Bar-Yam 2003] “When Systems Engineering Fails---Toward Complex Systems
+              |        Engineering”; Yaneer Bar-Yam, IEEE International Conference, 5-8 Oct. 2003,
+              |        Volume: 2, on page: 2022 vol.2
+blank         | 
+ref           | [Bar-Yam 2004a] “A Mathematical Theory of Strong Emergence Using Multiscale
+              |        Variety,” Bar-Yam, Yaneer, in Complexity, Wiley Periodicals, vol. 9, no. 6,
+              |        2004.
+blank         | 
+ref           | [Bar-Yam 2004b] “About Engineering Complex Systems: Multiscale Analysis and
+              |        Evolutionary Engineering”, Yaneer Bar-Yam; ESOA 2004, LNCS 3464, pp. 16-
+              |        31, 2005.
+blank         | 
+ref           | [Bar-Yam 2005] “About Engineering Complex Systems: Multiscale Analysis and
+              |        Evolutionary Engineering,” Bar-Yam, Yaneer, ESOA 2004, LNCS3464, S.
+              |        Brueckner et al (Eds), Springer-Verlag, 2005.
+blank         | 
+ref           | [Bobinis 2006] “Complex Self-Organizing Systems And Their Effect on the Systems
+              |        Engineering Paradigm”, Joe Bobinis, 2006.
+blank         | 
+ref           | [Bonissone 2006] “Evolutionary Algorithms plus Domain Knowledge equals Real-World
+              |        Evolutionary Computation,” Bonissone, Piero P., Subbu, Raj, Eklund, Neil, and
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                            95
+ref           |        Kiehl, Thomas R., IEEE Transactions on Evolutionary Computation, vol. 10, no.
+              |        3, June 2006.
+blank         | 
+ref           | [Braha 2007] “The Statistical Mechanics of Complex Product Development: Empirical
+              |        and Analytical Results,” Dan Braha and Yaneer Bar-Yam, Management Science,
+              |        Special Issue on Complex Systems; Volume 53, number 7, July 2007.
+blank         | 
+ref           | [Byler 2000] “Cultivating the Growth of Complex Systems Using Emergent Behaviours
+              |        of Engineering Processes,”     International Conference on Complex Systems:
+              |        Control and Modeling; Russian Academy of Sciences; Samara Russia, June
+              |        2000.
+blank         | 
+ref           | [Capaccio 2011] Tony Capaccio, "Cost Overruns Plague One-Third Of Pentagon's
+              |        Biggest Programs”, Bloomberg Government, March 29, 2011.
+blank         | 
+ref           | [Clouse 1999] Clouse, Raja Laifa and Waldron, Manjula. “Effect of History to Achieve
+              |        Self Adaptation”. Center for Integrated Design, Ohio State University,
+              |        manuscript in progress 1999.
+blank         | 
+ref           | [Crutchfield 2011] James P. Crutchfield and Jon Machta, “Introduction to Focus Issue on
+              |        Randomness, Structure, and Causality: Measures of Complexity from Theory to
+              |        Applications,” Chaos, An Interdisciplinary Journal on Nonlinear Science;
+              |        American Institute of Physics, 2011.
+blank         | 
+ref           | [de Smith 2008] “Simulation/Modelling (s/m) Systems for Agent-Based Modelling,” de
+              |        Smith, Goodchild, Longley, Geospatial Analysis – a Comprehensive Guide, 2nd
+              |        edition, 2008.
+blank         | 
+ref           | [Flack 2011] Jessica C. Flack and David C. Krakauer, “Challenges for Complexity
+              |        Measures: A perspective from social dynamics and collective social
+              |        computation,” Chaos, An Interdisciplinary Journal on Nonlinear Science;
+              |        American Institute of Physics, 2011.
+blank         | 
+ref           | [Flecker 2011] Benjamin Flecker, Wesley Alford, John M. Beggs, Paul L. Williams, and
+              |        Randall D. Beer, “Partial Information Decomposition as a Spatio-temporal Filter,”
+              |        Chaos, An Interdisciplinary Journal on Nonlinear Science; American Institute of
+              |        Physics, 2011.
+blank         | 
+              | 
+meta          |                                            96
+ref           | [Hofstadter] Hofstadter, Douglas. “Godel, Escher, Bach: an Eternal Golden Braid”, Basic
+              |        Books, 1979.
+blank         | 
+ref           | [Hogg 2001] “Controlling Smart Matter”, Tad Hogg and Bernardo A. Huberman; Xerox
+              |        Palo Alto Research Center, June 1, 2001
+blank         | 
+ref           | [Holland 1998] Holland, John B. “Emergence: From Chaos to Order”, Addison-Wesley,
+              |        1998.
+blank         | 
+ref           | [Howley 1999] Howley, Brian. Discussions on Design Agent Models at the Stanford
+              |        Center for Design Research, 1999.
+blank         | 
+ref           | [Kleene 1956] Kleene, S.C., “Representation of Events in Nerve Nets and Finite
+              |        Automata” // Automata Studies, Shannon & McCarthy eds. Princeton University
+              |        Press, 1956.
+blank         | 
+ref           | [Krakauer 2011] David C. Krakauer, “Darwinian Demons, evolutionary complexity, and
+              |        information maximization,” Chaos, An Interdisciplinary Journal on Nonlinear
+              |        Science; American Institute of Physics, 2011.
+blank         | 
+ref           | [Leifer 1999] Leifer, Liang, Cannon, Mabogunje, Yen, and Yang. “Experience Capture
+              |        and Reuse for Complex System Design-Deployment” // Proceedings of the
+              |        International Conference on Complex Systems: Control and Modeling Problems,
+              |        Myasnikov, Kuznetsov, and Vittikh eds., Samara, Russia, 1999.
+blank         | 
+ref           | [Linger 2002] “Flow–Service–Quality (FSQ) Engineering: Foundations for Network
+              |        System Analysis and Development”; Richard Linger, Mark Pleszkoch,
+              |        Gwendolyn Walton, & Alan Hevner, Carnegie Mellon University in performance
+              |        of Federal Government contract number F19628-00-C-0003, 2002, pg. v.
+blank         | 
+ref           | [Metzler 2003] Metzler, Bar-Yam, & Kardar, “Information Flow through a Chaotic
+              |        Channel: Prediction and Postdiction at Finite Resolution”, 2003; section IV A, pg
+              |        9.
+blank         | 
+ref           | [Metzler 2005] “Multiscale Complexity of Correlated Gaussians,” Metzler, Richard, and
+              |        Yaneer, Bar-Yam, Physical Review E71 046114, The American Physical Society,
+              |        2005.
+blank         | 
+              | 
+              | 
+meta          |                                            97
+ref           | [Miller 2007] John H. Miller and Scott E. Page, “Complex Adaptive Systems, an
+              |        Introduction to Computational Models of Social Life”, Princeton University
+              |        Press, 2007, pp 72-73.
+blank         | 
+ref           | [Minar 1996] Minar, Burkhart, Langton, and Askenazi. “The SWARM Simulation
+              |        System: A Toolkit for building Multi-Agent Simulations”,
+              |        <http://www.swarm.org>, June, 1996.
+blank         | 
+ref           | [Mitchell 1992] Complexity: The Emerging Science at the Edge of Order and Chaos, M.
+              |        Mitchell Waldrop, Simon & Schuster, 1992.
+blank         | 
+ref           | [Mitchell 2009] “Complexity: A Guided Tour”, Melanie Mitchell; p180; Oxford
+              |        University Press, 2009.
+blank         | 
+ref           | [Morrow 1994] Game Theory for Political Scientists, James D. Morrow, Princeton
+              |        University Press, 1994.
+blank         | 
+ref           | [Omerod 1999] Ormerod, Paul. “Butterfly Economics: A New General Theory of Social
+              |        and Economic Behavior”, Pantheon, 1999.
+blank         | 
+ref           | [Park 1995] Park, Hisup. “Modeling of Collaborative Design Processes for Agent-
+              |        Assisted Product Design”, Stanford Doctoral Thesis, March 1995.
+blank         | 
+ref           | [Petrie 1996] Petrie, Charles J. “Agent-Based Engineering, the Web, and Intelligence” //
+              |        IEEE Expert, December 1996.
+blank         | 
+ref           | [Railsback 2006] “Agent-based Simulation Platforms: Review and Development
+              |        Recommendations,” Railsback, Steven F.,Lytinen, Steven L., and Jackson,
+              |        Stephen K., in press at Simlation, Santa Fe Institute, 2006.
+blank         | 
+ref           | [Rhodes 2004] “The Case for Evolving Systems Engineering as a Field within
+              |        Engineering Systems”; Donna Rhodes & Daniel Hastings, MIT Engineering
+              |        Systems Symposium, March 2004, pg. 3.
+blank         | 
+ref           | [Ruffini 2007] Information, Complexity, Brains, and Reality (Kolmogorov Manifesto),
+              |        Giulio Ruffini, Starlab Technical Note TN00054, 2007.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                             98
+ref           | [Sangiovanni 2006] “A framework for modeling the distributed deployment of
+              |        synchronous designs”, Formal methods in systems design - an international
+              |        journal, Springer-Verlag, Vol. 28, No. 2.
+blank         | 
+ref           | [Shannon 1948] C. E. Shannon, The Bell System Technical Journal 27, 379 (1948).
+blank         | 
+ref           | [Strader 1998] Strader, Lin, and Shaw. “Simulation of Order Fulfillment in Divergent
+              |        Assembly Supply Chains” // Journal of Artificial Societies and Social Simulation,
+              |        vol. 1, no. 2, <http://www.soc.surrey.ac.uk/JASSS/1/2/5.html> March 1998.
+blank         | 
+ref           | [Verhulst 1838] “Notice sur la loi que la population poursuit dans son accroissement”,
+              |        Correspondance mathematique et physique 10: 113-121, 1838.
+blank         | 
+              | 
+              | 
+              | 
+meta          |                                            99
+blank         |