Wat wil je zijn: een architect of een ontwikkelaar?

Mijn leidinggevende stelde me onlangs de vraag: “Wil je een softwarearchitect zijn of wil je een softwareontwikkelaar zijn die zich met architectuur bezighoudt?”

Dat vond ik een confronterende vraag, ondere andere omdat ik me tot dan toe nauwelijks gerealiseerd had dat er een verschil bestond tussen die opties.

De architect als ontwikkelaar

Het deed me beseffen dat mijn kennis over softwareontwikkeling sterk gekleurd wordt door mijn ervaring als ontwikkelaar in een Scrumteam.

Binnen die kennishorizon vallen een architect en een ontwikkelaar die zich heeft gespecialiseerd in architectuur samen. Hij (of zij, maar in mijn geval dus niet) is het teamlid dat de architectuur van de applicatie stapsgewijs ontwerpt¹, de architecturele integriteit ervan continu monitort en zijn teamleden elke keer opnieuw de juiste richting op manouvreert als deze onder druk staat.

En ja, hij codeert. Als het op het ontwikkelen van nieuwe features aankomt, onderscheidt hij zich niet van de rest van het team. Al komt het in de praktijk wel vaker voor dat de architect-ontwikkelaar zich op de delen van de code focust die een grotere architecturele impact hebben.

Maar het is belangrijk om in het achterhoofd te houden dat de architect-ontwikkelaar in zijn eentje niet verantwoordelijk is voor de architectuur van een applicatie. Die verantwoordelijkheid valt aan het team als geheel toe. Het is geen toeval dat Scrum de rol architect niet kent.

De architect als stakeholder

Maar dat is niet de enige manier waarop een softwarearchitect zich kan verhouden tot het Scrumteam - en de applicatie waar ze voor verantwoordelijk is. Een organisatie kan er ook voor kiezen de verantwoordelijkheid voor de architectuur van een applicatie te beleggen buiten het team. De softwarearchitect is in dat geval een stakeholder. Zijn belang is: de architecturele integriteit van de gekozen oplossing waarborgen.

(Deze opzet zal, vermoed ik, vaker voorkomen binnen organisaties waar het aantal applicaties groter is dan het aantal softwareontwikkelaars met gedegen architecturele kennis en vaardigheden. Maar dit vermoeden zou het gevolg kunnen zijn van mijn bias als ontwikkelaar. Zou een architect zonder deze achtergrond hetzelfde vermoeden hebben?)

Dit doet iets met de invulling van de rol van softwarearchitect. De architect bouwt zelf niet (of nauwelijks) meer mee aan een applicatie, maar neemt een in hoofdzaak adviserende rol op zich. De feitelijke implementatie valt niet meer onder zijn directe verantwoordelijkheid; die blijft immers bij het team als geheel belegd.

Overeenkomsten…

Het is niet zo dat de werkzaamheden tussen de architect-ontwikkelaar en de architect-stakeholder radicaal verschillen.

In beide invullingen zal een architect softwarematige oplossingen voor businessproblemen ontwerpen. Hij zal deze middels Proofs of Concept (POCs) en architectuurdiagrammen presenteren aan de ontwikkelaars, en hen vragen erop te schieten. Misschien zou je dit het “harde”, codegerelateerde gedeelte van zijn vak kunnen noemen.

Hij zal de Product Owner ervan moeten overtuigen tijd en geld vrij te (blijven) maken om de architecturele integriteit van een applicatie te blijven waarborgen. Hij zal de voor- en nadelen van de gekozen oplossing op een rij moeten zetten in een taal die de business begrijpt. Dat zou dan het “zachte”, businessgerelateerde gedeelte van zijn vak zijn.

Dit zijn een potentieel zeer interessante wisselwerkingen. De architect en het team respectievelijk de business leren tegelijkertijd van elkaar. Het Scrumteam kan hem wijzen op plekken waar de wal van een concrete implementatie het schip van zijn ontwerp keert. En de business kan hem wijzen op de manieren waarop hun belangen onvoldoende vertegenwoordigd zijn in de voorgestelde oplossing.

Dat constante proces van inzicht vergaren is één van de dingen die me aanspreken in softwareontwikkeling in het algemeen en softwarearchitectuur in het bijzonder.

…en verschillen

Maar er is wel sprake van een accentverschuiving tussen de twee invullingen van de rol.

De architect-ontwikkelaar zal relatief meer code schrijven. Hij zal zich meer op één applicatie focussen. En dat is by design (no pun intended), want hij zit in één team. (Waarbij ik aanneem dat één team verantwoordelijk is voor één applicatie, wat niet altijd het geval is.)

De architect-stakeholder zal relatief meer onderzoeken, meer ontwerpen en meer communiceren, zowel met de ontwikkelaars als met de business. Hij moet ook wel, want hij heeft meerdere applicaties in zijn portefuille, waar hij bovendien verder vanaf staat.

Een open vraag

Wil ik een softwarearchitect zijn of wil ik een softwareontwikkelaar zijn die zich met architectuur bezighoudt?

Ik hou van code, en schone code bovendien. Wat dat betreft voel ik me sterk verwant met een architect-ontwikkelaar. Maar ik hou ook van de moeilijkheden van een constante afweging van tegengestelde belangen, en de manier waarop dat je steeds meer inzicht verschaft in een businessprobleem. In dat spel zie ik potentieel om te groeien.

Dus, wat wordt het? Ik moet bekennen dat ik op deze vraag nog geen antwoord heb. Het onderscheid architect-ontwikkelaar en architect-stakeholder biedt handvaten, maar geen doorslaggevende argumenten. (En het is belangrijk om te beseffen dat het onderscheid slechts handvaten biedt, want het valt niet één op één samen met het onderscheid dat mijn leidinggevende schetste.)

Verwonderlijk hoeft dat niet te zijn, want de vraag is ingewikkeld genoeg om alleen in de praktijk te kunnen worden beantwoord. Pas als ik beide rollen aan den lijve heb ondervonden, bestaat er zekerheid over wat ik wil zijn - of misschien dan zelfs al blijk te zijn.

Tot die tijd opereer ik in een permanente staat van onzekerheid - maar lerende.

Lees meer

• What Is Software Architecture in Scrum?
• As an Architect, What Is My Place in Scrum?
• Where Does an Architect Fit in a Scrum Sprint?
• What Is the Role of the Architect in Scrum?

carrièrepad · leermoment · scrum · software architect (rol) · software architectuur · software ontwikkelen · stakeholders