Agile Software Architecture

How Much is Enough?

Eoin Woods www.eoinwoods.info

About Me

Software architect at UBS n!est"ent Ban#

res$onsible for s%nthetic e&uit% $latfor" in 'ri"e Ser!ices

Software architect for (10 %ears Author of )Software S%ste"s Architecture* boo# with +ic# ,o-ans#i ASA and B.S /ellow0 E1 "e"ber0 .Eng

20100407 20100407

22

.ontent

2efining Software Architecture Agile 'rinci$les and Software Architecture .ase Stud% of Agile Software Architecture .onclusions and ,eflections

20100407 20100407

33

Defining Software Architecture

20100407 20100407

44

2efining Software Architecture

A co""on definition 4

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements the externally visible qualities of those elements, and the relationships among them 5en Bass0 'aul .le"ents and ,ic# 6a-"an 7SE 8 Software Architecture in 'ractice0 2nd Edition

20100407 20100407

99

2efining Software Architecture

An alternati!e definition 4

The set of design decisions which, if made wrongly, causes your project to be cancelled Eoin Woods www.sei.c"u.edu:architecture:definitions.ht"l

20100407 20100407

;;

Essence of Software Architecture

t is a design based acti!it%

designing so"ething 7a s%ste"0 a $rocess0 48 is #e% a wide constituenc% with $oorl% defined $roble"s %our wor# allows identification of ris#s and o$$ortunities e.g. &ualities rather than detailed functions no right answer : least worst o$tion

t re&uires focus on sta#eholders < their concerns

t addresses s%ste"=wide concerns

t in!ol!es balancing co"$eting concerns

t includes $ro!iding leadershi$

20100407 20100407

Agile Principles and Software Architecture

20100407 20100407

>>

1he Agile Manifesto ?alues

5ess ?alue
.o"$rehensi!e docu"entation .ontract negotiation 'rocesses < tools /ollowing a $lan

20100407 20100407

@@

Architects < agile tea"s share $riorities

/ocus on the consu"ers of the s%ste"s Efficient deli!er% of !aluable software Si"$lification and reduction of cost Aualit% < reliabilit% of deli!ered software Su$$orting efficient change Effecti!eness of co""unication

20100407 20100407

1010

Architecture and Agile 2isagree"ent

)Big U$ /ront 2esign*

$articularl% when architects $roduce large docu"ents

2ocu"ent centric !s. deli!er% centric 2ecision "a#ing !s. deli!er% res$onsibilit% 2ifferent !iews on $rocesses and controls 2iffering ti"e hori-ons for return on in!est"ent Architectural !s. )custo"er* 7user8 $riorities

"ore custo"ers than Bust the end users

Agile deli!eries in larger change $rogra""es

20100407 20100407

1111

Case Study

20100407 20100407

1212

Wh% "iC architecture and agileD

S"all co"$an% creating a new $roduct &uic#l%

needed to get to "ar#et in @ "onths needed 9 new ser!ers fro" scratch $roduct "ust su$$ort nternet scale loads $re!ious $roduct had a bad re$utation for reliabilit%0 su$$ortabilit%0 scalabilit% and $erfor"ance

this had to be sorted out this ti"e around

ser!er engineers were 400 "iles awa% fro" the rest of the engineering tea" 7and the ser!er architect8

and the%Ed Bust been ac&uired fro" another co"$an%F

20100407 20100407

1313

.ase Stud%G A +ew Ser!er /a"il%

Commissioning Service

Cryptographic Services

Authorisation Services

.lients
20100407 20100407

nternet

S%ste" Ser!ers 1414

S%ste" 2atabase s

.ould an )agile* a$$roach hel$D

