Download as a designer

Understanding the Viability of LargeScale System Designs
Two 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…
Device manufacturer
ISPs
Core
Service providers
Access
Private organisations
End users
Regulators
Public organisations
Political organisations
Lobby groups
…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?
• What value does this bring me
(personally)?
• …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?
• 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
Underpinning
Understanding 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 Method
An Introduction into Systems Dynamics
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
Confidential
The Methodology
Embedding the Analytics into the Design Evaluation
Evaluating Markets
Design Space
Steps applying SD modeling
derive
Main Design
Characteristics
derive
Stock/Flows
develop
Potential SocioEconomic Outcomes
formulate
Reference Modes
develop
Causal Loops
formulate
Potential SocioEconomic Scenarios
leads to
develop
Likely SocioEconomic Outcomes
formulate
Parameterized
Causal Loops
Evaluating Design Choices
Design Space
Steps applying SD modeling
derive
Main Design
Characteristics
derive
Stock/Flows
develop
Socio-Economic
Outcomes
formulate
Reference Modes
formulate
Design Strategies
develop
Causal Loops
formulate
formulate
Potential SocioEconomic Scenarios
develop
Viable Design
Strategies
formulate
Parameterized
Causal Loops
The Toolkit
No Methodology without Tools
Concepts of the Toolkit
Use Case
System
Dynamics
Triggers
Actors
Evaluation
Control Point
Constellations
Components
Services
Control Points
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).
•
•
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
Mechanics of the Toolkit
Intention is to provide a set of tools in which the steps can be
executed
Vensim
Powerpoint
Mind mapping
Techniques
XMind tool
Use Case
System
Dynamics
Triggers
Actors
Evaluation
Control Point
Constellations
Components
Services
Control Points
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
RP
ITF
TM
FN
Node Architecture
Roles in this Future Internet
Apps
pub
pub
pub
sub
Fragmentation
Service Model
Topology
ITF
ITF
Network Architecture
: Rendezvous point
: Inter-domain topology formation
: Topology management
: Forwarding node
Rendezvous
Caching
Helper
…
RP
RP
Rendezvous
Network
Error Ctrl
Forwarding
TM
TM
Forwarding
Network
TM
FN
Forwarding
Network
Forwarding
Network
TM
Forwarding
Network
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
Interconnection
Overlay
REndezvous
NEtwork RP
RP
RENE
RP
RP
pub
RP
RP
RP
RENE
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?
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
#
Ubiquitous interconnect
105
Commoditization
104
De-valuation
103
Commercialization
102
Consolidation
10
Dominant
Search Engines
1
One Search Engine
Market interest
Initial deployment
t
Number of RENE networks
#
Direct interconnect
105
104
103
102
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).
Commoditization of RENE
regions
De-valuation of RENE
regions
Formation of stable regions
Regionalization
De-regionalization
10
1
Extreme regionalization
Initial regionalization
Initial deployment
t
Incentive to Interconnect
1
Fully interconnected Internet
Death of fragmentation
Accelerated interconnection
Manifestation of fragmentation
Initial (intra-provider)
deployment
Growing inter-provider
deployment
Fragmented Interconnection markets
Adoption as intra
solution only
Failure of Adoption
Heavy fragmentation
t
Causal Loops
Overlay
Providers
Causal Loops
RENE
Providers
Causal Loops
Interconnection
Incentive
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 Design
Utilize 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 Different
Living 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
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:
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
Any Questions?