design theory for dynamic complexity

Research article

Design theory for dynamic complexity in

information infrastructures: the case of

building internetOle Hanseth1, Kalle Lyytinen2

1Department of Informatics, University of Oslo, Norway;2Department of Information Systems, Weatherhead School of Management, Case Western Reserve University, Cleveland, USA

Correspondence:O Hanseth, Department of Informatics, University of Oslo, Boks 1072 Blindern, NO-0316 OSLO, Norway.Tel: 47 95 90 85 09;Fax: 47 22 85 24 01;E-mail: [email protected]

AbstractWe propose a design theory that tackles dynamic complexity in the design for InformationInfrastructures (IIs) defined as a shared, open, heterogeneous and evolving socio-technicalsystem of Information Technology (IT) capabilities. Examples of IIs include the Internet, orindustry-wide Electronic Data Interchange (EDI) networks. IIs are recursively composedof other infrastructures, platforms, applications and IT capabilities and controlled byemergent, distributed and episodic forms of control. IIs evolutionary dynamics arenonlinear, path dependent and influenced by network effects and unbounded user anddesigner learning. The proposed theory tackles tensions between two design problemsrelated to the II design: (1) the bootstrap problem: IIs need to meet directly early usersneeds in order to be initiated; and (2) the adaptability problem: local designs need torecognize IIs unbounded scale and functional uncertainty. We draw upon ComplexAdaptive Systems theory to derive II design rules that address the bootstrap problem bygenerating early growth through simplicity and usefulness, and the adaptability problem bypromoting modular and generative designs. We illustrate these principles by analyzing thehistory of Internet exegesis.Journal of Information Technology (2010) 25, 119. doi:10.1057/jit.2009.19Keywords: design theory; Complex Adaptive Systems; information infrastructure; Internet; historicalcase study

Introduction

Increased processing power and higher transmission andstorage capacity have made it possible to build increas-ingly integrated and versatile Information Technology

(IT) solutions whose complexity has grown dramatically(BCS/RAE, 2004; Hanseth and Ciborra, 2007; Kallinikos,2007). Complexity can be defined here as the dramaticincrease in the number and heterogeneity of includedcomponents, relations, and their dynamic and unexpectedinteractions in IT solutions. Unfortunately, softwareengineering principles and design methodologies have notscaled up creating a demand for new approaches to bettercope with this increased complexity (BCS/RAE, 2004).The growth in complexity has brought to researchersattention novel mechanisms to cope with it like architec-tures, modularity or standards (Parnas, 1972; Schmidt and

Werle, 1998; Baldwin and Clark, 2000). Another, morerecent stream of research has adopted a more holistic,socio-technical and evolutionary approach putting thegrowth in the combined social and technical complexityat the center of an empirical scrutiny (see, e.g., Edwardset al., 2007). These scholars view these complex systems asnew types of IT artifacts and denote them with a genericlabel of Information Infrastructures (IIs). So far, empiricalstudies have garnered significant insights into the evolutionof IIs of varying scale, functionality and scope includingInternet (Abbate, 1999; Tuomi, 2002), electronic marketplaces and EDI networks (Damsgaard and Lyytinen, 2001;Wigand et al., 2006), wireless service infrastructures (Funk,2002; Yoo et al., 2005) or ERP systems (Ciborra et al., 2000).At the same time effective design of IIs holds considerable

Journal of Information Technology (2010) 25, 119& 2010 JIT Palgrave Macmillan All rights reserved 0268-3962/10

palgrave-journals.com/jit/

benefits for individuals, businesses and society at large astestified, for example, by the success of Internet. Yet,failures to design IIs are more common incurring hugelosses in foregone investments, opportunity costs, andpolitical and social problems. A case in point is current thedifficulty to implement a nation wide e-health system in theUK (Sauer and Willcocks, 2007; Greenhalgh et al., 2008).

One challenge in the II research has been in the difficultyof translating vivid empirical descriptions of IIs evolutioninto effective socio-technical design principles that promotetheir evolution, growth and complexity coordination. Inthis paper we make some steps in addressing this challengeby formulating a new design approach to address thedynamic complexity of IIs. From a technical view pointdesigning an II involves discovery, implementation, in-tegration, control and coordination of increasingly hetero-geneous IT capabilities. Socially, it requires organizing andconnecting heterogeneous actors with diverging interests inways that allow for II growth and evolution. In theproposed approach we posit that the growing complexityof IIs originates from local, persistent and limitless shapingof IIs IT capabilities due to the enrollment of diversecommunities with new learning and technical opportu-nities. We argue that one common reason for theexperienced II design culprits is that designers cannotdesign IIs effectively by following traditional top-downdesign. In particular, the dynamic complexity poses achicken-egg problem for the would-be II designer that hasbeen largely ignored in the traditional approaches. On onehand, IT capabilities embedded in II gain their value bybeing used by a large number of users demanding rapidgrowth in the user base (Shapiro and Varian, 1999).Therefore, II designers have to come up early on withsolutions that persuade users to adopt while the usercommunity is non-existent or small. This requires IIdesigners to address head on the needs of the very firstusers before addressing completeness of their design, orscalability. This can be difficult, however, because IIdesigners must also anticipate the completeness of theirdesigns. This defines the bootstrap problem of II design. Onthe other hand, when the II starts to expand by benefittingfrom the network effects, it will switch to a period of rapidgrowth. During this growth, designers need to heed forunforeseen and diverse demands and produce designs thatcope technically and socially with these increasingly varyingneeds. This demands infrastructural flexibility in that the IIadapts technically and socially. This defines the adaptabilityproblem of II design (Edwards et al., 2007). Clearly, these twodemands contradict and generate tensions at any point oftime in II design (Edwards et al., 2007).

In this paper we will address this tension by examiningemergent properties of IIs as adaptive complex systems. AsIIs exhibit high levels of dynamic complexity, they cannotbe designed in the traditional way starting with a completeset of requirements. II designers cannot design IIs justbased on the local knowledge, but they can increase thelikelihood for successful emergence and growth of IIs byinvolving elements in their designs that take into accountsocio-technical features of IIs generated by their dynamiccomplexity. We call this engagement design for IIs.1 Whiledesigning for IIs, the designers need to ask how they cangenerate designs that promote continued growth and

adaptation of IIs. To this end we outline a socio-technicalII design theory (Walls et al., 1992, 2004) consisting ofdesign principles and rules (Walls et al., 1992, 2004;Baldwin and Clark, 2000; Markus et al., 2002). This theorycan guide design behaviors in ways that allow IIs grow andadapt as self-organizing systems. It is a socio-technicaltheory, because its design domain involves both technicaland social elements and their relationships. It is a designtheory, because it consists of how to design principles andrules (Walls et al., 1992, 2004; Markus et al., 2002) backedby because of justifications derived from a kernel theory Complex Adaptive Systems (CAS) theory (Holland, 1995).We illustrate the validity of these design principles andrules by following the exegesis of Internet.

The remainder of this essay is organized as follows. Inthe next section we define IIs and characterize theirdynamic complexity. The following section formulates thedesign theory based on CAS to address dynamic complexityby deriving design principles. In the subsequent section wedetail the design rules to address dynamic complexity andillustrate their use during the design of the Internet. In thefinal section we offer concluding remarks and note someavenues for future research.

Information infrastructures

IT capabilities, applications and platformsAs noted, IIs form a different unit2 of design when comparedwith traditional classes of IT solutions. These design classescan be defined in their order of increasing complexity as: (1)IT capabilities, (2) applications, (3) platforms, and (4) IIs.The main differences between these classes lie in their overallcomplexity, how they relate to their design and useenvironments, and how they behave over time in relationto those environments. They pose different challenges duringthe design, are organized differently, controlled differentlyand obtain distinct emergent properties. The main features ofeach class are depicted in Table 1.

We denote an IT capability as the possibility and/or rightof the user or a user community to perform a set of actionson a computational object or process. An example of suchcapability would be a text editor. An IT capability is definedand managed locally by single or a small group ofdesigners. They typically control its evolution locally. ITcapabilities are viewed here solely as engineered artifacts.Applications consist of suites of IT capabilities. They are

developed to meet a set of specified user needs within aselect set of communities. They can grow amazinglycomplex in terms of effort and scope, but despite this,they still can be viewed as applications, if governed by a setof specifications3 through which their design scope remainsbounded. An application is a priori determined by choice ofdesign context, user groups and functional goals. Conse-quently, the application can be developed, and preferablyshould be done so, by a hierarchy assuming centralizedcontrol.4 Therefore, most proposed design theories addressthe design of applications by promoting ways of generatingeffectively a closure in the included IT capabilities as tomeet users needs (Boehm, 1976; Ross and Schoman, 1977;DeMarco, 1978; Olle et al., 1983; Agresti, 1986; Walls et al.,1992; Freeman, 2007).

