Understanding the Viability of Large-Scale System Designs

1. Understanding the Viability of Large-Scale System Designs Two Sides of the Same Coin in a Socio-economic Design Process

2. Outline for Today • Why do we need a socio-economic understanding? • What could be a methodology? • No methodology without tools Coffee Break • CASE STUDY: Global rendezvous • Possibly an interactive exercise

3. Why Socio-economics? We’re just technologist, aren’t we?

4. The Internet Has Been a Vast Success in Innovation • An evolution of services that nobody thought of (in detail) • Email, FTP, web, VR, voice (over IP), video (over IP), social networking, sensing, … • The desire to innovate has created new entrants as well as new incumbents • Google, Facebook, YouTube, MySpace, Hulu, … • The Internet’s design has been pointed to as a major enabler for these successful innovations!

5. Conflicts Are At The Heart of Innovation… Device manufacturer ISPs Service providers Core Access Private organisations End users Regulators Public organisations Political organisations Lobby groups

6. …And a Good Design Is Its Basis! IP run over anything and anything runs over IP! • Is it that simple? • Is it free of conflicts? • Why does it adapt?

7. So What Makes a Design a Good One? General principles of design • Generality • Open for innovation • Simplicity • Don’t favour particular actors with baked in functions • Modularity • Separate spaces of conflict

8. But How Much is Enough to Make it a Good Design? And How Good Will It be Under Evolving Conditions? Should I (as a designer) Really Bother?

9. The Power of Design • Similar to engineering for (technical) performance, design provides a power for creating truly sustainable and evolvable artifacts We, as technical designers, should not try to deny the reality of the tussle, but instead recognize our power to shape it. (Clark et al., Tussle in Cyberspace) • If we shape performance through understanding technological bottlenecks and engineering for performance improvements, how do we shape tussle?

10. Where to place control points? …and where not? How flexible is my architecture solution? What business does it enable? and which ones it does not (and should not)? What to place on what layer? How to enable generality? How to maximize utility? What value does this bring me (personally)? How much will I be impacted? How survivable is my business? What strategy will sustain my business? Where can I extract value in my offering? What implements (architecturally) my socio-economic strategy best? Who to partner with? How does this impact social norms and regulations? Designing Technical and Social Artefact:Two Sides of the Same Coin

11. Desired: A Framework that Tightly Combines Architectural Design and Business Modeling • Assume we had a framework that would combine architectural design and socio-economic modeling • Assume that we had a tool that would allow for evaluating success and failure of architectural designs RESULT:Design solutions as a duality of strategic planning and architectural design with measures for success and failure of propositions!

12. Three Envisaged Usages Evaluate the markets created • Technical solutions create markets under various possible evolution scenarios • Markets need to be understood since they create forces that impact the viability of the technical solutions -> extend the pure technical evaluation

13. Three Envisaged Usages (2) Evaluate possible design choices • Crucial functions have various design choices for realization • While technical ability to implement might restrict the set of possible choices, other socio-economic factors will further impact their viability • Impacts strategies for, e.g., alliances, standard activities, development efforts -> limit set of possible choices to be implemented

14. Three Envisaged Usages (3) Evaluate opportunities and threats • Solutions create opportunities and threads for existing and new players • Want to understand them to • advise stakeholders • facilitate adoption -> understand deployment, migration and value proposition

15. Expressing the Power: A Methodological and Analytical Underpinning Understanding incentives, their forces and causalities and the resulting dynamics

16. Requirements • Systems view • Need to incorporate several views and forces into coherent model • Capture incentives of actions • Derive the forces of actions • Derive the intertwined nature of actions on system level • Enable to tie back into the design process

17. Three Ingredients • A Methodology • Derives from understanding of design and ties tussle understanding back into design • An Analytical method • Provides the analytical underpinning • A Toolkit • Enables to codify the understanding for future evolutions

18. The Analytical Method An Introduction into Systems Dynamics

19. Confidential Understanding Dynamics • Systems Dynamics (SD) allows for • Formulating concrete problems • Translate into stock/flow model • Expressing causalities influencing the problem(s) • Translate into causal loop diagrams • Integrating evidence gathered • Find parameters for auxiliary variables • SD is rooted in analytical models • Time series of scenarios based on nested differential equations

20. Confidential Gathering Evidence • It comes in many forms • Interviews with domain experts • Desk research (historical evidence) and sensitivity analysis • Analysis of behaviour • E.g., SNA, evidence from interviews • Crucial: Recording of evidence • Analysis rather easy to record • SD part more complicated • Often done with notes only

21. Confidential An Iterative Process • An initial model is never a best fit • Often many iterations required • Gathering evidence becomes time-consuming • Recording evidence becomes crucial • Often it's been said before!

22. Confidential An Example: Chicken Farm

23. The Methodology Embedding the Analytics into the Design Evaluation

24. Evaluating Markets Design Space Steps applying SD modeling derive derive Main Design Characteristics Stock/Flows develop develop formulate Reference Modes Causal Loops Potential Socio-Economic Outcomes formulate Potential Socio-Economic Scenarios leads to develop formulate Likely Socio-Economic Outcomes Parameterized Causal Loops