1he tea" was relati!el% s"all 7(10 de!elo$ers8 1he tea" had do"ain #nowledge alread%

all $re!iousl% wor#ed on si"ilar s%ste"s $rior to ac&uisition

,ange of eC$erience but all HI 1> "onths A $roduct "anager was in $lace

$roduct de!elo$"entEs answer to the )on site custo"er*

Senior "anage"ent didnEt "andate $rocess But where did )architecture* fitD

"aBor refactoring after 1.0 wasnEt an o$tion needed to get s%ste" &ualities right first ti"e needed to "o!e &uic#l% as a coordinated unit

20100407 20100407

1919

.ase Stud%G 6e% ,is#s

1ight ti"escales result in )Bust to do it* a$$roach

danger of frag"ented a$$roach IH unsu$$ortable $roduct. couldnEt build a fra"ewor# to force co""onalit% ti"e for s"all $rotot%$es rather than real 'o.s e.g. $erfor"ance !s. scalabilit% or o$erational control

+o ti"e for a lot of BU/2 and ris# "itigation

/ocusing on so"e areas "ight cause neglect of others

2eli!er% focus could result in "aintenance < o$erational difficulties Jeogra$hical s$lit "ade co""unication difficult

new to the co"$an% so no $rior relationshi$s to fall bac# on

20100407 20100407

1;1;

.ase Stud%G Architecture $ractices 718

2efine co"$onents clearl%

$re!ented o!erla$ or confusion within the architecture hel$ed to $re!ent sco$e cree$

2efine clear design $rinci$les < .a$ture design decisions and rationale

"ade sure the #e% decisions were agreed u$ front onl% bothered with $rinci$les that reall% "attered allowed a shar$ focus on what was actuall% needed

Jood enough "odels and docu"ents

20100407 20100407

1717

AsideG Jood Enough Modelling

What is good enoughD

consider currenc%0 $recision0 detail0 co"$leteness focus at the co"$onent:interface:connection le!el $refer "odels < databases to $ictures be $recise0 e!en when abstract ensure "odels can be u$dated easil% "odel with a $ur$ose 7audience and use8 functional structure0 de$lo%"ent0 infor"ation

EC$erience suggests
K K K K K

Areas to consider
K

20100407 20100407

1>1>

.ase Stud%G Architecture $ractices 728

2efine solutions for cross=cutting concerns

securit% and LA in $articular were standardised sa!ed a lot of redundant design ti"e across the ser!ers architect created a wor#ing de"onstration ser!er be%ond this a $roduction ser!er was also deli!ered no ti"e for an%thing that wasnEt !aluable deli!erables that didnEt get used : read : re!iewed : "odified were for"all% abandoned

2eli!er wor#ing eCa"$les and $rotot%$es

La!e custo"ers for all deli!erables

20100407 20100407

1@1@

.ase Stud%G Architecture $ractices 738

Wor# in the tea"s

the ser!er architect was e"bedded in the ser!er tea" wee#l% tra!el between the sites0 dail% conference calls wor#ing on the $roduction code as well as architecture big hel$ in building "utual res$ect and relationshi$s !er% !aluable feedbac# into the architectural design little ti"e to deli!er% an%thing be%ond the essentials e!er% feature < &ualit% was challenged for !alue the critical re&uire"ents dictated the deli!er% ti"eboCes

Address ,eal Sta#eholder .oncerns

20100407 20100407

2020

AsideG Low to Wor# With 1ea"s

Sol!e their $roble"s

ha!e solutions for integration0 securit%0 2,0 4 i""ediate !alue to de!elo$"ent tea"s ensure the% are understood and agreed

Mointl% de!elo$ %our architectural $rinci$les

.ollaborate rather than $olice

re!iew to share < i"$ro!e0 not to go!ern tea"s own their wor# and should ha!e $ride in it unless in!ited or %ou need to a!ert catastro$he collaboration will "ean that %ou ha!e in$ut an%wa% when in!ited0 %ou #now %ouE!e succeeded
2121

Sta% out of internal decisions

20100407 20100407

.ase Stud%G Architecture 2eli!erables

A ser!er $roduct line architecture

4N1 !iews defined essential co""onalit% and rationale defined standard technolog% defined cross cutting "echanis"s and con!entions defined a standard design $attern for the ser!ers essentiall% the )de!elo$"ent !iew* of the architecture defined i1>n0 logging0 re&uest handling0 technolog% to use0 test a$$roach0 eCce$tion handling0 $roduct configuration0 4 An%thing not here or in the architecture was u$ for grabs architect suffered his own decisions resulted in ra$id refine"ent of the $roduct line architectureF
2222

2e!elo$"ent standards

1he i"$le"entation of one of the ser!ers

20100407 20100407

.ase Stud%G /unctional ?iew

Jatewa% Ser!let

2ata Manage"ent Ser!ice ,ights S%ste" Ser!ice 2,M 6ernel

