Voor de Via Open Space van 22 oktober met als onderwerp agile architectuur  willen wij graag het thema agile architectuur producten uitwerken? Graag wil ik van jullie horen wat jullie ideeen zijn bij dit subthema van agile architectuur. Vandaar dat  ik hoop dat er hieronder een levendige discussie ontstaat.

Agile en architectuur producten kent meerdere dimensies, twee belangrijke dimensies zijn

  • het op agile wijze vervaardigen van architectuur producten zoals project architecturen, principes, standaards en richtlijnen en referentie architecturen.
  • de voorwaarden die worden gesteld aan agile architectuur producten als het vervolgtraject een agile ontwikkel- en implementatietraject is.

Bij het laatste punt zie je dat een architect op een andere wijze de architectuur onder de aandacht moet gaan brengen. Een PSA zal bijvoorbeeld een andere opbouw, indeling en detaillering kennen bij een agile vervolgtraject. Dit om de eenvoudige reden dat bepaalde aspecten van de architectuur aan het begin van een agile ontwikkeltraject gewoon nog niet uitgewerkt zijn.

Vragen die bij me opkomen zijn:

  • Hoe zien architectuur producten eruit binnen een agile omgeving
  • Welke architectuuraspecten dienen bij de start van een implementatie wel uitgewerkt te zijn, welke moeten benoemd zijn en welke worden in de loop van het traject nader uitgewerkt.
  • In hoeverre is een beschrijvende architectuur nog interessant in een agile omgeving of kunnen we volstaan met een architectuurschets en een voorschrijvende architectuur op hoofdlijnen.

 

Weergaven: 374

Reactie van Ed van der Winden op 25 September 2012 op 17.07

Hallo Bert,

Ik zou aan de twee dimensies die je noemt nog een extra punt toe willen voegen. Jij noemt ten eerste het proces (agile wijze van vervaardigen) en ten tweede vraag je je af in hoeverre een "traditionele" architectuur er t.b.v. een agile ontwikkeltraject er anders uit zou moeten zijn.

Ik zou toe willen voegen dat ik denk dat er bij een "pure" agile ontwikkeling wellicht helemaal geen sprake meer is van een architectuur onafhankelijk van het product (jouw laatste vraag schuurt tegen dit punt aan). Als je agile ontwikkelt en je bent met een team steeds bezig om daadwerkelijk producten op te leveren die in productie kunnen worden genomen, dan is er minder en minder sprake van een afzonderlijke architectuur- en ontwikkelfase.

In de praktijk kan dit op verschillende manieren uitpakken:

1) Je kunt denken aan mini-trajecten, waarbij je voor elke oplevering nog steeds een architectuurfase en een ontwikkelfase onderscheidt. Je zou dan bijvoorbeeld een PSA kunnen maken met een zeer beperkte scope.

2) Je kunt ook denken aan een situatie waarbij in elke opleverslag de focus op het eindproduct ligt en dat er tijdens een dergelijke slag alleen over architectuuraspecten wordt nagedacht die direct hun nut hebben in de oplevering waar je dan mee bezig bent. De vraag is dan in hoeverre je nog met architectuur bezig bent.

Hoe dan ook is er in beide gevallen sprake van een vorm van Just-In-Time architectuur die niet verder kijkt (niet naar de toekomst en niet naar mogelijke uitbreidingen van de scope) dan de onmiddellijke toegevoegde waarde.

---

Mijn punt hierboven gaat nog steeds vooral over het proces. Een heel andere, en zeer interessante vraag is ook hoe een "agile oplossing" er precies uit ziet. Het gaat dan niet over architectuur in de zin van een ontwerp dat gerealiseerd moet worden, maar over architectuur in de zin van de globale kenmerken van een gerealiseerd product. Een agile oplossing moet (het woord zegt het al) een zekere mate van flexibiliteit hebben; een belangrijke deelvraag is dan in hoeverre we met zijn allen redundantie dan wel standaardisatie na moeten streven.

Ik vind dit een heel interessant onderwerp en ik ben net als jij Bert benieuwd naar bijdragen van anderen.

Tot zover,

Ed

Reactie van Bert Dingemans op 28 September 2012 op 19.28

Hallo Ed,

Interessante toevoegingen, je reactie over globale elementen triggert de gedachte dat we vanuit architectuur voorafgaand aan een agile traject mogelijk wel een aantal kaders moeten stellen voor het project, bijvoorbeeld een aantal principes stellen of algemene richtlijnen (die zijn er wel in elke ICT omgeving) en tijdens het project alleen een beschrijving te maken van delen waarbij die beschrijving toegevoegde waarde heeft

 

Bert

Reactie van Atilla Vigh op 22 Oktober 2012 op 14.21

Wat ook zou kunnen helpen is om heel duidelijk te definieren wanneer een Agile manier van werken past.

Ik kan mij niet aan de indruk onttrekken dat alle projecten vanaf nu op de "Agile manier moeten" lopen.

Zelf komende uit de IT-Infrastructuur wereld besef ik het grootste verschil tussen de software ontwikkeling wereld (waar Agile vandaan komt) en de IT-Infrastructuur wereld: de eerste is een pure dienstverleningswereld, waarbij in de IT-Infrastructuur wereld er kapitaalgoederen (servers, storage, networking,etc...) bij komt kijken. Hoewel je tegenwoordig met "Cloud" een aardig eind zou kunnen komen door klein te beginnen en groot te eindigen, of mee te ademen met je behoefte, zijn we nog lang niet zo ver als iedereen in de Cloud wereld suggereert. Met andere woorden het effect van dit verschil is dat ik op voorhand meer moet investeren dan ik dat bij een Software ontwikkeling traject doe (daar kan ik alleen uren verliezen als ik het fout doe). Hard- en software teruggegeven dat bestaat niet! Dus de business case voor grootschalige ICT projecten is anders als er een significante component IT-Infrastructuur in zit en derhalve is dan de vraag of een Agile manier van werken misschien niet de meest voor de hand liggende.

Nou ben ik absoluut geen software ontwikkelaar, maar heb vaak genoeg meegemaakt dat sommige database ontwerpen (relationele met name) niet te pas en te onpas kunnen worden aangepast. En wat je natuurlijk niet wilt is dat na iedere 3 a 4 iteraties steeds een compleet nieuw datamodel gaat introduceren, met alle migratie perikelen van dien.


Ik zoek eigenlijk criteria waarop het gebruik van Agile manier van werken tbv architectuur een goede keus is. Dit zal vermoedelijk ook de discussie over producten vereenvoudigen. Overigens denk ik nu niet dat we het verschil van de staande en veranderende organisaties moeten wijzigen. Voor mij is Agile (en ik ruil hem zo in als iemand mij kan overtuigen van het tegendeel) architectuur ontwikkelen niets anders architectuur bedrijven maar dan middels een ander proces (vergeleken met een watervalmethode, ie, Top-Down). Het totale project moet een keer een eind hebben en zal daarna worden ingebed in de staande organisatie. De producten uit het project zijn mijns inziens dezelfde als die je normaal hanteert.

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden