Understanding the Viability of Large-Scale System DesignsTwo Sides of the Same Coin in a Socio-economic Design Process

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

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

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!

Conflicts Are At The Heart of Innovation…

Service providersISPs

Device manufacturer

Core Access

End usersPrivate organisations

Public organisations

Regulators

Lobby groupsPolitical organisations

…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?

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

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?

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?

Designing Technical and Social Artefact:Two Sides of the Same Coin

• 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?

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!

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

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

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

Expressing the Power: A Methodological and Analytical UnderpinningUnderstanding incentives, their forces and causalities and the resulting dynamics

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

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

The Analytical MethodAn Introduction into Systems Dynamics

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

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

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!

Confidential

An Example: Chicken Farm

The MethodologyEmbedding the Analytics into the Design Evaluation

Evaluating Markets

Likely Socio-Economic Outcomes

Parameterized Causal Loops

develop

formulate

Potential Socio-Economic Scenarios

formulate

leads to

Main Design Characteristics

Potential Socio-Economic Outcomes Reference Modes Causal Loops

derive

derive

develop develop

formulate

Design Space Steps applying SD modeling

Stock/Flows

Evaluating Design Choices

Main Design Characteristics

Design Strategies

Viable Design Strategies

Reference Modes Causal Loops

Parameterized Causal Loops

Design Space

derive

derive

develop develop

develop

formulate

formulate

formulate

formulate

Potential Socio-Economic Scenarios

formulate

Steps applying SD modeling

Stock/Flows

Socio-Economic Outcomes

The ToolkitNo Methodology without Tools

Concepts of the Toolkit

SystemDynamics

Use Case

Actors

Components

Services

Control Points

Control PointConstellations

Triggers Evaluation

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.

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

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

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

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

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

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)

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

•

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

SystemDynamics

Use Case

Actors

Components

Services

Control Points

Control PointConstellations

Triggers Evaluation

Mechanics of the Toolkit

Intention is to provide a set of tools in which the steps can be executed

Mind mapping TechniquesXMind tool

VensimPowerpoint

Overview of Toolkit in XMind

• Different steps for a number of concepts

• Each step is implemented as a separate sheet

Usage: Market Evaluation for Global Rendezvous

Roles in this Future InternetRP : Rendezvous pointITF : Inter-domain topology formationTM : Topology managementFN : Forwarding node

ITFITF

Topology

RPRP

Rendezvous

RendezvousNetwork

Net

wor

k A

rchi

tect

ure

Service Model

Helper

Error Ctrl

…

Fragmentation

Caching

TMTM

TM TM

Forwarding

ForwardingNetwork Forwarding

Network

ForwardingNetwork

ForwardingNetwork

FN

pubpubpubsub

Apps

Nod

e A

rchi

tect

ure

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?

Matching Information Availability and Interest in Large-Scale: A Strawman Architecture

RP

RP

RP

RP

RPRP

RP

pub

REndezvousNEtwork RENE RENE

InterconnectionOverlay

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

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

Toolkit: Overview

Toolkit: Problem Definition

Toolkit: Identify Use Case and Assumptions

Toolkit: Services, Actors and Components

Toolkit: Control Points

Toolkit: Triggers

Toolkit: First Cut of Variables for SD Models

No. of Interconnection Overlays

t

#

1

10

102

103

104

105

One Search Engine

DominantSearch Engines

Ubiquitous interconnect

Initial deployment

Market interest

Commercialization

De-valuation

Commoditization

Consolidation

Number of RENE networks

t

Extreme regionalization

The number of RENE networks is indicative

for the 'regional' character of resolving SId queries since it is assumed that RENE networks are formed under some 'regional'

notion, such as geography, local

peering relations, ... (more under the notion

of 'region' following Sollins, not restricted

to geography).

Regionalization

1

10

102

103

104

105

Direct interconnect#

Initial deployment

Initial regionalization

De-regionalization

De-valuation of RENEregions

Commoditization of RENE regions

Formation of stable regions

Incentive to Interconnect

t

1

Heavy fragmentation

Fragmented Interconnection markets

Fully interconnected Internet

Initial (intra-provider) deployment

