Complexity made simple June 2012
Philippe Kruchten 1
Complexity Made Simple
Philippe Kruchten
1 Copyright © 2005-‐12 by KESL June 2012
Philippe Kruchten, Ph.D., P.Eng., CSDP
Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering
University of BriJsh Columbia Vancouver, BC Canada [email protected]
Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected]
3 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 2
Complex looks simple…
Copyright © 2005-‐12 by KESL June 2012 5
Complex looks simple… … but simple is complex
Copyright © 2005-‐12 by KESL June 2012 6
Complexity made simple June 2012
Philippe Kruchten 3
June 2012 Copyright © 2005-‐12 by KESL 7
“Complexity is the enemy of computer science, and it behooves us, as designers, to minimize it.” Charles Thacker, CACM, July 2010.
“The task of the soVware development team is to engineer the illusion of simplicity.”
Grady Booch, OOAD Book, 1994
June 2012 Copyright © 2005-‐12 by KESL 9
Complexity made simple June 2012
Philippe Kruchten 4
Complexity • What make Systems complex? – Scale
• Many “things”
– Diversity • Many different kinds of “things”
– InterconnecJvity • Many “things” connected to many things in different ways • Apparent lack of determinism, predictability
• “things” = features, developers, stakeholders, users, classes, SLoC, changes, technologies,….
Copyright © 2005-‐12 by KESL 14
Source: McDermid 2000
June 2012
Intrinsic complexity essenJal complexity
Extrinsic complexity
accidental complexity
Copyright © 2005-‐12 by KESL June 2012 18
Complexity made simple June 2012
Philippe Kruchten 5
Perceived complexity culture, familiarity, educaJon
Determinism
Visibility
Copyright © 2005-‐12 by KESL June 2012 22
Complex /= confusing
Complicated
Complex
ChaoJc
Copyright © 2005-‐12 by KESL June 2012 23
Complexity made simple June 2012
Philippe Kruchten 6
Complexity
• Perceived complexity vs. real complexity • Intrinsic complexity (<= nature of the system) – Scale, Diversity, InterconnecJvity
• Extrinsic complexity (<= environment) – Embedding in organizaJon – Embedding in other larger systems – Dependencies, visible and hidden – Success (Jme to market, etc.) – Dependability – Autonomy
Copyright © 2005-‐12 by KESL 24
Source: McDermid 2000
June 2012
Simplicity inverse of complexity?
Parsimony
Uniformity
Predictability
Copyright © 2005-‐12 by KESL June 2012 28
Complexity made simple June 2012
Philippe Kruchten 7
Simple /= simplisJc
Copyright © 2005-‐12 by KESL June 2012 29
“Make things as simple as possible, but no simpler.”
Albert Einstein
Occam’s Razor or Lex parsimoniae: “EnJa non sunt mulJplicanda praeter necessitatem”
William of Ockham, 14th century
Copyright © 2005-‐12 by KESL June 2012 31
Complexity made simple June 2012
Philippe Kruchten 8
“… perfecJon is achieved not when there is nothing leV to add, but when there is nothing leV to take away.” Antoine de St. Exupéry, Terre des Hommes, 1939, chap.3.
June 2012 Copyright © 2005-‐12 by KESL 32
Simplicity
• Parsimony • Uniformity, regularity
• Clear parJJon of concerns
• Inverse of complexity?
June 2012 Copyright © 2005-‐12 by KESL 33
Complexity made simple June 2012
Philippe Kruchten 9
PercepJon of simplicity
• In the eye of the beholder • Not perceived uniformly by all stakeholders – EducaJon, culture, frequency of interacJon, etc.
• CogniJve aspects • Increased sense of determinism – Not chaoJc system
• Simplicity = paucity • Simplicity = limitaJon • Simplicity = overconstraints
June 2012 Copyright © 2005-‐12 by KESL 34
See: Kurtz Snowden 2003
Towards simple
• Limit number of (visible) things – Few technologies, people, interfaces, etc…
• Limit number of (visible) types of things – Harder
• Limit interconnecJons, dependencies – Both in numbers and in kinds
• Increase perceived determinism – “if I do this, this will happen”
• Engineer the illusion of simplicity
June 2012 Copyright © 2005-‐12 by KESL 35
Complexity made simple June 2012
Philippe Kruchten 10
HeurisJcs to Address Complexity
• John Maeda has provided some “Laws of Simplicity”—heurisJcs for managing complexity – Reduce: the number of kinds of things
– Hide: removing elements from select viewpoints – Shrink: expose a simplified view – Organize: impose a paoern
• But how do we realize these heurisJcs?
36 June 2012 Copyright © 2005-‐12 by KESL
A “Simple” Example
• The internet: – Large numbers of things
– Large numbers of types of things (servers, routers, nodes, protocols, …)
– Large numbers of relaJonships
• How have Maeda’s heurisJcs been applied to the internet?
37 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 11
A “Simple” Example -‐ 2
• Reduce: strict control on the number of types of things (managed by the W3C)
• Hide: lower level protocols and physical infrastructure are all hidden
• Shrink: Google.com is a shrunk representaJon of millions of nodes
• Organize: many paoerns—e.g. P2P, client-‐server, SOA, broker—are used to structure the internet
38 June 2012 Copyright © 2005-‐12 by KESL
The System The Community around the system
Copyright © 2005-‐12 by KESL June 2012 42
Complexity made simple June 2012
Philippe Kruchten 12
June 2012 Copyright © 2005-‐12 by KESL
Classifying Systems Higher Technical Complexity
-‐ Embedded, real-‐=me, distributed, fault-‐tolerant -‐ Custom, unprecedented, architecture reengineering -‐ High performance
Lower Technical Complexity -‐ Mostly 4GL, or component-‐based -‐ Applica=on reengineering -‐ Interac=ve performance
Higher Management Complexity -‐ Large scale -‐ Contractual -‐ Many stake holders -‐ “Projects”
Lower Management Complexity -‐ Small scale -‐ Informal -‐ Single stakeholder -‐ “Products”
DoD MIS System
DoD Weapon System
Enterprise IS (Family of IS ApplicaJons)
Telecom Switch
Case Tool (Rose, SoDA)
NaJonal ATC System
Commercial Compiler
Business Spreadsheet
IS ApplicaJon Distributed Objects
(Order Entry)
Small ScienJfic SimulaJon
Large-‐Scale OrganizaJon/EnJty
SimulaJon
An average soVware project: 5-‐10 people 10-‐15 month duraJon 3-‐5 external interfaces Some unknowns, risks
Embedded AutomoJve SoVware
IS ApplicaJon GUI/RDB
(Order Entry)
43
June 2012 Copyright © 2005-‐12 by KESL
Process Tailoring Higher Technical Complexity
Lower Technical Complexity
Higher Management Complexity
Lower Management Complexity • Less emphasis on management perspecJve • More process freedom • More emphasis on individual skills • More emphasis producJon/transiJon
• More emphasis on management perspecJve • More process formality/ceremony • More emphasis on teamwork and win/win • Longer IncepJon/elaboraJon
• More emphasis on domain experience • Longer incepJon/elaboraJon phase • More iteraJons, risk management • Less predictable costs/schedules
• More emphasis on exisJng assets/knowledge base • Shorter incepJon/elaboraJon phases • Fewer iteraJons • More predictable costs/schedules
44
Complexity made simple June 2012
Philippe Kruchten 13
How do we design for complexity?
Architecture to the Rescue!
June 2012 45 Copyright © 2005-‐12 by KESL
Architecture as a parJal answer to complexity
• Level of abstracJon • Divide-‐and-‐conquer approaches • Filter for “things” – Technologies, requirements, teams, etc…
• Blueprints for other acJviJes
• Congruence (Conway’s Law)
June 2012 Copyright © 2005-‐12 by KESL 46
Complexity made simple June 2012
Philippe Kruchten 14
Simplicity, driven by architecture
• Parsimony • Uniformity, regularity
• Clear parJJon of concerns
• Right level of abstracJon • Modularity, encapsulaJon
June 2012 Copyright © 2005-‐12 by KESL 47
The System Architect’s Toolkit
• System architects have developed tools for dealing with complexity over the decades: – Knowledge management: representaJon, modeling, design methods, ontologies, …
– Design principles: modularity, abstracJon, separaJon of concerns, …
– PaUerns: brokers, layers, SOA, P2P, … – TacVcs: building blocks, aggregaJon, interacJon
• We will focus on paoerns and tacJcs. 48 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 15
Paoerns An architectural paoern – is a package of design decisions that is found repeatedly in pracJce
– has known properJes that permit reuse, and
– describes a class of architectures.
“I have not failed. I've just found 10,000 ways that won't work.”
-‐ Thomas Edison
49 June 2012 Copyright © 2005-‐12 by KESL
Paoerns
50 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 16
TacJcs
An architectural tacJc is a design decision that affects a quality aoribute response
Paoerns describe holisJc soluJons; tacJcs describe “atomic” architectural strategies.
51 June 2012 Copyright © 2005-‐12 by KESL
Paoerns: Hierarchy
• Herb Simon: “complexity frequently takes the form of hierarchy” (1962) – Such hierarchies need to be “nearly decomposable”
• The hierarchy paoern aids in taming complexity by: – prevenJng arbitrary relaJonships – enforcing selecJve visibility – simplifying pruning
52 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 17
Paoerns: P2P
• The largest complex systems are organized as a set of peers
• The peer-‐to-‐peer paoern aids in taming complexity by: – avoiding centralized resources – allowing for flexible organizaJon – allowing for dynamic reorganizaJon
53 June 2012 Copyright © 2005-‐12 by KESL
Paoerns: Core-‐Periphery
• The module structure of many complex systems is bifurcated into: 1) a core (kernel) infrastructure, and 2) a set of peripheral funcJons or services
• The C-‐P paoern tames complexity by dividing the engineering problem: – the core provides liole end-‐user funcJonality; it provides the foundaJon
– the majority of the funcJonality lives in the periphery
54 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 18
TacJcs
55
Scalability
Building blocks AggregaJon InteracJon
Modularity
Self descripJon
Environment Models
Self-‐similar structure
Heterogeneity
Parallelism
Abstract ConnecJons
ConnecJon Shuffling
Load Balancing
Gossiping
Tagging June 2012 Copyright © 2005-‐12 by KESL
TacJcs: Modularity
• A Jme-‐honored principle of soVware engineering
• It has been argued to support super-‐linear growth in soVware.
56 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 19
TacJcs: Gossipping
• Nodes need to interact to adapt to their ever-‐changing state and environment.
• Neighboring nodes need to be constantly “gossiping”, exchanging topological and task-‐specific informaJon .
57 June 2012 Copyright © 2005-‐12 by KESL
TacJcs: Self-‐similar Structure
• Complex systems must treat collecJons of enJJes (and collecJons of collecJons) similarly to individual agents: a fractal structure.
• This makes it easy for the system to be self-‐configuring and self-‐adapJng.
58 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 20
A Brief Example: MANETs
• MANETs (Mobile Ad hoc NETworks) exhibit many of these design approaches: – Paoern: Nodes are independent peers, operaJng in parallel with all others
– TacJc: Nodes are modular: do not expose internals; interact via a well-‐defined interface
– TacJc: Nodes may be heterogeneous, sharing only a common communicaJon protocol
– TacJc: Nodes may be nested (i.e. a hierarchy). In fact, nodes exhibit self-‐similar (fractal) structure.
59 June 2012 Copyright © 2005-‐12 by KESL
Conclusions -‐ 1
• We began by claiming that a designer needs to reduce, hide, shrink, and organize to be able to tame complexity.
• We claim that paoerns and tacJcs are templates for achieving these goals in a systemaJc way.
60 June 2012 Copyright © 2005-‐12 by KESL
Complexity made simple June 2012
Philippe Kruchten 21
Conclusions -‐ 2
By employing paoerns and tacJcs, a designer is faced with a simpler, more constrained set of tasks than designing from scratch: 1. choosing the set of primiJves to cover all
system funcJonality, while keeping the number of primiJves small
2. finding regular, systemaJc ways of assembling the primiJves into more complex aggregates
3. minimizing the forms of interacJon between the primiJves, or aggregates, and keeping these interacJons flexible and adaptable.
61 June 2012 Copyright © 2005-‐12 by KESL
Readings • McDermid, J. A. (2000). Complexity: concept, causes and control. Paper
presented at the Sixth IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 2000)."
• Maeda, J. (2006). The laws of simplicity. Cambridge, MA: MIT Press."• Cook, R. I. (2000). How complex systems fail. Cognitive Technologies
laboratory, University of Chicago."• Kurtz, C. F., & Snowden, D. J. (2003). The new dynamics of strategy:
Sense-making in a complex and complicated world. IBM Systems Journal, 42(3), 462-483. (see also Cynefin framework)"
• Nielsen, J (1993). Usability Engineering, Morgan Kaufman. (see 10 usability guidelines at: http://www.useit.com/papers/heuristic/heuristic_list.html)"
• Booch, G. (2004). The illusion of simplicity Available from http://www.ibm.com/developerworks/rational/library/2096.html "
• Sha, L. (2001). Using Simplicity to Control Complexity. IEEE Software, 18(4), 20-28."
• Suh, N.-P. (2005). Complexity in Engineering. Annals of the CIRP, 54(2), 46-63.
June 2012 Copyright © 2005-‐12 by KESL 62
Complexity made simple June 2012
Philippe Kruchten 22
More references
• Kazman, R., & Kruchten, P. (2012). Design approaches for taming complexity. Proceedings of the IEEE International Systems Conference (Syscon2012), Vancouver, BC."
• Kruchten, P. (2012). Complexity made simple. Proceeding of the 2012 Canadian Engineering Education Association Conference (CEEA12), Winnipeg, MB."
June 2012 Copyright © 2005-‐12 by KESL 63