25. Evaluating Design Choices Design Space Steps applying SD modeling derive derive Main Design Characteristics Stock/Flows develop develop formulate Socio-Economic Outcomes Reference Modes Causal Loops formulate formulate formulate Design Strategies Potential Socio-Economic Scenarios develop formulate Viable Design Strategies Parameterized Causal Loops

26. The Toolkit No Methodology without Tools

27. Concepts of the Toolkit Use Case System Dynamics Actors Evaluation Triggers Components Control Point Constellations Services Control Points

28. Use Case Particular case of interest Within the toolkit: • Describe your use in plain text version • Furthermore, describe the assumptions of your use case, e.g., identifying the scope of the use case or excluding certain functionality. Lastly, outline the focus of your use case study, e.g., the markets you intend to study, the part of the (technical) architecture you intend to focus on.

29. Actors Actors within the functional architecture, i.e., implementing functionality within the underlying architecture Within the toolkit: • Actors are captured in the Identify step • Map onto (subset of) functional control points

30. Components (Technical) components being used within the functional architecture to implement functionality Within the toolkit: • Actors are captured in the Identify step • Map onto (subset of) functional control points

31. Services Services being provided by actors, implemented through components of the technical architecture Within the toolkit: • Actors are captured in the Identify step • Allow for constructing the control point constellations

32. Control Points Definition: A control point is a point at which management can be applied. Control points can be rooted in business, regulatory, or technical regimes. • Control points do not only reflect technical components (the so-called functional control points) • although they will eventually be implemented by the technical components and the underlying architecture(s) • Control points are usually a superset of the (technical) components, including additional non-functional control point

33. Control Points (continued) • Control points usually hold some form of value • Control points are influenced by triggers, which we will capture in the triggers step • The resulting SD models, operating on these triggers, will show the influence on particular control points

34. Control Point Constellations (CPC) • CPCs are used in the methodology to: • describe the assumed technical implementation of a particular underlying architecture • give a first outline of potential value flow in the given architecture • assist the creation of SD models by outlining the functional part of the architecture that is considered (e.g., rendezvous markets) • Each CPC represents a particular (technical) implementation of the use case, using the functional control points • The CPCs are constructed based on some assumption of the technical architecture that defines the implementation of the particular CPC • The underlying technical architecture is often able to implement many/certain CPCs (each of which includes a number of business models per player)

35. CPCs and Business Models • A CPC is NOT a business model in itself - it is merely a technical implementation of the underlying architecture • It therefore includes a variety of business models • A business model is embedded within a particular CPC as an attempt of players to extract value in certain control points • These attempts of extracting value at certain points can lead to conflicts/tussles, potentially making the CPC break (i.e., the technical implementation) at certain relationships (i.e., service transactions). • Hence, the CPC step does not focus on the individual business models but the ability of an architecture to implement certain cases

36. Triggers • Triggers influence particular control points • Triggers directly lead to the development of SD models in part 2 of the methodology (i.e., the development of stock models and causal loops). • Triggers themselves are sufficient for most SD models to be developed • Similar to control points, triggers exist in many dimensions, apart from technology

37. Use Case System Dynamics Actors Vensim Powerpoint Mind mapping Techniques XMind tool Evaluation Triggers Components Control Point Constellations Services Control Points Mechanics of the Toolkit Intention is to provide a set of tools in which the steps can be executed

38. Overview of Toolkit in XMind • Different steps for a number of concepts • Each step is implemented as a separate sheet

39. Usage: Market Evaluation for Global Rendezvous

40. Apps pub sub Node Architecture pub Fragmentation pub Service Model Caching Topology Rendezvous Helper ITF ITF RP … RP Rendezvous Network Error Ctrl Forwarding TM TM TM TM FN Forwarding Network Forwarding Network Forwarding Network Forwarding Network RP : Rendezvous point ITF : Inter-domain topology formation TM : Topology management FN : Forwarding node Roles in this Future Internet Network Architecture

41. Our Interest Today • Finding the right rendezvous point for a particular scope • That enables ultimately to connect publisher and subscriber(s) • Interesting questions, like • How does the rendezvous network look like? • Who are the players? • How many players? • How fragmented are solutions?

42. Matching Information Availability and Interest in Large-Scale: A StrawmanArchitecture Interconnection Overlay RP RP REndezvous NEtwork RENE RENE RP RP RP RP RP pub

43. Market Questions • How many of these overlays will exist? • How many RENEs will exist? • To how many overlays is each RENE connected? • How fragmented is the interconnection? -> use the toolkit to answer these questions

44. Main Design Characteristics to Focus On • Number of IO providers • A higher number favors designs with manageable (or low) cost for providing the overlay, while solutions with higher costs for overlay provisioning might still be viable in scenarios with a low number of IO providers • Number of RENE providers • Could provide guidance on required scalability and load balancing for the technical solutions for local resolution • Incentive to Interconnect • Determines the fragmentation of regions and therefore markets. • Could possibly be reflected in the design, for instance, through utilizing hierarchical DHTs or similar

45. Toolkit: Overview

46. Toolkit: Problem Definition

47. Toolkit: Identify Use Case and Assumptions

48. Toolkit: Services, Actors and Components

49. Toolkit: Control Points

50. Toolkit: Triggers