Design theory for dynamic complexity O Hanseth and K Lyytinen2

Table

1Applications,platform

sandinform

ationinfrastructures

Property/Typeof

ITsystem

Application

Platform

Inform

ation

infrastructure

Emergentproperties

Shar

edY

es,

loca

lly

and

thro

ugh

spec

ifie

dfu

nct

ion

sY

es,

acro

ssin

volv

edu

ser

com

mu

nit

ies

and

acro

ssa

set

of

ITca

pab

ilit

ies

Yes

,u

niv

ersa

lly

and

acro

ssm

ult

iple

ITca

pab

ilit

ies

(Sta

ran

dR

uh

led

er,

1996

;P

orr

a,19

99)

Op

enN

o,

clo

sed

by

use

rgr

ou

pan

dfu

nct

ion

alit

yP

arti

ally

,d

epen

ds

on

des

ign

cho

ices

and

man

ager

ial

po

lici

esY

es,

un

iver

sall

yal

low

ing

un

lim

ited

con

nec

tio

ns

tou

ser

com

mu

nit

ies

and

new

ITca

pab

ilit

ies

(Wei

llan

dB

road

ben

t,19

98;

Kay

wo

rth

and

Sam

bam

urt

hy,

2000

;F

reem

an,

2007

)

Het

ero

gen

eou

sY

es,

par

tial

lyan

dm

ain

lyb

yin

volv

edso

cial

gro

up

sP

arti

ally

,m

ain

lyb

yso

cial

gro

up

sb

ut

also

by

tech

nic

alco

nn

ecti

on

s

Yes

,in

crea

sin

gly

het

ero

gen

eou

sb

oth

tech

nic

ally

and

soci

ally

(Kli

ng

and

Scac

chi,

1982

;H

ugh

es,

1987

;K

lin

g,19

92;

Ed

war

dset

al.

,20

07)

Evo

lvin

gY

es,

bu

tli

mit

edb

yti

me

ho

rizo

nan

du

ser

com

mu

nit

y.Y

es,

and

lim

ited

by

arch

itec

tura

lch

oic

esan

dfu

nct

ion

alcl

osu

reY

es,

un

lim

ited

by

tim

eo

ru

ser

com

mu

nit

y(S

tar

and

Ru

hle

der

,19

96;

Fre

eman

,20

07;

Zim

mer

man

,20

07)

Lin

ear

gro

wth

Mo

stly

lin

ear

gro

wth

Bo

thli

nea

ran

dn

on

lin

ear

gro

wth

(Hu

ghes

,19

87)

Evo

luti

on

bo

un

ded

and

con

text

free

Evo

luti

on

pat

hd

epen

den

tE

volu

tio

np

ath

dep

end

ent

(Sta

ran

dR

uh

led

er,

1996

;P

orr

a,19

99;

Ed

war

dset

al.

,20

07)

Structuralproperties

Org

aniz

ing

pri

nci

ple

Dir

ect

com

po

siti

on

of

ITca

pab

ilit

ies

wit

hin

ah

om

oge

neo

us

pla

tfo

rm

Dir

ect

com

po

siti

on

of

ase

to

fh

ori

zon

tal

ITca

pab

ilit

ies

wit

hin

ase

to

fh

om

oge

neo

us

pla

tfo

rms

Rec

urs

ive

com

po

siti

on

of

ITca

pab

ilit

ies,

pla

tfo

rms

and

infr

astr

uct

ure

so

ver

tim

e(S

tar

and

Ru

hle

der

,19

96;

Ed

war

dset

al.

,20

07)

Co

ntr

ol

Cen

tral

ized

Cen

tral

ized

Dis

trib

ute

dan

dd

ynam

ical

lyn

ego

tiat

ed(W

eill

and

Bro

adb

ent,

1998

)C

anin

volv

eo

nly

bas

iso

rgan

izin

gp

rin

cip

les

(sta

nd

ard

s)an

dre

lyo

nin

stal

led

bas

ein

erti

a(S

tar

and

Ru

hle

der

,19

96;

Ed

war

dset

al.

,20

07).


Platforms differ from applications due to their hetero-geneous and growing user base, that is their design contextis not fixed due to the constant generification of includedIT capabilities (Williams and Pollock, 2008). Platformsinclude, for example, office software platforms (MS Office,Officestar), operating system platforms (Windows, Unix),application frameworks like ERP or CRM packages (SAP,Oracle, SalesForge) or application development platforms(e.g. Service Oriented Architecture). Platform designs drawupon architectural principles that organize IT capabilitiesinto frameworks allowing the software to address a familyof generic functional specifications that meet the needs ofmultiple, heterogeneous and growing user communities(Evans et al., 2006; Williams and Pollock, 2008). Platformsare composed by formulating a design framework (archi-tecture) that allows organizing a growing set of ITcapabilities into a relatively well-bounded and controlledsystem. The platforms provide thus a (semi)-closed, andhighly complex suite of IT capabilities, which, thanks to theoriginal architecting, can be extended. A platforms initialdesign starts with a set of closed specifications determiningincluded IT capabilities and anticipated requirements fortheir extensions and combinations. Their evolution is alsogoverned and constrained by these initial specifications.Therefore, the design context remains controlled and therelationships between the user and design communities donot change significantly during the platforms lifetime.Platforms typically grow in complexity as designers takeinto account heterogeneous user needs while maintainingbackward compatibility and horizontal compatibility acrossdifferent combinations of capabilities. Therefore, manyplatforms, originally conceived as limited sets of ITcapabilities, obtain later emergent features; they startgrowing in seemingly unlimited fashion and serve unex-pected user communities generating exponentially growingtechnical and social complexity. Consider, for example, thegrowth of the MS Office platform, or Linux operating systemdue to the increasingly distributed and open character oftheir design and user communities (Scacchi, 2009).

Defining IIBased on an extensive literature review we will define next II.Hughes (1987) recognized early on heterogeneity, socio-technical nature and unbounded growth as essential featuresof infrastructures. Kling (1992) and Kling and Scacchi (1982)drew attention to additional material requirements ofinfrastructures like connectivity. Porra (1999) and Star andRuhleder (1996) have recently emphasized the criticality ofsharing and learning within and across communities, whileKayworth and Sambamurthy (2000), Weill and Broadbent(1998) and Chung et al. (2003) have pinpointed thepossibility to shape infrastructures by local choice. Finally,recent definitions of IIs recognize tensions between the localand the global, their recursive nature, their uniquecoordination challenges due to the lack of global control(Star and Ruhleder, 1996; Edwards et al., 2007; Freeman,2007; Zimmerman, 2007) (Table 1).

Accordingly, we will define an II as a shared, open (andunbounded), heterogeneous and evolving socio-technicalsystem (which we call installed base) consisting of a set ofIT capabilities and their user, operations and design

communities. This definition highlights both the structuralproperties and the emergent properties of IIs thatdistinguish IIs from their constituent elements (Table 1).

Structurally an II is recursively composed of otherinfrastructures, platforms, application and IT capabilities.Recursion forms the organizing principle implying that IIsreturn onto themselves by being composed of similarelements (Lee et al., 2006). Socially, IIs are also recursivelyorganized in that they are both outcomes and conditions ofdesign action and involve rule-following and rule-shapingactivity (Giddens, 1984). The control of II is distributed andepisodic and an outcome of negotiation and sharedagreements. Distributed forms of control form often theonly way to coordinate II evolution and thus IIs are neverchanged from above (Star and Ruhleder, 1996). Therefore,they cannot be truly designed in a traditional sense as intraditional approaches a designer assumes control over thedesign space (Edwards et al., 2007; Freeman, 2007). Episodicforms of control determine which groups of designerscontrol which parts or elements of the II; what IT capabilitiesbecome integrated and how; who has access to thecapabilities and so on (Tuomi, 2002; Edwards et al., 2007).

IIs become shared across multiple communities in amyriad and unexpected ways. In principle, they exhibitunbounded openness: new components can be added andintegrated with them in unexpected ways and contexts. Inaddition, there are no clear boundaries between those thatcan use an II and those that cannot; and there are no clearboundaries between those that can design the II and thosethat may not. As a result, II designs need to be approachedas if no closure, in principle, is assumed in their form orcontent, capability, form or scope of access.

The openness of IIs implies that during their lifetime thesocial and technical diversity and heterogeneity of IIs willincrease (Edwards et al., 2007). IIs become increasinglyheterogeneous as the number of different kinds of technolo-gical components are included, but first of all because IIsinclude (an increasing number of) components of verydifferent nature: user communities, operators, standardizationand governance bodies, design communities, etc.

