Relevance to Our World (28/53) – What Complexity Literature Suggests (21/46)

1. Relevance to Our World (28/53)–What Complexity Literature Suggests (21/46) • Project context (Gorod et al. 2015, Chapter 2) • An unfamiliar project context can create complexity. • Example: Creating a project in China when you’re used to your own country’s projects. • Complexity can be due to different • Legal systems • Governance arrangements • Suppliers • Etc.

2. Relevance to Our World (29/53)–What Complexity Literature Suggests (22/46) • Emergence (1/2) (Gorod et al. 2015, Chapter 2) • Characteristics/behaviours emerge from interactions among components and with the environment. • There is nosimple relationship among components parts. • Parts are notglobally coordinated. (Marion 1999) • Components interact and properties emerge, something you • Do not expect. (Ramalingam et al. 2008, p. 20) • Could nothave predicted. • Surprises that cannot even be explained afterwards are of greatest interest. (White 2007) (McCarter and White 2009) • Emergent behaviour influences individuals that may have produced it. (Langton, cited in Urry, 2003 and referenced in Ramalingam, et al. 2008) • Dynamic feedback among components shapes and changes the whole. (Haynes 2003) • Emergent properties help distinguish complex from complicated systems. • Such entities as • Structures • Processes • Functions • Memories • Measurements • Creativity • Novelty • Meaning can exhibit emergent properties.

3. Relevance to Our World (30/53)–What Complexity Literature Suggests (23/46) • Emergence (2/2) • Emergence has been used to describe • Social structure • Human personalities • The internet • Consciousness • Life itself. (Newell 2003) • Metaphors are useful, e.g., • Orchestra music • Emerges from dynamic, temporal interactions of many musicians. • May alter listener’s actions or behaviours. • Complex systems such as people have multiple emergent levels. • Generating phenomena that are more than a sum of parts are not reducible to parts. (Newell 2003 cited in Ramalingam et al. 2008: 21) • Emergence teaches us that over-controlling top down approaches will notwork. • For adaptation, innovation and novelty must be permitted. • Unfortunately most in the real world try to over-define and over-control.(Morgan 1986 cited in Ramalingam et al. 2009, p. 21).

4. Relevance to Our World (31/53)–What Complexity Literature Suggests (24/46) • Nonlinearity (1/2) (Gorod et al. 2015, Chapter 2) • Human systems are nonlinear because • Feedback processes lead to interdependent relationships that exhibit • Dynamic • Nonlinear • Unpredictable change. (Stacey 1996) • Causal relationships cannotbe traced because of multiple influences. (Ramalingam et al 2008, p. 24) • In linear systems (Strogatz 2003) • Responses are proportional to forces. • Causes are proportional to effects. • Problems can be broken down in reductionist fashion. • Each element can be • Analysed separately. • Recombined effectively. • The whole is equals the sum of its parts. • Linearity is an approximationto reality. (Strogatz 2003) • Most systems behave linearly only if they are • Close to equilibrium. • Notpushed too hard. • When system behaves in nonlinear fashion, all bets are off.

5. Relevance to Our World (32/53)–What Complexity Literature Suggests (25/46) • Nonlinearity (2/2) • Complex systems do not exhibit cause and effect. (Ramalingam 2008, p. 26), e.g., not • If Activity A, then Output B, leading to Outcome C and Impact D. • Linear assumptions about social phenomena should be questioned. • Nonlinear relationships have to be examined as coherent entity. • There are several other important aspects of nonlinearity. • Most variables are not independent; unfortunately. • Many researchers assume variables otherwise. • Holding other variables constant does not work. • Many nonlinear systems have • Interconnected/interrelated parts. • Feedback loops. • Adaptive agents/behaviors. • Dynamic, emergent properties. For example, providing more aid to foreign country, or more social security within country, does not necessarily create improved situation.

6. Break 2 Before we continue consider what questions or comments you might have and share them online. The next series of charts will finish: What Complexity Literature Suggests 12/28/18 6

7. See Notes Page Relevance to Our World (33/53)–What Complexity Literature Suggests (26/46) Architecture (1/9) (Gorod et al. 2015, Chapter 2) Description a

8. See Notes Page Relevance to Our World (34/53)–What Complexity Literature Suggests (27/46) 12/28/18 • Architecture (2/9) Description b • … Architecture is particularly important because (Maier & Rechtin 2009) • Architecting deals largely with unmeasurable using non-quantitative tools. • Architecting describes how architectures are created. • Creating architectures began in Egypt > 4000 years ago with pyramids. • Modern computer program design requires architecting. • Architecting responds to system complexity in that optimum solution never exists. • There are just too many variables. (p. 6) • Architecting helps link value judgements with design decisions. • Architecture design must include • Connections • Interfaces • Components. This produces unique system-level functions likely overlooked. • Modeling creates system abstractions to help analyze • Performance • Costs • Schedules • Risks. to provide guidelines for • Research • Development • Design • Manufacture • Management. (p. 12) • Architecting is embodiment of project strategy. 8

