Cloud Computing Papers

!"#$%&!
#'($)*+,&
-& !#"".!)* #+& #/& 0#12* +,& (-(.13&
&
)4#'-3& 5& 0* +-+3& -+%& 6 #4+& 3.."7& 51#0+&
'-7& 899:
&
&
&

!"#$%&'($')*+,-./0%+1+2.3')*+4)(.5#6&'.)+7"89).-.*$+:-6&(.5#%+7.+79"+,-./0%+1+2.&'36&'.)+7.+;"3"56*"+,-./0+<)0+
="53'8"+>5'0+7"89).-.*'"%+
uLLCl11L CLn1L8 lC8 1PL LuCL
1homas 8 Wlnans and !ohn Seely 8rown age 2
!"#$%& !#'($)*+,& frequenLly ls Laken Lo be a Lerm LhaL slmply renames common Lechnologles and
Lechnlques LhaL we have come Lo know ln l1. lL may be lnLerpreLed Lo mean %-)-&./+)/0&1#2)*+, and Lhen
subsequenLly dlsmlssed wlLhouL caLchlng Lhe lmprovemenLs Lo hosLlng called $)*"*)3& .#'($)*+, LhaL
permlL near realLlme, pollcy-based conLrol of compuLlng resources. Cr lL may be lnLerpreLed Lo mean #+"3&
%-)-&./+)/0&1#2)*+, raLher Lhan undersLood Lo be Lhe slgnlflcanL shlfL ln lnLerneL appllcaLlon archlLecLure
LhaL lL ls.
erhaps lL ls Lhe name. CerLalnly lL ls more +/4$"#$2 Lhan '+/'#+*., lf you'll pardon Lhe poor pun. We
happen Lo Lhlnk so Loo. We'd raLher use Lhe Lerm 2/05*./& ,0*%, frankly, buL LhaL name also has lLs
problems. 1he facL ls LhaL ."#$% and 2/05*./& ,0*%& .#'($)*+, are paradlgmaLlcally dlfferenL from Lhelr
common lnLerpreLaLlons, and Lhelr use can shed llghL on how lnLerneL archlLecLures are consLrucLed and
managed.
Cloud compuLlng represenLs a dlfferenL way Lo archlLecL and remoLely manage compuLlng resources. Cne
has only Lo esLabllsh an accounL wlLh MlcrosofL or Amazon or Coogle Lo begln bulldlng and deploylng
appllcaLlon sysLems lnLo a cloud. 1hese sysLems can be, buL cerLalnly are noL resLrlcLed Lo belng,
slmpllsLlc. 1hey can be web appllcaLlons LhaL requlre only hLLp servlces. 1hey mlghL requlre a relaLlonal
daLabase. 1hey mlghL requlre web servlce lnfrasLrucLure and message queues. 1here mlghL be need Lo
lnLeroperaLe wlLh C8M or e-commerce appllcaLlon servlces, necesslLaLlng consLrucLlon of a cusLom
Lechnology sLack Lo deploy lnLo Lhe cloud lf Lhese servlces are noL already provlded Lhere. 1hey mlghL
requlre Lhe use of new Lypes of perslsLenL sLorage LhaL mlghL never have Lo be repllcaLed because Lhe
new sLorage Lechnologles bulld ln requlred rellablllLy. 1hey mlghL requlre Lhe remoLe hosLlng and use of
cusLom or 3
rd
parLy sofLware sysLems. And Lhey mlghL requlre Lhe capablllLy Lo programmaLlcally lncrease
or decrease compuLlng resources as a funcLlon of buslness lnLelllgence abouL resource demand uslng
vlrLuallzaLlon. Whlle noL all of Lhese capablllLles exlsL ln Loday's clouds, nor are all LhaL do exlsL fully
auLomaLed, a good porLlon of Lhem .-+ be provlsloned.
60/&)1/&2/05*./2&)1-)&-0/&(0#5*%/%&43&)1/&."#$%&0#4$2)&*+&)1/&/+)/0(0*2/&2/+2/7
AbsoluLely . especlally lf you mean )1/& /+)/0(0*2/& -2& 8/& 9+#8& *)& )#%-3. Whlle Lhere are lmporLanL
securlLy, prlvacy and regulaLory lssues LhaL enLerprlses need Lo sorL Lhrough before full mlgraLlon Lo Lhe
cloud, and cloud vendors need Lo sLrengLhen cloud capablllLles ln Lhese areas before enLerprlse
appllcaLlons can be effecLlvely hosLed ln Lhe cloud, Lhere are beneflLs LhaL cloud Lechnologles %# offer
Loday LhaL can be leveraged ln Lhe deploymenL of many enLerprlse appllcaLlons. lurLher, cloud vendors
are llkely Lo offer 5*0)$-"& (0*5-)/& ."#$% funcLlonallLy LhaL qulLe posslbly wlll (aL leasL Lemporarlly)
compensaLe for currenL deflclencles as cloud vendors work Lo address Lhem ln a more sLraLeglc and long-
Lerm way.
MlgraLlon Lo Lhe cloud wlll noL be lmmedlaLe because of lssues noLed above, and because enLerprlses
need Lo approach mlgraLlon ln a sLaged fashlon, [usL as Lhey would underLake any slgnlflcanL Lechnology
LranslLlon. 1he flrsL sLage of mlgraLlon ls Lo deLermlne whaL enLerprlse lnfrasLrucLure and appllcaLlons can
be rellably rearchlLecLed uslng cloud compuLlng Lechnologles Loday Lo galn experlence wlLh a cloud-
orlenLed way of organlzlng and accesslng dlglLal Lechnology. 1hls sLage may lnclude developmenL of a
mlgraLlon paLh LhaL progresslvely LranslLlons more of Lhe enLerprlse lnfrasLrucLure and appllcaLlons Lo
cloud provlders as Lhey evolve more robusL servlces LhaL can supporL a broader range of enLerprlse l1
acLlvlLles. 1he key goal of Lhls sLage ls Lo deflne Lhe roadmap Lo repllcaLe whaL ls avallable on premlse
Loday uslng cloud Lechnologles (publlc or prlvaLe) where Lhls makes sense, and Lo deflne fundamenLals
LhaL wlll gulde fuLure archlLecLure efforLs. 1he second sLage beglns a perlod ln whlch expllclLly pollcy
based archlLecLures LhaL help Lo supporL aglllLy and lnnovaLlon are deslgned. 1he Lhlrd sLage ls Lhe perlod
ln whlch lmplemenLaLlon of Lhese fundamenLally new archlLecLures - LhaL are deslgned Lo supporL
scalable neLworks of relaLlonshlps across large numbers of very dlverse and lndependenL enLlLles (l.e.,
posslbly leveraglng a more fully developed servlce grld) - Lakes place.
lL ls crlLlcal Lo glve expllclL aLLenLlon Lo archlLecLure when preparlng Lo mlgraLe Lo Lhe cloud, slnce Lhls
represenLs an opporLunlLy for corporaLlons Lo rearchlLecL Lhemselves as +/:)& ,/+/0-)*#+& /+)/0(0*2/2.
1hese globallzed and dlsLrlbuLed enLerprlses musL scale process and pracLlce neLworks (ulLlmaLely
1homas 8 Wlnans and !ohn Seely 8rown age 3
comprlslng an enLlre ecosysLem) Lo lnclude Lhousands Lo Lens of Lhousands of members, wlLh Lhe number
of users lncreaslng Lo Lhe mllllons. 1hls Lype of scale requlres an archlLecLure and lnLeroperablllLy sLraLegy
modulaLed by !"#$%&'()*+ ,)-!&%.%/0+ "&*+ 123'&)33+ 4%.'-')3 Lo scale buslness elasLlcally. Wldespread
adopLlon of clouds as a compuLlng plaLform wlll requlre lnLeroperablllLy beLween clouds and managemenL
of resources ln one cloud by anoLher. Slnce currenL-day archlLecLures are noL sLrucLured Lo exLernallze
pollcy, Lhe Lyplcal archlLecLure fundamenLals of appllcaLlons LhaL enLerprlses deploy musL be modlfled Lo
effecLlvely use and explolL new cloud capablllLles.
ln Lhls conLexL, we urge execuLlves Lo develop more expllclL cloud compuLlng sLraLegles based on a more
expllclL and longer-Lerm vlew of Lhe llkely Lra[ecLorles of cloud compuLlng evoluLlon. 1here are
undoubLedly compelllng beneflLs Lo parLlclpaLlng ln clouds Loday. 8uL Lhe real power of cloud compuLlng
plaLforms sLems from Lhe poLenLlal over Llme Lo re-Lhlnk and re-deslgn l1 archlLecLures aL a more
fundamenLal level. Companles LhaL galn early experlence wlLh Lhls new lnfrasLrucLure wlll be ln Lhe besL
poslLlon Lo harness Lhese new archlLecLural approaches Lo re-shape Lhe broader buslness landscape.
1o seed Lhls efforL, we cull from varlous candldaLe deflnlLlons for boLh -.%2* and 3)#5'-)+/#'*+-%$42,'&/ a
seL of concepLs Lo be used as a LhoughLful framework of dlscusslon for whaL happens nexL ln lnLerneL-
based compuLlng. We presenL, here, a seL of Lhree papers LhaL dlscuss:
! CharacLerlsLlcs of whaL we belleve Lo be nexL generaLlon archlLecLures LhaL wlll supporL
subsLanLlve changes ln global enLerprlse consLrucLs and operaLlons,
! 1ransformaLlon from exlsLlng Lo nexL generaLlon archlLecLures Lo slmpllfy Lhe archlLecLures and
beLLer allgn Lhem wlLh Lhe buslnesses Lhey enable, and provlde Lhe means Lo exLernallze and
manage pollcy across all archlLecLure layers, and
! aln polnLs LhaL mlghL be ellmlnaLed alLogeLher by mlgraLlon+Lo nexL generaLlon archlLecLures.
We undersLand LhaL cloud and servlce grld compuLlng, ln Lhelr presenL sLaLe, do noL meeL all dlsLrlbuLed
compuLlng or enLerprlse needs. Powever, Lhey *% meeL many of Lhem ln a way LhaL wlll provlde a smooLh
LranslLlon Lo whaLever nexL generaLlon dlsLrlbuLed compuLlng becomes, and Lhey already are slgnlflcanLly
helpful ln modulaLlng Lhe Lechnology changes LhaL enLerprlses face Loday. 1he rapld pace aL whlch cloud
vendors are sysLemaLlzlng Lhelr plaLforms and aLLracLlng sLalwarL lndusLry supporLers and users conflrms
LhaL ecosysLems are formlng LhaL are based upon Lhe capablllLles LhaL cloud compuLlng enables. 1he
speed wlLh whlch Lhey are formlng sLrongly suggesLs LhaL cloud compuLlng wlll noL only meeL many of Lhe
needs of enLerprlse compuLlng as we have come Lo know lL, buL also could form Lhe dlglLal plaLform for a
shaplng sLraLegy
1
guldlng nexL generaLlon enLerprlses ln Lhelr mlgraLlon Lo and parLlclpaLlon ln such
ecosysLems. Pence our opLlmlsm of Lhlngs Lo come, and our conLrlbuLlon Lo a dlscusslon LhaL we hope
readers wlll flnd helpful.

1
Shaplng SLraLegy ln a World of ConsLanL ulsrupLlon, Parvard 8uslness 8evlew, by !ohn Pagel lll, !ohn Seely 8rown,
and Lang uavlson, CcL 2008
1A8LL Cl CCn1Ln1S
!"#$%&'($')*+,-./!%0+"12345678+,349:+;7:+%<5=6><+*56:+?5>@6A<>A95<B+
!"#$%&'(#!%") *+*
,"),'#%"%-!().$,-/)%.)-!"&) *+0
(1,$,(#/$!2#!(2)%.),"),'#%"%-!()2/$3!(/),$(1!#/(#'$/) 1-5
,$(1!#/(#'$/)2#45/) *+6
/7#/$",5)'2/$),"&),((/22)(%"#$%5)-,",8/-/"#) *+6
!"#/$,(#!%")(%"#,!"/$) *+9
/7#/$",5!:/&);%5!(4)-,",8/-/"#<;%5!(4)/"8!"/) *+=
WPA1 lS CLlC?? 1-9
'#!5!#4)(%-;'#!"8) *+*>
CLCuu CCMCSl1lCn 1-11
2/$3!(/)8$!&)?)#1/)@/"/.!#)?(&"C)#1/),'#%"%-!()/"&;%!"#) *+*0
(%"#,!"/$);/$-/,@!5!#4) *+*A
(5%'&)3/"&%$2),"&)3/"&%$)5%(B+!") *+*C
3!$#',5)%$8,"!:,#!%"2),"&)(5%'&)(%-;'#!"8) *+*C
(%"(5'&!"8)$/-,$B2) *+*6

#.D')*+')(.C#?&'.)+&",E).-.*$+F-?&(.C#%+&.+&E"+,-./!%0+'7B68@AB+'7A4+'&+
F3;AG45H+?5>@6A<>A95<+&5;7BG45H;A647+
!"#$%&'(#!%") 0+*
%'#2!&/+!"),"&)!"2!&/+%'#),$(1!#/(#'$/)2#45/2) 0+0
(5%'&2),"&)2/$3!(/)8$!&2) 0+A
,$(1!#/(#'$/)#$,"2.%$-,#!%") 0+C
#$,"2.%$-!"8),")/7!2#!"8),$(1!#/(#'$/) 0+C
Auu8LSSlnC A8CPl1LC1u8L LA?L8lnC Anu A81l1lCnlnC 2-3
Lx1L8nALlZlnC CLlC? 2-8
8LLAClnC ALlCA1lCn lunC1lCnALl1? Wl1P (CCMCSl1L) SL8vlCLS 2-10
2#,$#!"8).$%-)2($,#(1)?)-,4@/)/,2!/$)#%)&%D)@'#)2%-/#!-/2)1,$&)#%)2/55) 0+**
(%"(5'&!"8)$/-,$B2) 0+**

#.&'D?&'.)+&.+-"D"C?*"+,-./!+?)!+%"CD',"+*C'!+&",E).-.*'"%0+F;67+F467AB+
&@;A+,349:+?7:+%<5=6><+*56:B+?::5<BB+
ln18CuuC1lCn) 3-1
l1 Aln Cln1S) 3-2
Aln Cln1: uA1A CLn1L8 MAnACLMLn1) 3-2
Aln Cln1: A8CPl1LC1u8L 18AnSlC8MA1lCn/LvCLu1lCn (1PL 88CWnllLLu vS.
C8LLnllLLu CCnunu8uM)) 3-3
Aln Cln1: CLlC?-8ASLu MAnACLMLn1 Cl l1 LA1lC8MS) 3-5
(%"(5'&!"8)$/-,$B2E)#%)#1/)0*
2#
)(/"#'$4),"&)@/4%"&) 3-6

!
uLM?S1l l?lnC CLCuuS
LxLC8l nC CLCuu Anu SL8vl CL C8l u A8CPl 1LC1u8LS

1PCMAS 8 Wl nAnS Anu ! CPn SLLL? 88CWn
26 MA? 2009