Finally, because IIs are open, they evolve, seemingly, adinfinitum. IIs are never built in a green field, nor do theydie though they may wither to rise in new forms (Edwardset al., 2007). IIs are often bootstrapped by experimentingand thereby enrolling new communities. For example,Berners-Lee designed the first web service to meetinformation sharing needs among high energy physicists(Berners-Lee and Fischetti, 1999). As this design unfolded,designers and users discovered additional IT capabilities, ortransformed the existing ones to new uses, or to otherdesign contexts thereby expanding the web (Ciborra et al.,2000) generating its fractal evolution. Hence, the evolutionof Infrastructure is fixed in modular increments, not all atonce or globally (Star and Ruhleder, 1996).

Overall, the evolution of infrastructures is both enabledand constrained by the installed base,5 that is the existingconfiguration of II components (Hughes, 1987; Star andRuhleder, 1996; Porra, 1999). Whatever is added needs tobe integrated and made compatible with this base. This setsup demands for horizontal and/or backwards compatibilityand imposes constraints on what can be designed atany time. Accordingly, II evolution is path dependent


and shaped by neighboring infrastructures, existing ITcapabilities, user and designer learning, cognitive inertia,etc. (Hughes, 1987; Kling, 1992; Star and Ruhleder, 1996;Hanseth and Monteiro, 1997; Porra, 1999).

Related researchMost II research has aimed at identifying the main featuresand characteristics of IIs their nature as they evolve anddevelopers and users are struggling to make them work (Starand Ruhleder, 1996; Ciborra et al., 2000; Kallinikos, 2004,2006, 2007; Edwards et al., 2007; Contini and Lanzara, 2009).

Standards are core elements of IIs; hence standardsresearch constitutes a major part of II research (Star andRuhleder, 1996; Edwards et al., 2007). A large part of thisresearch has focused on and disclosed a very dense andcomplex web of relations between technical and social (ornon-technical) issues and elements of the standards(Hanseth and Monteiro, 1997; Bowker and Star, 1999;Lyytinen and Fomin, 2002) Another key part of the researchhas focused on the creation and role of network effects, thatis self-reinforcing processes leading to lock-ins (Shapiroand Varian, 1999; Hanseth, 2000).

A minor part of II research has focused explicitly onstrategies for developing standards and infrastructures.Cordella (2004), Hanseth and Lundberg (2001), Grisot(2008) and Pipek and Wulf (2009) describe how infrastruc-tures emerge in use while users appropriate a variety of ITcapabilities and bring them together in novel ways by makingthem components of IIs . Even without technically integratingthe capabilities, they are de facto becoming integrated andinterdependent in work practices (Pipek and Wulf, 2009).

A few researchers have addressed design strategies forinfrastructure development. Hanseth et al. (1996) recognizethe need to manage the tension between standardizationand flexibility (see also Egyedi, 2002). Hanseth andAanestad (2003) argue, using telemedicine as an illustra-tion, that II design needs to be seen as a bootstrappingprocess, which utilizes network effects and spillovers withina growing user base by using simple solutions as a sort ofstunts, which offer detours on the road toward infra-structures (Aanestad and Hanseth, 2002). Hanseth (2001)also demonstrates the importance of gateways in flexible IIdesign by reviewing the history of the Internet design inScandinavia. Lessig (2001) and David (2001) note thecriticality of Internets architectural features especially itsend-to-end architecture in supporting adaptability at theedge of chaos (Saltzer et al., 1984). Benkler (2006)emphasizes the importance of the local programmabilityof terminals, and its mutual dependency on the end-to-endarchitecture. Finally, Zittrain (2006) recently combinedthese features into an encompassing concept of a generativetechnology a notion close to our idea of dynamiccomplexity. We add next to Zittrains concept a morecoherent design framework formulated as a design theory.

Design theory for addressing adaptive complexity in IIevolution

IT design theoriesSince the publication of Walls et al.s (1992) article, theterm IS design theory has denoted a set of concepts, beliefs

and laws either natural or social which help designersmap a class of design problems to effective solutions thatmeet design goals. Design theories are about how toprinciples and rules of form and function, and justificatorybecause of explanatory knowledge that can be mobilizedduring the design (Gregor, 2006). They encapsulate threeelements: (1) a set of design goals shared by a family ofdesign problems; (2) a set of system features that meetthose goals; and (3) a set of design principles and rules toguide the design so that a set of system features is selectedto meet chosen design goals. Design principles state broadguidelines how the design can be carried out and where thedesigner can focus his or her attention during function andform shaping. They can be further detailed into design rulesthat formulate in concrete terms how to generate and selectdesired system features as to achieve stated system goals.

The crux of a design theory is its kernel theory (Wallset al., 1992). It postulates falsifiable predictions for a classof design solutions (i.e. product theories), or designprocesses (i.e. process theories) in relation to system goals.They vary significantly in their generality, structure andpredictive power (Gregor, 2006). Each design theory appliesin a certain design context in which a specific set of systemgoals have been selected, and apply to a specific class ofsystems and associated design processes. The design contextis determined by the nature of the system, its size, thedesign phase, the type of technology, the type of users ordesigners (Walls et al., 1992, 2004). Next we will focus on IIdesign theory for dynamic complexity. Our main interest isin generating technical and social components of the IIs inways that address the tensions between the bootstrap andthe adaptability problems.

CAS as a design theory about dynamic complexity in IIWe draw upon CAS theory as our kernel theory (Holland,1995; Benbya and McKelvey, 2006). CAS addresses non-linear phenomena within physics and biology, but also insocial domains including financial markets (Arthur, 1994).CAS investigates systems that adapt and evolve while theyself-organize. The systems are made up of autonomousagents with the ability to adapt according to a set of rules inresponse to other agents behaviors and changes in theenvironment (Holland, 1995). Key characteristics of CASare: (1) nonlinearity, that is small changes in the input orthe initial state can lead to order of magnitude differencesin the output or the final state; (2) order emerges fromcomplex interactions; (3) irreversibility of system states,that is, that change is path dependent; and (4) unpredict-ability of system outcomes (Dooley, 1996).

We chose CAS as our kernel theory as it recognizesfactors that generate the dynamics associated with the IIbootstrap and adaptability problems and helps describe IIevolution as an example of path-dependent and nonlinearchange. CAS brings theoretical rigor to generate insights tothese two design challenges. In addition, these challengesare not highlighted in two pet theories among II scholars:the social shaping of technology (Edwards et al., 2007), andBatesons ecological theory (Star and Ruhleder, 1996). Next,the design principles are deductively derived from CAS. Inthe section Design rules to manage dynamic complexity the Internet case we instantiate these principles with a set


of 19 design rules whose application is illustrated withconcrete episodes from the design history of Internet.6

CAS categories and design principles for dynamic complexity in IIsCAS helps characterize how the IIs can be initiated and howthey grow and evolve while they self-organize. This isaddressed by following the two principles: (1) create anattractor that feeds system growth to address the bootstrapproblem; and: (2) assure that the emerging system willremain adaptable at the edge of chaos while it grows toaddress the adaptability problem. We surmise that theseprinciples can promote design for IIs in ways that lead themto self-organize and to grow. We will next describe keycategories of CAS theory and the logic that underpins thesedesign principles and their because of reasons assuggested in Table 2.

Addressing growth in IIA central claim in CAS is that order emerges it is notdesigned by an omnipotent designer. Typical example isthe dynamic arrangements among cells and the establish-ment of standards without anyone ever intending to designthem as such (e.g. QWERTY, TCP/IP). According to CAS,such orders emerge around attractors, that is a limitedrange of states within which the system growth canstabilize, and which allow the system to bootstrap (Holland,1995). The simplest attractor is a single point in the systemstate space. Attractors can also come in other forms, whichare called strange attractors (Carpa, 1996) that stabilizesthe system into a specific region (David, 1986). De-facto

standards (e.g. MS Windows, QWERTY, Internet stan-dards) are examples of such attractors. Attractors stabilize asystem through feed-back loops (also called network effectsor increasing returns). In case of standards this happensbecause the value of a standard defining an IT capabilitydepends on the number of users having adopted it. So whena user adopts a standard its value increases. This againmakes it more likely that another user will adopt it, whichfurther increases its value and so on (Arthur, 1994; Shapiroand Varian, 1999). A large installed base will also attractcomplementary IT capabilities thereby making the originalcapability increasingly attractive (Shapiro and Varian, 1999).A larger installed base increases also the credibilityassociated with the capability and reduces user risks offoregone investments. Together these features make an ITcapability more attractive leading to increased adoption thatfurther increases its installed base (Grindley, 1995). Somedescribe this process of getting the bandwagon moving.

Positive network effects lead to self-reinforcing path-dependent processes. Overall, the involved path dependencysuggests that past events for example a serendipitousadoption, or correctly timed designs can change history bygenerating irreversible effects called butterfly effects. Suchpath-dependent growth will eventually lead to a lock-in whenthe adoption rates cross a certain threshold (David, 1986).Such a lock-in happens when a systems growth reaches whatHughes (1987) calls a momentum. This creates a new lastingorder with irreversible effects (Arthur, 1994).