9. See Notes Page Relevance to Our World (35/53)–What Complexity Literature Suggests (28/46) 12/28/18 • Architecture (3/9) Description c (Crawley et al. 2004) • Is an abstract description of a system. • Entities • Interconnections • Interactions. • Is a link between • Form • Function. • Provides • Rules to follow when creating a system. • Guidance and structure to design. • For addressing • Alternative forms • Substructures and modules • Complexity • Flexibility • -ilities. • Invites abstract thinking about unifying themes. • Is used to • Define and manage interfaces. • Standardize • Components • Interfaces. • Systematize • Integration • Verification • Validation. 9

10. See Notes Page Relevance to Our World (36/53)–What Complexity Literature Suggests (29/46) • Architecture (4/9) Description d (Dahmann 2009)addresses • Translating SoS capability objectives into requirements. • Understanding SoS • Components • Relationships. • Assessing whether SoS meets capability objectives in • Developing • Evolving • Maintaining the design. • Monitoring/assessing impacts of changes on SoS performance. • Addressing SoS • Requirements. • Solution options. • Orchestrating SoS upgrades.

11. See Notes Page Relevance to Our World (37/53)–What Complexity Literature Suggests (30/46) • Architecture (5/9) Description e (Gharajedaghi 2006, pp. 152-84) proposes business design; identify or develop • System boundaries • Business environment • System purpose • System functions • System structure • Output dimensions • Market dimensions • Organizational/Business processes • Planning sub-system • Learning sub-system • Control sub-system • Measurement sub-system.

12. See Notes Page Relevance to Our World (38/53)–What Complexity Literature Suggests (31/46) • Architecture (6/9) Description f(Dagli and Kilicay-Ergin 2009) (SoS) architecting includes • Properties. • Abstract • Meta level • Uncertain requirements • Network centric • Software intensive • People intensive • Intensive communication infrastructure • Networks of various stakeholders • Collaborative emergent development • Dynamic architecture. • Constraints. • Emphasis on collaborative interfaces • Right collection of systems • Scalability • Inter-operability • Trustworthiness • Hidden cascading failures • Confusing life cycle context. • Legacy systems. • The abstraction level determines how legacy systems are integrated. • Architecture help balance heuristics, analytical techniques, and integration modeling.

13. See Notes Page Relevance to Our World (39/53)–What Complexity Literature Suggests (32/46) • Architecture (7/9) Description g • Changes in context present challenges. • Dynamic requirements increase uncertainty. • One needs to design for fuzzy attributes. • How can we assure • Trustworthiness? • Interoperability? • Large-scale design? • Distributed testing? • Evolutionary growth? • How can we • Deal with hidden interdependencies? • Guard against cascading failures? • The plug and play concept provides flexibility. • An information dream architecture is the backbone of an SoS architecture.

14. See Notes Page Relevance to Our World (40/53)–What Complexity Literature Suggests (33/46) • Architecture (8/9) Other important issue questions are • What are differences among the sub-architectures in the architecture? • Was project vision is clearly expressed? • Were values addressed? • Were requirements addressed? • Were core and peripheral elements in the system design and structure recognised? • Was a Design Structure Matrix created? • If so, were design rules also developed? • To what extent was there an attempt to modularise software? (Azani 2008): Architecture is the structure of a system. • Functions • Environment • Processes.

15. See Notes Page Relevance to Our World (41/53)–What Complexity Literature Suggests (34/46) • Architecture (9/9) • (Khoo 2009) comments • Requirements must be changed from closed to open and flexible. • Ability to rigorously capture complexity is lacking. • Government contracting and procurement processes are too restrictive. • Remember (Maier and Rechtin 2009) • Architecture is the embodiment of strategy. • The problem becomes clarified as the solution is developed. • Developing SoS/SoSE architectures has been difficult(Meilich 2006) • An adaptive architecture will be required to support future battlefield operations. • Operating in changing contexts and adapting to changing missions is a challenge. • Developing an SoSE architecture is too challenging at this stage. • (Bjelkemyr, et al. 2007): (SoS) architecture defines a clearer purpose and boundary; recognize that • Internal SoS properties resemble those of an organism. • Significantly more research is required. • (DeLaurentis and Crossley 2005) provide a • Hierarchical (SoS) description framework for describing an architecture. • Taxonomy for guiding design methods. They conclude that • A comprehensive set of methods for (SoS) design do not yet exist. • More development effort is needed. • There is no agreed (SoSE) architectural template, as yet.