Maakt agile architecturing architectuur- en ontwerpdocumenten overbodig?

In een discussie over agile architectuur hoorde ik een definitie over wat architectuur is. Het aardige is dat de definitie haarscherp een scheidslijn maakt tussen architectuur en ontwerp.

"Architectuur beschrijft de eigenschappen van een systeem die ertoe doen".

Met name de woorden "die ertoe doen" maakt het onderscheidt tussen architectuur en ontwerp, werd gezegd. Want, een andere, of wijzigende, architectuur impliceert een andere missie, terwijl een ander ontwerp of wijzigingen in een ontwerp in het algemeen niet zal leiden tot een andere/wijzigende missie.

Met deze definitie wordt focussen op hoofdlijnen - de dingen die ertoe doen - wel heel concreet. Als je ontwerpen gaat beschrijven in je architectuur ben je niet meer bezig met de hoofdlijnen. Met andere woorden, beschrijf geen oplossingen en ontwerpen in een project start architectuur, referentiearchitectuur of applicatiearchitectuur. Da's mooi want dan is er geen reden om hiervan dikke boekwerken te maken, die ook nog eens weken/maanden kosten om op te stellen.

Alleen, hoe dichter je bij de techniek komt, des te lastiger wordt het volgens mij om de scheiding tussen architectuur en ontwerp vast te houden. Daar zie je toch vaak gebeuren dat (technisch) ontwerp en architectuur door elkaar heen gaan lopen. Hoe gaan we daar in ons vak mee om? Dat is de centrale vraag van dit artikel. Het ultieme antwoord wordt in dit artikel niet gegeven. Wel worden in dit artikel een aantal ideeën en standpunten neergezet die tot denken leiden en misschien ook tot discussie op deze site.

Mooie definitie. Architectuur moet richting geven - oplossingsrichting - maar hoeft niet de oplossing zelf te geven. Daar sta ik helemaal achter. Echter, het wordt wel lastig als je dan gaat praten over solution architecturen. Moeten die ook alleen richting geven, of juist wel de oplossing? Ikzelf denk het eerste omdat de richting ertoe doet in context van de bovengenoemde definitie van architectuur. De oplossing doet er niet toe: vele wegen leiden naar Rome.

Om goed antwoord te kunnen geven op de vraag, wat bevat een solution architectuur; richting of oplossing, moet je weten wat het verschil is tussen technisch ontwerp en solution architectuur? Daarnaast, is het dan ook relevant om na te gaan wie welke architecturen opstelt? Tenslotte, hoe ga je in een agile architectuur om met de diverse documenten, als technisch ontwerp, solutionarchitectuur en project start architectuur (PSA)?

Verschillen in technisch ontwerp en solution architectuur

Terugkijkend tot circa 1997 naar de projecten, zijn er verschillen tussen een technisch ontwerp en een solution architectuur. Een technisch ontwerp bevat een gedetailleerde beschrijving van de technische oplossing, soms zelfs met pseudo-code. Uitgangspunt is het vertalen van de requirements, oftewel de functionele eisen/wensen, naar de techniek. Doordat de technisch ontwerpen zoals ik die ken een vertaling zijn van een functioneel ontwerp, is het euvel dat de non-functionals, de softwarekwaliteitseisen, onderbelicht blijven.

Een solutionarchitectuur zoals ik die ken bevat een (high level?) beschrijving van de technische oplossing - van de dingen die ertoe doen - in software patterns, systeemstructuren, systeem gedragingen, samenhang van modules en implementatie-artefacten, en samenhang processen. De dingen die ertoe doen liggen op het vlak van functionele dingen + non-functionele dingen. De laatste kan je ook aanduiden als de constructieve, kwaliteits- en decoratieve eigenschappen.

Een solutionarchitectuur en een technisch ontwerp belichten beide andere aspecten van het softwaresysteem en leggen de focus op andere aspecten. Dit is het verschil tussen richting en ontwerp. De scope van beide is wel dezelfde, namelijk het softwaresysteem. Hetzelfde kan gezegd worden over de levensduur van beide documenten, de technisch ontwerp en de solutionarchitectuur blijven relevant gedurende de gehele levenscyclus van het softwaresysteem en dienen dus als levende documenten te worden gezien, aan te passen bij elke wijziging van de software.

