Sinds de introductie van het begrip agile rond de eeuwwisseling wordt er gepuzzeld hoe het te verenigen is met architectuur. Er lijkt een fundamenteel verschil in doelstellingen te bestaan: architecten zoeken stabiliteit en toekomstvastheid, agilisten zoeken wendbaarheid, een soort toekomst 'los'heid. Om de juiste balans te kunnen vinden moeten zowel agile-aanhangers als architecten hun eigen discipline op een iets andere manier bekijken.
Sommigen vinden onder architectuur en agile werken tegenstrijdig. Het lijdt geen twijfel dat de manier waarop de agile-beweging aankijkt tegen Big Up-Front Design (BUFD) op het eerste gezicht lijnrecht tegenover het werken onder architectuur staat. Deze perceptie van onverenigbaarheid wordt versterkt door het door Philippe Kruchten amusant beschreven verschijnsel dat de agile-beweging zich soms als een religie gedraagt, compleet met dogma’s en verkettering van andersdenkenden (KRUCHTEN2007). Op blogs gaan agile-aanhangers wild tekeer tegen iedere suggestie dat van tevoren nadenken over architectuur soms nuttig kan zijn, of dat niet alle belangrijke (kwaliteits-)eisen achteraf nog kunnen worden ingevuld via het magische ‘refactoren’ van een it-oplossing.
Wie goed kijkt, ziet dat architectuur en agile twee kanten van een spectrum vertegenwoordigen. Waar op het spectrum je project het beste kan verblijven hangt af van de context. Barry Boehm suggereert dat de ideale plaats op dit spectrum afhankelijk is van drie factoren die bepalen hoeveel architectuur vooraf nodig is: de grootte van het project, de veranderlijkheid van de omgeving en de mate waarin de it-oplossing kritiek is voor de bedrijfsvoering (BOEHM2010).
Agilisten kunnen succesvoller worden als ze de projectcontext meenemen in hun oordeel over het nut van architectuur, maar wat kunnen architecten doen om de kloof tussen agile en architectuur van hun kant te dichten? De principes uit het Agile Manifesto zijn lang genegeerd door de architectuur-beweging, althans zo lijkt het als je bijvoorbeeld naar Togaf kijkt, het populaire architectuur-framework van de Open Group. De Togaf Architectuurmethode ADM vereist nog steeds behoorlijk zware documentatie, geproduceerd door vaak logge processen als Business Architecture, Information Systems Architecture en Technology Architecture. Voor een wendbare architectuur-omgeving zijn dit soort EA-aanpakken niet geschikt. In de wereld van de software-architectuur zie je wel langzaam lichtere architectuur-aanpakken opkomen, zoals de ‘Just Enough Software Architecture’-aanpak van George Fairbanks (FAIRBANKS2010). Deze meer wendbare aanpakken zien architectuur niet meer hoofdzakelijk als een ontwerpdiscipline, maar meer als een manier om risico’s te beheersen en met onzekerheden om te gaan.
Een recent beschikbaar gekomen agile architectuur-aanpak is Risk- and Cost Driven Architecture (RCDA) voor solution-architectuur. Deze aanpak is ontwikkeld om het gat tussen enterprise-architectuur en software-architectuur te dichten. Bestaande software-architectuur praktijken zijn namelijk vaak te beperkt voor de complexiteit en scope van de oplossingen die ontworpen moeten worden, maar de enterprise-architectuur praktijken zijn vaak te log voor de wendbaarheid die wordt vereist door tijdsdruk en frequent optredende onzekerheden en veranderingen. De RCDA-aanpak neemt een aantal aspecten uit agile software-ontwikkelmethodes over. Zo werkt de aanpak met een backlog van architectuurvraagstukken die soms dagelijks geherprioriteerd worden op economische gronden.
Het geheim van het agile maken van architectuurwerk zit hem, net als bij agile software-methodes, in het op een andere manier kijken naar wat het werk oplevert. Zo levert een agile software-ontwikkelteam niet een ‘big-bang systeem’, maar een continue stroom van verbeteringen aan een systeem. Op dezelfde manier levert een agile architect niet een ‘big up-front design’, maar een continue stroom van architectuurbeslissingen die stap voor stap de onzekerheden en risico’s rond complexe it-oplossingen onder controle brengen. Hoeveel architectuur er moet worden ingebouwd wordt dan niet bepaald door agile dogma’s als ‘You Ain’t Gonna Need It’ (YAGNI), maar door economische afwegingen die de werkelijke waarde van architectuur bepalen.
Samenvattend, architecten kunnen veel doen om de kloof met agile te dichten. Dat is ook dringend nodig, want anders verliezen architectuurafdelingen alle voeling met it-ontwikkelafdelingen, waar agile werken de norm aan het worden is, en met de business, waar de vraag vandaan komt sneller en beter in te spelen op veranderende (markt)omstandigheden. De belangrijkste verandering die architecten moeten maken is dat ze architectuur niet meer zien als een vooraf aan projecten op te leveren ontwerpdocument, maar als een continu proces van besluitvorming met als doel om risico’s, kosten en onzekerheden onder controle te brengen. Zo kunnen architecten de toegevoegde waarde en flexibiliteit leveren die de business van ze verwacht.
Uitstekend artikel!
Een verademing, dit artikel… na al die BYOD en Cloud artikelen waarin telkens dezelfde problematiek werd besproken.
Ik ben wel benieuwd hoe een architect ‘ingepast’ kan worden in een agile/scrum werkwijze. Is hij/zij bijvoorbeeld lid van een development team?
lastig vak, IT architect. Van onderen moet alles agile, van boven ook. Mag jij daar een stevig fundament voor bakken 🙂
Deze “stress” vind je tegenwoordig op steeds meer plekken. Denk maar eens aan beheer, daar herken je hetzelfde fenomeen. Klassiek beheer is op zoek naar stabiliteit, betrouwbaarheid enz. Terwijl de ontwikkelingen elkaar in een rap tempo opvolgen. De uitdaging van de toekomst denk ik maar zo eens.
Een best leuk stuk maar ook wat theoretisch want veel organisaties, vooral de multi-nationals zijn het resultaat van allerlei fusies en overnamen. Er is dus veelal geen sprake van 1 architectuur maar meerdere. Onderzoek en besluit naar best passende oplossing wordt ook niet altijd objectief genomen. Architectuur is hier vaak een verdedigend gevecht door eerdere investeringen.
De oplossing: “If duct tape doesn’t work, use more duct tape” kom je dus nogal vaak tegen in architecturen. Bovenkant in de vorm van presentatielaag naar de business telt nu eenmaal zwaarder dan de integratie aan de onderkant. En het gaat vaak al mis bij de requirements omdat goedkoop (kosten), flexibel (onzekerheden) en betrouwbaar (risico) niet te verenigen zijn. In mijn opinie kan een architect dus uiteindelijk ontwerpen voor:
1. Fit for business – de strategische keuzen
2. Fit for purpose – de tactische keuzen
3. Fit for cost – de operationele keuzen
Architecten moeten dus niet de kloof tussen agile dichten maar het gat wat er zit tussen theorie en praktijk. Ondertussen heeft de business namelijk al weer een andere richting gekozen met concepten als cloud en BYO. Kieren en gaten kunnen we net als in bouw proberen te dichten met PUR maar daar wordt het uiteindelijk niet steviger van.
Eltjo, bedankt voor dit artikel. Veel links naar bronnen en onderbouwing, super.
Voor mij was het zelfs een a-ha momentje met betrekking tot de verschillende architecten. Je hebt me inzichten gegeven die ik hiervoor nog niet had.
“Samenvattend, architecten kunnen veel doen om de kloof met agile te dichten. Dat is ook dringend nodig, want anders verliezen architectuurafdelingen alle voeling met it-ontwikkelafdelingen, waar agile werken de norm aan het worden is, en met de business, waar de vraag vandaan komt sneller en beter in te spelen op veranderende (markt)omstandigheden”
Hier ben ik het helemaal mee eens.
En als je bijvoorbeeld kijkt naar hoe Microsoft vorige week nogmaals benadrukte dat ze met “rapid releases” gaat werken en dat dit vanaf nu standaard is onderbouwd dit je punt.
Ik heb nu weer genoeg leesvoer op mijn lijstje staan. Meer graag.
Eltjo, ik heb 2 jaar geleden nog de SAPC cursus van jou gehad waar RCDA werd besproken. Daar kwam Agile helemaal niet ter sprake als voordeel van RCDA en kregen we zelfs een computer based presentatie van SEI waar Agile/Scrum werd afgeserveerd. Er werd ons verteld dat architectuurbeslissingen die dus ook in RCDA terug kwamen bijzonder moeilijk aan te passen zijn. Het fundament onder een huis pas je ook niet zomaar aan als je bezig bent de muren te metselen. Daarnaast werd RDCA met name ingezet op Bid-trajecten. Wat is er in die 2 jaar veranderd? Of heb ik gewoon niet goed op zitten letten? Ik zou jouw stukje graag eens een keer in de praktijk willen zien.
Ik ben het overigens wel met je eens dat de architecten de kloof met Agile teams moeten dichten net als de opmerkingen dat die kloof van 2 kanten gedicht moet worden. De meeste technische uitdagingen zijn ook vrij makkelijk te tackelen met standaard architectuur. Er wordt vaak veel te moeilijk gedaan door architecten die vanuit een ivoren toren veel te abstract blijven.
Stof tot nadenken Eltjo, dank!
Agile en architecture behoren samen te gaan. Ik heb diverse organisaties gezien waar de architect met de product owner richting geeft aan agile teams. Met architectuurkeuzes gericht op de klantbehoeften van de huidige en volgende sprints, en ook rekening houdend met wat daarna mogelijk gaat komen. Goede discussies over technical debt, flexibele architectuur, het kan.
@MichelMartens Alles Agile, als ik het lees ga ik bijna denken dat agile een synoniem is geworden voor ad hoc de plannen kunnen aanpassen. Dat levert inderdaad stress op. En chaos. Maar wat je schrijft over systeem en applicatiebeheer: zorgen voor stabiliteit en betrouwbaarheid is klasiek. Maar dit zou toch altijd het streven moeten zijn? Ik ben benieuwd wat je bedoelt met ‘ontwikkelingen die elkaar in rap tempo opvolgen’? Of refereer je hiermee aan de laatste trends zoals continous delivery en devops? Software productie via de lopende band.
Architectuurkeuzes hoeven volgens mij niet zo agile te zijn. De keuze voor een voorkeurstaal voor ontwikkeling mag best een paar jaar geldig blijven. Flexibiliteit prioriseren boven kosten (of andersom) idem.
De keuze om agile te ontwikkelen is op zich al een architectuurkeuze. En soms moet je —als de omgeving zich daar niet toe leent— ook bewust besluiten om te blijven watervallen.
Langzaam veranderende architectuur en agile ontwerpen zijn volgens mij dan ook niet in tegenspraak met elkaar. Integendeel.