Growing inter-providerdeployment

Manifestation of fragmentation

Accelerated interconnection Death of fragmentation

Adoption as intrasolution only

Failure of Adoption

Causal Loops Overlay Providers

Causal Loops RENE Providers

Causal Loops InterconnectionIncentive

Assumptions for Evaluation

• 20 years lifetime

• Full commercial deployment model

• New entrant scenarios not considered here

• Upper limit 20 IO entrants per months

• Taken from VPN market

• 10 times higher for RENE providers (tiered assumption)

• 10% capital burnout rate

• Technology reliability assumed to develop linearly from 0.1 to 0.8

Scenario 1: Anti-Monopoly Movement

• Driven by grass root movements and increasing privacy breaches

• Actors driving this trend are

• end users (through public campaigns),

• legislators (through increased public pressure and the need to address international monopolies),

• regional powers (not accepting monopolies imposed by other regional powers) and

• corporations not being successful in establishing themselves as monopolies.

Influence of End User Concern of IO Providers

Clear overall influence

…but more concern for competition decreases the number of players!

-> explained by equation used to weigh exit rate and overall number in the end user concern (the rate weighs more than the overall number)

Same for RENE providers

Clear overall influence

…but more consolidation can be seen!

Scenario 2: Regional Power Struggle

• Driven by standard activities and regional market competition

• Stakeholders driving this scenario are

• end users (through perceived superiority of regional values),

• legislators (through setting policies for strengthening local structures in disadvantage of global ones),

• corporations (attempting to benefit from such struggles) and

• stock markets (speculating on the outcomes of such struggles).

End User Influence

• End user influences hardly matter

• Viral effect is not modeled and therefore not recognized!

Regulatory Influence

• Regulatory influences visible but hardly any different than direct end user influences

• Similarities lies in used equations

• Difference expected when capturing viral campaigns

Use of DRM to Fragment

• Subtle difference in curve slope

• Running longer simulation reveals fragmented outcome

• No surprise for DRM influence!

Known Shortcomings

• Equations are critical

• Capturing, e.g., viral campaigns, highly influence results

• Current knowledge determines the outcomes: model what you want to see

• Better model what you understand

• Utilize power of codification to extend when new knowledge becomes available

• Selection of scenarios is critical

• As neutral case developer, select broadly

• Bias often given by interest in particular study!

General Lessons Learned for DesignUtilize the power of shaping the tussles

Design for Flexible Interconnection

• Interconnection on equal bit transfer terms is not the only charging methods!

• Bit transfer can facilitate the charge for something else

• Advertisement!

• Information labeling opens space for variety of pricing regimes(*)

• Usage-based pricing

• Locality-based pricing

• Discount pricing(*) See D. Trossen, G. Biczok, Not Paying the Truck Driver: Differentiated Pricing for the Future Internet, ACM Workshop on Rearchitecting the Internet (ReArch) in conjunction with ACM CoNEXT, December 2010

Design for Choice

• Realize that rendezvous is NOT the DNS!

• Information inherently carries value for end users

• Choice is important for end users and corporations alike

• Likely model is to host various information spaces with different IO and/or RENE providers

• This provider is unlikely to be your local ISP!

Design for Isolation

• Isolation is an important aspect of choice

• DRM is an element for such isolation forced onto end users

• Facebook is another end-user driven isolation along social boundaries

• Methods of Social Serendipity can be at the core to define (and overcome) the boundaries of isolation

Design for Flexible Deployment

• Full deployment unrealistic

• Need to accommodate ‘hostile’ or at least agnostic deployments

• Evolution of parts of the system can happen at different speeds

• Need to accommodate these different speeds

• Different deployment model themselves can have significant market and design impact!

Decouple Business Models

• Business models in various parts of the system do not have to be aligned!

• Do not assume the same workings defined by the business model in other parts

• Example: inter-domain routing of requests

• Do not need to adhere bit transfer rules!

In the Context of PURSUIT

Design for Flexible Interconnection

• Current Assumption: everybody connects with everybody else on agreed (bucket) charging terms, i.e., charging indifferent from info

• Revisit this assumption:• Differentiation on information level is

