Good Ideas - Agile en architectuur

Twee jaar geleden maakte mijn collega Daan Kalmeijer een 4 minuten durende animatie waarin hij de essentie van agile perfect wist neer te zetten. Het zet ook de relatie met architectuur op scherp. En dat leidt niet bij iedereen tot dezelfde conclusies heb ik gemerkt.


In dit filmpje legt Daan uit dat de traditionele benadering een aantal waarden vertegenwoordigt die op zich niet slecht zijn, maar dat al die waarden bij elkaar topzwaar zijn geworden. In de stijl van het Agile Manifesto: “de traditionele waarden zijn belangrijk, maar de nieuwe waarden vinden we net iets belangrijker”.

Wat betekent die verandering van waarden nu voor architectuur? Ik kom verschillende interpretaties tegen, en daar wil ik het in deze blog over hebben. Ik hoor graag wat jij ervan vindt!

Interpretatie 1

Dit gaat over software development en niet over architectuur.

Op zich is dit een ware constatering. Wie als architect nu denkt dat daarmee de kous af is, heeft de afgelopen jaren niet opgelet. Een organisatie die agile ontwikkelt vraagt om een andere architectuur (meer flexibel), een andere mindset (denken en doen combineren), een andere ‘engagement’ (er bij blijven), en dus ook andere skills (open). Kortom: de agile waarden raken architectuur in al zijn aspecten.

Interpretatie 2

OK, agile is belangrijk, maar al die oude waarden ook.

Dit is m.i. een verdedigbaar standpunt; hoewel dat ‘maar’ wel defensief klinkt. Als je constateert dat traditionele waarden plaatsgemaakt hebben voor meer eigentijdse, kán je dat lezen als én-én, maar wellicht is dat te dogmatisch. Neem nu de volgende paradigma veranderingen.

Traditioneel Agile
In één keer goed Al doende lerend
Samenhang Functionele componenten
Hergebruik Gebruik
Geïntegreerd Integreerbaar


Het gaat me er nu niet om of dit de juiste typeringen zijn, en of het altijd opgaat. Het gaat me erom dat het uitmaakt. In de linker kolom is Big Design Up Front een optie, in de rechter niet meer. Links maken we een dikke Project Start Architectuur, rechts maken we óf een dunne PSA, óf we doseren de lading per sprint. Links vinden we redundantie een ontwerpfout, rechts misschien wel een feature. Én-en is niet altijd een optie. De uitdaging is dat we als architect ons telkens moeten bezinnen op de principes en redeneringen die we hanteren. Zijn die nog bepalend? Of moeten we ze loslaten? Loslaten is veel moeilijker dan bijleren.

Interpretatie 3

Alle ballast overboord. Autonome teams bedenken het zelf wel.

Laten we eerlijk zijn. Dit klinkt sympathiek. En is ‘zelfsturende teams’ niet de essentie van agile?
Hmmm, ik hoop van niet. Ik hoorde laatst iemand zeggen: “Al die architectuur. Tegenwoordig staat alles op internet. Gewoon even googlen en je weet hoe het zit. Daar heb je echt geen architect voor nodig.” Hier wordt ongemerkt de stap gemaakt van zelfsturend naar zelf-bedenkend. Dat is in mijn ogen een kapitale denkfout. We hebben een beschaving opgebouwd door ‘op de schouders van onze voorgangers te gaan staan’. Al die kennis en ervaring overboord te gooien, lijkt mij naïef en een recept voor mislukking. Alles is op internet te vinden? Misschien, maar je moet wel weten waar je naar moet zoeken, en ook nog begrijpen wat je vindt. Ik stel me voor dat deze persoon een slecht hart heeft, en ik zeg: “Oh, ik google wel even, en dan doe ik de operatie wel…”. Zelfsturend is geen excuus voor amateurisme. Learning by Doing en Leren van de fouten van anderen. Het eerste beklijft beter, het tweede gaat aanzienlijk sneller, en met veel minder kosten en fatale fouten. Maar, met ‘Good Ideas’ in het achterhoofd, het vraagt wél van de organisatie dat we al die goede ideeën (niet alleen architectuur) op de juiste manier in stelling brengen:

  • op het juiste moment,
  • goed gedoseerd, en
  • op een behapbare manier ingebracht.

