Lean Architecture training

Lean Architecture training

In eerste instantie voelde het toch wel als ‘vreemde eend in de bijt’. Ik, als business architect met ‘hoog over’ ideeën, in feite als adviseur voor de business en mediator tussen de business en ICT, te midden van allemaal programmeurs en ontwerpers; de solution architecten waar ik wel eens naar verwijs. Toch voelde het wel erg prettig met al die leergierige mensen. Volgens mij waren namelijk alleen de echte liefhebbers en geïnteresseerden in het verhaal van James Coplien, onze trainer, aanwezig. Sowieso voelde ik mij gezegend om allemaal leuke mensen te hebben ontmoet.

De training, die georganiseerd werd door Zilverline in Amsterdam, startte met definities van Agile, Lean en architectuur en ook over de uitgangspunten van scrum die door de simpele 3 x 3 opsomming te veel naar de achtergrond waren verdwenen. Het ging over het verschil tussen vorm en structuur, over wat een systeem is en wat het systeem doet en de noodzaak om daar ernstig onderscheid in te maken.

Het ging over mentale modellen van gebruikers (een van de stakeholders) van een systeem, de communicatie daarover met ontwikkelaars en hoe zich dat uiteindelijk vertaalt in code. Het ging over het verschil tussen plannen en planning (wat bij mij een soort mindshift teweeg bracht) en het feit dat we de essentie van een systeem (het geheel, de vorm, de functie) moeten blijven zien, ook als we met de structuur bezig zijn. En ons niet in het laatste verliezen.

Het ging over de contrasten en de overeenkomsten tussen lean en Agile. Over diversiteit, cross functional/ multidisciplinair en over collectieve kennis, en over de dragers van de domeinkennis die in feite de architecten zijn. En de allergie van de Agile gemeenschap voor architectuur.

Er passeerden een heleboel wetenschappers de revue. Van Japans tot Scandinavisch tot Anglo- Amerikaans. Zelfs Geert Hofstede kwam aan de beurt.

De cursus was veel technischer dan ik had verwacht en uiteraard zeer software gericht. De eerste dag was zeer goed te doen maar de tweede dag moest ik erg mijn best doen om iedereen bij te houden.

Van sommige zaken begreep ik niet waar het probleem nou zat; bijvoorbeeld de dingen die over de context gingen en een aantal andere inzichten. Dat bleek te liggen aan het feit dat dit gewoon bedrijfskundige zaken waren die bij mij wel in het voorhoofd zitten maar niet altijd evident zijn voor iedereen. Aan de andere kant werden er ook softwarepraktijken toegelicht waar ik de details niet eens van weten wilde. Dat laat ik graag aan de ontwikkelaars over. Je moet niet overal van zijn.

Het deel van de training dat over leiderschap ging, Kaizen (continue verbetering) en Hansei (discipline en verantwoordelijkheid) zou ik graag wat meer uitgediept hebben. Dit omdat ik zeer geïnteresseerd ben in leiderschap vraagstukken en uitdagingen. Misschien een idee om “lean architecture for managers’ te ontwikkelen?

Maar begrijpelijk is, dat het toen wel eens tijd werd voor de uitwerking van de ideeën op de manier waarop zich dat uit in de verschillende ontwikkeltalen. Ik heb ook een heleboel nieuwe TLA’s (tree letter acronyms) geleerd. Om een paar voorbeelden te noemen BNF (Backus Naur Form – context vrije taal) MVC (model view controller) DCI (data, collaboration and interaction) En ik heb enigszins begrepen wat het verschil is tussen procedurele talen, object georiënteerde talen en class georiënteerde talen, en de verschillende tussen C++, Scala, Ruby en Java. Al moet ik toegeven dat ik de laatste 2, 5 uren van dag twee nog het meest in het boek van James heb zitten lezen.

Ik moest telkens vreselijk lachen als James weer eens een methode, architectuur, denkraam, aanpak of taal over de hekel haalde. SOA vond ie helemaal niks qua architectuur en hergebruik onzin, Unit testen volledig onzinnig omdat het helemaal niets zegt over de kwaliteit van de code of de test zelf, Java vond hij een onmogelijke taal omdat deze strikt klassegebaseerd is, verder werd TDD onder handen genomen omdat daar de benodigde koppeling (coupling) en cohesie niet mee bereikt gaat worden en XP kreeg een schrobbering omdat daar nauwelijks nagedacht wordt over de context en de samenhang met andere delen van het systeem. Je kon af en toe een geluid door de zaal horen gaan dat het midden hield tussen het door de tanden binnenzuigen van lucht en de energie die rondwaart omdat men de neiging heeft te roepen ‘hé, maar wacht even!”

