SATURN conference - Dag 1 - Architecture centric design

Twee van onze collega’s, Rogier Schrama en Wim van Gool, wonen deze week de SATURN conference bij van het SEI (Software Engineering Institute) van Carnegie Mellon University en doen ons hiervan verslag. 

Maandag 5 mei 2014 is de eerste dag van de SATURN conferentie in Portland, Oregon. Dit is deel 1 van een dagelijkse samenvatting van de onderwerpen die tijdens de conferentie aan de orde komen. De SATURN conferentie is een jaarlijks terugkerende, 5-daagse conferentie die wordt georganiseerd door het Software Engineering Institute (SEI). De focus van de conferentie is ‘general software architecture’. Het programma is variabel. Dat betekent dat er gekozen kan worden uit een combinatie van courses en tutorials op de eerste twee dagen, aangevuld met korte, gevarieerde sessies op de daaropvolgende drie dagen.

Dag 1: Course ‘Advanced Software Architecture Workshop’.

De course is opgezet rondom het SEI principe van ‘Architecture-centric Design’. Dit principe onderkent een tweetal feedback loops. In de eerste loop wordt de software architectuur, of de wijzigingen erop, afgestemd op de wensen en doelen van de organisatie. In de tweede, daaropvolgende loop, wordt de afgestemde architectuur toegepast op het te bouwen systeem. De activiteiten in de twee loops hebben als doel om de kwalitatieve aspecten van de architectuur te waarborgen. Dit gebeurt door middel van review processen gebaseerd op verifieerbare eigenschappen van de architectuur.

De methode die SEI in de eerste loop gebruikt is Attribute Driven Design. In grote lijnen lijkt dit op het selecteren van architectuur relevante use cases zoals dit binnen Endeavour ook gebeurt. Er wordt een aantal architectuur relevante scenario’s getoetst aan hypothesen. Dit proces moet bewijzen dat de architectuur voldoet aan specifieke eisen, zoals bijvoorbeeld performance. SEI hanteert peer-review sessies tussen verschillende architecten om onzuiverheden in de architectuur boven tafel te krijgen om zo de kwaliteit te verbeteren.

In de tweede loop omvat de communicatie van architectuur naar ontwikkelaars en methoden om de conformiteit van de ontwikkelde software ook weer zo goed mogelijk te verifiëren (governance). De methode die SEI hanteert is voor een belangrijk deel gebaseerd op documentatie van de architectuur. Op basis van deze documentatie en presentaties van de architect aan het ontwikkelteam, wordt een interactief proces bewerkstelligd dat er ook voor moet zorgen om fouten in een vroeg stadium boven tafel te krijgen. De bewijslast ligt hierbij bij de architect.

De methode komt op sommige vlakken vrij formeel over, maar is gebaseerd op een verzameling breed toepasbare, common-sense uitgangspunten. Een paar voorbeelden die de scope van deze uitgangspunten weergeven:

• Als je een architectuurmodel documenteert, geef architectuurcomponenten dan niet alleen een naam, maar ook een omschrijving.
• Maak alle doelstellingen meetbaar. Dit maakt verificatie mogelijk.
• Stimuleer fout-eliminatie in ontwerpen door interactie met andere peers.
• Documenteer de uitkomsten van review sessies.
• Werk zoveel mogelijk in ‘eenheden van 5’ omdat dit beter aansluit bij wat mensen tegelijkertijd kunnen bevatten.

Veel van de zaken in de door SEI gebruikte methode zijn, zoals al eerder aangegeven, common-sense. Veel ervan zijn ook een intrinsiek onderdeel van bijvoorbeeld Endeavour. Maar het is altijd goed om hier scherp op te blijven zoals ook deze methode benadrukt.