We distinguish two facets of path dependence in IIs:cumulative adoption and technology traps. Cumulativeadoption takes place when an II designer builds up an

Table 2 CAS-based design theory for dynamic complexity in Information Infrastructures (IIs)

Design goals Bootstrap the IT capability into an installed base so that it gains momentumManage and allow for maximum II adaptability.

A set of systemfeatures

II as an unbounded, evolving, shared, heterogeneous and open recursively organizedsystem of IT capabilities whose evolution is enabled and constrained by its installed baseand the nature and content of its components and connections.

Kernel theoryof flexible IIs

CAS informs how to address bootstrap problem in II designs by suggesting thatK Designer can gain momentum in the growth of II through attracting a critical mass

of usersK Designer can enable nonlinear growth by new combinations of the installed baseCAS informs how to address the adaptability problem in II designs by suggesting thatK Designer needs to recognize path dependencies within the installed baseK Designer needs to create lock-in through network externalities that exclude alternative pathwaysK Designer need to achieve modularity to accommodate the growing need for openness and

heterogeneity in future

Design principles For the II bootstrap problem:1. Design initially for usefulness2. Draw upon existing installed base3. Expand installed base by persuasive tacticsFor the II adaptability problem:4. Make each IT capability simple5. Modularize the II by building separately its principal functions and sub-infrastructures using

layering and gateways


installed base ahead of its alternatives and accordinglybecomes cumulatively attractive, and starts growing in anunbounded manner. Bootstrapping for cumulative growthis possible when the timing is right and users can still bepersuaded (Edwards et al., 2007; Zimmerman, 2007).Design choices for II thereby become path dependent, asconditions for cumulative adoption are created during theearly stages of growth (Grindley, 1995; Shapiro and Varian,1999). Technology traps suggest that many times blind earlydesign decisions later constrain the further expansion of IIand become reverse salients (Hughes, 1987). Design forexpansion is typically carried out technically and socially inways that is compatible with the early installed base and itspredicted trajectory. Thereby, early design decisions canlater block the expansion as new communities join, ortechnological trajectories change, and create adverseconstraints for growth. Such adverse constraints we calltechnology traps. Examples of technology traps are, forexample, the need to support archaic computer architec-tures (e.g. IBM 9010, IBM360 or Intel 8086), operatingsystems (DOS, Windows95) (Mashey, 2009) or the effects ofarchitecture choices for the growth of the French Minitelsystem (Cats-Baril and Jelassi, 1994).

Addressing adaptability in IIAll systems evolve, but all systems do not adapt equallywell. Systems that reach early on lock-in, or exhibit a largenumber of reverse salients (Hughes, 1987) will fail to doso. According to CAS, highly adaptable systems arecharacterized by the increased variety achieved throughhigh modularity: variation is the raw material for adapta-tion (Axelrod and Cohen, 1999: 32). In other words, thelarger the variety of agents and pathways for evolution, themore design alternatives can be tried out, and the moreagents learn (Holland, 1995; Benbya and McKelvey, 2006).Accordingly, the larger the variety of IT capabilities and thelarger the number of II designers the larger is IIadaptability. At the same time a certain level of order isnecessary in order to maintain stability in the designcontext. This stability is achieved through modularity.According to CAS, modularity creates a balance betweenvariety and order by localizing the change and permittingfast and deep change in parts of the system. Engineered aswell as living systems must thus be modular to remainrobust and at the same time to generate variety (Simon,1969; Baldwin and Clark, 2000; Wagner, 2007). Adaptationbecomes optimal at the edge of chaos (Stacey, 1996),where variety generation and modularity are balanced.7 Towit, traditional application design theory assumes thecomplete order of stasis as designers are assumed tocontrol all the system states during the design. In contrast,random order excludes the possibility for any design as noorder can be detected in the context. Hence, in designingfor II, designers need to establish a self-organization, wherethe II will remain at the edge of chaos.

Design rules to manage dynamic complexity theInternet caseThe design principles listed in Table 2 guide II designers toconceive their designs in ways where they can generatenatural order at the edge of chaos. To carry out effectively

designs that conform to these principles we need to breakdown the five design principles into design rules thatgovern designers behaviors influencing specific II compo-nents or their environments. In this section we willarticulate such design rules. The next section introducessome modularity concepts necessary in stating design rules.The following section offers a summary of their content andreports how we used Internet design to illustrate them. Thesection after that introduces each design rule withillustrative examples from Internet design.

Modularization of IIIn formulating the design rules we need to distinguishproperties of IIs that help modularize them. We thereforenext define analytical types of (sub) IIs that allow whencomposed together the generation of modular IIs. Weapply recursively de-composition, that is identify separatesubsets of IT capabilities within any II, which also are IIs,but which share either a set of common functions and/ orinternal or external connections without having strongdependencies with the remaining IIs (Baldwin and Clark,2000; Kozlowski and Klein, 2000).

We will first split IIs into vertical application IIs and ofhorizontal support IIs. The former will deliver functionalcapabilities, which are deployable directly by one or moreuser communities. An example of application capabilitywould be e-mail. The latter support infrastructures offergeneric services often defined in terms of protocols orinterfaces necessary in delivering most, if not all applicationservices. They are primarily deployed by designer commu-nities while building application capabilities8 and includecapabilities for data access and identification (addressing),transportation (moving) and presentation (formatting). Theyalso constitute part of the installed base, which II designersneed to take into account when bootstrapping an applicationinfrastructure or making changes in support IIs.

We can further recursively decompose both applicationand support IIs. Thus, any II can be split into its applicationand support infrastructures until a set of atomic ITcapabilities are reached (per recursive definition of II). Inaddition, any support infrastructure can be split intotransport and service IIs. This split is justified as transportinfrastructure is necessary to make any service infrastruc-ture work. The transport IIs offer data or messagetransportation services like the UDP/TCP/IP protocol stack(Leiner et al., 1997). On the other hand service infra-structures support, for example, direct addressing, serviceidentification, service property discovery, access andinvocation, or security capabilities. They become usefulwhen IIs start to grow in complexity and scale, anddesigners need more powerful capabilities to configureapplication capabilities. A classic example of a service II isthe Domain Name Service (DNS) in the Internet, whichmaps mnemonic identifiers like amazon.com to varyinglength bit representations, that is IP addresses. Bothapplication and service IIs can be finally linked togetherhorizontally through gateways. These offer flexible path-ways for II expansion and navigation (Hanseth, 2001;Edwards et al., 2007). An example of a gateway would be anIT capability, which supports multiple e-mail servicesrunning on different e-mail protocols.


Design rules for dynamic complexity in IIs

Derivation and summary of the design rulesIn total, we propose 19 design rules for II dynamiccomplexity shown in Table 3. Overall, the design rulescharacterize: (1) appropriate ways to organize and relate IIcomponents technically and socially (modular design,organize recursively) that address dynamic complexity simi-lar to Baldwin and Clarks (2000) design rules; (2) desirableproperties of specifications of II components (e.g. simpli-city), (3) desirable sequences for design (e.g. design one-to-many IT capabilities before many-to-many IT capabil-ities) (4) desirable ways to relate II specifications andassociated components to one another (modularity, recur-sive application).

Illustrating II design rules- the case of InternetBelow we illustrate the deployment of each design rule byreferring to episodes of Internet design. We chose Internetdesign as an illustration as its design history offers richinsights into the situated application of the proposed designtheory in use. We chose to illustrate the theory with thedesign of Internet, because it qualifies as a grand successstory about II design par excellence (Table 4). By anycriterion its design involved cultivating an II, which isshared, open and heterogeneous, organized recursively andoperates without centralized control. We also content thatthe success of Internet testifies to the plausibility of thedesign rules discussed below.

We gleaned the design rules by content analyzing designepisodes, that is, moments when new IT capabilities wereadded, modified, expanded or purged in the Internetregime. A review of these design situations permit usgeneralize identified design rules by triangulating data withthe emerging theory (Eisenhardt, 1989). Documents like theInternet Engineering Task Force (IETF) rules for RequestsFor Change, but also the credo coined in Clarks famousspeech in 1992: We reject: kings, presidents, and voting.We believe in rough consensus and running code (Russell,2006), and personal biographies all exemplify the behaviorsof the Internet designers and consequently their designtheories-in-use. To this end we probed Internet standardi-zation archives and primary secondary sources on Internethistory especially Abbates (1999) excellent narrative. Wealso examined personal accounts of Internet design (Leineret al., 1997; Berners-Lee and Fischetti, 1999), and recentscholarly analyses of the Internet growth (Tuomi, 2002).Finally, we interviewed Robert Kahn, one of the originaldevelopers and sponsors of Internet protocols. As a resultwe were able to solicit 19 design rules as summarized inTable 5 founded on CAS that had worked during Internetdesign.