Het doel van architectuur – agile style is om dit voor elkaar te krijgen. Laten we het kind niet met het badwater weggooien!

Interpretatie 4

Agile heeft zijn eigen set van waarden. Het is aan de architecten om een architectuur te bedenken die dat realiseert.

In deze interpretatie omarmen we het agile gedachtengoed. Of niet? Wat in ieder geval niet de bedoeling kan zijn is een wij-zij onderscheid te maken. We weten inmiddels wel dat ‘emergente architectuur’ maar tot op zekere hoogte werkt. Architectuur is – net als kwaliteit of veiligheid – iets van de hele organisatie. Iedereen heeft er een rol in.

Verder denk ik dat de agile waarden in het huidige tijdsgewricht belangrijker zijn geworden, maar dat er tal van andere waarden ook nog steeds meespelen. Kijk bijvoorbeeld naar de software kwaliteit standaard ISO 25010 in onderstaande tabel. De kwaliteitscriteria in deze standaard worden maar voor een deel door het agile gedachtegoed benadrukt. Architectuur heeft een bredere scope dan alleen agile.

Waarden die in agile benadrukt worden (*) Waarden die in agile minder aandacht krijgen
Functionaliteit Compatibiliteit
Performance efficiency Veiligheid
Bruikbaarheid Onderhoudbaarheid
Effectiviteit Efficiency
Gebruikerstevredenheid Risicobeheersing
Context bewustzijn
Betrouwbaarheid

(*) Ik weet dat zowel in agile als in architectuur idealiter alles de aandacht krijgt. Maar als je toonaangevende artikelen scoort op bovenstaande waarden, valt er toch een tweedeling te maken.

Conclusie

Het filmpje ‘Good Ideas’ legt terecht de nadruk op het feit dat we zaken los moeten laten om een nieuwe weg in te kunnen slaan. Waar het filmpje m.i. te ver gaat is dat het de kwestie als een alles of niets propositie neerzet. Ik denk dat échte vooruitgang vraagt om het slim combineren van agile en architectuur. These – antithese – synthese. Dat vraagt werk van beide kanten. We zijn er nog niet.

Wat vind jij? Ik hoor het graag. Mail naar: serge.bouwens@inspearit.com.

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • ‘Just enough’ architectuur

    In gesprek met collega’s en klanten over hoeveel architectuur een organisatie nodig heeft, lijken we elkaar te kunnen vinden in de formulering ‘Just-enough’. Maar hoeveel is dat dan?

    Lees verder
  • U bevindt zich hier

    Architectuur is bij grotere organisaties een volwassen functie. Enterprise Architectuur wordt ingezet om grip te krijgen op de informatievoorziening. Solution Architecturen worden gemaakt om project specifieke oplossingen in te kaderen.

    Lees verder
  • Waar blijft het applaus?

    Het overkomt ons allemaal wel eens. Je hebt je best gedaan op een mooi stuk werk, en je bent trots op het resultaat. De analyse is degelijk, de architectuur die je bedacht hebt is beter dan marktconform, helder gedocumenteerd en gepresenteerd.

    Lees verder
  • Niet met 'n Ferrari in de file

    Deze blog gaat over de agile enterprise, en wat er voor nodig is om agile te worden. (Dan komen we vanzelf weer uit bij architectuur, maar net even anders.)

    Lees verder
  • Het stiefkind van de enterprise architectuur

    Ik stel me voor dat u bij het lezen van deze titel onbewust al heeft ingevuld waar ik het over heb. En ik stel me ook voor dat velen van u het goed geraden hebben. De Architectuur van de Technische Infrastructuur, verder afgekort met TIA.

    Lees verder
  • Decision Driven Architecture

    Met een Decision Driven Architectuur ben je in staat optimaal mee te leven met wat de organisatie belangrijk vindt, nu én in de toekomst. Dat lijkt me een vereiste in deze agile tijden blogt Serge Bouwens.

    Lees verder
  • Architectuur veert weer op!

    In november vond het jaarlijkse LAC congres plaats. "Meestal kom ik terug met de conclusie: er waren wel enkele aardige presentaties, vele bekende gezichten, prima verzorgd. Dit jaar was het echter anders", blogt Serge Bouwens. Lees verder.

    Lees verder
  • Zin en onzin van documentatie

    Willen jullie meer of minder documentatie? Minder! Minder! Minder! Lees verder.

    Lees verder