A$$lication Ser!ice Message 5ogging Ser!ice Ser!ice Manager .onfiguration Ser!ice

20100407 20100407

2323

2e$lo%"ent and 2e!elo$"ent ?iews

.lient +ode

5oad Balancing /irewall

Ser!let Engine 1

.lient +ode

20100407 20100407

2424

.ase Stud%G 'ractices we "issed

2eli!er wor# incre"entall%

the ser!er software was de!elo$ed incre"entall% the architect was largel% done u$ front ti"escales "eant bac#trac#ing was a $roble" so"e "itigation using the )de"onstration ser!er* so"e use of Wi#is0 but "ostl% docu"ents and word of "outh could ha!e greatl% i"$ro!ed this with longer ti"escales architect got bogged down in i"$le"entation detail so"eti"es lost focus on architectural concerns

Share infor"ation si"$l%

/ocus on architectural concerns

20100407 20100407

2929

.ase Stud%G 1he ,esults

Successful because $roduct was deli!ered

first !ersion read% for beta testing within @ "onths de$lo%ed at "aBor "obile "anufacturer test labs Budged to ha!e "et all of its significant re&uire"ents the ser!er de!elo$ers all used it high degree of co""onalit% achie!ed 7little reuse8 $arts of it were refined right through de!elo$"ent c%cle challenge of $roble" forced co""unication architecture $ro!ided conteCt for decisions and discussions so"ething to )rall% around* when dealing with other tea"s architect wor#ing in the tea" had a lot of beneficial results
2;2;

1he architecture was definitel% used

Ser!er tea" beca"e "uch "ore integrated

20100407 20100407

1he 1wel!e ArchitectEs 'ractices

20100407 20100407

2727

Conclusions

20100407 20100407

2>2>

Low do %ou wor# with an agile tea"D

Start with the s"allest a"ount of architecture $ossible

but ha!e an architecture before $roduction iterations are created $articularl% around long ter" concerns and &ualit% $ro$erties a!oid the $roble"s where the tea" will hel$ itself itEs often as "uch about $resentation as substance align with how the tea" is wor#ing

5oo# for the ris#s that the $roBect is facing

Where can architectural design s$ecificall% hel$D

A$$l% architecture $ractices in a s%"$athetic wa%

f %ou canEt find an% "ore benefit which can be )sold* to the tea" and the custo"er0 then %ou ha!e )enough*

20100407 20100407

2@2@

Signs of sufficient architecture

E!er%one can eC$lain the o!erall s%ste" structure Engineers understand their "odules

res$onsibilities0 interfaces0 interactions i"$act of the "odule on the larger whole

A credible argu"ent can be "ade that %ou can $ro!ide all of the i"$ortant &ualities

$erfor"ance0 scalabilit%0 securit%0 ad"inistration0 ... co""on )loo#* to code0 sa"e tools in general use0 reuse of $atterns and software0 docu"entation testing a$$roach0 ...

1here is general agree"ent on standards and nor"s

'eo$le #now how things wor#s and how we do things

20100407 20100407

3030

Architect P ,es$onsibilit% or 'ersonD

Should )architect* Bust be a shared res$onsibilit%D

agile tea"s share res$onsibilit% for "an% things

As alwa%s0 it de$ends on the situation ,easons for ha!ing an architect 7$erson8 include

architect sco$e is often a do"ain not a single s%ste" good designs co"e fro" a s"all nu"ber of "inds not e!er% de!elo$er "a#es a good architect "an% de!elo$ers donEt stud% software architecture "an% architectural concerns need significant focus

But so"e tea"s do fine sharing the res$onsibilit%

20100407 20100407

Su""ar%

1here is no need for agile !s. architecture conflicts

both schools of thought want to achie!e the sa"e thing a little less -eal and a little "ore reflection on both sides though the tea" need to "a#e it $ossible this isnEt about new $ractices0 "ore tailoring $ro!en ones

1he onus is generall% on the architect to fit in

1he $roble" is often $resentation not substance

S$ecific $ractices can address each $art of the agile "anifesto An architect should $lug the ga$s the de!elo$"ent tea" is facing0 not tr% to control e!er%thing

20100407 20100407

3232

Auestions and .o""entsD

Eoin Woods www.eoinwoods.info contactQeoinwoods.info

3333