For sure, not all designers at all times and consciouslyfollowed these rules. But many of them acted consistent withthese rules. For example, they underpin many commoninteraction rules in the Internet design ecology. Many keyfigures have also openly embraced proposed design princi-ples. For instance, throughout Internets history, from Kahnsand Cerfs initial design to the creation of BitTorrent, theInternet designers have favored bottom-up, experimentaldesign and utilization of network effects. At the core was also

the recognition of high uncertainty related to desired ITcapabilities. Bob Kahn noted vividly this:

They (DoD) didnt have a problem. And thats why its sohard for those kinds of things to actually get in motion. Ifyoure saying, Can I imagine a problem that somebodymight have at some unspecified point in the future?Absolutely, that was what was driving it. And, so you hadto really trust what was in your minds eye. And that wasthe basis on which the internal justifications wereeventually made. But it took a while to get there. (Kahn,2006)

Therefore, he argued that the only way to design wasexperimental:

But when youre dealing with something as really state ofthe art, its hard to know what to build upfront because alot of what makes it what it is a function of, you know,iterating with users and feedback and allowing the systemto evolve and grow and to see how it would work. This isnot something that most people, who are, you know, inmanagement chain, are very uncomfortable with becausethey dont exactly know what to expect. So its very hardfor those people, you know, to deal with those kinds ofcreative processes. (Kahn, 2006)

Design rules for dynamic complexity in the design for IIWe next discuss in detail how the 19 design rules in Table 3were inferred from the CAS theory offering a because ofjustification for the design principles. To wit, each designrules offers a falsifiable statement of design outcomes tovalidate the theory. By analyzing whether the designerfollowed the rule and related design outcomes, we candetermine whether the rule following did not lead to thepredicted outcome thus falsifying (partly) the proposeddesign theory.

Design rules for the bootstrap problemOften new IT capabilities are not adopted despite theirnovelty, because users wait others to adopt first: earlyadopters face high risks and costs, but few benefits. In lightof CAS, an II designer must generate attractors to propelusers to adopt the IT capability so that its growth will reach amomentum (Hanseth and Aanestad, 2003). We observe threedesign principles decomposed into 12 design rules that helpgenerate and manage such attractors (see Tables 3 and 5).

Design rules for principle #1: Design initially for directusefulness: Early users cannot be attracted to IT capabil-ities reasons like the size of their installed base. Therefore,we need design rules that foster relationships between theproposed IT capability and user adoption. Therefore, asmall user population needs to be identified and targeted(Design Rule 1 (DR19)). The proposed IT capability has tooffer the group immediate and direct benefits (DR2).Because first adopters accrue high adoption costs andconfront high risks, the IT capability to-be-adopted must be


Table

3Designrulesfordynamic

complexityin

thedesignforIIs

Designproblem

Elementof

CAS

Designprinciples

Designrules

Bootstrapproblem

Des

ign

goal

:G

ener

ate

attr

acto

rsth

atb

oo

tstr

apth

ein

stal

led

bas

e

Cre

ate

anIT

cap

abil

ity

that

can

bec

om

ean

attr

acto

rfo

rth

esy

stem

gro

wth

.1.

Des

ign

init

iall

yfo

rd

irec

tu

sefu

lnes

s.D

R1.

Tar

get

ITca

pab

ilit

yto

asm

all

gro

up

DR

2.M

ake

ITca

pab

ilit

yd

irec

tly

use

ful

wit

ho

ut

the

inst

alle

db

ase

DR

3.M

ake

the

ITca

pab

ilit

ysi

mp

leto

use

and

imp

lem

ent

DR

4.D

esig

nfo

ro

ne-

to-m

any

ITca

pab

ilit

ies

inco

ntr

ast

toal

l-to

-all

cap

abil

itie

s.

Avo

idd

epen

den

cyo

no

ther

IIco

mp

on

ents

that

def

lect

away

fro

mth

eex

isti

ng

attr

acto

rsU

sein

stal

led

bas

eas

tob

uil

dad

dit

ion

alat

trac

tors

by

incr

easi

ng

po

siti

ven

etw

ork

exte

rnal

itie

s

2.B

uil

du

po

nex

isti

ng

inst

alle

db

ases

DR

5.D

esig

nfi

rst

ITca

pab

ilit

ies

inw

ays

that

do

no

tre

qu

ire

des

ign

ing

and

imp

lem

enti

ng

new

sup

po

rtin

fras

tru

ctu

res

DR

6.D

eplo

yex

isti

ng

tran

spo

rtin

fras

tru

ctu

res

DR

7.B

uil

dga

tew

ays

toex

isti

ng

serv

ice

and

app

lica

tio

nin

fras

tru

ctu

res

DR

8.U

seb

and

wag

on

sas

soci

ated

wit

ho

ther

IIs

Exc

lud

eal

tern

ativ

eat

trac

tors

by

per

suas

ive

tact

ics

Off

erad

dit

ion

alp

osi

tive

net

wo

rkex

tern

alit

ies

by

exp

and

ing

lear

nin

gin

the

use

rco

mm

un

ity

3.E

xpan

din

stal

led

bas

eb

yp

ersu

asiv

eta

ctic

sto

gain

mo

men

tum

DR

9.U

sers

bef

ore

fun

ctio

nal

ity

gr

ow

the

use

rb

ase

alw

ays

bef

ore

add

ing

new

fun

ctio

nal

ity

DR

10.

En

han

cean

yIT

cap

abil

ity

wit

hin

the

IIo

nly

wh

enn

eed

edD

R11

.B

uil

dan

dal

ign

ince

nti

ves

soth

atu

sers

hav

ere

alm

oti

vati

on

tou

seth

eIT

cap

abil

itie

sw

ith

inth

eII

inn

eww

ays

DR

12.

Dev

elo

psu

pp

ort

com

mu

nit

ies

and

flex

ible

gove

rnan

cest

rate

gies

for

feed

bac

kan

dle

arn

ing

Adaptability

problem

Des

ign

Go

al:

Mak

eth

esy

stem

max

imal

lyad

apti

vean

dva

riet

yge

ner

atin

gas

toav

oid

tech

no

logy

trap

s

Bu

ild

cap

abil

itie

sth

aten

able

gro

wth

bas

edo

nex

per

ien

cean

dle

arn

ing

Use

abst

ract

ion

and

gate

way

sto

sep

arat

eII

com

po

nen

tsb

ym

akin

gth

emlo

ose

lyco

up

led

4.M

ake

the

ITca

pab

ilit

yas

sim

ple

asp

oss

ible

DR

13.

Mak

eth

eII

assi

mp

leas

po

ssib

lein

term

so

fit

ste

chn

ical

and

soci

alco

mp

lexi

tyb

yre

du

cin

gco

nn

ecti

on

san

dgo

vern

ance

cost

DR

14.

Pro

mo

tep

artl

yo

verl

app

ing

ITca

pab

ilit

ies

inst

ead

of

all-

incl

usi

veo

nes

.

Des

ign

ITca

pab

ilit

ies

and

thei

rco

mb

inat

ion

sin

way

sth

atal

low

IIgr

ow

thU

seev

olu

tio

nar

yst

rate

gies

inth

eev

olu

tio

no

fII

that

allo

win

dep

end

ent

incr

emen

tal

chan

gein

sep

arat

eco

mp

on

ents

Dra

wu

po

nII

des

ign

sth

aten

able

max

imal

vari

atio

ns

atd

iffe

ren

tco

mp

on

ents

of

the

II

5.M

od

ula

rize

the

IID

R15

.D

ivid

eII

recu

rsiv

ely

alw

ays

into

tran

spo

rtat

ion

,su

pp

ort

and

app

lica

tio

nin

fras

tru

ctu

res

wh

ile

des

ign

ing

the

IID

R16

.U

sega

tew

ays

bet

wee

nst

and

ard

vers

ion

sD

R17

.U

sega

tew

ays

bet

wee

nla

yers

DR

18.

Bu

ild

gate

way

sb

etw

een

infr

astr

uct

ure

sD

R19

.D

evel

op

tran

siti

on

stra

tegi

esin

par

alle

lw

ith

gate

way

s


simple, cheap and easy to learn (DR3). Here cheap isdefined in relation to both design and learning costs.Simple means that the design covers only the essentialfunctionality expected and the capability is designed so thatit is easy to integrate the IT capability with the installedbase. Significant user investments cannot be expectedbecause a small user base does not contribute either tothe demand or the supply side economies of scale.

