INF5210 Information Infrastructure Class #11 Bootstrapping & - - PowerPoint PPT Presentation

Information Infrastructure Class #11 Bootstrapping & Gateways

Ben Eaton Dan Truong Le 30/10/2013

INF5210

Discuss this weeks reading for class discussion

• Hanseth & Aanestad (2003) - Design as bootstrapping
• Hanseth (2002) – Gateways: just as important as standards

Towards a Theory of Information Infrastructures

A Theories of Information Infrastructures (Evolution & Design) Assemblage Theory

Process Strategies Architecture Governance Complexity Science Actor Network Theory Reflexive Modernisation

Aims

• To provide you with concepts to describe and explain:

▫ How to establish an installed base on an II

Overview

1. 2 Key Challenges of IIs 2. Building an installed base 3. Bootstrapping 4. Gateways

2 Key Challenges of IIs

• 1. Getting them to establish themselves

▫ Building an installed base

• 2. Managing them once they become established

▫ Evolving/extending/developing an II

2 Key Challenges of IIs

• 1. Getting them to establish themselves

▫ Building an installed base

• 2. Managing them once they become established

▫ Evolving/extending/developing an II

2) Managing an established II

• Once an II does take off, one of the issues is

managing it size

• It appears to begin to behave in an autonomous way

▫ Characteristics: reflexive & self destructive ▫ It can develop in undesired directions

 It can become fragmented (e.g. Android Operating System)  Users can become locked in

▫ It can become increasingly complex

 Thus increasing or adding to the problems it was trying to solve in the first place!

2) Managing an established II cont.

• What are the possible solutions?
• Standardisation

▫ As a coordination mechanism ▫ But it can become very stifling

 For example by limiting innovation

▫ Inflexibility due to standardisation

• Gateways

▫ Loose coupling of modular components

• Generativity

▫ Allowing functionality to develop at the edges & not in the core

 End to end (Saltzer et al 1984, Lessig 2002)  Programmable terminals (Benkler 2006)  Zittrain

2 Key Challenges of IIs

• 1. Getting them to establish themselves

▫ Building an installed base

• 2. Managing them once they become established

▫ Evolving/extending/developing an II

But todays focus is how to get IIs to become established.

Establishing an II – part 1

• What are we trying to encourage?

▫ Adoption! ▫ To kick start network effects

 Gain a critical mass of users in a network  So that it becomes self propelling  Positive Network Effects: Value for each user increases with each new user (Shapiro & Varian 1999)

Establishing an II – part 2

• What problem are we trying to solve?

▫ The significant risk of being the first user of a technology

 Potentially very expensive mistake for first user  Risk is that no one else will join the network

▫ E.g. Microsoft Windows Phone 8

• The Question

▫ Is it only "rational" to join a network when there are already significant numbers of users? ▫ or can the II have inherent value (other than the potential value of the network) in order to attract initial users?

 An easy but expensive way is to subsidise initial users

Establishing an II – part 3

• Background theory - Granovetter / Schelling Model

▫ Observations

 Pedestrians crossing the street at a red (pedestrian) light

 A few people cross after the first person crosses  After a few people crossing then "everyone" crosses

• Why this distribution of people deciding to cross the street?

▫ individual preferences amongst an audience of potential network users vary ▫ small changes in this distribution of preferences can have large effects on adoption, e.g.,

 if everyone preferred that no traffic could be seen before crossing - then no one would cross  but if people felt that if individuals were already crossing, and that traffic was light, then they would cross

Establishing an II – part 4

• A solution to the critical mass problem

▫ rather than "buying" (subsidising) first users ▫ identify and address the preferences of initial "lead" users ▫ Hence

 Bootstrapping

 Hanseth & Aanestad (2003) - Design as bootstrapping

 The use of gateways

 Hanseth (2002) – Gateways: just as important as standards

Bootstrapping – Part 1

• Bootstrapping as the process of

▫ Enrolling the first users ▫ Drawing upon them and the technology to extend the network

Bootstrapping – Part 2

• Examples (from Hanseth & Aanestad 2003)

▫ Treating Heart Attacks - Telemedicine in Ambulances

 Example of success  Gradual step by step enrolment until "critical mass" achieved