• crucial for applications, e.g., sponsored links, financial information, resilience requirement, regional relevance, …

• crucial on resource level, too (e.g., utilizing caches and particular access types, …)

• crucial for trust reasons, e.g., critical services, financial services etc

• Charging likely to differ with such differentiation (see next item)

• Might result in proxy solutions or entirely separated deployments (with different charging models)

• Impact on outcomes: (regional) monopolies, regional and sector differentiation (and power struggles)

Decouple Business Models

• Current Assumption: Routing of rendezvous requests follows established bit-level interconnection paths

• Money flows differently for bits than for information

• Revisit this assumption:

• Similar to issue on flexible interconnection but here policy enforcement might apply on aggregated (i.e., on scope) level within single IO provider

• Charging mechanism might be enforced on scope or item level

• Metadata management and (micro-)payment solution becomes crucial

• Impact on outcome: more regionalization around industries

Design for Choice

• Current Assumption: resolution via local RENE, followed by interconnection in case local resolution not successful

• Interconnection choice not specified (e.g., based on charging or other policy)

• Revisit this assumption:

• Expose choice as policy with execution on scope or even item level

• Create market of RENE providers as well as IO providers

• Address network attachment process as crucial element (e.g., home vs visiting RENE)

• Impact on outcomes: stronger sector-dependent outcomes

NOTE: with choice comes desire for isolation -> possibly more regional power struggles

Design for Flexible Deployment

• Allow for different deployment scenarios to come to fruition

• Not a direct impact on current design, more a charter for future evaluation, e.g.,

• Extend towards ‘edge’ scenarios vs ‘core’ scenarios

• Switch-over analysis

• Full vs partial deployment

• Hostile vs agnostic deployment

Conclusions

We, as technical designers, should not try to deny the reality of the tussle, but instead recognize our power to shape it.

• A system’s viability is defined by more than its technical performance

• Every decision we make as designers potentially influence the overall viability of the system beyond its mere performance

• We cannot be oblivious to this fact!

• The power to shape the tussles lies in codifying the knowledge of the design’s impact and the forces impacting the design

• You have seen a small toolbox that can help you in your own work as a designer!

Let Us Try Something DifferentLiving the Toolkit

Motivation

The toolkit is aimed at the (business or technical) developer of a solution to better understand the socio-economic environment in which the solution will operate

• Two major problems:

• Understanding stakeholders' views

• Getting to the stakeholders (interviews)

• Getting to the right stakeholders

• Getting to not yet existing stakeholders

• Understanding the dynamics

• Again, interviews

• Repeated consultation with the stakeholders

Stepping Back For A Moment

In the application of the toolkit, there are the following roles:

• Functional actors within the toolkit, e.g., ISPs, service provider, manufacturer, end user, … (see Sketch&Scope step)

• Non-functional actors, such as regulators

• Solution designer, or generally somebody with a larger (architectural) functional implementation understanding

• Case investigator, i.e., the one conducting the study

What If?

…we use a role play to capture concerns, dynamics, and expected change of a particular use case?

Today: An Experiment in Using the Toolkit

• Study: SocialTV, i.e., the combination of TV and social networking (SN) experience

• Case: Delivery of video-like experience in combination with programming information shared by social networking sites

• Assumptions:

• Include web delivery (YouTube)

• Federation of different SN sites

• Inclusion of highly private information in my mash-up of experience (e.g., location, sensed in-house information)

• Information being mashed-up from a variety of sources

• Focus:

• Identity provisioning

• Usage: understand markets for identity provisioning

I Want You To…

• Work the first two steps of the toolkit together

• Clarify case, identify actors/components/services

-> clarify focus and scope of study among yourselves

• Appoint roles to at least one individual

• ALL: support case investigator in taking appropriate notes

-> role somewhat shared

• Conduct the remaining steps within the roles

• Identify control points and triggers through dialogue among yourselves

• Consult solution designer in questions of implementation

• Support case investigator in recording your findings

• Capture the dynamics

• Play scenarios in which certain triggers are invoked within your role

• Record the created dynamics through your counterparts

• Finally: report your findings and lessons learned

• Single combined toolkit but short report from each on impressions

Any Questions?