IT capabilities have varying impacts on the scale ofincreasing returns and the amount of positive feedback.They vary significantly between capabilities where every userinteracts symmetrically with every user (like e-mail) andcapabilities where one user interacts uni-directionally withthe rest. Capabilities can also have multiple possibleimplementation sequences. In general, IT capabilitiessupporting asymmetrical interactions (one-to-many) andthus less dependent on network effects should be imple-mented first as the growth can be promoted locally (DR4).These capabilities have lower adoption barriers as they donot need to reach a critical mass to generate fast adoption.

The Internets success has been widely attributed to itssuccessful bottom-up bootstrapping (Leiner et al., 1997;Abbate, 1999; Tuomi, 2002; Kahn, 2006). Though early onInternet designers built bold scenarios of how the future oftelecommunications would unfold (Tuomi, 2002), the earlyuses of packet switching were targeted to small groups ofresearchers, who were interested in accessing powerful andexpensive computers (DR1). The aim was to provide alimited range of directly useful IT capabilities: remote loginand file transfer (DR1). Among these capabilities, remote

login was a perfect choice, because each user could adopt itindependently from others and users had the skills andmotivation to do so (DR3, DR4). While the number of usersgrew, they could start share data through file transfer. Lateron, new capabilities have been introduced in the same way(DR2). E-mail, for instance, was originally developed tosupport communications between persons responsible formaintaining the network when only four computers wereconnected to it (Abbate, 1999) (DR1 and DR2). The designof transportation services (TCP) followed also an evolu-tionary approach as multiple versions of increasinglycomplete protocols for TCP and IP were implemented inthe early 1980s (DR3).

Design rules for principle #2: build on installed bases:The second principle promotes connections with theexisting installed base during design time. The II designershould thus design toward existing support infrastructuresthat the targeted user groups use (DR5). If an IT capabilityis designed so that it requires a new support infrastructure,this will erect heightened adoption barriers as, per ourdefinition, the support infrastructure will be sui generis anII, which then needs to be bootstrapped with high learningbarriers (Attewell, 1992). As noted, transport infrastruc-tures form the base for implementing II while the need forservice infrastructures depends on the size and sophistica-tion of application capabilities, or the size of installedbase. While the installed base remains small, the II doesnot need advanced service infrastructures. The II designer

Table 4 Internet as an II

Internet as an II

Structural propertiesOrganizingprinciples

Internet is composed of multiple layers of distinct IT capabilities that carry out similarfunctions at different layers (e.g. transport and application layer). It consists of or drawsupon multiple platforms, IT capabilities and social groups that design, implement andmaintain its functionality.

Control The control of Internet design is distributed among a large set of designers, user communitiesand forms of governance. The control of different capabilities is separated and distributedand the control forms are loosely coupled through architectural principles. Control formsvary among different communities (IETF, W3C or OASIS) as well as governance structures(Nickerson and Zur Muehlen, 2006; Russell, 2006).

Emergent propertiesShared Shared by an increasingly growing number of heterogeneous user communities, designers,

regulators and other social actors.

Open Any new IT capability, designer or user group can be added as long as it conforms to thearchitectural principles of Internet and thus abstracts data transfer into a transfer of datastreams to a specified set of IP addresses.

Heterogeneous Internet has grown immensely in heterogeneity both socially and technically since its inceptionand during its exponential growth.

Evolving Evolving set communication and distributed computing capabilitiesFor any set of users at any time Internet is seen as a distinct set of capabilities(telnet, ftp, smtp, http, etc.) that are available. Internet evolves because this set hasgrown significantly during its evolution integrating new users and design communities.


Table

5DesignprinciplesandrulesforInternet

Challenge:Bootstrapproblem

Designprinciple

Designrules

Followed

Evidence

from

Internet

designhistory

1.D

esig

nin

itia

lly

for

use

fuln

ess

DR

1.T

arge

tIT

cap

abil

ity

toa

smal

lgr

ou

p|

Des

ign

edo

rigi

nal

lyas

asu

pp

ort

cap

abil

ity

for

Def

ense

Ad

van

ced

Res

earc

hP

roje

cts

Age

ncy

(DA

RP

A)

rese

arch

ers

tosh

are

exp

ensi

vean

dce

ntr

aliz

edco

mp

uti

ng

reso

urc

esD

R2.

Mak

eIT

cap

abil

ity

dir

ectl

yu

sefu

lw

ith

ou

tan

inst

alle

db

ase

|D

esig

ned

asap

pli

cati

on

for

log

inan

dfi

led

ow

nlo

ads

Th

ed

evel

op

edIT

cap

abil

ity

was

wel

lsu

ited

for

exp

erim

enti

ng

wit

hd

istr

ibu

ted

Un

ixan

dL

AN

tech

no

logi

es,

inw

hic

ho

rigi

nal

lyre

ach

ing

larg

ein

stal

led

bas

ew

asn

ot

anis

sue

DR

3.M

ake

the

ITca

pab

ilit

ysi

mp

leto

use

and

imp

lem

ent

|O

bta

inex

per

ien

ceb

ased

on

the

use

of

sim

ple

pro

toty

pes

and

cap

abil

itie

s.T

his

has

bee

nan

imp

ort

ant

des

ign

pri

nci

ple

inth

eIn

tern

etco

mm

un

ity,

inp

arti

cula

rd

uri

ng

the

earl

yad

op

tio

n(L

ein

eret

al.

,19

97;

Ab

bat

e,19

99)

DR

4.D

esig

nfo

ro

ne-

to-m

any

ITca

pab

ilit

ies

inco

ntr

ast

toal

l-to

-all

|R

emo

telo

gin

asa

firs

tca

pab

ilit

y

2.B

uil

du

po

nex

isti

ng

inst

alle

db

ases

DR

5.D

esig

nIT

cap

abil

ity

that

do

esn

ot

dep

end

on

new

sup

po

rtin

fras

tru

ctu

re|

Ap

rin

cip

ald

esig

nru

lein

imp

lem

enti

ng

the

TC

P/I

Pp

roto

col

stac

kw

asto

mak

eit

run

on

top

of

mu

ltip

leu

nd

erly

ing

ph

ysic

alac

cess

laye

rs:t

elep

ho

ne,

rad

io,

sate

llit

e,L

AN

tech

no

logi

es,

etc.

(Ab

bat

e,19

99)

DR

6.D

eplo

yex

isti

ng

tran

spo

rtin

fras

tru

ctu

res

|A

llea

rly

cap

abil

itie

sw

ere

intr

od

uce

dw

ith

ou

tan

yn

ewre

late

dtr

ansp

ort

infr

astr

uct

ure

sD

R7.

Bu

ild

gate

way

sto

exis

tin

gse

rvic

ean

dap

pli

cati

on

infr

astr

uct

ure

s|

Gat

eway

sw

ere

dev

elo

ped

for

exam

ple

too

ther

e-m

ail

pro

toco

lsan

do

ther

ITca

pab

ilit

ies.

Rec

entl

yga

tew

ays

(e.g

.C

GI)

tod

atab

ases

and

app

lica

tio

nca

pab

ilit

ies

hav

eb

een

imp

ort

ant

inm

akin

gW

eb-s

ervi

ces

use

ful

DR

8.U

seb

and

wag

on

sas

soci

ated

wit

ho

ther

IIs

|D

uri

ng

the

1980

s,In

tern

etin

crea

sed

its

acce

pta

nce

wit

hth

ed

iffu

sio

no

fw

ork

stat

ion

/Un

ix/L

AN

tech

no

logi

es3.

Exp

and

inst

alle

db

ase

by

per

suas

ive

tact

ics

toga

inm

om

entu

mD

R9.

Use

rsb

efo

refu

nct

ion

alit

y|

Man

yIn

tern

etca

pab

ilit

ies

hav

eb

een

add

edw

hen

thei

rn

eed

sh

ave

bee

nre

cogn

ized

.T

he

dev

elo

pm

ent

of

TC

P/I

Pan

dit

sn

ewve

rsio

ns

IPv6

,th

ein

tro

du

ctio

no

fD

NS,

enh

ance

men

to

fth

ew

ebb

yX

ML

and

CC

Sar

eex

amp

les

of

this

DR

10.

En

han

ceth

eIT

cap

abil

ity

wit

hin

the

IIo

nly

wh

enn

eed

ed|

Inte

rnet

off

ered

low

cost

and

inn

ova

tive

way

sfo

rm

any

scie

nti

fic

and

engi

nee

rin

gco

mm

un

itie

sto

com

mu

nic

ate

and

shar

ein

form

atio

nan

db

uil

das

soci

ated

serv

ices

.Im

po

rtan

tal

lies

wer

ere

sear

chfu

nd

ing

agen

cies

and

rese

arch

com

mu

nit

ies

DR

11.

Bu

ild

and

alig

nin

cen

tive

sas

nee

ded

|D

evel

op

men

tan

du

sein

tert

win

edto

bu

ild

com

mu

nit

ies.

Ala

rge

com

mu

nit

y(c

riti

cal

mas

s)w

as,