Wie stelt welke architecturen op?

Welke rol kan verantwoordelijk worden gehouden voor de architectuurproducten? Ik denk dat het nuttig is dat in een projectteam één iemand het voortouw neemt om de technische oplossingsrichtingen te bewaken. Voortouw nemen kun je interpreteren als verantwoordelijkheid nemen, en als je weet dat iemand die moet nemen kun je soms ook wel iemand daarvoor aanwijzen. Het bewaken van de (kwaliteit van) de oplossingsrichtingen kun je misschien wel interpreteren als solution architectuur.

Terugkijkend in projecten zie je dat er bijna altijd één iemand die rol op zich nam, ook in het tijdperk dat ik het woord architectuur nooit gebruikte, maar feitelijk was het wel wat er gebeurde. En als je architectuur omschrijft in de zin van "als we samen één doel willen bereiken is het wel handig om een aantal gezamenlijke afspraken te maken", dan kom ik ook al aardig in de richting. Bijvoorbeeld, een senior ontwerper, ondersteunt door een architect, zou dan een solution architectuur op kunnen stellen.

Welke documenten overleven Agile architecturing?

Hoe zit het dan met agile architectuur en de diverse architectuurdocumenten? In een agile architectuur streeft men ernaar het documenteren zo veel mogelijk te minimaliseren. Dit onder andere door zelf beschrijvende code en kleine multidisciplinaire teams, waarin kennis over hele team gedeeld wordt. Gaat het minimaliseren van documentatie te koste van de solutionarchitectuur, van technisch ontwerp en van de PSA of versmelten de documenten tot één alomvattend document?

Ik vermoed dat, als er documenten geschrapt moeten worden, een technisch ontwerp in een agile architectuur de eerste kandidaat is om te schrappen vanwege de scope en levensduur in vergelijking tot de solutionarchitectuur en omdat de ervaring leert dat “in de code kijken” sneller tot resultaat leidt dan het lezen van een technisch ontwerp. Met andere woorden, het uitgangspunt van zelf beschrijvende code laat zich gelden. In een artikel van iSense[1] wordt geschreven dat een agile architectuur document zowel de solutionarchitectuur als ook de PSA vervangt. Interessante stelling, alleen zitten daar niet haken en ogen aan? De scope van beide producten is namelijk totaal verschillend, wat samenvoegen vervelend kan maken. Door beide samen te voegen bevat de solutionarchitectuur ineens ook de kaders en richtlijnen waarbinnen het project de inhoud realiseert. Hierdoor krijgt het solutionarchitectuur een extra scope, namelijk een projectscope, naast de eerder genoemde softwaresysteem-scope.

Als het project is afgelopen is de PSA doorgaans niet meer relevant, lezenswaardig (levenswaardig) en wordt ook niet meer up to date gehouden. De scope van de software eindigt op moment dat de stekker uit de software gaat en overspant wellicht meerdere projecten en misschien ook wel aanpassingen buiten projecten om. Door de samenvoeging krijgt het documenteren een lastig staartje. Want blijven de kaders en richtlijnen van vorige projecten in het document staan (verkapt versiebeheer) of worden ze overschreven met de voor het huidige project geldende kaders en richtlijnen of ...? Wie het weet mag het zeggen.

Vertaald naar agile architecturing fungeert de agile architectuur als solution architectuur. Dit betekent dat een architect samen met het team on the fly architectuur uitwerkt. Een architect in de lijnorganisatie stelt bijvoorbeeld een referentiearchitectuur voor een organisatie(domein) op, laten we zeggen inclusief een applicatiearchitectuur en een gegevensarchitectuur. Als de DYA methodiek gevolgd wordt , dan stelt een architect die aan het project is verbonden een PSA op en de architect in de lijnorganisatie doet daar review op. In de TOGAF ADM methodiek is geen sprake van een PSA, en evolueren de bestaande architectuurproducten naar een volgende iteratie. In dit geval stelt een architect die aan het project is verbonden de volgende iteratie op en laat deze reviewen door de lijnarchitect.

Referenties

[1] Bender, K.J., Grgic, V., Solingen, van, R., Agile Architectuur – Hoe gaan Architectuur en Agility samen en wat is de impact op de architect?, iSense Prowareness.