In Agile software ontwikkeling is pair programming een bekend fenomeen. De één schrijft de code, terwijl de ander observeert. De voordelen zijn onder andere hogere kwaliteit van de code, betere samenwerking in teams en, niet onbelangrijk, een groter plezier in het werk.
Op het gebied van software-architectuur missen we dit eigenlijk. In de praktijk zie ik vaak dat architecten in Agile teams behoorlijke eilanden zijn. Zeker in omgevingen waar meerdere Scrum teams werken aan producten die onder een bepaald programma vallen kunnen daardoor op het gebied van architectuur al snel misverstanden ontstaan. Hierdoor kunnen de teams te ver uit elkaar gaan lopen en zijn de onderdelen van de uiteindelijke totaaloplossing niet goed op elkaar afgestemd. Dat kan ook leiden tot moeilijke beheerbare oplossingen en veel refactoring.
Zou pair architecting (volgens mij bestaat de term nog niet) hier niet een oplossing kunnen bieden?
Er bestaan verschillende vormen van pair programming en dus ook van pair architecting. De twee meest voorkomende zijn:
- Expert-Expert
- Expert-Nieuwkomer
Beide varianten hebben hun voor- en nadelen. In het Expert-Expert geval zal minder vaak tot nieuwe inzichten worden gekomen, omdat de al jaren toegepaste principes niet snel zullen leiden tot vragen of kritiek. Het Expert-Nieuwkomer model levert vaker verrassende inzichten op, omdat de Expert zaken opnieuw helder moet proberen uit te leggen aan de Nieuwkomer en daardoor tot nieuwe inzichten kan komen én de Nieuwkomer zal vaak al jarenlang toegepaste principes ter discussie stellen, als hij of zij een beetje assertief is. Beide varianten leveren in de meeste gevallen een betere en beter onderbouwde architectuur op.
Het belangrijkste is echter dat er meerdere mensen bezig zijn met het bedenken, tekenen en documenteren van architectuur en dat men elkaar scherp houdt. Waarbij de één ook meer tactisch bezig is en de ander tegelijkertijd meer strategische inzichten kan bieden. Tegelijkertijd is er borging van kennis bij meerdere personen en kan de rol van het borgen van architectuur in de Agile software-ontwikkelteams altijd ingevuld worden, al is het maar parttime. Door regelmatig de rollen om te draaien in de paren (dan tekent en documenteert de één en observeert de ander en dan weer andersom) houdt men het architectenpaar ook fris.
Architecten die in paren samenwerken zullen in de praktijk ook, net als bij programmering, merken dat:
- De kwaliteit van de architectuur beter is en men met meer zekerheid achter de gekozen architectuur staat
- De ontworpen architectuur breder gedragen wordt
Een laatste belangrijke conclusie is dat hoe eerder in een software-ontwikkeltraject fouten worden voorkomen, hoe goedkoper het is om het op te lossen. Architectuurfouten te laat ontdekken kan leiden tot zeer dure refactoring. Wat dat betreft levert pair architecting potentieel nog veel meer voordeel op dan pair programming.
Een betere combinatie zou zijn: een architect met de techneut die het design gaat realiseren.
Leuk, alles gezellig met zijn twee. Doet me denken aan die systeembeheerder die boos naar zijn baas stapte : “ik werk hier al een jaar en doe het werk van drie man, tijd voor loonverhoging”. Antwoord : “Helaas geen budget voor, maar wie zijn die andere twee ? dan kan ik die tenminste ontslaan.”
Om een lang verhaal kort te maken, als de blinde de lamme leert lopen wordt het beweeglijkheid zonder richting. Misschien is het in dat kader een goed idee alleen is het wel handig om eerst de kapitein vast te binden aan het stuurwiel omdat juist hier vaak wat misgaat als ik kijk naar alle ‘second opinions’ achteraf, tussen de gedragen en werkende architectuur zitten nog heel wat dure lessen.
Nee joh, is helemaal geen goed idee. Het basisontwerp van een systeem (ik kan het woord “architectuur” nauwelijks over mijn lippen krijgen) dient onteiland te worden. Niet van een eenmanseiland naar een tweemanseiland, maar helemaal van dat eiland af.
Systeemontwerpen dienen iteratief in elkaar te worden gestoken. Paar rondjes op een white board, dan eens wat opschrijven, dat document reviewen, eerst documentair, daarna in een meeting. Die vroege reviews moeten worden gedaan op het moment dat er nog geen palen in de grond staan waarvan niet meer kan worden afgeweken.
Daarbovenop: systeemontwerp is dusdanig belangrijk dat het niet moet worden overgelaten aan mensen die het dan vervolgens zelf niet kunnen of niet hoeven te programmeren. Weg met die “ivoren toren” architecten!
@Jos,
Dat (enterprise-)architectuur tegenwoordig in een crisis verkeert, gekenmerkt door een uitwaaiering van meningen, visies en inzichten (wat je aversie hiertegen wel begrijpelijk maakt) is nog geen reden om terug te grijpen naar de eilandautomatisering van het pré-internet tijdperk. Systemen zijn bij uitstek eilandjes, juist omdat ze een (adequate service-georiënteerde) architectuur missen.
@Jack inderdaad.