e.g.

,b

uil

to

rigi

nal

lyto

lear

nfr

om

dis

trib

ute

dco

mp

uti

ng.

Th

esa

me

app

lies

toW

eb,

Inst

ant

mes

sagi

ng

or

mu

ltic

asti

ng

DR

12.

Dev

elo

psu

pp

ort

com

mu

nit

ies

|D

evel

op

ers

and

use

rsar

eb

oth

inn

ova

tors

for

ITca

pab

ilit

ies

and

org

aniz

edsu

pp

ort

com

mu

nit

ies

tod

oso


Table

5Continued

Challenge:Bootstrapproblem

Designprinciple

Designrules

Followed

Evidence

from

Internet

designhistory

4.M

ake

the

des

ign

of

ITca

pab

ilit

yas

sim

ple

asp

oss

ible

DR

13.

Mak

eth

eII

inte

rms

of

its

tech

nic

alan

dso

cial

com

ple

xity

assi

mp

leas

po

ssib

le

|T

his

rule

was

exp

lici

tly

stat

edea

rly

on

(RF

C,1

994)

and

has

bee

nim

po

rtan

tth

rou

gho

ut

the

des

ign

his

tory

of

the

Inte

rnet

DR

14.

Pro

mo

tep

artl

yo

verl

app

ing

ITca

pab

ilit

ies

inst

ead

of

all-

incl

usi

veo

nes

|T

his

rule

isen

able

db

yth

ep

rin

cip

leth

atst

and

ard

sar

eo

pen

and

any

on

eca

nd

esig

nat

the

edge

new

fun

ctio

nal

ity

resu

ltin

gin

mu

ltip

leo

verl

app

ing

cap

abil

itie

s5.

Mo

du

lari

zeth

eII

DR

15.

Div

ide

infr

astr

uct

ure

recu

rsiv

ely

into

tran

spo

rtat

ion

,su

pp

ort

and

app

lica

tio

nin

fras

tru

ctu

res

|T

he

arch

itec

tura

lp

rin

cip

leo

fe

nd

-to

-en

d

arch

itec

ture

that

pro

mo

tes

ind

epen

den

cean

dm

od

ula

riza

tio

n(D

avid

,20

01)

Inte

rnet

isco

mp

ose

do

fa

larg

en

um

ber

of

sep

arat

eca

pab

ilit

ies,

sub

-in

fras

tru

ctu

res

that

are

esta

bli

shed

and

op

erat

edb

yin

dep

end

ent

acto

rsin

clu

din

gIS

Ps,

etc.

DR

16.

Use

gate

way

sb

etw

een

spec

ific

atio

nve

rsio

ns

|T

he

par

adig

mat

icex

amp

leo

fth

isis

the

use

of

tun

nel

ing

inth

etr

ansi

tio

nfr

om

vers

ion

4to

6o

fth

eIP

pro

toco

lD

R17

.U

sega

tew

ays

bet

wee

nla

yers

|T

his

isk

eyar

chit

ectu

ral

pri

nci

ple

of

Inte

rnet

that

sep

arat

esap

pli

cati

on

s,tr

ansp

ort

,ad

dre

ssin

gan

dp

hys

ical

con

nec

tio

ns.

All

thes

ela

yers

are

con

nec

ted

thro

ugh

op

enga

tew

ays

DR

18.

Bu

ild

gate

way

sb

etw

een

infr

astr

uct

ure

s|

Th

isw

aso

rigi

nal

lyu

sed

toco

nn

ect

dif

fere

nt

net

wo

rks

(BIT

NE

T,

Dec

net

)w

ith

Inte

rnet

e-m

ail

pro

toco

ls.

Th

esa

me

too

kp

lace

wit

hA

OL

and

Pro

gid

yD

R19

.D

evel

op

tran

siti

on

stra

tegi

esin

par

alle

lw

ith

gate

way

s|

Co

nsi

der

atio

no

ftr

ansi

tio

nst

rate

gies

isca

refu

lly

intr

od

uce

din

toth

en

ewve

rsio

ns

of

the

pro

toco

lsp

ecif

icat

ion

s


should therefore design toward the simplest possible serviceinfrastructure (DR6). Next, capabilities associated withseparate service and application infrastructures should beconnected, when possible, through gateways increasingconnections between isolated user communities and benefit-ting adopters with larger positive network effects (DR7). Asthe designers link the new IT capabilities to the existing IIs,they need to take into account the speed and direction of theadoption of IT capabilities in neighboring infrastructures,and capitalize on their bandwagon effects (DR8).

The Internets early success resulted from exploitingestablished infrastructures as transport infrastructures(DR5) when TCP/IP was first implemented using modemsover the telephone lines (Abbate, 1999). In addition, eachadopted capability has served to develop more advancedcapabilities (Abbate, 1999) (DR6). Currently, the Internetprovides, for example, capabilities for electronic commerceincluding transaction support (e.g. EbXML10), identificationsupport (e.g. digital certificates) or security (e.g. SET) builtas separate capabilities on top of TCP/IP and http (Farajet al., 2004; Nickerson and Zur Muehlen, 2006). Anotherexample is the initial growth of Internets service infra-structures (DR6). In the beginning there was none and theirneed was discovered later when new service capabilitiesstarted to grow. Yet, the scale of Internet was still relativelysmall so that it was easy to design DNS capabilities and linkit to a (now) stable transportation infrastructure. Later onDNS became critical as it increased flexibility of usethrough the management of dynamic IP addresses (DHCP).The Internet designers have also increased the installedbase through gateways (DR7). The expansion of the Webfunctionality is a case in point. The Web was originallythought to be useful for static information provisioning sothat HTML tagged files could be downloaded using the httpprotocol (Tuomi, 2002). A significant added value for Webwas created by building gateways that leveraged upon dataresiding in organizational databases. This added dynamicor deep web features: a call to data base could be nowembedded in HTML as defined by Common GatewayInterface (CGI) specifications,11 and later expanded withJava standards (RMI12).

Design rules for principle #3: expand installed base withpersuasive enrollment tactics: After establishing the firstattractor (usefulness), the II designers have to sustaingrowth. Therefore, when a simple version of the ITcapability is available, the II designer needs to seek asmany users as possible (DR9). This principle is capturedwell in a slogan: users before functionality emphasizingthe criticality of generating positive network effects: the ITcapability derives its value from the size of its user base not from its superior functionality. New functionalityshould be added only when it is truly needed, and theoriginal capability obtains new adoption levels so that theproposed capability will have enough users willing to coverthe extra cost of design and learning (DR10). Many timesuseful new functionality emerges when users start deploythe IT capability in unexpected ways through learning bydoing and trying, or re-organizing the connections betweenthe user communities and the IT capability (DR11). Agrowing installed base urges II designers to find means to

align heterogeneous user interests and persuade them tocontinue to participate in the II. One approach is to use theinstalled base as a source of useful learning by creating usercommunities that offer feedback. This helps introduce newcapabilities based on feedback and unexpected actorinteractions (DR12) (Tuomi, 2002; Zimmerman, 2007).

Many capabilities during Internet design were estab-lished at times when the capabilities could be expected towork satisfactorily and serve a useful purpose (DR9). As aresult increasingly sophisticated application capabilitiesemerged including Gopher (Minnesota), WAIS (Cambridge,Mass) and irc (University of Oulu) (Rheingold, 1993). As aresult Internet has grown over the years enormously interms of new services and protocols. Typically thesecapabilities emerged as local community responses to anidentified local need (DR10), and only a tiny fraction of theInternets current protocol stack was part of the initialspecifications (DR10). Main reason for this was that mostinnovations took place at the edge as design capability andapplication functionality were early on moved to thenetwork boundary. New capabilities could be conceivedand tried out whenever a user with a problem and enoughtransportation capability could leverage upon the newfunctionality (Tuomi, 2002). Internet was also widelyadopted by computer science and associated engineeringcommunities as their research-computing infrastructure(DR11 and DR12). The open packet switching standardsturned out to be perfectly suited for the research visionshared by this movement (Kahn, 2006).

Design rules for the adaptation problemWhen the bandwagon starts rolling, the II designers need toguarantee that the II will grow adaptively and re-organizeconstantly with new connections between II components.Ad hoc designs, which were originally created for earlyusers will now threaten to create technology traps. Ifdesigners continue to generate highly interdependent andlocal IT capabilities, the whole system will becomeinflexible and reach a stasis. In contrast, if IT capabilitiesare organized modularly through loosely coupled layers,which can change independently, this will generate highercomponent variation for successful adaptation. The follow-ing two design principles decomposed into seven rules offerguidance to promote modularity.