l n18CuuC1l Cn
!"#$%& !#'($)*+, ls ln vogue. 8uL whaL ls lL? ls lL -$.) Lhe same Lhlng as #$).#$/0*+,& )12& 1#.)*+,& #3& 425&
6(("*06)*#+.? Why mlghL lL be useful and Lo whom? Pow does lL change Lhe fuLure of enLerprlse
archlLecLures? Pow mlghL clouds form Lhe backbone of LwenLy-flrsL-cenLury ecosysLems, vlrLual
organlzaLlons and, for a parLlcular example, healLhcare sysLems LhaL are Lruly open, scalable,
heLerogeneous and capable of supporLlng Lhe players/provlders 5#)1& 5*,& 6+%& .'6""? ln Lhe pasL, l1
archlLecLures Look alm aL Lhe enLerprlse as Lhelr endpolnL. erhaps now we musL radlcally ralse Lhe bar
by lmplemenLlng archlLecLures capable of supporLlng enLlre ecosysLems and, ln so dolng, enable Lhese
archlLecLures Lo scale boLh downward Lo an enLerprlse archlLecLure as well as upward and ouLward.
We see cloud compuLlng offerlngs Loday LhaL are sulLable Lo hosL enLerprlse archlLecLures. 8uL whlle Lhese
offerlngs provlde clear beneflL Lo corporaLlons by provldlng capablllLles complemenLary Lo whaL Lhey
have, Lhe facL LhaL Lhey can help Lo elasLlcally scale enLerprlse archlLecLures should noL be undersLood Lo
also mean LhaL slmply scallng ln Lhls way wlll meeL LwenLy-flrsL-cenLury compuLlng requlremenLs. 1he
archlLecLure requlremenLs of large plaLforms llke soclal neLworks are /6%*06""7 dlfferenL from Lhe
requlremenLs of a healLhcare plaLform ln whlch geographlcally and corporaLely dlsLrlbuLed care provlders,
medlcal devlces, paLlenLs, lnsurance provlders, cllnlcs, coders, and bllllng sLaff conLrlbuLe lnformaLlon Lo
paLlenL charLs accordlng Lo care programs, quallLy of servlce and PlAA consLralnLs. And Lhe requlremenLs
for boLh of Lhese are very dlfferenL Lhan Lhose LhaL provlslon .)/6*,1)8)1/#$,1& (/#02..*+, servlces
common ln Lhe flnanclal servlces lndusLry. Clouds wlll have Lo accommodaLe dlfferences ln archlLecLure
requlremenLs llke Lhose lmplled here, as well as Lhose relaLlng Lo characLerlsLlcs we subsequenLly dlscuss.
ln Lhls paper, we wanL Lo revlslL 6$)#+#'*0&0#'($)*+,, whlch deflnes a seL of archlLecLural characLerlsLlcs
Lo manage sysLems where complexlLy ls lncreaslng buL musL be managed wlLhouL lncreaslng cosLs or Lhe
slze of Lhe managemenL Leam, where a sysLem musL be qulckly adapLable Lo new Lechnologles lnLegraLed
Lo lL, and where a sysLem musL be exLenslble from wlLhln a corporaLlon ouL Lo Lhe broader ecosysLem and
vlce versa. 1he prlmary goal of auLonomlc compuLlng ls LhaL sysLems manage Lhemselves accordlng Lo an
admlnlsLraLor's goals. new componenLs lnLegraLe . efforLlessly ..."
i
. 9$)#+#'*0& 0#'($)*+, per se may
have been vlewed negaLlvely ln Lhe pasL years - posslbly due Lo lLs blologlcal meLaphor or Lhe 9: or '6,*08
16((2+.812/2 feel of mosL auLonomlc lnlLlaLlves. 8uL lnnovaLlons ln cloud compuLlng ln Lhe areas of
vlrLuallzaLlon and flner-gralned, conLalner-based managemenL lnLerfaces, as well as Lhose ln hardware
and sofLware, are demonsLraLlng LhaL Lhe goals of auLonomlc compuLlng can be reallzed Lo a pracLlcal
degree, and LhaL Lhey could be useful ln developlng cloud archlLecLures capable of susLalnlng and
supporLlng ecosysLem-scaled use.
1aklng an auLonomlc approach permlLs us Lo ldenLlfy core componenLs of an auLonomlc compuLlng
archlLecLure LhaL Cloud CompuLlng lnsLanLlaLlons have Lhus far placed llLLle emphasls on. We ldenLlfy
Lechnlcal characLerlsLlcs below LhaL musL noL be overlooked ln fuLure archlLecLures, and we elaboraLe
Lhem more fully laLer ln Lhls paper:
! An archlLecLure sLyle (or sLyles) LhaL should be used when lmplemenLlng cloud-based servlces
1homas 8 Wlnans and !ohn Seely 8rown age 1-2
! LxLernal user and access conLrol managemenL LhaL enables roles and relaLed responslblllLles LhaL
serve as lnLerface deflnlLlons LhaL conLrol access Lo and orchesLraLe across buslness funcLlonallLy
! An lnLeracLlon ConLalner LhaL encapsulaLes Lhe lnfrasLrucLure servlces and pollcy managemenL
necessary Lo provlslon lnLeracLlons
! An exLernallzed pollcy managemenL englne LhaL ensures LhaL lnLeracLlons conform Lo regulaLory,
buslness parLner, and lnfrasLrucLure pollcy consLralnLs
! uLlllLy CompuLlng capablllLles necessary Lo manage and scale cloud-orlenLed plaLforms
An Au1CnCMl C l8AML Cl Ml nu
Slnce a wldely accepLed lndusLry deflnlLlon of !"#$%& !#'($)*+, - beyond a relaLlonshlp Lo Lhe lnLerneL
and lnLerneL Lechnologles - does noL exlsL aL presenL, we see Lhe Lerm used Lo mean -#.)*+,&#/&-01%2013&
*+& 0+& 34)31+0"& %0)0& 53+)31 (someLlmes called *+/10.)1$5)$13& 0.& 0& .316*53), uLlllLy compuLlng (whlch
packages compuLlng resources so Lhey can be used as a uLlllLy ln an always-on, meLered, and elasLlcally
scalable way), plaLform servlces (someLlmes called mlddleware as a servlce), and appllcaLlon hosLlng
(someLlmes called sofLware or appllcaLlons as a servlce). All of Lhese ways seem - ln some way - rlghL, buL
Lhey are noL helpful Lo undersLand Lhe Lopology of a cloud, Lhe lmpacL LhaL Cloud CompuLlng wlll have on
deploymenL of buslness plaLforms, wheLher or noL Lhe buslness sysLem archlLecLure belng deployed ln
commerclal or prlvaLe daLa cenLers Loday wlll be effecLlve ln a cloud, or whaL archlLecLures should be
lmplemenLed for cloud-based compuLlng. nelLher do Lhey even begln Lo geL aL Lhe challenge of managlng
very large and dynamlc organlzaLlons, called 6*1)$0"&#1,0+*70)*#+. (Lo be deflned laLer ln Lhls paper), LhaL
reorlenL Lhlnklng abouL Lhe need for an archlLecLure Lo scale masslvely, and Lhe need Lo make parLs of an
archlLecLure publlc LhaL, Lo Lhls polnL, have been kepL prlvaLe.
1o saLlsfy Lhe requlremenLs of nexL cenLury compuLlng, cloud compuLlng wlll need Lo mean more Lhan
[usL exLernallzed daLa cenLers and hosLlng models. AlLhough archlLecLures LhaL we deploy ln daLa cenLers
Loday should be able Lo run ln a cloud8 slmply movlng Lhem lnLo a cloud sLops well shorL of whaL one
mlghL hope LhaL Cloud CompuLlng wlll come Lo mean. ln facL, Lackllng global-scaled collaboraLlon and
Lradlng parLner neLwork problems ln governmenL, mlllLary, sclenLlflc, and buslness conLexLs wlll requlre
more Lhan whaL currenL archlLecLures can readlly supporL. lor example:
! lL wlll be necessary Lo rapldly seL up a Lemporary collaboraLlon neLwork enabllng neLwork
members Lo securely lnLeracL onllne, where lnLeracLlon could lmply lnLeroperablllLy wlLh back
offlce sysLems as well as human-orlenLed exchanges - all ln a maLLer of hours. Lxamples LhaL
come Lo mlnd lnclude emergency medlcal scenarlos, global supply chalns and oLher buslness
process neLworks. ollcles deflnlng lnfrasLrucLure and buslness consLralnLs wlll be varled, so
pollcy musL be exLernal Lo, and musL lnLeracL wlLh, deployed funcLlonallLy. 1hese examples also
lmply Lhe need for lnLeroperablllLy beLween publlc and prlvaLe clouds.
! 8uslness lnLeracLlons have Lhe poLenLlal Lo become more complex Lhan personal LransacLlons.
8ecause Lhey are llkely Lo be formed as composlLe servlces, and because servlces on whlch Lhey
depend may be provlsloned ln mulLlple clouds, Lhe ablllLy Lo provlslon and unlformly manage
composlLe cloud servlces wlll be requlred, as wlll be Lhe ablllLy Lo ensure LhaL Lhese servlces
saLlsfy speclfled buslness pollcy consLralnLs.
! 1he way LhaL users and access conLrol are managed ln Lyplcal appllcaLlons Loday ls no longer
flexlble enough Lo express roles and responslblllLles LhaL people wlll play ln nexL-generaLlon
buslness lnLeracLlons. 8oles wlll be played by people ouLslde of or across corporaLe boundarles&ln
an onllne conLexL [usL as frequenLly as Lhey are lnslde. Access conLrol and Lhe managemenL of
roles and responslblllLles musL be exLernallzed from buslness funcLlonallLy so LhaL lL becomes
more feaslble Lo composlLe funcLlonal behavlor lnLo dlsLrlbuLed servlce-orlenLed appllcaLlons
LhaL can be governed by exLernallzed pollcy.
1hese conslderaLlons suggesL LhaL clouds wlll have Lo have 0)&"30.) Lhe followlng characLerlsLlcs
ii
:
! Clouds should be unlquely ldenLlflable so LhaL Lhey can be lndlvldually managed even when
comblned wlLh oLher clouds. 1hls wlll be necessary Lo dlsLlngulsh and harmonlze cloud buslness
and lnfrasLrucLure pollcles ln force.
! A cloud should be dynamlcally conflgurable: conflguraLlon should be auLomaLable ln varylng and
unpredlcLable, posslbly even evenL-drlven, condlLlons.
! SysLems managemenL Lechnologles for clouds musL lnLegraLe consLralnLs on buslness wlLh
consLralnLs on lnfrasLrucLure Lo make Lhem manageable ln aggregaLe.
o A cloud should be able Lo dynamlcally provlslon lLself and opLlmlze lLs own consLrucLlon
and resource consumpLlon over Llme.
o A cloud musL be able Lo recover from rouLlne and exLraordlnary evenLs LhaL mlghL
cause some or all of lLs parLs Lo malfuncLlon.
o A cloud musL be aware of Lhe conLexLs ln whlch lL ls used so LhaL cloud conLenLs can
behave accordlngly. lor example, lf clouds are composlLed, pollcy wlll have Lo be
harmonlzed across cloud boundarles, when ln mulLlLenanL mode, servlce level
agreemenLs may be used Lo deLermlne prlorlLy access Lo physlcal resources. AppllcaLlon
plaLforms Loday are unaware of Lhelr usage conLexL, buL buslness funcLlonallLy ln nexL-
generaLlon plaLforms wlll have Lo be managed wlLh conLexL ln mlnd.
! A cloud musL be secure, and lL musL be able Lo secure lLself.
1hese coarse-gralned characLerlsLlcs, someLlmes descrlbed as !"#$%$&'()($&*"#'%+, can be represenLed
ln Lhe form of flner-gralned archlLecLure drlvers LhaL are useful ln characLerlzlng sLeps #$-!./ an
auLonomlc compuLlng archlLecLure. Cloud CompuLlng offerlngs LhaL are avallable Loday share many of Lhe
same drlvers LhaL we have organlzed lnLo 012#3&2 and 4**5'(!#'$%) 6!%!+3&3%#) 7.'83.2 ln Lhe flgure
below.

numbered clrcles ln Lhe graphlc above denoLe drlvers LhaL are llsLed below:
0. ArchlLecLure sLaLe: no sysLems managemenL
1. SysLems and resources musL be ldenLlflable
2. SysLem and resources musL be manageable
3. ollcy-drlven secured access Lo Lhe sysLem and
managed resources musL be provlded
4. SysLem musL reallocaLe managed resources on
fallures as a funcLlon of pollcy
varlous sysLem-level condlLlons by pollcy
6. SysLem musL be managed llghLs-ouL ln a slngle
daLa cenLer conLexL
7. SysLems managemenL capablllLy musL scale
across clouds of Lhe same Lype
8. SysLems managemenL capablllLy musL scale
across clouds of dlfferenL Lypes, Lhese clouds
musL be managed unlformly whlle malnLalnlng
separaLe cloud ldenLlLles
varlous sysLem-level condlLlons as a funcLlon of
pollcy Lo accommodaLe real-Llme and buslness-
orlenLed usage paLLerns
10. SysLems managemenL pollcles are harmonlzed across
cloud boundarles
11. lL musL be posslble Lo lnLegraLe managemenL pollcles
of dlfferenL clouds
12. MonollLhlc appllcaLlons and LradlLlonal appllcaLlon
lnLegraLlons exlsL/are sufflclenL
13. AppllcaLlon plaLform musL be servlce orlenLed
14. AppllcaLlons are replaced wlLh buslness servlces
13. 8uslness servlces have secured access
16. An lnLeracLlon ConLalner
1
musL be used as !""#$%!&$'()
%'(&!$(*+ ln a slngle-LenanL envlronmenL
17. ollcles musL be consolldaLed and managed uslng a
slngle (posslbly federaLed) pollcy englne
18. SysLem musL reallocaLe managed buslness servlces on
varlous buslness-level condlLlons by pollcy Lo
accommodaLe real-Llme/baLch usage paLLerns
19. An lnLeracLlon ConLalner musL be used as
!""#$%!&$'()%'(&!$(*+ ln a mulLlLenanL
envlronmenL
20. 8uslness servlce and sysLems managemenL
pollcles are lnLegraLed
21. ArchlLecLure sLaLe: poslLloned as an auLonomlc
archlLecLure plaLform for vlrLual organlzaLlon-
orlenLed appllcaLlon sysLems
22. ArchlLecLure sLaLe: addlLlonal sLrucLural and
buslness consLralnLs poslLlonlng archlLecLure
plaLform as a servlce grld

1
ueflned ln Lhe nexL secLlon


1he graphlc shows Lwo paLhs Loward auLonomlc compuLlng LhaL ulLlmaLely converge aL an archlLecLure
polnL LhaL could supporL buslness ecosysLems and emergenL and fluld vlrLual organlzaLlons:
! 1he flrsL paLh, !"#$%&#' ()*)+%&%*$' ,-./%-#, beglns wlLh no sysLems managemenL, and ends
wlLh a sysLems managemenL capablllLy LhaL ls pollcy drlven, and LhaL enables auLomaLed sysLems
managemenL ln a cloud and harmonlzaLlon of buslness and lnfrasLrucLure pollcles wlLhln and
across cloud boundarles - ln boLh slngle- and mulLl-LenanL modes. 1he drlvers for sysLems
managemenL are grouped Lo lllusLraLe needs common Lo baslc sysLems managemenL (SysLems
ManagemenL CapablllLles), and needs LhaL go beyond baslc capablllLles (uLlllLy CompuLlng
ManagemenL and CuLslde-ln ArchlLecLure
iii
CapablllLles).
! 1he second paLh, 0112.3)$.4*#' ()*)+%&%*$' ,-./%-#, beglns wlLh common monollLhlc corporaLe
appllcaLlons. lL ends wlLh Lhese appllcaLlons havlng been replaced wlLh servlce-orlenLed ones,
where pollcy has been exLernallzed so LhaL buslness pollcles can be harmonlzed wlLh uLlllLy
managemenL pollcles, where lL ls posslble Lo lmplemenL end-Lo-end servlce level agreemenLs and
enforce conformance Lo buslness and regulaLory consLralnLs, and where Lhe use of buslness
funcLlonal and lnfrasLrucLural componenLs can be meLered and elasLlcally load balanced. AL Lhls
endpolnL, buslness servlces and lnfrasLrucLure can be organlzed lnLo a cloud and used ln boLh
slngle- and mulLlLenanL modes.
SysLems and AppllcaLlons ManagemenL urlvers paLhs converge aL Lhe polnL where lL ls necessary Lo
manage boLh Lhe buslness and Lhe lnfrasLrucLure uslng common managemenL capablllLles, and where
relaLed pollcles &5#$ be harmonlzed.
resenLlng drlvers on paLhs ls someLlmes rlsky, as such suggesLs a llnear progresslon Loward lmplemenLlng
an ulLlmaLe archlLecLure, or glves preference Lo one suggesLed archlLecLure vlslon over anoLher. nelLher ls
meanL ln Lhls case. ln facL, one can vlew how far one Lraverses each paLh as one of archlLecLure need over
a percelved archlLecLure maLurlLy. 1o underscore, we make Lhe followlng observaLlons relaLlng Lo
commerclally avallable cloud compuLlng producLs:
! Cloud compuLlng does noL reallze Lhe goals of auLonomlc compuLlng as Lhey are deflned
currenLly, Lhough comblnlng Lhe characLerlsLlcs of exlsLlng clouds geLs closer Lo Lhls goal. 1hls
facL does noL dlmlnlsh Lhelr value for opLlmlzlng deploymenLs of appllcaLlons ln place Loday.
! noL every cloud needs Lo be auLonomlc - buL Lhere are beneflLs along each paLh regardless.
o lmplemenLlng archlLecLure feaLures on Lhe AppllcaLlons ManagemenL urlvers paLh wlll
lead Lo opLlmlzlng cosLs of operaLlng and malnLalnlng lnfrasLrucLure and buslness
funcLlonallLy LhaL currenLly run a buslness, and auLomaLlng sysLems managemenL,
resulLlng ln more efflclenL daLa cenLer managemenL.
o Lvolvlng an archlLecLure Loward uLlllLy CompuLlng ManagemenL )*6 CuLslde-ln
ArchlLecLure CapablllLles wlll help organlzaLlons expand Lhelr l1 sysLems beyond
corporaLe boundarles. 1hls supporLs lmplemenLaLlon of more flexlble parLner neLworks
and value chalns, buL lL also can scale Lo serve vlrLual organlzaLlons.
CPA8AC1L8l S1l CS Cl An Au1CnCMl C SL8vl CL A8CPl 1LC1u8L
As cloud compuLlng soluLlons and producLs are lmplemenLed, we belleve lL crlLlcal - especlally Lo Lhose
belng drlven by Lhelr buslness needs up Lhe SysLems and AppllcaLlons ManagemenL urlvers curves - Lo
carefully conslder Lhelr need for supporL of Lhe archlLecLure characLerlsLlcs LhaL we skeLched ln Lhe
openlng parL of Lhls paper and LhaL we now elaboraLe.
A8CPl1LC1u8L S1?LL
ArchlLecLure sLyles deflne famllles of sofLware sysLems ln Lerms of paLLerns for characLerlzlng how
archlLecLure componenLs lnLeracL. 1hey deflne whaL Lypes of archlLecLure componenLs can exlsL ln
archlLecLures of Lhose sLyles, and consLralnLs on how Lhey may be comblned. 1hey deflne how
componenLs may be comblned LogeLher for deploymenL. 1hey deflne how unlLs of work are managed,
e.g., wheLher or noL Lhey are LransacLlonal (n-phase commlL). And Lhey deflne how funcLlonallLy LhaL
componenLs provlslon may be composlLed lnLo hlgher order funcLlonallLy, and how such can be exposed
for use by human belngs or oLher sysLems.
1he!"#$%&'()*+ archlLecLural sLyle ls lnherenLly Lop-down and emphaslzes decomposlLlon Lo Lhe funcLlonal
level, buL noL lower, ls servlce-orlenLed raLher Lhan appllcaLlon-orlenLed, facLors ouL pollcy as a flrsL-class
archlLecLure componenL LhaL can be used Lo govern LransparenL performance of servlce-relaLed Lasks, and
emphaslzes Lhe ablllLy Lo adapL performance Lo user/buslness needs wlLhouL havlng Lo conslder Lhe
lnLrlcacles of archlLecLure worklngs
2
.
1he counLer sLyle,! whaL we call! &+%&'()-#$,! ls lnherenLly boLLom-up! and Lakes much more of an
lnfrasLrucLural polnL of vlew as a sLarLlng polnL, bulldlng up Lo a buslness funcLlonal layer. AppllcaLlon
plaLforms consLrucLed uslng ./&(+$! %(01(0, -23(.$)-0&(+$(', and 4565+)$&(0 archlLecLure sLyles are Lhose Lo
whlch we apply Lhe generallzaLlon &+%&'()-#$ because Lhey form Lhe basls of enLerprlse appllcaLlon
archlLecLures Loday, and because archlLecLures of Lhese Lypes have llmlLaLlons LhaL requlre
LransformaLlon Lo scale ln a masslve way vls-a-vls ouLslde-ln plaLforms (see Web Servlces 2.0 for a more
deLalled dlscusslon of boLh CuLslde-ln and lnslde-CuL archlLecLure sLyles).
lmplemenLaLlon of an ouLslde-ln archlLecLure resulLs ln beLLer archlLecLure layerlng and facLorlng, and
lnLerfaces LhaL become more 2#%&+(%% Lhan '7$7 orlenLed. ollcy becomes more expllclL and ls exposed ln
a way LhaL makes lL easler Lo change lL as necessary. Servlce orlenLaLlon guldes Lhe lmplemenLaLlon,
maklng lL more feaslble Lo lnLegraLe and lnLeroperaLe uslng commodlLy lnfrasLrucLure raLher Lhan uslng
complex and lnflexlble appllcaLlon lnLegraLlon mlddleware.
As a rule, lL ls slmpler Lo lnLegraLe buslnesses aL funcLlonal levels Lhan aL lower Lechnology layers where
lmplemenLaLlons mlghL vary wldely. Pence we emphaslze decomposlLlon Lo Lhe funcLlonal level, whlch
ofLen ls dlcLaLed by sLandards wlLhln a markeL, regulaLory consLralnLs on LhaL markeL, or even accounLlng
(A/A8/CL) pracLlces.
ArchlLecLure sLyle wlll be crlLlcal Lo orchesLraLlng servlces and enabllng operablllLy beLween Lhousands of
collaboraLlng buslnesses. 1he Ll & lung Croup manages supply chalns lnvolvlng over 10,000 companles
locaLed ln over 40 counLrles of Lhe world. olnL lnLegraLlon soluLlons are lnfeaslble aL Lhls scale. Slmllarly,
aLLempLs Lo lnLegraLe hundreds of hosplLal paLlenL managemenL sysLems and devlces lnLo a healLhcare
cloud, repleLe wlLh PL7 varlanLs and new and legacy appllcaLlons, would resulL ln Lhe same concluslon
LhaL lnLeroperablllLy musL be reallzed Lhrough Lhe lmplemenLaLlon of an archlLecLure LhaL lnLegraLes aL a
buslness funcLlonal level raLher Lhan a daLa level.
Lx1L8nAL uSL8 Anu ACCLSS CCn18CL MAnACLMLn1
user and access conLrol managemenL #%#7//8 ls lmplemenLed wlLhln a Lyplcal enLerprlse appllcaLlon. A
user ls asslgned one Lo many appllcaLlon roles, and a role names a seL of prlvlleges LhaL correlaLe Lo use of
parLlcular appllcaLlon funcLlonallLy Lhrough a graphlcal user lnLerface, or Lhrough some programmlng
lnLerface. user auLhenLlcaLlon and auLhorlzaLlon can be lnLegraLed wlLh corporaLe ldenLlLy managemenL
soluLlons (e.g., slngle slgn-on soluLlons) LhaL are ln place Lo ensure LhaL only people wlLhln a corporaLlon
or corporaLe parLner neLwork are permlLLed Lo use corporaLe appllcaLlons.

2
An ouLslde-ln archlLecLure ls a klnd of servlce-orlenLed archlLecLure (SCA) whlch ls fully elaboraLed ln 1homas Lrl's
book called Servlce-CrlenLed ArchlLecLure: ConcepLs, 1echnology, and ueslgn," so we wlll noL dlscuss SCA ln deLall
ln Lhls paper.
8uL as buslnesses globallze and couple more fluldly and dynamlcally, Lhe managemenL of users and Lhelr
asslgnmenLs Lo roles and responslblllLles/prlvlleges musL be lmplemenLed ln a scalable fashlon LhaL
supporLs composlLlon of servlces lnLo more complex servlce-orlenLed behavlor. lurLher, lL musL be
posslble for role players Lo LransparenLly change ln response Lo buslness- and parLner-relaLed changes
made over Llme, especlally ln buslness lnLeracLlons LhaL could be ln progress over monLhs Lo years.
A fundamenLal parL of user managemenL ls !"#$%!%&' ()$)*#(#$%. 1here are numerous ldenLlLy soluLlons
avallable Loday from vendors llke MlcrosofL, Sun MlcrosysLems, and Cracle. 1he challenges faclng Lhese
soluLlon vendors lnclude Lhelr ablllLy Lo manage Lhe varled ways a user can be represenLed ln an onllne
conLexL, Lhe means Lo verlfy ldenLlLy and deLecL and manage ldenLlLy LhefL, Lhe need Lo accommodaLe
audlLs of LransacLlons and lnLeracLlons conducLed wlLh a speclflc ldenLlLy, and so forLh. ldenLlLy
ManagemenL ls (+,- larger Lhan any slngle cloud or sofLware vendor, and formlng a soluLlon for Lhe
LwenLy-flrsL-cenLury ls even llkely Lo requlre help from naLlonal governmenLs
iv
.
ln1L8AC1lCn CCn1AlnL8
1he !2LL/!ava LL communlLy lnLroduced Lhe noLlon of conLalner Lo Lhe enLerprlse archlLecLure communlLy
as a means Lo sLreamllne Lhe sLrucLure of Lhln [ava cllenLs. normally, Lhln-cllenL mulLlLlered appllcaLlons
would requlre code Lo lmplemenL perslsLence, securlLy, LransacLlon managemenL, resource pool
managemenL, dlrecLory, remoLe ob[ecL neLworklng, and ob[ecL llfe cycle managemenL servlces. 1he !2LL
archlLecLure lnLroduced a ,.$%)!$#/ model LhaL made Lhls funcLlonallLy avallable - LransparenLly, ln many
cases - Lo buslness loglc lmplemenLed as classes of behavlor as long as lL was lmplemenLed Lo conform Lo
speclal (e.g., 0#)$) lnLerfaces, freelng developers Lo focus on lmplemenLlng buslness funcLlonallLy and noL
lnfrasLrucLure - resulLlng ln a sLandardlzed use of lnfrasLrucLure servlces. ConLalners are hosLed ln
appllcaLlon servers.
As we move Loward servlce orlenLaLlon, Lhere ls need for an analog Lo an appllcaLlon server LhaL noL only
manages common lnfrasLrucLure servlces buL provldes Lhe lnfrasLrucLure exLenslon polnLs for managlng
pollcy LhaL ls harmonlzed across Lechnology and buslness funcLlonal sLacks wlLhln a cloud. lor Lhe purpose
of dlscusslon here, we use Lhe Lerm 1$%#/),%!.$'2#/3#/ Lo mean an archlLecLure componenL LhaL provldes
runLlme servlces used by lnLeracLlon ConLalners (deflned below) Lo manage Lhe llfe cycle of mulLl-parLy
buslness servlce lnLeracLlons ln boLh slngle- and mulLlLenanL conLexLs. 8unLlme servlces can lnclude Lhose
slmllar Lo appllcaLlon servlces (e.g., llke !2LL conLalner servlces), buL also servlces Lo manage pollcy
(harmonlzaLlon across archlLecLure layers, pollcy enforcemenL, and pollcy excepLlons), lnLeracLlon llfe
cycle managemenL, and even speclallzed collaboraLlon servlces (e.g., evenL-based publlsh and subscrlbe
capablllLles, and servlces LhaL brlng LogeLher Lhose people who are lnvolved ln buslness lnLeracLlons).
We use Lhe Lerm 1$%#/),%!.$ Lo mean a servlce orlenLed mulLlparLy buslness collaboraLlon. An lnLeracLlon
can be vlewed as an orchesLraLlon of buslness servlces where orchesLraLlon 45.6 (noL 6./745.6 ln Lhe
Lyplcal enLerprlse appllcaLlon lnLegraLlon sense) ls managed uslng exLernallzed pollcy (please see Web
Servlces 2.0 for a more deLalled dlscusslon on Lhls Loplc). An lnLeracLlon ls hosLed wlLhln an lnLeracLlon
ConLalner (deflned below), and orchesLraLes servlces provlsloned ln dlsLrlbuLed conLexLs. lnLeracLlon llfe
cycle evenLs are used Lo Lrlgger sysLem behavlor and enforce managemenL pollcles and are publlshed by
Lhe lnLeracLlon Server Lo subscrlbers.
llnally, we use Lhe Lerm 1$%#/),%!.$' 8.$%)!$#/' as an analog Lo 9:;;<9)3)' ;; )==5!,)%!.$' ,.$%)!$#/> 1he
lnLeracLlon ConLalner ls hosLed ln an lnLeracLlon Server, sLaLlcally and dynamlcally conflgured Lo provlde
lnfrasLrucLure and pollcy ad[udlcaLlon servlces LhaL are speclflc Lo a buslness user's envlronmenL,
lnLegraLed wlLh sysLems managemenL capablllLles, and used Lo manage one-Lo-many lnLeracLlons and
Lhelr llfe cycles. An lnLeracLlon ConLalner essenLlally holds an execuLlon conLexL ln whlch role players -
people or sysLems parLlclpaLlng ln an lnLeracLlon and conformlng Lo speclflc roles (lnLerfaces) - lnLeracL Lo
perform Lhelr parLs ln a buslness orchesLraLlon and manage excepLlons and/or faulLs should Lhey occur ln
Lhe process.
An !"#$%&'#()"* +)"#&("$%* can be consldered Lo be organlzaLlonally based (l.e., lL can be used Lo manage
many lnLeracLlons beLween a seL of parLlclpanLs/role players over Llme), or ouLcome-based (ln whlch only
one lnLeracLlon would be performed). 1hese Lwo usage scenarlos reflecL Lhe need Lo manage lnLeracLlons
ln a dynamlc user communlLy, where role players could change over Llme, and Lhe need Lo manage an
lnLeracLlon as a slngle posslbly long-runnlng buslness LransacLlon.
Lx1L8nALlZLu CLlC? MAnACLMLn1/CLlC? LnClnL
A ollcy Lnglne harmonlzes and ad[udlcaLes confllcLlng pollcles used across archlLecLure layers.
ComponenLs aL all archlLecLure layers can parLlclpaLe ln pollcy harmonlzaLlon and enforcemenL, whlch
requlres Lhe followlng:
! ollcy exLenslon polnLs musL be exposed and formally declared ln any parL of Lhe archlLecLure
LhaL musL be managed.
! ollcy managemenL musL supporL ,)-('.* ,/012)3" Lo enable exLenslble and dynamlc deLecLlon
of pollcy vlolaLlon and pollcy enforcemenL.
! lL musL be posslble Lo verslon pollcy so LhaL pollcy declslons made aL a glven Llme can be
reproduced.
! ollcy excepLlons should be managed ln as auLomaLed a fashlon as posslble, buL supporL also
musL be glven Lo cases where human [udgmenL and declslon maklng may be requlred. noLe LhaL
4&/-# or $5'$,#()" can connoLe boLh sysLem-level occurrences &"2 domaln evoluLlon ln whlch
pollcy consLralnLs valld ln Lhe pasL become lnvalld. lor example:
o lnablllLy Lo connecL Lo a daLabase ls a sysLem faulL LhaL should be auLomaLlcally handled
as a sofLware sysLem excepLlon.
o A regulaLory consLralnL LhaL permlLLed conducL of buslness ln one way Lo a cerLaln polnL
ln Llme, buL LhaL no longer does due Lo changes ln law, ls a buslness excepLlon LhaL may
requlre human [udgmenL Lo deLermlne lf compleLlon of a buslness LransacLlon accordlng
Lo old law should be permlLLed.
ollcy embedded ln appllcaLlon funcLlonallLy ls noL easy Lo change, buL fuLure sofLware sysLems wlll have
Lo be lmplemenLed ln a way LhaL vlews change as Lhe norm - where change resulLs from Lhe emergence
of new markeLs, markeL evoluLlon, changes ln regulaLlons and sLandards, flxlng of pollcy bugs, Lhe whlms
of lnLeracLlon parLlclpanLs, and maybe even Lhelr cusLomers' whlms.
LxLernallzlng pollcy hlghllghLs a slgnlflcanL dlsLlncLlon beLween lnslde-CuL and CuLslde-ln archlLecLure
sLyles. lnslde-CuL archlLecLures usually lnvolve legacy appllcaLlons ln whlch pollcy (0 embedded and Lhus
exLernallzlng lL ls - aL besL - very dlfflculL. Where appllcaLlon pollcles dlffer ln Lyplcal corporaLe
envlronmenLs, lL becomes Lhe responslblllLy of lnLegraLlon mlddleware Lo lmplemenL pollcy ad[udlcaLlon
loglc LhaL may work well Lo harmonlze pollcles over small numbers of lnLegraLed sysLems, buL Lhls wlll noL
generallze Lo manage pollcy ln larger numbers of appllcaLlons as would be Lhe case ln larger value chalns.
1he red recLangle ln Lhe flgure below ldenLlfles where an lnslde-CuL archlLecLure musL Lransform (and
slmpllfy ln Lhe process) Lo become an CuLslde-ln archlLecLure, maklng lL more feaslble Lo exLernallze
pollcy and progress Loward Lhe fully auLonomlc compuLlng endpolnL
3
.

3
ln prlvaLe conversaLlons, we refer Lo Lhls LransformaLlon as a klnd of archlLecLural Laplace 1ransform LhaL helps ln
solvlng challenglng problems wlLh an archlLecLure by Lransformlng lL Lo a slmpler form by creaLlng an alLernaLlve
frame or polnL of vlew.

!"#$%&'%()*+,-.%
1he word /)*+,- could have a number of meanlngs as lL ls used ln con[uncLlon wlLh l1 archlLecLure and
sysLems. lor example, lL could mean governance relaLlng Lo sofLware archlLecLure developmenL and
lmplemenLaLlon, or lL could mean operaLlonal rules and sLandards for admlnlsLerlng a deployed
producLlon sysLem.
Cur use of Lhe word connoLes consLralnLs placed upon Lhe buslness funcLlonallLy of a buslness sysLem,
harmonlzed wlLh consLralnLs on Lhe lnfrasLrucLure (hardware and sofLware) LhaL provlslons LhaL
funcLlonallLy. 1hese consLralnLs could lnclude accounLlng rules LhaL buslnesses follow, role-based access
conLrol on buslness funcLlonallLy, corporaLe pollcy abouL Lhe maxlmum allowable hoLel room raLe LhaL a
nonexecuLlve employee could purchase when uslng an onllne reservaLlon servlce, rules abouL peak
buslness Lrafflc LhaL deLermlne when a new vlrLuallzed lmage of an appllcaLlon sysLem should be
deployed, and Lhe varlous lnfrasLrucLural pollcles LhaL mlghL glve cusLomer 0 preference over cusLomer 1
should crlLlcal resource conLenLlon requlre such.
ollcy exLenslon polnLs, as noLed above, provlde Lhe means by whlch pollcy consLralnLs are exposed Lo
buslness and correspondlng lnfrasLrucLural funcLlonallLy and lncorporaLed lnLo Lhelr execuLlon. 1hey are
noL conflguraLlon polnLs LhaL are usually known ln advance of when an appllcaLlon execuLlon sLarLs and
LhaL sLay consLanL unLll Lhe appllcaLlon resLarLs. 8aLher, pollcy exLenslon polnLs are dynamlc and laLe
bound Lo buslness and lnfrasLrucLural funcLlonallLy, and Lhey provlde Lhe means Lo 2-3#4+,#**- '"#/5
execuLlon of Lhls funcLlonallLy. 1he sense of Lhe word '"#/5 ls conslsLenL wlLh how pollcy ls applled ln Lhe
Lelecom world where, for example, bandwldLh mlghL be made avallable Lo users durlng parLlcular Llmes ln
Lhe day as a funcLlon of LoLal number of users presenL. !usL as pollcy ls used ln Lhe Lelecom world Lo '"#/5
use of crlLlcal resources, pollcy can be used Lo shape execuLlon of buslness funcLlonallLy.
lor example, suppose LhaL an lnLeracLlon beLween buslness parLners ls sLarLed by a parLner locaLed ln a
Luropean counLry LhaL legally requlres all lnLeracLlon daLa Lo remaln ln LhaL counLry, whereas Lhls same
Lype of daLa could be sLored anywhere LhaL Lhe deploymenL plaLform deLermlnes convenlenL oLherwlse. A
pollcy exLenslon polnL on sLorage could be exposed Lo ensure LhaL sLorage sysLems locaLed ln Lhe
approprlaLe Luropean counLry are used when requlred. 8ecause pollcy ls exLernallzed as descrlbed above,
Lhls pollcy does !"# lmply Lhe need for mulLlple code bases Lo reallze Lhls consLralnL.
1he example above ls a slmple one LhaL one could lmaglne lmplemenLlng aL Lhe appllcaLlon $%&'!(&& layer
of an enLerprlse archlLecLure. Suppose, however, LhaL Lhls Lype of pollcy ls moved from Lhe buslness layer
'!#") #*() !(#+",-. lrom 2003 Lo daLe, we have seen Lhe emergence of xML acceleraLors (e.g., l8M/uaLa
ower, lnLel, Layer 7 1echnologles) LhaL make such posslble by brlnglng Lo appllcaLlon proLocol
managemenL whaL neLwork proLocol analyzers, or &!'..(,&, brlng Lo neLwork proLocol managemenL. 1hese
acceleraLors are able Lo lnspecL, Lransform, and rouLe boLh xML and blnary daLa ln ways LhaL are
consclous of ecosysLem and lnLeracLlon consLralnLs, e.g., consLralnLs llke Lhe Luropean sLorage rule above.
Cnce equlpmenL llke Lhls ls aware of Lhe buslness daLa and Lhe workflow conLexL ln whlch lL ls
communlcaLed, lL can carry ouL neLworklng funcLlons such as forwardlng, securlLy, usage analysls, Lrafflc
managemenL, and bllllng, ln a much more sophlsLlcaLed manner ln comparlson Lo LradlLlonal neLworklng
Lechnlques - and lL can do Lhls Laklng lnLo accounL pollcy consLralnLs across an enLlre Lechnology sLack.
u1lLl1? CCMu1lnC
1he ralson d'Lre of auLonomlc compuLlng ls Lhe need Lo address Lhe growlng complexlLy of l1 sysLems.
Whlle loosely coupllng archlLecLure componenLs makes Lhem less brlLLle, lL also exposes more movlng
parLs LhaL also musL have managemenL and conflguraLlon exLenslon polnLs. 1he auLhors of /*() 0'&'"!) ".
1%#"!"2'3)4"25%#'!6 worded Lhelr concerns over complexlLy as follows:
As sysLems become more lnLerconnecLed and dlverse, archlLecLs are less able Lo anLlclpaLe and deslgn
lnLeracLlons among componenLs, leavlng such lssues Lo be dealL wlLh aL runLlme. Soon sysLems wlll
become Loo masslve and complex for even Lhe mosL skllled sysLem lnLegraLors Lo lnsLall, conflgure,
opLlmlze, malnLaln, and merge. And Lhere wlll be no way Lo make Llmely, declslve responses Lo Lhe rapld
sLream of changlng and confllcLlng demands."
LxLernallzaLlon of pollcy goes a long way Loward maklng lL posslble Lo composlLe clouds and manage
pollcy compllance. 8uL Lhe sLrucLure of Lhe cloud also musL be addressed lf we expecL Lo manageably
scale a cloud. An auLonomlc compuLlng archlLecLure calls for archlLecLure componenLs Lo, Lhemselves, be
auLonomlc. 1hls mlghL sound a blL far-feLched unless we conslder LhaL we have been solvlng
heLerogenelLy problems wlLh absLracLlon layers aL Lhe operaLlng sysLem layer for some years now, and
LhaL Lhls Lechnlque can be used agaln Lo manage large collecLlons of compuLlng resources unlformly. ln
parLlcular, lf Lwo clouds are auLonomlc and essenLlally supporL Lhe same managemenL lnLerfaces, Lhen
Lhey could be composlLed lnLo a larger cloud whlle preservlng Lhe ldenLlLles of Lhe orlglnal clouds.
lnLulLlvely, Lhls slmpllfles scallng clouds and reconclllng pollcy dlfferences.
As we see Lhe emergence of Cloud CompuLlng producLs lnLo Lhe markeL, we see (aL leasL) Lwo LhaL appear
Lo recognlze Lhe need Lo composlLe clouds, grlds, or meshes of manageable compuLlng resources. Some
cloud lnfrasLrucLure vendors have Laken an approach dlfferenL from Amazon's ln LhaL Lhey lnLend Lo deal
dlrecLly wlLh archlLecLure componenLs Lhrough a sofLware absLracLlon layer. Cne approach Laken Lo
manage clouds ls Lo provlde a managemenL lnLerface Lo whlch all manageable resources, lncludlng Lhe
cloud lLself, conform &") #*7# managemenL over heLerogeneous lnfrasLrucLure ls unlform. 1he approach
LhaL MlcrosofL has Laken acknowledges a need for a unlform managemenL absLracLlon layer, whlch lL
achleves by requlrlng LhaL Lhe seL of manageable resources conform Lo lnLerfaces ln Lhe .nL1 lramework.
ln elLher case, exposlng a cloud 7!8)'#&)3"25"!(!#&)Lhrough a well deflned managemenL lnLerface enables
managemenL pollcles Lo be applled (9(!) #") #*() 3"!#(!#&) ".) 3"!#7'!(,&) :'-() #*() '!#(,73#'"!) 3"!#7'!(,)
8'&3%&&(8) (7,:'(,, maklng lL posslble Lo harmonlze pollcles and dellver lnformaLlon ln conLexL across
buslness and lnfrasLrucLure layers.
1hls ls ln sLark conLrasL Lo elasLlc compuLlng sLraLegles LhaL are vlrLuallzaLlon-based, ln whlch Lhe conLenLs
of vlrLual lmages are noL dlrecLly manageable by Lhe elasLlc compuLlng lnfrasLrucLure. Amazon, wlLh lLs
CloudWaLch managemenL dashboard and Als, provlde Lhe ablllLy Lo manage LC2-based sysLems uslng
sLandard sysLems managemenL meLrlcs. SysLems managemenL funcLlonallLy layered on Lop of LC2
managemenL could correlaLe buslness resources Lo sysLem resources Lhrough sysLems meLrlcs, Lhough Lhe
correlaLlon ls made ouLslde of CloudWaLch. 8ecenL parLnershlps beLween l8M and Amazon allow for
conLalners fllled wlLh l8M lnfrasLrucLure Lo be managed uslng 1lvoll or slmllar sysLems managemenL
funcLlonallLy. Powever, even ln Lhls case, lL ls lmporLanL Lo noLe LhaL managemenL of !"#$% &'% &(% $")%
*+($#&(), ls dlsLlncL from -#(#.)-)($% +/% 0-#1+(2'% *3+45 unless an lnLegraLlon beLween Lhe Lwo ls
ulLlmaLely lmplemenLed. We have referred earller ln Lhls paper Lo Lhe mechanlsm permlLLlng conLenLs of
a conLalner Lo parLlclpaLe ln cloud managemenL as 6+3&*7% )8$)('&+(% 6+&($'. ln pracLlce, pollcy exLenslon
polnLs lmplemenL a managemenL lnLerface LhaL makes Lhe resources wlLh whlch Lhey are assoclaLed
manageable and makes lL posslble for Lhese resources Lo parLlclpaLe ln cloud managemenL.
93+45%9+-6+'&$&+(%
1he ablllLy of one cloud Lo parLlclpaLe ln managlng anoLher wlll become crlLlcal Lo scallng a cloud. lL wlll
provlde a means for a prlvaLe cloud Lo Lemporarlly use Lhe resources of a publlc cloud as parL of an elasLlc
resource capaclLy sLraLegy. lL also wlll make lL posslble Lo more lmmedlaLely share funcLlonallLy,
lnformaLlon, and compuLlng resources.
Cne ,)#3:3&/) example of a composlLe cloud ls Skype. Whlle Skype may be consldered Lo be [usL a p2p
appllcaLlon, lL acLually ls a global mesh neLwork of managed neLwork elemenLs (servers, rouLers, swlLches,
encoders/decoders, eLc.) LhaL provlslons a global vol neLwork wlLh volce endpolnLs LhaL are
lapLop/deskLop compuLers or handheld devlces LhaL run Skype's cllenL appllcaLlon aL Lhe edge of Lhe
Skype cloud. When Lhe Skype appllcaLlon ls noL runnlng on a lapLop/deskLop/handheld devlce, vol calls
are noL conducLed Lhrough lL. 8uL when Lhe appllcaLlon ls runnlng and calls can be conducLed, Lhe Skype
cloud expands Lo use Lhe lapLop/deskLop/handheld devlce Lo rouLe Lrafflc and manage neLwork
excepLlons lf needed.
A second ,)#3% 3&/) example ls lorLlusCne's CeoCommons (hLLp://www.lorLlusCne.com,
hLLp://www.geocommons.com). lorLlusCne ls developlng a nexL-generaLlon locaLlon lnLelllgence plaLform
by blendlng analysls capablllLles of geographlc lnformaLlon sysLems (ClS) wlLh locaLlon-based lnformaLlon
on Lhe Web. lorLlusCne's premlse ls LhaL lL can help organlzaLlons make beLLer locaLlon-senslLlve
declslons by slmpllfylng how buslness lnformaLlon ls correlaLed Lo vlsual maps. 1he Lechnology and daLa
LhaL make up Lhe lorLlusCne plaLform ls a comblnaLlon of open source Lechnology and daLa LhaL lL
llcenses Lo complemenL whaL lL can geL from Lhe publlc domaln.
1wo appllcaLlons are made avallable aL CeoCommons: ;&(5),< ls an appllcaLlon used Lo flnd, organlze, and
share geodaLa, and =#>),< ls an appllcaLlon used Lo creaLe maps uslng CeoCommons and personal daLa.
A slmple use case lnvolvlng boLh of Lhese Lools ls Lhe upload of a named daLa seL lnLo ;&(5),< LhaL can be
llnked Lhrough posLal code, longlLude/laLlLude, or some oLher locaLlon hook Lo a map, and Lhe subsequenL
use of =#>),< Lo produce a renderlng of a map wlLh Lhe named daLa seL superlmposed onLo lL.
lorLlusCne has lmplemenLed lLs funcLlonallLy boLh as Web appllcaLlons and servlces (wlLh a Web servlce
programmlng lnLerface). lL makes Lhls funcLlonallLy avallable ln lLs own cloud, whlch ls very slmllar Lo
Amazon's LlasLlc CompuLe Cloud core.
! CeoCommons makes lLs sofLware-as-a-servlce plaLform avallable Lhrough a subscrlpLlon, wlLh
prlclng deLermlned by number of reporLs generaLed, daLa seL slze, and daLa sLorage
requlremenLs.
! lor Lhose who wlsh Lo operaLe ln a more secure yeL managed )($),6,&') conLexL, CeoCommons
can be prlvaLely hosLed for a cusLomer. 1hls verslon of Lhe plaLform lncludes an expanded daLa
seL #(5 daLa lnLegraLlon servlces.
! And for Lhose wlshlng Lhe ulLlmaLe ln daLa prlvacy who slmply do noL LrusL on-llne secure
envlronmenLs, lorLlusCne packages lLs CeoCommons funcLlonallLy and supporLlng daLa on a
llnux appllance and updaLes daLa and funcLlonallLy perlodlcally as requlred.
1he poLenLlal for Lwo Lypes of !"#$%&!#'(#)*+*#, can be seen ln Lhe lorLlusCne offerlngs. llrsL, Amazon's
LlasLlc CompuLlng offerlng can be used should lorLlusCne requlre addlLlonal resources beyond lLs currenL
capaclLy. Second, Lhe CeoCommons ls accesslble vla a Web servlce programmlng lnLerface, whlch makes
lL posslble Lo lnvoke Lhe servlces provlsloned ln Lhe lorLlusCne cloud from anoLher cloud. lnvoklng
servlces of one cloud by anoLher does noL requlre cloud composlLlon, buL a need Lo manage mulLlple
clouds wlLh Lhe same pollcy seL could.
WlLh Lhese examples ln mlnd, we characLerlze uLlllLy CompuLlng as follows:
! An CS managemenL layer LhaL Lransforms hosLed resources ln a daLa cenLer lnLo a pollcy-
managed cloud, exLenslble beyond daLa cenLer boundarles.
o lL slLs over (posslbly componenLs physlcally run on) producLlon hardware.
! lL enables clouds conformlng Lo Lhe same cloud managemenL lnLerface Lo be composlLed whlle
malnLalnlng cloud ldenLlLy.
! lL knows and manages all resources ln a cloud (recurslvely, as dlcLaLed by pollcy).
! lL reallocaLes (ln an auLonomlc sense) resources ln a cloud, as permlLLed by pollcy, Lo
accommodaLe real-Llme and buslness-orlenLed usage paLLerns.
! lL meLers use of all resources managed wlLhln a cloud.
! lL provldes securlLy and access conLrol LhaL can federaLe across cloud boundarles.
! lL parLlclpaLes ln ad[udlcaLlon of pollcy colllslons across all cloud archlLecLure layers where
approprlaLe.
uLlllLy compuLlng can be consldered an overlay on a cloud Lo make lL and lLs elemenLs manageable and
composlLlonal. reservaLlon of cloud ldenLlLy also ls a nod Loward Lhe ablllLy Lo federaLe clouds, whlch has
been elaboraLed ln -./0*!.& 1/*%2& 34.& 5*))*,6& 7*,8& *,& 9.:& -./0*!.), LogeLher wlLh early Lhlnklng of Lhe
foundaLlonal naLure of servlce grlds vls-a-vls buslness compuLlng ecosysLems
v
.
SL8vl CL C8l u - 1PL 8LnLll 1 ;<3=> 1PL Au1CnCMl C LnuCl n1
8efore Lhe Lerm !"#$%, Lhe Lerm )./0*!.& 6/*% was someLlmes used Lo deflne a managed dlsLrlbuLed
compuLlng plaLform LhaL can be used for buslness ?)& @.""& ?) sclenLlflc appllcaLlons. Sald sllghLly
dlfferenLly, a servlce grld ls a manageable ecosysLem of speclflc servlces deployed by servlce buslnesses or
uLlllLy companles. Servlce grlds have been llkened Lo a (#@./ or $+*"*+A& 6/*%: always on, hlghly rellable, a
plaLform for maklng managed servlces avallable Lo some user consLlLuency. When Lhe Lerm came lnLo use
ln Lhe l1 domaln, Lhe word )./0*!. was lmplled Lo mean 9.:& )./0*!., and )./0*!.& 6/*% was vlewed as an
lnfrasLrucLure plaLform on whlch an ecology of servlces could be composed, deployed, and managed.
1he phrase )./0*!.& 6/*% lmplles )+/$!+$/.. Whlle grld elemenLs - )./0./)& +#6.+4./& @*+4& B$,!+*#,?"*+A& +4.A&
4#)+& @*+4*,& ?& )./0*!.& 6/*% - may be 4.+./#6.,.#$) vls-a-vls Lhelr consLrucLlon and lmplemenLaLlon, Lhelr
presence wlLhln a servlce grld lmplles '?,?6.?:*"*+A& ?)& (?/+& #B& +4.& 6/*%& ?)& ?& @4#".. 1hls lmplles LhaL a
capablllLy exlsLs Lo manage grld elemenLs $)*,6&(#"*!A LhaL ls .C+./,?"&+# lmplemenLaLlons of servlces ln a
servlce grld (aL Lhe mlnlmum *,& !#,D$,!+*#,& @*+4 pollcy LhaL mlghL be embedded ln legacy servlce
lmplemenLaLlons). And servlces ln a grld become candldaLes for reuse Lhrough servlce composlLlon,
servlces ouLslde of a grld also are candldaLes for composlLlon, buL Lhe servlce grld only can manage
servlces wlLhln lLs scope of conLrol. Cf course, servlce grlds deflned as we have above are auLonomlc, can
be recurslvely sLrucLured, and can collaboraLe ln Lhelr managemenL of composlLe servlces provlsloned
across dlfferenL grlds.

A !"#$%, as deflned by Lhe cloud Laxonomy noLed earller, &'()#*()+!+'',-&".(,('+-/&!+(0-&%. 1here ls noLhlng
ln cloud deflnlLlons LhaL requlre all servlces hosLed ln Lhem Lo be managed ln a predeLermlned way. 1here
ls no pollcy englne requlred ln a cloud LhaL ls responslble Lo harmonlze pollcy across lnfrasLrucLure and
buslness layers wlLhln or across lLs boundarles, Lhough lncreased aLLenLlon ls belng glven Lo pollcy-drlven
lnfrasLrucLure managemenL. Clouds are noL formed wlLh reglsLrles or oLher lnfrasLrucLure necessary Lo
supporL servlce composlLlon and governance.
A servlce grld can be formed as an auLonomlc cloud and wlll place addlLlonal consLralnLs on cloud
sLrucLure (e.g., exLernal pollcy managemenL, lnLeracLlon conLalner-supporLed composlLlon, a common
managemenL lnLerface, supporL of speclflc lnLerface sLandards). 1hese sLandards wlll be necessary Lo
manage a servlce grld boLh as a Lechnology ,)% a buslness plaLform.
CCn1AlnL8 L8MLA8lLl1?
Clouds and servlce grlds boLh have !#)*,&)+-'. ln clouds, !#)*,&)+- ls used Lo mean ,( /&-*$,"&1+%( &2,0+(
!#)*,&)&)0(*+!3)#"#0.( ,)%(,44"&!,*&#)( '*,!5'. 1he conLalner mlghL hold oLher klnds of conLalners (e.g., a
!2LL/!ava LL appllcaLlon conLalner), buL Lhe cloud conLalner ls &24+-2+,6"+, whlch means LhaL Lhe cloud
does noL dlrecLly manage conLalner conLenLs, and Lhe cloud conLenLs do noL parLlclpaLe ln cloud or
conLalner managemenL. ln a servlce grld, !"#$%&#'( ls Lhe means by whlch Lhe grld provldes underlylng
lnfrasLrucLural servlces, lncludlng securlLy, perslsLence, buslness LransacLlon or lnLeracLlon llfe cycle
managemenL, and pollcy managemenL. ln a servlce grld, lL ls posslble for conLenLs &# a conLalner Lo
parLlclpaLe ln grld managemenL as a funcLlon of lnfrasLrucLure managemenL pollcles harmonlzed wlLh
buslness pollcles llke servlce level agreemenLs. lL also ls posslble LhaL pollcy exLernal Lo conLalner conLenLs
can )*%+'
4
how Lhe conLalner's funcLlonallLy execuLes. So a servlce grld conLalner's wall ls permeable vls-
a-vls pollcy, whlch ls a crlLlcal dlsLlncLlon beLween clouds and servlce grlds
5
.
CLCuu vLnuC8S Anu vLnuC8 LCCk- l n
vendor lock-ln ls a concern LhaL wlll grow as cloud compuLlng becomes more prevalenL. Lock-ln ls besL
addressed by Lhe lmplemenLaLlon of and compllance Lo sLandards. ln parLlcular, sLandards for securlLy,
lnLeroperablllLy, servlce composlLlon, cloud and servlce grld composlLlon, managemenL and governance,
and audlLlng wlll become especlally crlLlcal as clouds become embedded lnLo Lhe way LhaL corporaLlons
conducL buslness
6
.
SLandards for cloud managemenL are emerglng as vendors llke Amazon, Coogle, and MlcrosofL make Lhelr
offerlngs avallable for use. 1he Web Servlces communlLy has developed a seL of sLandards for Web servlce
securlLy, Web servlce managemenL, and Web servlce pollcy managemenL, and so forLh, LhaL can serve as a
basls for sLandards Lo be supporLed ln cloud compuLlng. And sofLware vendors
7
are lmplemenLlng Web
servlce managemenL plaLforms based on such sLandards LhaL provlde Lhe means Lo deflne servlce level
agreemenLs LhaL, when lnLegraLed wlLh Web servlce and supporLlng lnfrasLrucLure, govern end-Lo-end
Web servlce-based lnLeracLlons, ensure quallLles of servlce, LhroLLle Web servlce use Lo ensure
performance mlnlmums, eLc.
WlLh all Lhls sald, however, Lhe facL ls LhaL comprehenslve sLandards for cloud compuLlng do noL yeL exlsL,
slnce cloud compuLlng ls nascenL. And unLll (and probably even afLer) such sLandards exlsL, cloud users
should expecL Lo see feaLures and capablllLles LhaL [usLlfy lock-ln - [usL as one does wlLh oLher sofLware
and uLlllLy plaLforms. LxLernallzlng pollcy (dlscussed laLer ln Lhls paper) and lmplemenLlng servlces from
an ouLslde-ln perspecLlve wlll resulL ln geLLlng beneflLs from clouds whlle amelloraLlng aL leasL some of Lhe
aspecLs of vendor lock-ln Lhrough loose coupllngs and manageable lnLerfaces.
vl 81uAL C8CAnl ZA1l CnS Anu CLCuu CCMu1l nC
Soclal neLworks are examples of plaLforms LhaL use a somewhaL amorphous deflnlLlon of "(,%#&-%$&"#
slmllar Lo a .&($/%01 "(,%#&-%$&"#, whlch ls deflned by Lhe naLlonal Sclence loundaLlon as a group of
lndlvlduals whose members and resources may be dlspersed geographlcally and lnsLlLuLlonally, buL who
funcLlon as a coherenL unlL Lhrough Lhe use of cyberlnfrasLrucLure."
vi
vlrLual organlzaLlons can form ln a
varleLy of ways, usually as a funcLlon of roles/responslblllLles played ln lnLeracLlons and less as a funcLlon

4
1he sense of Lhe word )*%+' ls conslsLenL wlLh how pollcy ls applled ln Lhe Lelecom world where, for example,
bandwldLh mlghL be made avallable Lo users durlng parLlcular Llmes ln Lhe day as a funcLlon of LoLal number of users
presenL.
5
Cloud managemenL Lyplcally ls exposed by Lhe cloud vendor Lhrough a dashboard. vendors llke Amazon also make
funcLlonallLy underlylng Lhe dashboard avallable as Web servlces such LhaL cloud users' funcLlonallLy could
programmaLlcally ad[usL resources based on some lnLernal pollcy. A servlce grld ls consLrucLed Lo acLlvely manage
lLself as a uLlllLy of pooled resources and funcLlonallLy for all grld users. Pence, a servlce grld wlll requlre lnLeracLlon
wlLh funcLlonallLy LhroughouL Lhe grld and deLermlne wlLh Lhe use of pollcy exLenslon polnLs wheLher resource supply
should be ad[usLed.
6
noLe Lhe absence of porLablllLy ln Lhls llsL. lnLeroperablllLy ls far more lmporLanL Lhan porLablllLy, whlch more ofLen
leads Lo senseless Lechnology wars. lL ls unllkely Lo be posslble Lo porL appllcaLlons from one cloud Lo anoLher lf Lhese
appllcaLlons make use of cloud Als. Slnce clouds are noL sLandard as yeL, nelLher wlll Lhe Als be for some Llme.
Powever, maklng pollcy expllclL, and provldlng Als ln Lhe noLed areas wlll go a long way Loward enabllng lnLeracLlons
Lo be orchesLraLed across cloud and servlce grld boundarles.
7
See AmberolnL and SCA SofLware as Lwo examples of Web servlce managemenL plaLform vendors.
of LlLle or poslLlon ln an organlzaLlon. 8oles/responslblllLles represenL lnLerfaces LhaL have lnLeracLlon
scope and can be used Lo auLomaLe compuLlng and excepLlon handllng.
A vlrLual organlzaLlon's use of cloud servlces could vary wldely:
! A vlrLual organlzaLlon mlghL be a sLarLup company LhaL uses an lnfrasLrucLure cloud Lo deploy lLs
compuLlng servlces because Lhe economlc model ls rlghL - a pay-for-use model ls whaL lL can
afford as lL geLs off Lhe ground, and maybe even LhroughouL lLs enLlre corporaLe exlsLence. 1hls
Lype of organlzaLlon may be lnLeresLed ln Lhe elasLlc resources of a cloud, buL may noL need
more advanced capablllLles.
! A neLwork of Lhousands of supply chaln parLners could be consldered Lo be a vlrLual organlzaLlon.
lL could use a buslness lnLeracLlon server hosLed ln a cloud LhaL manages lnLeracLlons, ensurlng
Lhey conform Lo legal and conLracL pollcles and glvlng all parLlclpanLs ln an lnLeracLlon a record of
Lhelr parLlclpaLlon when LhaL lnLeracLlon compleLes. 1hls vlrLual organlzaLlon mlghL need Lhe full
range of auLonomlc compuLlng capablllLles Lo manage Lhe complexlLy of lnLeroperaLlng wlLh
many parLner sysLems and accommodaLlng pollcy dlfferences.
! A neLwork of hundreds of Lhousands of corporaLe cllenLs LhaL use Lravel and enLerLalnmenL
servlces LhaL comply wlLh corporaLe sLandards - all hosLed ln a cloud - could be consldered a
vlrLual organlzaLlon. Cne can lmaglne !"#$%#&!'($ &($%()'*#!'($% and (!+,"- &),#"'$.+(/%,-
0/$&!'($% LhaL are parL of Lhls small ecosysLem. lnLeracLlons mlghL be complex and somewhaL
long-llved and gulded by buslness pollcles, Lhough Lhe roles/responslblllLles played are llkely Lo
be slmple.
o 8earden Commerce (hLLp://www.reardencommerce.com/) lmplemenLs [usL such a
plaLform LhaL (as of !an 2009) serves over 4000 corporaLe cllenLs and 2 mllllon users
(cllenL cusLomers). lL brlngs LogeLher corporaLe buslness Lravel pollcles, revlews of
Lravel/enLerLalnmenL servlce provlders, expense processlng and reporLlng, eLc., ln a way
LhaL recognlzes llfe of a Lraveler and makes lL easler by ellmlnaLlng Lhe need Lo bulld
dlrecL polnL-Lo-polnL Lraveler Lo servlce provlder relaLlonshlps.
! A vlrLual organlzaLlon could be composed of sclenLlsLs who collaboraLe from Lhelr labs across Lhe
globe ln compuLe- and daLa-lnLenslve lnLeracLlons hosLed ln a cloud. 1hese organlzaLlons Lyplcally
are noL large, buL Lhelr work requlres access Lo an elasLlc seL of compuLe resources for hours aL a
Llme, and Lhe capablllLy Lo manlpulaLe huge daLabases.
! And we could conslder a healLhcare conLexL as an example of an ecosysLem of vlrLual
organlzaLlons LhaL scales Lo be even larger Lhan Lhe user bases of popular soclal neLwork
plaLforms. Members mlghL lnclude healLhcare provlders whose credenLlals musL be Lracked.
aLlenLs musL be able Lo access Lhelr healLh records securely, and auLhorlze access Lo porLlons of
Lhelr charLs Lo oLhers. PealLhcare devlces and appllcaLlons or servlce funcLlonallLy emlL PL7
message sLreams and relaLed evenLs LhaL resulL ln updaLlng paLlenL charLs, lnformlng care
provlders of procedure resulLs, communlcaLlng bllllng lnformaLlon Lo hosplLal bllllng sysLems and
lnsurance provlders, measurlng quallLy of care, and keeplng each member of a care provlder
group lnformed of all acLlvlLles and Lhe correspondlng ouLcomes LhaL occur whlle Lhey care for a
paLlenL who mlghL be physlcally locaLed ln anoLher counLry.
o PL7 appllcaLlon messaglng proLocols are evolvlng from belng ASCll/speclal characLer
dellmlLed proLocols (v2.x) Lo belng xML-based (v3.x). lrom a Lechnology polnL of vlew,
PL7's evoluLlon Lo xML ls very complemenLary Lo Web servlce orlenLaLlon, Lhough lL
does noL force sLandardlzaLlon of PL7 messages as yeL, we hope LhaL lL wlll brlng abouL
sLandardlzaLlon as v3.x becomes more wldely adopLed. use of xML (and xSL1) also
complemenLs a sLraLegy Lo enrlch daLa passed ln messages ln a more sLandard (daLa
exLenslon polnL) fashlon, maklng lL posslble for parLlclpanLs ln mulLlparLy lnLeracLlons Lo
pass lnformaLlon LhaL Lhey care abouL (buL maybe no oLher parLlclpanL does) along wlLh
sLandard lnformaLlon useful Lo all parLlclpanLs ln Lhe lnLeracLlon. lurLher, because xML
sLrucLure can be made very expllclL, enforcemenL of buslness pollcles ls more easlly
enabled.
Cloud compuLlng musL (and ln some cases already does) address Lechnlcal challenges Lo accommodaLe
Lhese organlzaLlonal forms, lncludlng Lhe followlng:
! 1he number of machlnes ln a cloud servlng hundreds of mllllons of users can reach Lens of
Lhousands of machlnes physlcally dlsLrlbuLed across mulLlple daLa cenLers, where lL also may be
necessary for daLa cenLer capaclLy Lo splll over Lo sLlll oLher daLa cenLers. lalled servers ln such a
large-scale envlronmenL have Lo be dlscoverable and cannoL lmpacL Lhe capablllLles of Lhe Cloud
ln aggregaLe, falled cloud componenLs musL be adopLed as !"#$%&'( and noL !"#$#)*#+!,&%.
! lalled compuLers have Lo be replaced (vlrLually) by oLhers LhaL are walLlng ln lnvenLory for
auLomaLlc conflguraLlon and deploymenL.
! SLorage models wlll have Lo be reconsldered, slnce lL may be expedlenL Lo use masslvely
dlsLrlbuLed sLorage schemes ,%$-..,!,&%$!& Lhe cenLrallzed relaLlonal and hlerarchlcal models now
ln use. We are seelng Lhe beglnnlngs of such wlLh Amazon's and MlcrosofL's offerlngs (uslng
Padoop-llke sLorage models), and Lhe Coogle llle SysLem. 8ackup and 8ecovery" Lakes on new
meanlngs wlLh dlsLrlbuLed flle sysLems. SLorage faulL Lolerance llkely wlll be lmplemenLed
dlfferenLly ln large clouds Lhan ln smaller enLerprlse clouds.
! SecurlLy managemenL sysLems mlghL have Lo be federaLed. Access conLrol schemes wlll have Lo
accommodaLe global user bases securlng servlce meLhods LhroughouL Lhe cloud. 1here also are
global consLralnLs Lo be consldered: some counLrles do noL wlsh daLa relaLlng Lo Lhelr clLlzens Lo
be hosLed ouLslde of Lhelr naLlonal boundarles.
! We ofLen Lhlnk of neLwork Lrafflc aLLrlbuLed Lo sysLems managemenL Lo be small ln comparlson
Lo Lhe Lrafflc generaLed by user lnLeracLlons wlLh hosLed buslness funcLlonallLy. ManagemenL of
clouds and Lhelr componenLs, especlally clouds conLalnlng buslness funcLlonallLy managed wlLh
exLernallzed buslness and lnfrasLrucLure pollcles, may have Lo be federaLed as a funcLlon of Lhe
slze of Lhe cloud Lo manage a more appreclable amounL of managemenL-relaLed neLwork Lrafflc.
! /&(+0#!# LesLlng wlll be dlfflculL Lo lmposslble Lo perform ln a very large and dynamlc cloud
conLexL, so lL ls llkely LhaL new LesL meLhods and Lools wlll be requlred.
1he range of cloud-relaLed vlrLual organlzaLlon use cases noLed above leverage Lhe cloud compuLlng
lnsLanLlaLlons we see ln Lhe markeL, and makes clear LhaL Lhe demand ls lmmlnenL for cloud compuLlng Lo
serve as Lhe lnfrasLrucLure and uLlllLy servlce grld for a user consLlLuency LhaL ls much larger and varled
Lhan we've seen Lo daLe. We see Lhe flrsL slgns of such ln soclal neLworklng plaLforms and Lhe success LhaL
Lhey en[oy as measured by number of users. lL wlll be only a maLLer of Llme when we see LhaL buslness
lnLeracLlons wlll be conducLed ln buslness neLwork group conLexLs where buslness pollcy, roles,
responslblllLles, and funcLlonallLy converge ln a new Lype of cloud archlLecLure.
CCnCLuul nC 8LMA8kS
12!&%&(,*$*&(+2!,%3, Lhough vlewed wlLh susplclon or dlsbellef ln Lhe pasL years, can be senslbly applled
Lo Cloud CompuLlng ln a way LhaL wlll be useful when developlng cloud archlLecLures capable of susLalnlng
and supporLlng ecosysLem-scaled plaLforms. We suspecL LhaL Lhls wlll become Lhe norm as adopLlon of
cloud compuLlng lncreases and as soclal neLwork plaLforms LranslLlon Lo lnclude buslness capablllLles.
Cloud compuLlng as we see lL emerglng Loday ls somewhaL amorphously deflned, maklng lL dlfflculL Lo
form a polnL of vlew abouL Lhe capablllLles of currenLly avallable cloud compuLlng lnsLances Lo manage
nexL-cenLury plaLforms. Whlle lL ls clear LhaL Lhey can manage Loday's common plaLforms, we see
archlLecLural challenges for Lhe fuLure LhaL we belleve wlll be dlfflculL Lo address uslng currenL cloud
archlLecLures and archlLecLure sLyles. We ldenLlfy Lechnlcal challenges - lncludlng archlLecLure sLyle, user
and access conLrol managemenL, Lhe need Lo have exLernally managed buslness and lnfrasLrucLure
pollcles Lhrough lnLeracLlon conLalners, and Lhe need for uLlllLy CompuLlng capablllLles - LhaL musL be
addressed Lo meeL fuLure archlLecLure requlremenLs.
Almlng aL lmplemenLaLlon of an !"#$%$&!' plaLform wlll Lake us beyond Lhe managemenL capablllLles of
currenL cloud offerlngs. Addlng archlLecLure componenLs llke Lhe lnLeracLlon conLalner and exLernallzed
pollcy englne wlll lmprove cloud capablllLles, buL unLll Lhese become fundamenLal componenLs ln cloud
archlLecLure, lL ls unllkely LhaL a cloud wlll be able Lo manage Lhe concerns of a servlce grld. lL ls
lnLeresLlng Lo noLe, however, LhaL Lhe consLrucL of a servlce grld enables lL Lo manage Lhe concerns of a
cloud. A servlce grld, as an auLonomlc archlLecLure LhaL ls hardened Lo be boLh a servlce-orlenLed
Lechnology plaLform and a buslness plaLform, can be expecLed Lo scale boLh downward Lo supporL
enLerprlse archlLecLures ()* upward and ouLward Lo supporL Lhe Lypes of archlLecLures llkely Lo be
pervaslve ln LwenLy-flrsL-cenLury compuLlng.
PealLhcare represenLs an area where we belleve servlce grld compuLlng and nexL-generaLlon
archlLecLures wlll prove Lo be lnvaluable. PealLhcare sysLems world-wlde are dlfflculL Lo manage and
archlLecLurally exLend, and Lhey cerLalnly are dlfflculL Lo lnLegraLe. unlfylng lnformaLlon across healLhcare
faclllLy boundarles ls noL only an lnformaLlcs problem, buL also an archlLecLure problem LhaL, lf noL
addressed, wlll hlnder naLlonal healLhcare agendas ln Lhe unlLed SLaLes and elsewhere
8
. We wlll dlscuss a
servlce grld-enabled healLhcare plaLform archlLecLure ln deLall ln a subsequenL paper.
A8Cu1 1PL Au1PC8S
1homas 8 (1om) Wlnans ls Lhe prlnclpal consulLanL of ConcenLrum lnc., a professlonal sofLware
englneerlng and Lechnology dlllgence consulLancy. Pls cllenL base lncludes Warburg lncus, LLC and Lhe
uelolLLe CenLer for Lhe Ldge. 1om may be reached Lhrough hls WebslLe aL hLLp://www.concenLrum.com.
!ohn Seely 8rown ls Lhe lndependenL co-chalrman of Lhe uelolLLe CenLer for Lhe Ldge, where he and hls
uelolLLe colleagues explore whaL execuLlves can learn from lnnovaLlon emerglng on varlous forms of
edges, lncludlng Lhe edges of lnsLlLuLlons, markeLs, geographles and generaLlons. Pe ls also a vlslLlng
Scholar and Advlsor Lo Lhe rovosL aL 1he unlverslLy of SouLhern Callfornla. Pls WebslLe ls aL
hLLp://www.[ohnseelybrown.com.

8
Cne of Lhe flrsL efforLs of whlch we are aware Lo solve access conLrol/role-responslblllLy problems ln healLhcare
sysLems as Lhese relaLe Lo managemenL of blomedlcal lnformaLlon ln a servlce grld ls belng conducLed by ur. Carl
kesselman and ur. SLephan Lrberlch aL lSl/uSC's Medlcal lnformaLlon SysLems dlvlslon. WlLhouL doubL, lSl's work wlll
be crlLlcal Lo Lhe lmplemenLaLlon of servlce grld-based nexL-generaLlon healLhcare sysLems.

i
1he vlslon of AuLonomlc CompuLlng, by !effrey C kepharL and uavld M Chess, l8M 1homas ! WaLson 8esearch
CenLer, 2001
ii
AuLonomlc CompuLlng ManlfesLo, hLLp://www.research.lbm.com/auLonomlc/manlfesLo/auLonomlc_compuLlng.pdf,
lnLernaLlonal 8uslness Machlnes CorporaLlon 2001
iii
Web Servlces 2.0, by 1homas 8 Wlnans and !ohn Seely 8rown, uelolLLe, 2008
iv
ldenLlLy ManagemenL, by 8lll Coleman, Worklng aper, 2009
v
Servlce Crlds: 1he Mlsslng Llnk ln Web Servlces, by !ohn Pagel lll and !ohn Seely 8rown, Worklng aper Serles, 2002
vi
8eyond 8elng 1here: A 8lueprlnL for Advanclng Lhe ueslgn, uevelopmenL, and LvaluaLlon of vlrLual CrganlzaLlons,
naLlonal Sclence loundaLlon, May 2008
!
MCvl nC lnlC8MA1lCn 1LCPnCLCC? LA1lC8MS 1C
1PL CLCuuS
l nSl CP1S l n1C l 1 LA1lC8M A8CPl 1LC1u8L 18AnSlC8MA1l Cn

23 A8l L 2009

l n18CuuC1l Cn
1he Long-1erm CredlL 8ank (L1C8) of !apan underwenL a very LraumaLlc reorganlzaLlon beglnnlng ln 1998
followlng !apan's economlc collapse ln 1989. 1he bank was beseL wlLh dlfflculLles rooLed ln bad debLs.
osslble mergers wlLh domesLlc banks were proposed, buL Lhe bank evenLually was sold Lo an
lnLernaLlonal group, whlch seL abouL puLLlng Lhe bank back LogeLher, launchlng lL ln !une 2000 as Shlnsel
8ank, LlmlLed (Shlnsel).
L1C8's l1 lnfrasLrucLure was malnframe based, as many banks' lnfrasLrucLure was aL Lhe Llme (and sLlll ls).
AcqulslLlons and organlc growLh resulLed ln a varleLy of dlfferenL sysLems supporLlng slmllar bank card
producLs. Among Lhe many challenges wlLh whlch Lhe bank had Lo grapple as lL began lLs new llfe was l1
lnfrasLrucLure consolldaLlon, whlch, ln parL, LranslaLed lnLo decldlng how Lo consolldaLe bank card
producLs and Lhelr supporLlng l1 sysLems !"#$%&#' (&)#$*)' +",)&-#"%.' #%' "#,' /0.1' 23"*.#*3*. 1he bank 2%&3+
have lssued a .*! card represenLlng bank card feaLures and beneflLs of lLs lndlvldual producLs
consolldaLed lnLo a slngle one, buL Lhls would have vlolaLed Lhe consLralnL Lo noL furLher dlsrupL lLs cllenL
base, rlsklng loss of more cllenLs. Cr lL could have conLlnued Lo accepL Lhe enLlre bank card producLs as lL
had ln Lhe pasL buL, aL Lhe same Llme, flnd a way Lo LransparenLly consolldaLe sysLems and appllcaLlons
supporLlng Lhese cards lnLo a very reduced seL of sysLems - ldeally one sysLem - LhaL would enable Lhe
reLlremenL of many oLhers.
ln sum, Shlnsel Look Lhls second paLh. ConcepLually, and uslng l1 Lermlnology, Lhe bank vlewed lLs varlous
card producLs as buslness lnLerfaces Lo Shlnsel LhaL lL had Lo conLlnue Lo supporL unLll a card Lype no
longer had any users, afLer whlch Lhe producL (Lhe card Lype) could be reLlred. lurLher, Lo effecL
consolldaLlon, Lhe bank had Lo lmplemenL an l1 appllcaLlon plaLform supporLlng boLh lLs fuLure and lLs
legacy. 1he bank l1 group seL abouL Lhls mlsslon, empowered by Lhe freedom lLs buslness lnLerfaces
provlded, and, over Lhe nexL Lhree Lo flve years, replaced many (poLenLlally all) of lLs malnframe legacy
sysLems uslng appllcaLlons consLrucLed wlLh modern Lechnologles and hosLed on commodlLy hardware
and operaLlng sysLems.
Shlnsel's example ls a dlrecL analog Lo whaL l1 Leams ln corporaLlons Loday musL do Lo Lransform
legacy/exlsLlng 4.,"+*56&#' appllcaLlon plaLforms lnLo 6&#,"+*54.' servlce orlenLed ones LhaL effecLlvely
leverage Lhe capablllLles LhaL are afforded Lhrough use of cloud and servlce grld Lechnologles. We begln
Lhls paper wlLh a very brlef explanaLlon of CuLslde-ln versus lnslde-CuL archlLecLure sLyles, clouds, and
servlce grlds. 1hen we explore sLraLegles for lmplemenLlng archlLecLure LransformaLlons from lnslde-CuL
Lo CuLslde-ln and lssues llkely Lo be encounLered ln Lhe process.
CClnC-lC8WA8u ASSuM1lCnS Anu ulSCLAlML8S
CloballzaLlon, economlc crlses, Lechnology lnnovaLlons, and many oLher facLors are maklng lL lmperaLlve
for buslnesses Lo evolve away from currenL core capablllLles Loward new cores. lurLher, Lhere appear Lo
be lndlcaLors LhaL Lhese buslnesses - lf Lhey are Lo parLlclpaLe ln LwenLy-flrsL-cenLury buslness ecosysLems
for more Lhan [usL a few years - wlll have Lo make more core LranslLlons durlng Lhelr corporaLe llfe Lhan
Lhelr LwenLleLh-cenLury counLerparLs, so Lhe capablllLy Lo leverage Lechnology Lo efflclenLly Lransform ls
lmporLanL Lo corporaLe survlval.
We belleve LhaL clouds, servlce grlds, and servlce orlenLed archlLecLures havlng an CuLslde-ln archlLecLure
sLyle are Lechnologles LhaL wlll be fundamenLal Lo successfully maklng such corporaLe LransformaLlons.
1here are near-Lerm ob[ecLlves, llke Lhe need for cosL and resource efflclency or l1 appllcaLlon porLfollo
managemenL LhaL [usLlfy use of Lhese Lechnologles Lo rearchlLecL and modernlze l1 plaLforms and
opLlmlze Lhe way corporaLlons currenLly deploy Lhem. 8uL Lhere are longer-Lerm buslness lmperaLlves as
well, llke Lhe need for a company Lo be aglle ln comblnlng Lhelr capablllLles wlLh Lhose of Lhelr parLners by
creaLlng a dlsLrlbuLed plaLform, and lL ls aL Lhese corporaLlons we speclflcally LargeL Lhls paper.
Cu1Sl uL- l n Anu l nSl uL- Cu1 A8CPl 1LC1u8L S1?LLS
ArchlLecLure sLyles deflne famllles of sofLware sysLems ln Lerms of paLLerns for characLerlzlng how
archlLecLure componenLs lnLeracL. 1hey deflne whaL Lypes of archlLecLure componenLs can exlsL ln
archlLecLures of Lhose sLyles, and consLralnLs on how Lhey may be comblned. 1hey deflne how
componenLs may be comblned LogeLher for deploymenL. 1hey deflne how unlLs of work are managed,
e.g., wheLher Lhey are LransacLlonal (n-phase commlL). And Lhey deflne how funcLlonallLy LhaL
componenLs provlslon may be composlLed lnLo hlgher order funcLlonallLy and how such can be exposed
for use by human belngs or oLher sysLems.
1he!"#$%&'()*+ archlLecLural sLyle ls lnherenLly Lop-down and emphaslzes decomposlLlon Lo Lhe funcLlonal
level buL noL lower, ls servlce-orlenLed raLher Lhan appllcaLlon-orlenLed, facLors ouL pollcy as a flrsL-class
archlLecLure componenL LhaL can be used Lo govern LransparenL performance of servlce-relaLed Lasks, and
emphaslzes Lhe ablllLy Lo adapL performance Lo user/buslness needs wlLhouL havlng Lo conslder Lhe
lnLrlcacles of archlLecLure worklngs
1
.
1he counLer sLyle,! whaL we call! *+%&'()"#$,! ls lnherenLly boLLom-up! and Lakes much more of an
lnfrasLrucLural polnL of vlew as a sLarLlng polnL, bulldlng up Lo a buslness funcLlonal layer. AppllcaLlon
plaLforms consLrucLed uslng -.&(+$! %(/0(/, 123(-$)1/&(+$(', and 4565+)$&(/ archlLecLure sLyles are Lhose Lo
whlch we apply Lhe generallzaLlon *+%&'()"#$ because Lhey form Lhe basls of enLerprlse appllcaLlon
archlLecLures Loday, and because archlLecLures of Lhese Lypes have llmlLaLlons LhaL requlre
LransformaLlon Lo scale ln a masslve way vls-a-vls CuLslde-ln plaLforms.
lmplemenLaLlon of an CuLslde-ln archlLecLure resulLs ln beLLer archlLecLure layerlng and facLorlng, and
lnLerfaces LhaL become more 2#%&+(%% Lhan '7$7 orlenLed. ollcy becomes more expllclL, and ls exposed ln
a way LhaL makes lL easler Lo change lL as necessary. Servlce orlenLaLlon guldes Lhe lmplemenLaLlon,
maklng lL more feaslble Lo lnLegraLe and lnLeroperaLe uslng commodlLy lnfrasLrucLure raLher Lhan uslng
complex and lnflexlble appllcaLlon lnLegraLlon mlddleware.
As a rule, lL ls slmpler Lo lnLegraLe buslnesses aL funcLlonal levels Lhan aL lower Lechnology layers where
lmplemenLaLlons mlghL vary wldely. Pence we emphaslze decomposlLlon Lo Lhe funcLlonal level, whlch
ofLen ls dlcLaLed by sLandards wlLhln a markeL, regulaLory consLralnLs on LhaL markeL, or even accounLlng
(A/A8/CL) pracLlces.
lor a much more deLalled dlscusslon of CuLslde-ln versus lnslde-CuL archlLecLure sLyles, please see Lhe
worklng paper we call Web Servlces 2.0"
i
.

1
An CuLslde-ln archlLecLure ls a klnd of servlce-orlenLed archlLecLure (SCA) whlch ls fully elaboraLed ln 1homas Lrl's
book called Servlce-CrlenLed ArchlLecLure: ConcepLs, 1echnology, and ueslgn," so we wlll noL dlscuss SCA ln deLall
ln Lhls paper.
CLCuuS Anu SL8vl CL C8l uS
Slnce a wldely accepLed lndusLry deflnlLlon of cloud compuLlng - beyond a relaLlonshlp Lo Lhe lnLerneL
and lnLerneL Lechnologles - does noL exlsL aL presenL, we see Lhe Lerm used Lo mean hosLlng of hardware
ln an exLernal daLa cenLer (someLlmes called lnfrasLrucLure as a servlce), uLlllLy compuLlng (whlch
packages compuLlng resources so Lhey can be used as a uLlllLy ln an always on, meLered, and elasLlcally
scalable way), plaLform servlces (someLlmes called mlddleware as a servlce), and appllcaLlon hosLlng
(someLlmes called sofLware or appllcaLlons as a servlce).
1he poLenLlal of cloud compuLlng ls noL llmlLed Lo hosLlng appllcaLlons ln someone else's daLa cenLer,
Lhough cloud offerlngs can be used ln Lhls way Lo elasLlcally manage compuLlng resources and clrcumvenL
Lhe need Lo buy new lnfrasLrucLure, Lraln new people, or pay for resources LhaL mlghL only be used
perlodlcally. Speclal flle sysLem, perslsLence, daLa lndexlng/search, paymenL processlng, and oLher cloud
servlces can provlde beneflLs Lo Lhose who deploy plaLforms ln clouds, buL Lhelr use ofLen requlres
modlflcaLlons Lo plaLform funcLlonallLy so LhaL lL lnLeroperaLes wlLh Lhese servlces.
8efore Lhe Lerm cloud, Lhe Lerm servlce grld was someLlmes used Lo deflne a managed dlsLrlbuLed
compuLlng plaLform LhaL can be used for buslness as well as sclenLlflc appllcaLlons. Sald sllghLly
dlfferenLly, a servlce grld ls a manageable ecosysLem of speclflc servlces deployed by servlce buslnesses or
uLlllLy companles. Servlce grlds have been llkened Lo a power or uLlllLy grld . always on, hlghly rellable, a
plaLform for maklng managed servlces avallable Lo some user consLlLuency. When Lhe Lerm came lnLo use
ln Lhe l1 domaln, Lhe word servlce was lmplled Lo mean Web servlce, and servlce grld was vlewed as an
lnfrasLrucLure plaLform on whlch an ecology of servlces could be composed, deployed, and managed.
1he phrase servlce grld lmplles sLrucLure. Whlle grld elemenLs, servers LogeLher wlLh funcLlonallLy Lhey
hosL wlLhln a servlce grld, may be heLerogeneous vls-a-vls Lhelr consLrucLlon and lmplemenLaLlon, Lhelr
presence wlLhln a servlce grld lmplles manageablllLy as parL of Lhe grld as a whole. 1hls lmplles LhaL a
capablllLy exlsLs Lo manage grld elemenLs uslng pollcy LhaL ls exLernal Lo lmplemenLaLlons of servlces ln a
servlce grld (aL Lhe mlnlmum ln con[uncLlon wlLh pollcy LhaL mlghL be embedded ln legacy servlce
lmplemenLaLlons). And servlces ln a grld become candldaLes for reuse Lhrough servlce composlLlon,
servlces ouLslde of a grld also are candldaLes for composlLlon, buL Lhe servlce grld only can manage
servlces wlLhln lLs scope of conLrol. Cf course, servlce grlds deflned as we have above are auLonomlc, can
be recurslvely sLrucLured, and can collaboraLe ln Lhelr managemenL of composlLe servlces provlsloned
across dlfferenL grlds.
Clouds and servlce grlds boLh have !"#$%&#'(). ln clouds, !"#$%&#'( ls used Lo mean %* +&($,%-&.'/* &0%1'*
!"#$%&#&#1*$'!2#"-"13* %#/*%44-&!%$&"#* )$%!5). 1he conLalner mlghL hold oLher klnds of conLalners (e.g., a
!2LL/!ava LL appllcaLlon conLalner), buL Lhe cloud conLalner ls &04'(0'%6-', whlch means LhaL Lhe cloud
does noL dlrecLly manage conLalner conLenLs, and Lhe cloud conLenLs do noL parLlclpaLe ln cloud or
conLalner managemenL. ln a servlce grld, !"#$%&#'( ls Lhe means by whlch Lhe grld provldes underlylng
lnfrasLrucLural servlces, lncludlng securlLy, perslsLence, buslness LransacLlon or lnLeracLlon llfe cycle
managemenL, and pollcy managemenL. ln a servlce grld, lL ls posslble for conLenLs &# a conLalner Lo
parLlclpaLe ln grld managemenL as a funcLlon of lnfrasLrucLure managemenL pollcles harmonlzed wlLh
buslness pollcles llke servlce level agreemenLs. lL also ls posslble LhaL pollcy exLernal Lo conLalner conLenLs
can )2%4'
2
how Lhe conLalner's funcLlonallLy execuLes. So a servlce grld conLalner's wall ls permeable vls-
a-vls pollcy, whlch ls a crlLlcal dlsLlncLlon beLween clouds and servlce grlds
3
.

2
1he sense of Lhe word )2%4' ls conslsLenL wlLh how pollcy ls applled ln Lhe Lelecom world where, for example,
bandwldLh mlghL be made avallable Lo users durlng parLlcular Llmes ln Lhe day as a funcLlon of LoLal number of users
presenL.
3
Cloud managemenL Lyplcally ls exposed by Lhe cloud vendor Lhrough a dashboard. vendors llke Amazon also make
funcLlonallLy underlylng Lhe dashboard avallable as Web servlces such LhaL cloud users' funcLlonallLy could
programmaLlcally ad[usL resources based on some lnLernal pollcy. A servlce grld ls consLrucLed Lo acLlvely manage
lLself as a uLlllLy of pooled resources and funcLlonallLy for all grld users. Pence, a servlce grld wlll requlre lnLeracLlon
A !"#$%, as deflned by Lhe cloud Laxonomy noLed earller, &'()#*()+!+'',-&".(,('+-/&!+(0-&%. 1here ls noLhlng
ln cloud deflnlLlons LhaL requlre all servlces hosLed ln Lhem Lo be manageable ln a conslsLenL and
predeLermlned way
4
. 1here ls no pollcy englne requlred ln a cloud LhaL ls responslble Lo harmonlze pollcy
across lnfrasLrucLure and buslness layers wlLhln or across lLs boundarles, Lhough lncreased aLLenLlon ls
belng glven sofLware vendors Lo pollcy-drlven lnfrasLrucLure managemenL. Clouds are noL formed wlLh
reglsLrles or oLher lnfrasLrucLure necessary Lo supporL servlce composlLlon and governance.
Powever, a servlce grld can be formed by lmplemenLlng a cloud archlLecLure, addlng consLralnLs on cloud
sLrucLure, and addlng consLralnLs on buslness and lnfrasLrucLure archlLecLure layers so LhaL Lhe resulL can
be managed as boLh a Lechnology ,)% a buslness plaLform.
lor a much more deLalled dlscusslon of archlLecLures ln clouds and servlce grlds, please see Lhe worklng
paper we call uemysLlfylng Clouds: Lxplorlng Cloud and Servlce Crld ArchlLecLures"
ii
.
A8CPl 1LC1u8L 18AnSlC8MA1l Cn
Pow Lo consLrucL an CuLslde-ln archlLecLure LhaL meeLs nexL cenLury compuLlng requlremenLs ls a Loplc
LhaL requlres debaLe. Should we leverage our pasL lnvesLmenLs ln lnfrasLrucLure, bespoke sofLware
developmenL, and

Lhlrd parLy sofLware producLs? lf so, how can we self-fund Lhls and how long wlll lL
Lake? Cr do we go back Lo Lhe l1 fundlng well wlLh raLlonale LhaL defends our need now Lo develop a new
servlce plaLform and [eLLlson LhaL mulLlmllllon-dollar lnvesLmenL we [usL barely flnlshed paylng off?
1he answer ls &*(%+1+)%'. We've seen boLh approaches Laken. And we've seen LhaL developmenL of a new
plaLform ls no longer as drasLlc as lL sounds.
18AnSlC8MlnC An LxlS1lnC A8CPl1LC1u8L
lL ls enLlclng Lo Lhlnk LhaL one could lmplemenL an CuLslde-ln archlLecLure slmply by wrapplng an exlsLlng
lnslde-CuL appllcaLlon plaLform wlLh Web servlce Lechnologles Lo servlce-enable lL.
noL qulLe.
lL &' posslble Lo do LhaL ,)%( *2+) evolve Lhe lnslde-CuL archlLecLure Lo an CuLslde-ln one as budgeL and
oLher resources allow uslng a sLraLegy very slmllar Lo Shlnsel's 3$'&)+''(&)*+-4,!+('*-,*+0. dlscussed ln Lhe
lnLroducLlon of Lhls paper. 8uL Lhe facL LhaL an lnslde-CuL archlLecLure Lyplcally ls )#* servlce-orlenLed -
even Lhough lL mlghL be posslble Lo access appllcaLlon funcLlonallLy $'&)0 Web servlces - suggesLs LhaL
[usL uslng Lhe wrapper sLraLegy wlll noL yleld Lhe beneflLs of a full CuLslde-ln archlLecLure lmplemenLaLlon,
and compensaLlon for lnslde-CuL archlLecLure llmlLs may even be more cosLly Lhan Laklng an alLernaLlve
approach.
1o lllusLraLe Lhe process of converLlng an lnslde-CuL archlLecLure Lo an CuLslde-ln one, we conslder how a
Lyplcal Web appllcaLlon plaLform could be converLed Lo an CuLslde-ln archlLecLure ln whlch some Web
appllcaLlon accesses all crlLlcal buslness funcLlonallLy Lhrough a Web servlces layer, and Web servlces are
hosLed ln a cloud, a servlce grld, or lnLernally.
lrom a layered perspecLlve, a Web appllcaLlon usually can be descrlbed by a graphlc of a Lhree-Llered
archlLecLure llke Lhe one below.

wlLh funcLlonallLy LhroughouL Lhe grld and deLermlne wlLh Lhe use of pollcy exLenslon polnLs wheLher resource supply
should be ad[usLed.
4
1hls should noL suggesL LhaL clouds and elemenLs ln Lhem are noL managed, because Lhey are. Servlce grlds,
however, lmpose an auLonomlc, acLlve, and pollcy-based managemenL sLraLegy on all of Lhe elemenLs wlLhln Lhelr
scope of conLrol so LhaL heLerogeneous appllcaLlon and Lechnology lnfrasLrucLure can be managed Lhrough a common
lnLerface LhaL can be applled Lo flne-gralned grld elemenLs as deslred or necessary.

!"#$%&'('
AL Lhe Lop of Lhe graphlc we see a user lnLerface layer, whlch usually ls lmplemenLed uslng some Web
server (llke MlcrosofL's llS or Apache's P11 Web server) and scrlpLlng languages or servleL-llke
Lechnologles LhaL Lhey supporL. 1he second layer, Lhe buslness loglc layer, ls where all buslness loglc
programmed ln !ava, C#, vlsual 8aslc, and php/pyLhon/perl/Lcl (or plck your favorlLe programmlng
language LhaL can be used Lo code llbrarles of buslness funcLlonallLy) ls puL. 1he daLa layer ls where code
LhaL manlpulaLes baslc daLa sLrucLures goes, and Lhls usually ls consLrucLed uslng ob[ecL and/or relaLlonal
daLabase Lechnologles. All of Lhese layers are deployed on a server conflgured wlLh an operaLlng sysLem
and neLwork lnfrasLrucLure enabllng an appllcaLlon user Lo access Web appllcaLlon funcLlonallLy from a
browser or rlch lnLerneL cllenL appllcaLlon.
1he blue and red llnes lllusLraLe LhaL buslness and daLa loglc someLlmes are commlngled wlLh code ln
oLher layers of Lhe archlLecLure, maklng lL dlfflculL Lo modlfy and manage Lhe appllcaLlon over Llme (code
LhaL ls spread ouL and copled all over Lhe archlLecLure ls hard Lo malnLaln). ldeally, Lhe red and blue llnes
would noL exlsL aL all ln Lhls dlagram, so lL ls here where we sLarL ln Lhe process of converLlng Lhls lnslde-
CuL archlLecLure Lo an CuLslde-ln one.
!""#$%%&'()!#*+&,$*,-#$)./0$#&'()/'")1/#,&,&2'&'()
1he flrsL sLep of LranslLlonlng from one archlLecLure sLyle Lo anoLher ls Lo correcL mlsLakes relaLlng Lo
layerlng wherever posslble. 1hls requlres code Lo be cleaned and commenLed, refacLored, and
consolldaLed so LhaL lL ls packaged for reuse and orderly deploymenL, and so LhaL cross-layer vlolaLlons
(e.g., daLabase speclflcs and buslness loglc are removed from Lhe ul layer, or buslness loglc ls removed
from Lhe daLa layer) are ellmlnaLed.
Assumlng layerlng vlolaLlons are addressed, lL makes sense Lhen Lo lnLroduce a servlce appllcaLlon
programmlng lnLerface (Al) beLween Lhe user lnLerface Layer and Lhe 8uslness Loglc Layer as shown ln
Lhe sllghLly modlfled layer dlagram below:

!"#$%&'('
1he servlce layer lllusLraLed here ls poslLloned beLween Lhe user lnLerface and lower archlLecLure layers
as Lhe !"#$ means of accesslng lower level funcLlonallLy. 1hls means LhaL Lhe concerns of one archlLecLure
layer do noL become or compllcaLe Lhe concerns aL oLher levels.
8uL whlle we may have cleaned up layerlng archlLecLure vlolaLlons, we may noL have cleaned up
%&'()()!")"* vlolaLlons. +&'()()!")"* refers Lo Lhe componenLlzlng" or modularlzlng" of buslness
funcLlonallLy such LhaL a componenL ln one buslness funcLlonal domaln (e.g., order managemenL)
accesses funcLlonallLy ln anoLher such domaln (e.g., lnvenLory managemenL) Lhrough a slngle lnLerface
(ldeally uslng Lhe approprlaLe servlce Al). Lnsurlng LhaL common lnLerfaces are used Lo access buslness
funcLlonallLy ln oLher modules ellmlnaLes Lhe use of prlvaLe knowledge (e.g., prlvaLe Als) Lo access
buslness funcLlonallLy ln anoLher domaln space. arLlLlonlng also may be referred Lo as ,&-(!')"*. When
LranslLlonlng Lo a new archlLecLure sLyle, Lhe flrsL sLage of parLlLlonlng ofLen ls lmplemenLed aL Lhe
8uslness Loglc Layer, resulLlng ln a modlfled archlLecLure deplcLed as follows:

!"#$%&')'
1he nexL phase of LransformaLlon focuses aLLenLlon on parLlLlonlng funcLlonallLy ln Lhe daLabase so LhaL,
for example, slde effecLs of lnserLlng daLa lnLo Lhe daLabase ln an area supporLlng one buslness domaln
does noL also publlsh lnLo or oLherwlse lmpacL Lhe daLabase supporLlng oLher buslness domalns.
!"#$%&$'&$()*"$'+&),-./$
8ecause lL ls posslble Lo LranslLlon Lhe archlLecLure ln llgure 1 Lo become llke one of Lhe deplcLlons below.
llgure 4 lllusLraLes a well-organlzed plaLform LhaL mlghL be cenLrally hosLed.

!"#$%&'('

llgure 3 lllusLraLes a well organlzed plaLform LhaL could be hosLed ln a servlce grld or even many servlce
grlds.


!"#$%&'('
llgures 4 and 3 make lL slmple Lo see LhaL servlces and Lhelr supporLlng buslness loglc and daLa
funcLlonallLy could be replaced easlly wlLh an alLernaLlve servlce lmplemenLaLlon wlLhouL negaLlvely
lmpacLlng oLher areas of Lhe archlLecLure, !"#$%&'&()*+)(funcLlonallLy ln one servlce domaln ls accessed by
anoLher servlce domaln #,-.( )*"#/0*( )*'( 1'"$%2'( %,)'"3+2'. And such capablllLy ls requlred ln order Lo
slmpllfy managemenL of an appllcaLlon porLfollo lmplemenLed on such an archlLecLure as well as
dlsLrlbuLe and federaLe servlce lmplemenLaLlons.
45)'",+-%6%,0(7#-%2.(
1he nexL sLep Loward lmplemenLlng an CuLslde-ln archlLecLure ls Lo exLernal boLh buslness and
lnfrasLrucLure pollcles from any of Lhe funcLlonallLy provlslonlng servlces lllusLraLed ln Lhe flgures above.
Cur use of Lhe word !#-%2. connoLes consLralnLs placed upon Lhe buslness funcLlonallLy of a sysLem,
harmonlzed wlLh consLralnLs on Lhe lnfrasLrucLure (hardware and sofLware) LhaL provlslons LhaL
funcLlonallLy. 1hese consLralnLs could lnclude accounLlng rules LhaL buslnesses follow, role-based access
conLrol on buslness funcLlonallLy, corporaLe pollcy abouL Lhe maxlmum allowable hoLel room raLe LhaL a
nonexecuLlve employee could purchase when uslng an onllne reservaLlon servlce, rules abouL peak
buslness Lrafflc LhaL deLermlne when a new vlrLuallzed lmage of an appllcaLlon sysLem should be
deployed, and Lhe varlous lnfrasLrucLural pollcles LhaL mlghL glve cusLomer 8 preference over cusLomer 9
should crlLlcal resource conLenLlon requlre such.
7#-%2.( '5)',1%#,( !#%,)1 provlde Lhe means by whlch pollcy consLralnLs are exposed Lo buslness and
correspondlng lnfrasLrucLural
5
funcLlonallLy and lncorporaLed lnLo Lhelr execuLlon. 1hey are noL

5
8ob Clngell and Lhe CassaLL Leam are lncorporaLlng pollcy lnLo Lhelr nexL-generaLlon uLlllLy compuLlng plaLform,
called SkyneL. ln Lhelr parlance, pollcy prlmlLlves represenL meLrlcs used by pollcy exLenslon polnLs ln supporL of
managemenL as a funcLlon of appllcaLlon demand, appllcaLlon servlce levels, and oLher pollcy-based prlorlLy lnpuLs,
such as LoLal cosL. 1he pollcy-based approach Lo managemenL ls belng lmplemenLed so LhaL lnfrasLrucLure pollcy can
conflguraLlon polnLs LhaL are usually known ln advance of when an appllcaLlon execuLlon sLarLs and LhaL
sLay consLanL unLll Lhe appllcaLlon resLarLs. 8aLher, pollcy exLenslon polnLs are dynamlc and laLe bound Lo
buslness and lnfrasLrucLural funcLlonallLy, and Lhey provlde Lhe poLenLlal Lo !"#$%&'$((" )*$+, execuLlon
of lL wlLhln Lhe deploymenL envlronmenL's runLlme.
LxLernallzlng pollcy hlghllghLs a slgnlflcanL dlsLlncLlon beLween lnslde-CuL and CuLslde-ln archlLecLure
sLyles. lnslde-ouL archlLecLures usually lnvolve legacy appllcaLlons ln whlch pollcy ls embedded and Lhus
exLernallzlng lL ls - aL besL - very dlfflculL. Where appllcaLlon pollcles dlffer ln Lyplcal corporaLe
envlronmenLs, lL becomes Lhe responslblllLy of lnLegraLlon mlddleware Lo lmplemenL pollcy ad[udlcaLlon
loglc LhaL may work well Lo harmonlze pollcles over small numbers of lnLegraLed sysLems, buL Lhls wlll noL
generallze Lo manage pollcy ln larger numbers of appllcaLlons as would be Lhe case ln larger value chalns.
1o lllusLraLe Lhe problem of scallng sysLems where pollcy ls dlsLrlbuLed LhroughouL lL, conslder Lhe sysLem
lllusLraLed ln llgure 6.

!"#$%&'('
llgure 6 lllusLraLes a sysLem where buslness pollcy exlsLs ln mulLlple locaLlons of Lhe archlLecLure as
lndlcaLed by areas ouLllned ln red. Scallng Lhls archlLecLure would be dlsasLrous because pollcy would be
dlsLrlbuLed as coples (or, worsL case, as dlfferenL code bases) over a very complex deploymenL

be connecLed Lo buslness servlce level agreemenLs. 1hls wlll be fundamenLal Lo auLomaLlng resource allocaLlon,
servlce prlorlLlzaLlon, eLc., when cerLaln buslness funcLlonallLy ls lnvoked or when usage Lrends deLermlne need. Such
capablllLy wlll prove lnvaluable as Lhe number of elemenLs wlLhln a cloud or servlce grld becomes large.
envlronmenL. 8uL a well-facLored envlronmenL llke Lhe ones lllusLraLed ln llgures 4 and 3 have buslness
loglc locaLed ln a slngle loglcal archlLecLure layer and, from lL, pollcy can be exLernallzed wlLh Lhe
developmenL of adapLers or slmllar archlLecLure componenLs LhaL play Lhe role of pollcy exLenslon polnLs
descrlbed above. Cnce Lhls ls accompllshed, Lhe archlLecLure we sLarLed wlLh now beglns Lo resemble Lhe
archlLecLure lllusLraLed ln llgure 7 below, ln whlch pollcy has been exLernallzed, posslbly federaLed, and
puL under Lhe conLrol of pollcy managemenL servlces. Cnce pollcy from buslness funcLlonallLy ls
exLernallzed, lL can be harmonlzed wlLh lnfrasLrucLure pollcy as feaslble/deslred.

!"#$%&'('
!"#$%&'()*+##$'&%,'-(*./(&,'-(%$',0*1',2*34-5#-6',"7*8"9:'&"6*
1he flnal sLep ln Lransformlng an lnslde-CuL plaLform Lo an CuLslde-ln plaLform ls Lo replace ;/6'("66*
%##$'&%,'-(*&-<"*,2%,*&--9<'(%,"6*'(:-&%,'-(*-=*5/$,'#$"*6"9:'&"6 wlLh &-5#-6',"*6"9:'&"*lf Lhls ls posslble.
ln llgure 7 we use Lhe Lerm &-5#-6',"* 6"9:'&" Lo mean buslness servlces formed by comblnlng oLher
buslness servlces (or meLhods Lhereof) LogeLher Lo form coarse (larger) buslness funcLlons LhaL are peer
wlLh appllcaLlon funcLlonallLy. lor example, we mlghL see servlces Lo manage order fulflllmenL, lnvolce
submlsslon and paymenL processlng, orchesLraLlons wlLh whlch bllllng sLaff use Lo prepare for lnvolclng,
loglsLlcs plannlng, and so forLh. As a klnd of menLal mapplng beLween llgures 1 and 7, Lhe composlLe
servlce funcLlonallLy ln llgure 7 maps Lo buslness loglc LhaL has $"%>"< lnLo Web pages of Lhe Web
appllcaLlon ln llgure 1 (shown wlLh red and blue llnes) LhaL are used Lo manage order fulflllmenL, lnvolce
submlsslon, eLc.
CrchesLraLlon ls ofLen equaLed Lo workflows used Lo coordlnaLe some orderlng of servlce meLhod
lnvocaLlons. Workflow and oLher buslness process managemenL Lechnologles are now well-known wlLhln
Loday's corporaLlons. Workflow englnes for Web servlces have been commodlLlzed Lhrough open source
lnlLlaLlves and by commerclal sofLware vendors. 1hese englnes make lL posslble Lo lmplemenL composlLe
Web servlces as elLher sLaLe machlne or sequenLlal workflows. use of sLaLe machlne flows makes lL
posslble Lo avold prescrlpLlvely dlcLaLlng how sysLems lnLeroperaLe. 1hey also provlde Lhe opporLunlLy Lo
lncorporaLe human lnLelllgence Lasks Lo help resolve excepLlon condlLlons LhaL ofLen emerge from
composlLe servlces or sLralghL Lhrough processlng flows
6
.
S1A81lnC l8CM SC8A1CP - MA?8L LASlL8 1C uC, 8u1 SCML1lMLS PA8u 1C SLLL
Many ClCs and l1 execuLlves hope LhaL Lhe cosLs and rlsks of Lransformlng a legacy plaLform archlLecLure
Lo an CuLslde-ln one can be amorLlzed over Llme, and who can blame Lhem. MosL have probably spenL a
conslderable sum developlng Lhe currenL archlLecLure, so Lhe lasL Lhlng any l1 execuLlve wanLs Lo ask for ls
new budgeL sufflclenL Lo fund sLlll more lnfrasLrucLure-level acLlvlLles or requlre Lhelr companles Lo
choose beLween new funcLlonallLy or resolved lnfrasLrucLure lssues.
8uL we have experlenced many changes ln Lhe Lechnology world durlng Lhe lasL 20 years LhaL sLrongly
suggesL Lhere ls value ln aL leasL conslderlng wheLher lmplemenLlng CuLslde-ln archlLecLures from scraLch
would be worLhwhlle. An lnLeresLlng caLch here ls LhaL Lhls argumenL could have been made and !"#
made aL each new sLage of developmenL over Lhe lasL 20 years. $%&' (#' )%*' #)+,&' -+!' #+' .(//*,*-)0
8ecause Loday's conLexL versus [usL a few years ago ls quallLaLlvely dlfferenL. SlgnlflcanL broadband
capaclLy, economlc sLorage (boLh self- and cloud-hosLed), cheap memory and modern cachlng servlces,
commodlLy 64-blL operaLlng sysLems, xML acceleraLors and sophlsLlcaLed appllcaLlon proLocol
managemenL capablllLles, commodlLlzed lnLegraLlon/lnLeroperablllLy Lechnologles, vlrLuallzaLlon and
uLlllLy compuLlng, cloud and servlce grld compuLlng, and oLher relaLlvely recenL lnnovaLlons challenge Lhe
LradlLlonal wlsdom LhaL lL ls beLLer Lo evolve and exLend an exlsLlng plaLform Lhan lL ls Lo creaLe a new one
LhaL could clrcumvenL problems from reLroflLLlng an exlsLlng archlLecLure ln ways qulLe counLer Lo lLs
orlglnal deslgn.
Coupled wlLh Lhese advances are elaboraLlons of lndusLry domalns ln Lhe form of (-.1#),& or 21#(-*##'
#+31)(+-' 4"5#. 1hese maps are used by consulLlng companles and sofLware vendors Lo provlde buslness
process orlenLed vlews of lndusLry, deflne roles played and responslblllLles performed wlLhln buslness
processes, begln (aL leasL) Lo bulld ouL funcLlonal decomposlLlons of Lhe lndusLry domaln, and map
processes Lo Lechnology soluLlons where feaslble. uslng Lhese maps as sLarLlng polnLs sLreamllnes process
and daLa mapplng efforLs LhaL used Lo Lake monLhs Lo even several years Lo perform (ln larger
companles), and resulLs ln a deLalled funcLlonal vlew LhaL ls necessary Lo bulld a well-formed CuLslde-ln
archlLecLure.
61(3.(-7'/,+4'#8,")8%'(#',*"33&'-+)')%*'#"4*'"#'#)",)(-7'!()%'-+)%(-7'21)'"'23"-9'#%**)'+/'5"5*,. Whlle lL ls
unusual Lo flnd a company able Lo Lake a purely greenfleld approach (unless lL ls a sLarLup), Lhere are ways
for esLabllshed buslnesses Lo geL comforLable wlLh Laklng a greenfleld approach Lo developlng an CuLslde-
ln archlLecLure, and subsequenLly developlng a sLraLegy Lo lmplemenL lL even lf uslng componenLs of
exlsLlng plaLforms.
CCnCLuul nC 8LMA8kS
1ransformlng an lnslde-CuL archlLecLure Lo an CuLslde-ln archlLecLure can be a lengLhy process - lL ls a
funcLlon of exlsLlng sysLem complexlLy, slze, and age. Cne company who shared wlLh us lLs experlences
when maklng such a LranslLlon was 8earden Commerce (8earden). rlor Lo Lhree and a half years ago,
8earden's archlLecLure was composed llke many of Lhe Web appllcaLlons we see Loday: Lhree-Llered, open
source Web and appllcaLlon server Lechnologles, and a relaLlonal daLabase. 8earden's Web appllcaLlon
exposed a framework Lo whlch merchanL cllenLs could lnLerface Lo 8earden servlces" or funcLlons.
8earden's managemenL Leam had Lhe foreslghL Lo recognlze Lhe company's need Lo creaLe a plaLform (noL
[usL an appllcaLlon), and Lhe correspondlng need Lo make archlLecLure changes Lo supporL more rapld

6
ulLlmaLely, lL may prove necessary Lo lncorporaLe a consLralnL englne lnLo Lhe way LhaL servlces are composlLed Lo
harmonlze pollcles and dynamlcally govern execuLlon of Lhe composlLe.
developmenL and slmpler deploymenL of new servlces. 8y Lhls Llme, 8earden already had cllenLs, so lL
undersLood LhaL change had Lo be made LransparenLly Lo lLs user base whenever posslble or ln a way LhaL
Lhe user base vlewed as a poslLlve upgrade of capablllLy Lo whlch Lhey could mlgraLe as dolng so became
expedlenL Lo Lhelr buslness.
8earden sLrengLhened lLs leadershlp Leam wlLh LechnologlsLs who had parLlclpaLed ln Web servlce
lnfrasLrucLure companles and could gulde ln 8earden's archlLecLure modernlzaLlon. 1hls new leadershlp
Leam underLook a LransformaLlon of Lhe company's Lhree-Llered archlLecLure Lo a servlce-orlenLed one
over a Lwo-year perlod uslng a process llke Lhe one descrlbed above. AL Lhe end of Lhe Lwo-and-a-half-
year perlod, 8earden had Lransformed lLs LradlLlonal Web appllcaLlon archlLecLure Lo a servlce orlenLed
one wlLh exLernallzed pollcy managemenL.
When performlng an archlLecLure LransformaLlon, ls lL necessary LhaL !"" archlLecLure componenLs are
#$%&'#"( Lransformed - as was Lhe case wlLh 8earden? lf Lhere was queue-based mlddleware ln Lhe old
archlLecLure, should lL be replaced? Should all )"* appllcaLlons be replaced wlLh cusLom appllcaLlons
havlng approprlaLe pollcy exLenslon polnLs?
1he answer Lo Lhese quesLlons ls &%+ *#,#$*-. CerLalnly lL ls posslble Lo replace enLerprlse appllcaLlon
lnLegraLlon Lechnologles wlLh commodlLy or open source Lechnologles, slmpllfy Lhem, or maybe - ln some
cases - even ellmlnaLe Lhem. lL ls unllkely LhaL mlddleware supporLlng rellable messaglng and long-llved
buslness LransacLlons beLween buslness parLners needs Lo be LoLally replaced ln or removed from an
CuLslde-ln archlLecLure. 8uL lLs use can be couched ln ways LhaL ellmlnaLe LlghL coupllng beLween
parLners, and commlngllng of buslness pollcy wlLh lnLegraLlon funcLlonallLy LhaL makes parLner lnLegraLlon
dlfflculL Lo change as pollcles change or as a parLner neLworks expand.
1aklng an CuLslde-ln polnL of vlew requlres LhaL we separaLe concerns from Lhe sLarL. AppllcaLlon
plaLforms should be vlewed as dlsLrlbuLed from Lhelr beglnnlng raLher Lhan be made so afLer Lhe facL by
aLLachlng some dlsLrlbuLlon layer Lo Lhem. We musL undersLand how we have permlLLed buslness securlLy
and access conLrol models Lo be bullL lnLo our archlLecLures and how, now LhaL Lechnology lnnovaLlons
enable us Lo challenge Lhese llmlLs, we musL remove Lhem from our compuLlng plaLforms Lo reallze
buslness aglllLy goals LhaL wlll be demanded of an archlLecLure ln Lhe LwenLy-flrsL-cenLury. 1echnologles
we've used ln Lhe pasL can be useful Lo us ln Lhe fuLure. Success ln lmplemenLlng an CuLslde-ln
archlLecLure ls less a funcLlon of Lechnology Lhan lL ls of a buslness and Lechnology archlLecLure vlslon LhaL
forces buslness and Lechnology archlLecLs Lo vlew buslness capablllLles from a global, ouLslde ln and Lop
down perspecLlve.
A8Cu1 1PL Au1PC8S
uelolLLe colleagues explore whaL execuLlves can learn from lnnovaLlon emerglng on varlous forms of
edges, lncludlng Lhe edges of lnsLlLuLlons, markeLs, geographles, and generaLlons. Pe ls also a vlslLlng
Scholar and Advlsor Lo Lhe rovosL aL 1he unlverslLy of SouLhern Callfornla. Pls WebslLe ls aL
hLLp://www.[ohnseelybrown.com.

i
Web Servlces 2.0, by 1homas 8 Wlnans and !ohn Seely 8rown, uelolLLe, 2008
ii
uemysLlfylng Clouds: Lxplorlng Cloud and Servlce Crld ArchlLecLures, by 1homas 8 Wlnans and !ohn Seely 8rown,
uelolLLe, 2009

MC1l vA1l Cn 1C LLvL8ACL CLCuu Anu SL8vlCL C8lu
1LCPnCLCCl LS
Al n Cl n1S 1PA1 CLCuuS Anu SL8vl CL C8l uS Auu8LSS

26 MA? 2009

ln18CuuC1lCn
lL was SepLember 2008 when Larry Llllson was asked abouL wheLher Cracle would pursue a cloud vlslon.
Pls response aL Lhe Llme was LhaL Cracle would evenLually offer cloud compuLlng producLs. 8uL ln Lhe
same conversaLlon, Mr. Llllson also noLed - ln hls lnlmlLable fashlon - LhaL cloud compuLlng was such a
commonly used Lerm as Lo be !"!#$%&"
lalr commenL, acLually, glven LhaL cloud compuLlng !' such an overloaded Lerm. lL can be used as a
synonym for #()'#(*$+","-)-, $+.)+*, /#')!.0. lL can be used Lo deflne whaL Salesforce.com and neLSulLe
do - Lhey offer '#1)2-*+, -', -, '+*3!$+. Some have referred Lo Lhe lnLerneL as )/+, $4#(", 5, an uber-cloud
conLalnlng all oLhers. Cloud compuLlng someLlmes ls lmpreclsely used Lo reference 0*!", $#67()!.0 for
daLabase resource managemenL or masslvely parallel sclenLlflc compuLlng. And cloud compuLlng has been
Laken Lo mean )!6+, '/-*!.0, whlch ls boLh a sLyle of buslness and a Lechnology sLraLegy LhaL soughL Lo
share expenslve compuLlng resources across corporaLe boundarles aL aLLracLlve prlce polnLs. lL appears #.,
)/+,'(*1-$+ LhaL Lhe l1 lndusLry /-' redeflned much of whaL lL does now -.",/-',"#.+,1#*,8(!)+,-,2/!4+,as
cloud compuLlng, and LhaL Cracle lndeed mlghL need only Lo change verblage ln a few of lLs ads Lo allgn
Lhem wlLh a well-formed cloud vlslon.
8uL Loday's l1 leaders are operaLlng ln a buslness cllmaLe ln whlch lnLense commodlLlzaLlon and change
force deploymenL of .+2 l1-enabled buslness processes and requlre acknowledgemenL LhaL buslness
processes and archlLecLures LhaL are flxed/rlgld ln Lhelr deflnlLlon wlll noL scale Lo large neLworks of
pracLlce, LhaL l1 budgeLs may have reached Lhe polnL where convenLlonal lnLernal cosL cuLLlng can wrlng
ouL only nomlnal addlLlonal value unless buslness and l1 processes change, and LhaL "#!.0, 9('!.+'',
!.)+*.-)!#.-44% ls .#) Lhe same as $#."($)!.0, 04#9-4, 9('!.+'' (l.e., ouLsourclng ls noL equlvalenL Lo
organlzlng and conducLlng global buslness). So, whlle Mr. Llllson's remarks may express Lhe senLlmenLs of
many l1 leaders Loday who have spenL a conslderable amounL on lnfrasLrucLure, Lhey $-..#) be correcL
(.4+'' Lhe processes and Lechnlques developed ln l1 durlng Lhe pasL 20 years wlll be Lhe foundaLlon for
processes and Lechnlques of Lhe nexL 20 years.
:+,"#,.#),9+4!+3+,)/-),)2+.)!+)/;$+.)(*%,<=,)/!.>!.0,$-.,#*,'/#(4",9+,)/+,"+,1-$)#,1#(."-)!#.,1#*,)2+.)%;
1!*');$+.)(*%, <=, 7*-$)!$+'. We belleve LhaL now, more Lhan ever before, l1 maLLers, and lL has already
become Lhe crlLlcal cenLer of buslness operaLlons Loday. As such, l1 leaders have no cholce buL Lo
conLlnue Lo chase cosL and margln opLlmlzaLlon. 1hey -4'# have no cholce buL Lo carefully seL and
navlgaLe a course Lo renovaLe and/or replace )2+.)!+)/;$+.)(*%, pracLlces wlLh 1#*, )2+.)%;1!*');$+.)(*%
pracLlces and Lechnologles so LhaL producL llnes and servlces LhaL companles offer Loday can remaln
relevanL Lhrough slgnlflcanL markeL LranslLlons.
1hls paper ls Lhe flrsL ln a seL of Lhree LhaL aLLempL Lo esLabllsh a LhoughL framework around cloud
compuLlng, lLs archlLecLural lmpllcaLlons, and mlgraLlon from currenL compuLlng archlLecLures and hosLlng
capablllLles Lo cloud compuLlng archlLecLures and hosLlng servlces. We begln by explorlng Lhree l1 paln
polnLs LhaL can be addressed by cloud and servlce grld compuLlng. SubsequenL papers more compleLely
elaboraLe Lhese paln polnLs and meLhods Lo handle Lhem.
l1 Aln Cln1S
1here probably ls a very large number of !"#$%&'#$(&')* LhaL l1 leaders ln Loday's corporaLlons would wanL
Lo see addressed by cloud and servlce grld compuLlng. We hlghllghL Lhree ln Lhls paper:
! uaLa CenLer ManagemenL
! ArchlLecLure 1ransformaLlon and LvoluLlon (evolvlng currenL archlLecLures or beglnnlng from
scraLch)
! ollcy-based ManagemenL of l1 laLforms
Aln Cln1: uA1A CLn1L8 MAnACLMLn1
!"##$%&: 1he challenges of managlng a daLa cenLer, lncludlng neLwork managemenL, hardware
acqulslLlon and currency, energy efflclency, and scalablllLy wlLh buslness demands, all are cosLly Lo
lmplemenL ln a way LhaL easlly expands and conLracLs as a funcLlon of demand. Also, as buslnesses
aggregaLe and collaboraLe ln global conLexLs, daLa cenLer scalablllLy ls consLralned by cosL, Lhe ablllLy Lo
efflclenLly manage envlronmenLs and saLlsfy regulaLory requlremenLs, and geographlc llmlLaLlons. Addlng
Lo Lhls complexlLy, Lhe need Lo manage change demanded by Loday's changlng global and corporaLe
cllmaLes underscores Lhe need for Lransformlng Lhe ways LhaL we manage daLa cenLers: meLhods of Lhe
pasL 3 Lo 10 years do noL scale and do noL provlde Lhe requlsLe aglllLy LhaL ls now needed.
'()"*+ ,)("-.)/,: Cloud soluLlons can form Lhe basls of a nexL generaLlon daLa cenLer sLraLegy, brlnglng
aglllLy, elasLlclLy, and economlc vlablllLy Lo Lhe fore:
! Affordable elasLlclLy, scalablllLy
o 8esource opLlmlzaLlon Lhrough vlrLuallzaLlon
o ManagemenL dashboards slmpllfy responses evoked by seasonal peak uLlllzaLlon
demands or buslness expanslon
o llner-gralned conLalner managemenL capablllLles (e.g., CassaLL's) wlll serve Lo flne Lune
elasLlclLy pollcles
o CapablllLy Lo affordably deploy many currenL Lechnology-based appllcaLlons as Lhey
exlsL Loday, posslbly Lo rearchlLecL Lhem over Llme
o Mlnlmlzed caplLal ouLlay, whlch ls especlally lmporLanL for sLarLups, where lnlLlal
fundlng ls way Loo llmlLed Lo use Lo caplLallze lnfrasLrucLure
o LxLreme elasLlclLy - handllng splkes of Lrafflc sLemmlng from someLhlng caLchlng on or
golng vlral" (e.g., havlng Lo scale from 30 Lo 3000 servers ln one day because of Lhe
power of soclal medla)
! Affordable and alLernaLlve provlslonlng of dlsasLer recovery
o Cloud daLa sLorage schemes provlde a dlfferenL way Lo perslsLenLly sLore cerLaln Lypes
of lnformaLlon LhaL make expllclL daLa repllcaLlon unnecessary (sLorage ls
dlsLrlbuLed/federaLed LransparenLly)
1

o CreaLlon of vlrLual lmages of an enLlre Lechnology sLack sLreamllnes recovery ln Lhe
evenL of server fallure

1
lL ls lnLeresLlng Lo conslder Lhe lmpllcaLlons LhaL new cloud perslsLence schemes can have on reglsLrles llke publlc
unS and Web servlce reglsLrles. Were Lhese reglsLrles Lo be hosLed ln a cloud, lL mlghL be posslble Lo reLhlnk Lhelr
lmplemenLaLlon so as Lo slmpllfy underlylng daLabase repllcaLlon and sLreamllne propagaLlon of reglsLry updaLes.
o uLlllLy compuLlng managemenL plaLforms enable conslsLenL managemenL across daLa
cenLer boundarles. LvoluLlon of uLlllLy compuLlng Lo enable cloud composlLlon wlll
slmpllfy lmplemenLaLlon of fallover sLraLegles
! Affordable sLaLe-of-Lhe-arL Lechnology
o 1he exponenLlal naLure of dlglLal hardware advances makes Lhe challenge of keeplng
hardware currenL parLlcularly vexlng. 8uylng cloud servlces Lransfers Lhe need Lo keep
hardware currenL Lo Lhe cloud vendor - excepL, posslbly, as Lhls applles Lo malnframe or
oLher legacy Lechnologles LhaL remaln vlable
" lL ls reasonable Lo expecL cloud vendors Lo offer speclallzed hardware
capablllLles (e.g., uS/Cu/SM capablllLles) over Llme ln supporL of
gamlng/graphlcs, parallel/mulLlLhreaded appllcaLlons, eLc.
" Speclallzed hardware needs (e.g., malnframe-based) probably wlll noL be Lhe
responslblllLy of Lhe cloud vendor, buL Lhere ls no reason why a prlvaLe
cloud/servlce grld should noL be able Lo be composed wlLh a publlc
cloud/servlce grld
! CperaLlonal aglllLy and efflclency - cloud vendors wlll oversee managemenL of hardware and
neLwork asseLs aL a mlnlmum. Where Lhey provlde sofLware asseLs or provlslon a servlce grld
ecosysLem, Lhey llkely wlll provlde sofLware sLack managemenL as well
o ManagemenL of asseLs deployed lnLo a cloud ls sLandardlzed. ManagemenL dashboards
slmpllfy Lhe managemenL and deploymenL of boLh hardware and sofLware
! Lnergy efflclency becomes Lhe cloud vendor's challenge. 1he scale of a cloud may well
preclplLaLe Lhe move Lo alLernaLlve coollng sLraLegles (e.g., waLer vs. fan aL hardware
(board/hardware module) levels), alr and waLer coollng of daLa cenLers, lncreased managemenL
sofLware capablllLles Lo lnLeroperaLe wlLh daLa cenLer pollcles Lo conLrol power up/down of
resources and consolldaLe (on fewer boxes) processes runnlng ln a cloud glven Lhe vlslblllLy Lo
uLlllzaLlon, servlce level agreemenLs, eLc. Cne could even lmaglne lmplemenLlng a power sLraLegy
LhaL conLlnuously moves resource lnLenslve appllcaLlons Lo run where power ls less expenslve
(e.g., power mlghL be less expenslve aL nlghL Lhan Lhe day so keep runnlng Lhls appllcaLlon on Lhe
dark slde of Lhe earLh)
! 8lg enLerprlse capablllLles for small company prlces
o SLarLups can use and sLay wlLh cloud soluLlons as Lhey grow and become more
esLabllshed
! Pardware and daLa cenLer cosL-savlngs and sLaff cosL opLlmlzaLlons enable buslnesses Lo self-
fund lnnovaLlve l1 lnlLlaLlves
o 1hose who wlsh Lo leverage Lhe cloud's funcLlonal capablllLles wlll have Lo bulld Lhelr
own capablllLles (e.g., servlces and/or appllcaLlons) Lo lnLeroperaLe wlLh resources ln
Lhe cloud provlded LhaL Lhey wlsh Lo do more Lhan slmply use a cloud as ouLsourced
hosLlng
! SecurlLy compllance (e.g., securlLy of lnformaLlon and daLa cenLer pracLlces, Cl daLa securlLy
compllance) wlll lncreaslngly become Lhe responslblllLy of cloud vendors
o 1hls wlll be Lrue especlally as clouds become/evolve lnLo servlce grlds, as cloud vendors
geographlcally dlsLrlbuLe Lhelr capablllLles, and as speclallzed clouds are provlsloned Lo
serve speclflc lndusLrles!
Aln Cln1: A8CPl1LC1u8L 18AnSlC8MA1lCn/LvCLu1lCn (1PL 88CWnllLLu vS.
C8LLnllLLu CCnunu8uM)
!"##$%&: SlgnlflcanL lnvesLmenL ln appllcaLlon plaLforms ln Lhe lasL 10 years have resulLed ln
heLerogeneous besL-of-breed appllcaLlon sysLems LhaL have proved hard and cosLly Lo lnLegraLe !"#$"%&
'()*()+#,& -(.%/+)",0. Scallng Lhem -,1(%/ corporaLe boundarles lnLo corporaLe neLworks of pracLlce
Lakes lnLegraLlon Lo a level of complexlLy LhaL appears lnsurmounLable, buL Lhe percelved cosLs of sLarLlng
fresh seem equally so. l1 leadershlp knows lL musL do someLhlng abouL Lhe appllcaLlon porLfollo lL has
assembled Lo make lL lnLeroperable wlLh parLner neLworks wlLhouL requlrlng masslve Lechnology
resLrucLure ln unreallsLlcally shorL Llme perlods. lL also knows Lhe buslness musL qulckly respond Lo global
markeL opporLunlLles when Lhey presenL Lhemselves. Pow does l1 Leadershlp gulde Lhe archlLecLural
evoluLlon and LransformaLlon of whaL exlsLs Loday Lo enable rapld-flre response wlLhouL sLarLlng from
scraLch or Lrylng Lo change lLs appllcaLlon plaLform ln unreallsLlc Llme perlods?
'()"*+,)("-.)/,: Cloud soluLlons can form Lhe basls of an appllcaLlon porLfollo managemenL sLraLegy LhaL
can be used Lo address LacLlcal shorL-Lerm needs, e.g., lnLeroperablllLy wlLhln a buslness communlLy of
pracLlce uslng Lhe cloud Lo provlslon communlLy resources, and Lo address Lhe longer-Lerm needs Lo
opLlmlze Lhe appllcaLlon porLfollo and posslbly rearchlLecL lL.
! Cloud vendors offer Lhe capablllLy Lo consLrucL cusLomlzed vlrLuallzed lmages LhaL can conLaln
sofLware for whlch a corporaLlon has llcenses. PosLlng currenL lnfrasLrucLure ln a cloud (where
such ls posslble) provldes an lsolaLed area ln whlch a corporaLlon or corporaLe parLners (probably
on a smaller scale due Lo lnLegraLlon complexlLles assoclaLed wlLh older lnfrasLrucLure and
appllcaLlon Lechnologles) could lnLeroperaLe uslng exlsLlng Lechnologles
o Why would companles do Lhls?
" 1o move qulckly wlLh currenL plaLforms
" 1o economlcally hosL appllcaLlons, mlnlmlze prlvaLe daLa cenLer modlflcaLlons,
and, ln so dolng, self-fund porLfollo opLlmlzaLlon and/or rearchlLecLure work
" use currenL capablllLles, buL shadow Lhem wlLh new capablllLles as Lhey are
developed - ulLlmaLely replaclng new wlLh old
" Slmpllfy archlLecLure by removlng unnecessary movlng parLs
! Cloud vendors offer appllcaLlon funcLlonallLy LhaL could replace exlsLlng capablllLles (e.g., small-
Lo-large L8, C8M sysLems). lncorporaLlng Lhls funcLlonallLy lnLo an exlsLlng appllcaLlon porLfollo
leads Lo lncremenLal re-archlLecLure of appllcaLlon lnLegraLlons uslng newer Lechnologles and
Lechnlques (8rownfleld), whlch, ln Lurn, should resulL ln servlce-orlenLed lnLerfaces LhaL can
become foundaLlonal Lo fuLure sLaLe. An lncremenLal move Loward a rearchlLecLed plaLform
hosLed uslng cloud Lechnologles may prove Lo be Lhe only way Lo mlLlgaLe rlsks of archlLecLural
LransformaLlon whlle keeplng corporaLe buslness runnlng. Conversely, clouds also represenL
locaLlons where Creenfleld efforLs can be hosLed. Creenfleld efforLs are noL as rlsky as Lhey
sound glven Lhe maLurlLy (now) of hosLed plaLforms llke Saleslorce, neLSulLe, eLc.
o Pow qulckly can LransformaLlon of an exlsLlng plaLform be accompllshed? 1hls depends
upon Lhe archlLecLural complexlLy of whaL ls Lo be Lransformed or replaced. A very
complex and LlghLly coupled archlLecLure mlghL requlre several years Lo decouple so
LhaL new archlLecLure componenLs could be added - assumlng no Creenfleld scenarlo ls
deslred or feaslble - whereas lL mlghL be posslble Lo move a slmply sLrucLured Web
appllcaLlon ln a maLLer of hours. A plaLform LhaL has speclallzed hardware requlremenLs
(e.g., Lhere ls malnframe dependency, or dlglLal slgnal processlng hardware ls requlred)
mlghL have Lo be prlvaLely hosLed, or be hosLed parLly ln publlc and parLly ln prlvaLe
clouds
! Cloud appllcaLlon programmlng lnLerfaces (Als), LogeLher wlLh Lhe concepLs of dlsLrlbuLlon,
federaLlon, and servlces LhaL are !"#$%&'(, provlde a foundaLlon on whlch Lo lmplemenL loosely
coupled, servlce-orlenLed archlLecLures and can loglcally lead Lo beLLer archlLecLure
o Web servlces, rellable queulng, and dlsLrlbuLed sLorage (nonrelaLlonal wlLh somewhaL
relaLlonal lnLerfaces, and relaLlonal) provlde foundaLlonal lnfrasLrucLure capablllLles Lo
lmplemenL modern archlLecLures uslng sLandardlzed Als (e.g., WS-*)
o SLandardlzed lnLerfaces, loose archlLecLure coupllngs, and sLandardlzed deploymenL
envlronmenLs and meLhods lncrease reuse poLenLlal by maklng lL easler Lo compose
new servlces wlLh exlsLlng servlces
! Clouds provlde a means Lo deal wlLh heLerogenelLy
o lnlLlally, heLerogenelLy ls dealL wlLh Lhrough managemenL layers
o 8eLLer archlLecLure as noLed above furLher enhances Lhls as heLerogenelLy ls
encapsulaLed beneaLh sLandardlzed and servlce-orlenLed Als
o Cnce heLerogenelLy ls conLalned, a porLfollo opLlmlzaLlon/modernlzaLlon sLraLegy can
be puL lnLo place and lmplemenLed
Aln Cln1: CLlC?-8ASLu MAnACLMLn1 Cl l1 LA1lC8MS
!"##$%&: ollcy consLralnLs are dlfflculL Lo lmposslble Lo lmplemenL especlally ln a rapldly changlng
world/conLexL. 8uslness processes and pollcles are embedded ln monollLhlc appllcaLlons LhaL comprlse
corporaLe buslness plaLforms Loday. Lven Lhe bespoke appllcaLlons consLrucLed ln Lhe pasL 10 years share
Lhls characLerlsLlc slnce pollcy and process were noL LreaLed as formal archlLecLure componenLs.
ConsequenLly, appllcaLlon scalablllLy vls-a-vls provlslonlng pollcy-drlven buslness capablllLles ls llmlLed.
CrganlzaLlonal model changes, e.g., mergers and acqulslLlons (or dlvesLlLures) or corporaLe globallzaLlon
lnLo very loosely coupled buslness neLworks, underscore Lhe need for pollcy Lo be made expllclL. 1he
ablllLy Lo conducL buslness ln a qulckly changlng world wlll be a dlrecL funcLlon of Lhe capablllLy Lo manage
uslng pollcy.
!'%()*'+ ,%)-+ ./0"1)/2.: ln one sense, Lhls paln polnL can be consldered Lo be relaLed Lo Lhe
8rownfleld/Creenfleld Conundrum LhaL, lf addressed, resulLs ln a dlsLrlbuLed/federaLed, servlce-orlenLed,
loosely coupled archlLecLure ln whlch pollcy )"( be facLored ouL and consldered a flrsL-order archlLecLure
componenL. Powever, lL also ls clear LhaL: (1) $*$+,-($ does noL need pollcy facLored llke Lhls, and (2)
where pollcy musL be exposed may vary by domaln, communlLy, geography, eLc. Pence we deal wlLh Lhls
paln polnL separaLely and conslder Lhe need Lo address lL a prerequlslLe condlLlon Lo leveraglng Lhe full
capablllLles of a servlce grld.
CorporaLlons requlre enLerprlse quallLles ln archlLecLures, and Lhey wlll have Lhe same expecLaLlons of
clouds where Lhey wlll deploy crlLlcal plaLforms. Scallng archlLecLures for use ln lncreaslngly larger
communlLles as well as slmply maklng plaLforms LhaL are far more conflgurable and composlLlonal
requlres Lhe ablllLy Lo expose pollcy exLenslon polnLs LhaL can be lncorporaLed lnLo a managemenL
scheme LhaL can lmplemenL and enforce pollcy across Lhe enLlre Lechnology sLack. 1he resulL of such
archlLecLurally pervaslve pollcy managemenL ls LhaL conLrol over envlronmenLal as well as buslness
consLralnLs ls provlsloned. When corporaLe archlLecLures are deployed lnLo servlce grlds, Lhese pollcy
exLenslon polnLs musL be used even ln grlds composed of oLher grlds.
! Cloud vendors are lmplemenLlng ./'0'/,& )-12./'(3 managemenL capablllLles, whlch are,
Lhemselves, pollcy drlven. As Lhese capablllLles are furLher reflned, lL wlll become feaslble Lo
lnLegraLe buslness pollcles wlLh lnfrasLrucLure managemenL pollcles on whlch buslness and
lnfrasLrucLure servlce level agreemenLs/processes can be based
! CuLslde-ln archlLecLures (ln our vlew, servlce-orlenLed archlLecLure properly done) provlslon
lnLerfaces LhaL easlly allgn wlLh buslness processes and mlnlmlze archlLecLure complexlLy,
resulLlng ln a slmpler archlLecLure ln whlch pollcy ls exLernallzed. LxLernallzed pollcy provldes Lhe
opporLunlLy for buslness pollcy Lo [oln wlLh lnfrasLrucLure pollcy
! LxLernallzed pollcy provldes Lhe foundaLlon on whlch pollcy-drlven buslness processes can be
consLrucLed and managed. 1hls resulLs ln lncreased buslness aglllLy because lL slmpllfles how
buslnesses lnLeroperaLe: Lhey lnLeroperaLe aL Lhe buslness process level, and noL aL Lhe
Lechnology level, pollcles can be changed wlLh slgnlflcanLly less lmpacL on Lhe code LhaL
provlslons buslness funcLlonallLy
! Cloud vendors use conLalners Lo deploy funcLlonallLy. As Lhese conLalners become permeable
such LhaL Lhelr conLenLs can boLh be managed and expose pollcy exLenslon polnLs, Lhen pollcles
can span Lhe enLlre cloud and grld Lechnology sLacks
! Servlce grlds provlslon archlLecLure componenLs, e.g., pollcy englnes and lnLeracLlon servlces,
LhaL enable pollcy Lo be managed/harmonlzed expllclLly and separaLely from oLher buslness
funcLlonallLy - across archlLecLure layers, across buslness neLworks of pracLlce - and used as Lhe
foundaLlon of buslness lnLeracLlons
o lL ls lmporLanL Lo noLe LhaL pollcy ls vlewed as a consLralnL conLlnuum coverlng
lnfrasLrucLure managemenL Lo domaln (regulaLory, lndusLry/markeL secLor) pollcy
consLralnLs
CCnCLuulnC 8LMA8kS: 1C 1PL 21
sL
CLn1u8? Anu 8L?Cnu
We see, ln Lhls paper, LhaL cloud compuLlng can be used Lo address LacLlcal problems wlLh whlch l1
conLlnually deals, llke resource avallablllLy and rellablllLy, daLa cenLer cosLs, and operaLlonal process
sLandardlzaLlon. 1hese near-Lerm ob[ecLlves represenL sufflclenL [usLlflcaLlon for companles Lo use cloud
compuLlng Lechnologles even when Lhey have no need Lo lmprove Lhelr plaLforms or pracLlces. 8uL Lhere
are longer-Lerm buslness lmperaLlves as well, llke Lhe need for a company Lo be aglle ln comblnlng Lhelr
capablllLles wlLh Lhose of Lhelr parLners by creaLlng a dlsLrlbuLed plaLform LhaL wlll drlve aggresslvely
Loward cloud and servlce grld compuLlng. We belleve LhaL clouds, servlce grlds, and servlce-orlenLed
archlLecLures are Lechnologles LhaL wlll be fundamenLal Lo LwenLy-flrsL-cenLury corporaLlons' successfully
navlgaLlng Lhe changes LhaL Lhey now face.
1he paln polnLs dlscussed above lllusLraLe a progresslon of change LhaL mosL corporaLlons have already
begun, wheLher Lhey are [usL sLarLlng up or are well esLabllshed. We began wlLh use of cloud hosLlng
servlces as an alLernaLlve Lo self-hosLlng, or as an alLernaLlve Lo oLher currenL day Lhlrd-parLy hosLlng
arrangemenLs LhaL do noL offer aL leasL Lhe poLenLlal of cloud compuLlng. lor Lhose companles LhaL need
Lo pursue lmplemenLaLlon and managemenL of a servlce-orlenLed archlLecLure, we dlscussed paln polnLs
relaLlng Lo rearchlLecLlng currenL plaLforms Lo leverage cloud compuLlng, and Lhe posslble need Lo
formallze Lhe way LhaL pollcy ls used Lo manage l1 plaLforms wlLhln and across servlce grld boundarles.
Many of Lhe concepLs menLloned ln Lhe paln polnL dlscusslons are archlLecLural, and are noL deflned aL all
ln Lhls paper. Powever, Lhey are more compleLely elaboraLed ln our oLher papers, called !"#$%&'($')*+
,-./0%1+234-.5')*+ ,-./0+6)0+7"58'9"+:5'0+;59<'&"9&/5"%, and =.8')*+ >)(.5#6&'.)+?"9<).-.*$+@-6&(.5#%+?.+
?<"+,-./0%1+>)%'*<&%+>)&.+>?+@-6&(.5#+;59<'&"9&/5"+?56)%(.5#6&'.).
A8Cu1 1PL Au1PC8S
uelolLLe colleagues explore whaL execuLlves can learn from lnnovaLlon emerglng on varlous edges,
lncludlng Lhe edges of lnsLlLuLlons, markeLs, geographles, and generaLlons. Pe ls also a vlslLlng Scholar and
Advlsor Lo Lhe rovosL aL uSC. Pls WebslLe ls aL hLLp://www.[ohnseelybrown.com.

Cloud Computing Papers

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cloud Computing Papers

Uploaded by

Copyright:

Available Formats

!"#$%&!

You might also like