▫ "Medical Records" - EDI Infrastructures

 Example of failure  Initial success, but then the next step (jumping to X400 based system) was too big a step to gain enrolment

Bootstrapping – Part 3

• Lessons learnt from the paper:

▫ Information Infrastructure user preferences are more complex & harder to address than in Granovetter & Schelling model ▫ User preferences have to be arranged and shaped according to many different attributes ▫ Recommendations for infrastructure design & build …. See next slide …..

Bootstrapping – Recommendation #1

▫ Target the users' Motivation to use & knowledge of the new II – e.g:

 Better to target more motivated individuals than less motivated individuals as "lead" users  Better to target initially individuals who have good knowledge of tech solution and the use that it is being put to

Bootstrapping – Recommendation #2

▫ Consider the impact of the context of work environment on adoption, e.g:

 Are there sufficient resources (time & money) available to allow people the opportunity to adopt?  Better to target initial use areas that are simple rather than complex - Complexity implies risk of failure  Better to target initial use areas that are non critical rather than critical - The cost of failure is higher if use of solution fails in critical areas

Bootstrapping – Recommendation #3

▫ Consider the nature of the technological solution itself, e.g:

 AVAILABILITY: of designers & support personel to users  SIMPLICTY: best just match the actual practice in the first instance, rather than bells & whistles in terms of extra functions  COSTS: it's got to be cheap enough!  FLEXIBILITY: instantiations of practices vary & evolve  FUTURE ORIENTED: to prevent being trapped in a solution that cannot change to match evolving practices

Bootstrapping – Recommendation #4

▫ Appropriate use of coordinating institutions, e.g:

 In the development and implementation of large scale IIs - Institutions for coordination & governance (e.g. standardisation bodies) can help  In the development and implementation of smaller scale IIs

 Flexibility and a "light touch" may be requires  Coordination and governance institutions can suffocate progress

Gateways – part 1

• Hanseth (2002) – Gateways: just as important as standards
• Gateways can be seen in different contexts

▫ Gateways as a bridge between different II solutions allowing

 cross compatibility  interaction between two solutions

▫ Gateways as an enabler for

1. Bridging and migrating users from an old II solution to a new II solution

 cf Cha 4. From Control to Drift - The Economics of Standards

2. Experimentation and allowing for the evolution of the best solution

 cf - Hanseth 2002 Gateways - just as important as standards

Gateways – Part 2:

Overview of Hanseth 2002 Gateways - just as important as standards

• Paper describes the ascendency of the use of the

internet within Nordic Universities amongst other competing network solutions

• Multiple different network solutions competing for

dominance, e.g:

 ISO / OSI packet X.25 based connetion solutions

 Top down standards driven approach  A "complex" technology

 IP based connection less solutions

 Much for flexible evolutionary approach  A "simple" technology

Gateways – Part 3:

Overview of Hanseth 2002 Gateways - just as important as standards

• The need for bridges

▫ To allow for interconnection of university networks in Scandinavia ▫ Elements that made up the bridge

 Nordunet Plug - as "converged" network backbone  Application Protocol Gateways - to allow different application solutions (e.g. email) to interact  Dual stack solutions on PCs & Workstations - allowing user to use different technological solutions easily

• Politics

▫ Each solution had its supporters and detractors - it was hard to drive the adoption of either by "policy“ ▫ ISO/OSI solutions delayed by standardisation effort ▫ IP solutions gradually improved, became more widely adopted, before it became dominant

Gateways – Part 4:

Overview of Hanseth 2002 Gateways - just as important as standards

▫ Lessons Learnt from bridging approach

 Allowing Experimentation & Learning

 Allowed different competing solutions to be tried out and ultimate the "survival of the fittest" (Evolutionary Approach)

▫ User Involvement & Democratic Design Process

 Allowed the user to drive which solution "won" as they were able to adopt the solution that best matched their needs

Gateways – Part 5:

Overview of Hanseth 2002 Gateways - just as important as standards

▫ Adaptation to changing events

 Changes driven by

 New Requirements  Growth in use and range of use

 Gateways provide flexibility for infrastructures to change

▫ Large II development is a pragmatic & judicial balance of

 Standards  Gateways