Design rules for principle #4: make the organization of ITcapabilities simple: The first principle asks for the use ofsimple architectural principles during the initial design ofthe IT capabilities (DR13). It is easier to change somethingthat is simple than something that is complex. What makesa collection of IT capabilities simple or complex is afunction of its technical complexity as defined by thenumber of its technical elements, their connections and rateof change (Edwards et al., 2007). Therefore followinginformation hiding, simple interface protocols and func-tional abstraction can help make the design simple. But,just as important is it to recognize the socio-technicalcomplexity of the design space: the number and type ofconnections between technical and the social elements. Inthe lingo of Actor Network Theory (Latour, 1999) the actornetwork constituted by the II, that is its data elements, use


practices, specifications and their discovery and enforce-ment practices, the relationships to other infrastructures,the multiplicity of developers, the role of organizations, thevariety of users, the regulatory bodies etc. and a myriad oflinks between all affect what can be changed and how (Starand Ruhleder, 1996; Latour, 1999). Simpler actor networkscan be created by making them initially as small as possible,and keeping them loosely connected, and avoidingconfrontations with competing networks. This is achievedby pursuing separate specifications for distinct domainsand separating the concerns of different social andtechnical actors through functional abstraction (Tilson,2008). Limiting the functional scope of application infra-structures to a minimum keeps the related infrastructuresseparate. Decomposing service IIs into a set of layers andseparating their governance achieves the same goal. Theseprinciples decrease the technical complexity of specifica-tions but, more importantly, reduce their social complexity.Finally, designs should promote partly overlapping ITcapabilities instead of all-inclusive ones. This increasesvariance and stimulates innovation at different pockets bymaking it operate at the edge of chaos (DR14).

The principles of early Internet design promotedsimplicity (DR13). Its protocols were lean and simple, andtherefore had less ambiguity and errors. As a result theimplementations were simpler, and easier to test andchange. Origins of this approach date back to early designs,which confronted early on the challenge of how to promotechange, but at the same time to avoid technology traps. Thiswas expressed early in the Internets specification approach:

From its conception, the Internet has been, and isexpected to remain, an evolving system whose partici-pants regularly factor new requirements and technologyinto its design and implementation. (RFC, 1994: 6)

This vision was opposite to traditional design strategiesin the telecommunication industry followed in the design ofthe ISO/OSI protocol stack where designers assumed onehomogeneous, complete and controllable network, whichhad to be completely specified (Abbate, 1999; Russell, 2006).This difference was later at the center of the controversybetween the Internet community and the ISO/OSI commit-tee (Schmidt and Werle, 1998; Russell, 2006). The OSIstandardizers argued that Internet lacked critical functions;in contrast, the Internet community advocated technicalsimplicity and pragmatic value. As Kahn observed:

So the only way that you could ever get anything to be astandard was: you had to have built it first; it had to bedeployed; and basically, people would speak by adoption.So the things that became standard y were the thingsthat were starting to become in widespread use and theywould eventually become standards when they werealready used. This is the equivalent of ratification afterthe fact, the standard is simply a means of ratifying whathas become in widespread use y a very differentapproach than specifying upfront and hoping people willbuild it. (Kahn, 2006)

Many scholars have attributed the demise of the OSIto its disregard to this pragmatic approach (Rose, 1992;

Stefferud, 1994). Finally, Internet always promoted designsthat were partly overlapping increasing variety. Forexample it has generated several transportation protocols,e-mail protocols, information distribution protocols and soon (DR14).

Design rules for principle #5: modularize the II: As noted, IIdesigners need to organize modularly capabilities intoloosely coupled sub-infrastructures (Parnas, 1972; Baldwinand Clark, 2000). Therefore, IIs should be decomposedrecursively into separate application, transport and servicesub-infrastructures (DR15). Each II interface must hidemechanisms that implement these capabilities as tomaintain loose couplings between the connected IIs. IIsneed to be also decomposed vertically into independentneighboring application infrastructures, and II designersneed to build gateways to connect them. Consequently,gateways must connect regions of II that run differentversions of the same IT capabilities (DR16), or betweendifferent IT capability layers, for example, transport orservice (DR17), or between several dedicated applicationinfrastructures (DR18) (Edwards et al., 2007). Finally,transitions between incompatible IT capabilities need tobe supported by navigation strategies that allow localchanges in different versions of the IT capability that runon the current installed base (DR19).

One reason for the speed of innovation in Internet was itsinitial modular design (DR15) (Tuomi, 2002). The Inter-nets simple end-to-end architecture, which puts theintelligence into the end nodes, has proven to be a criticalfor its adaptive growth (DR15, DR16, DR17) (Abbate, 1999;David, 2001). The design stimulated continued localapplication or service infrastructure innovation laid ontop of separate transportation infrastructure of TCP/IP orUDP (DR15) (Rheingold, 1993; Tuomi, 2002). Each of thesecapabilities was designed independently and its designdecisions were insulated from potential changes in theunderlying transport infrastructures. They were alsogoverned separately.13 The erection of the W3C andgovernance of the web service community forms a case inpoint (Berners-Lee and Fischetti, 1999). Gateways continueto play a critical role in the evolution of Internet andextensive use of gateways has prevented designers to actlike blind giants, and made early decisions easier toreverse (Hanseth, 2001). Multiple gateways prevail, forinstance, between the Internets e-mail service and pro-prietary e-mail protocols (DR17). Another important familyof gateways has been built between the Internets accessservices and organizations applications and databasesthrough web servers (DR18). Over the years Internetprotocols have been revised and extended (DR16, DR19).One example is the revision of the transportation protocolfrom IPv4 to IPv6. The need to add new capabilities whileattempting to overcome installed base inertia has been amajor design challenge (RFC, 1994; Monteiro, 1998; Hovavand Schuff, 2005). Between 1974 and 1978, four versions ofthe IP protocol were developed in fast experimental cyclesuntil IPv4 was released (Kahn, 1994). For the next 15 yearsIPv4 remained stable. In the early 1990s Internets addressspace was expected to run out due to the Internetsexponential growth. Moreover, the addressing scheme in


IPv4 did not support multicasting and mobility. Thistriggered a new round of designs to deliver a new IP versioncalled IP version 6.14 The final version, however, fulfilledonly few of the original requirements the most importantone being the extension of the reverse salient addressspace to awesome 2128 addresses.15 The most importantcriterion in accepting the final specifications was indetermining mechanisms that would introduce the newversion in a stepwise manner (DR19), though initially thiswas not at all in the requirements (RFC, 1995; Steinberg,1995; Hovav and Schuff, 2005).16

Concluding remarksTodays IT systems involve complexity that extends beyondwhat can be addressed by traditional design approaches.Accordingly, we need to theorize in fresh ways how todesign complex IT systems. To this end we have formulateda design theory based on CAS theory that tackles IIsdynamic complexity. The theory was derived by scrutiniz-ing design histories of large infrastructures, a review of CAStheory principles and illustrated by the analysis of Internetexegesis. The theory formulation follows an approachsimilar to Lindgren et al. (2004), and Markus et al.(2002). By formulating this design theory we make acontribution to IS Design and Software Engineeringresearch on how to develop large and complex ICTsolutions viewed as IIs. We do so by drawing extensivelyon prior research on II evolution and soliciting theempirical insights into a coherent design theory.

The proposed theory defines its unit of analysis, itsessential properties and related kernel theory CAS as toderive five design principles, and19 design rules. Itrecognizes and draws upon earlier research on IIs (Kling,1992; Star and Ruhleder, 1996) by observing pivotalrelationships between technical and social elements, andtheir dynamic interactions. In contrast to earlier II research(Freeman, 2007; Zimmerman, 2007), the proposed theoryadopts the viewpoint of designers: how to cultivate aninstalled base and promote its dynamic growth byproposing design rules for II bootstrapping and adaptivegrowth. Opposed to other design theories and methodol-ogies, which are all design from scratch approaches, ourdesign theory puts the installed base at the center: IIdevelopment is about how to create a self-reinforcinginstalled base by drawing upon existing ones, and how toavoid being trapped by the force of the installed base.

All theories are incomplete (Weick, 1989) and so is ourproposed theory. Hence, the key question is not to askwhether the proposed theory is incomplete (as it will be),but rather: what are the implications of its limits? We willaddress this in two ways: (1) how to address incompletenessin the scope of our theoretical formulation, (2) and how toimprove consequently its external validity. We drew uponCAS as to account for the feedback-based growth withincomplex socio-technical systems. The principles thatunderlie CAS are widely accepted as illustrating howcomplex systems evolve. Our contribution has been torevise CAS into a form that can be utilized in designthinking in the context of IIs. In doing so we drew uponextant II and other literatures to propose a set of falsifiabledesign rules (Baldwin and Clark, 2000). Unfortunately,

our theory refinement still does not offer detailedrecommendations of how to decide in specific contingen-cies about II designs. We are confident that in somesituations the theory has limited applicability. For example,the design of IIs that necessitate single point coordinationthrough significant early inves