Wat mij aangenaam verraste was dat James – ongevraagd – bevestigde dat scrum wel degelijk veel met discipline en commitment te maken heeft en het productowner proces (niet zijnde sprint 0 of -1) de ‘fase’ van het software ontwikkelproject is waar heel creatief gewerkt wordt en die niet ge-time-boxed is. (Net als het UX deel, hoewel ik dat nog wel pre-parallel kan zien gebeuren) En hij maakte reclame voor het gebruik van use cases voor het productowner proces i.p.v. user stories.

De lean aanpak van architectuur met Poka-Yoke (een soort van matrijs /voorbeeld), upfront nadenken over welke beslissingen je moet nemen (niet de beslissingen zelf nemen), een planning en met een werkstroom dat uit 1 item bestaat (SMED, single piece of continuous flow) kwam aan de orde. Met de resultaten van onderzoeken wees James erop dat je met heel weinig programmeren (10KSLOC) toekan met heel weinig architectuur. Veel architectuur leidt dan tot rework. Terwijl je met 10.000 broncode regels ongeveer 40% aan architectuur moet besteden omdat de code dan tot rework leidt.

Enfin, er is mega veel aan de orde geweest en ik zal de hand-out (en het boek uiteraard) nog eens stevig doorlezen.

Wat ik verder nog aan inzichten heb overgehouden van deze tweedaagse training is dat de kloof tussen ontwikkelaars / scrum teams en business architecten veel groter / breder is dan ik eerder dacht. Dit maakt me minder optimistisch. Hopelijk is Lean architectuur een aanvulling op de middelen die ik heb ik om die kloof te overbruggen.

Daarnaast ontdekte ik dat zelfs ik door het lineair ‘platte’ logisch denken paradigma ben aangetast zodra het over rangschikken van data en processen gaat. Volgens deze paradigma’s werden we gedwongen om te denken in twee dimensies, zoals in een matrix (alleen x en y as). Er leek nu een derde dimensie (vector) aan toegevoegd.

Ja dames en heren, het was niet ‘the matrix reloaded’ of ‘the matrix preloaded’ (zoals in C++) maar ‘the matrix gridded” Tevens begreep ik dat hergebruik van algoritmen nooit zal voorkomen maar dat hergebruik vooral in de domein overeenkomsten gezocht moet worden; dat er méér dan twee manieren van separation of concerns zijn, dat er nu dus ook meer definities van ‘rollen’ (naast bijvoorbeeld werknemer, klant, manager) zijn en dat UML use cases zeer bruikbaar zijn, zelfs wanneer ze beschouwd worden als ‘BUFD ‘

Ik ben benieuwd of mijn ervaringen verschillen of overeenstemmen van mijn medestudenten. Ik heb ’t ze gevraagd. Het zou heel mooi zijn als zij daarover met mij van gedachten willen wisselen.

James zal ergens in april weer deze cursus in Nederland geven, dan bij Xebia in Hilversum. Wees voorbereid op enige hersenspoeling, op verrassingen, op grote ogen achter brillenglazen, op gedegen kennis en grote ervaring van de trainer, op regelmatig gekrab aan baard en hoofdhaar, op met zijn allen lachen en op sandalen met blote voeten.

Als je in de gelegenheid bent zou ik het doen, als ik jou was…

1 comment

Hoi Mary,Ik ben blij dat ik je blog tegen kom. Ondanks dat ik zelf veel aantekeningen heb gemaakt, komen er toch weer dingen boven die ik al weer diep weggestopt had.Coplien kan op fascinerende wijze over software in al zijn facetten spreken. Hij zet je aan het denken is niet bang controversiële uitspraken te doen en mensen te prikkelen. Dat werkte voor mij erg inspirerend.De cursus zelf was, zeker de eerste dag, meer op het ‘proces’ dan op software architectuur gericht dan ik van tevoren had verwacht. Daardoor absoluut niet minder interessant.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *