Development

Software-ontwikkeling
Architectuur

Softwarearchitectuur onderbelicht

Softwarearchitectuur is ondanks alle aandacht een slecht begrepen discipline.

© CC0 - Pixabay PeteLinforth
27 februari 2017

Softwarearchitectuur is ondanks alle aandacht een slecht begrepen discipline.

De softwarearchitectuur heeft een grotere impact op de kwaliteit van een product dan de meetbare kwaliteit van broncode. De gemeten broncodekwaliteit biedt schijnzekerheid. Het zet ontwikkelaars aan tot symptoombestrijding. Softwarearchitectuur is ondanks alle aandacht een slecht begrepen discipline.

Bij agile softwareontwikkeling is de aandacht sterk gericht op functionaliteit die zichtbaar is voor de (eind)gebruiker.

Aandacht voor het duurzaam houden van software beperkt zich in het beste geval tot het verbeteren van broncode op basis van bevindingen uit statische codeanalyse. Onderhoudbaarheid en bruikbaarheid op de lange termijn worden daarentegen sterk bepaald door de kwaliteit van de softwarearchitectuur. De mate waarin de architectuur is geïmplementeerd in de code heeft een grotere impact op productkwaliteit dan de meetbare kwaliteit van broncode.

Softwarearchitectuur is ondanks alle architectuurcongressen en architectuurforums een slecht begrepen en onderbelichte discipline. Zij laat zich omschrijven als een reeks van ontwerpbeslissingen die resulteert in de beschrijving van high-­level componenten en hun onderlinge samenhang binnen een applicatie. Softwarearchitectuur beschrijft een applicatie vanuit meerdere perspectieven. Zoals de indeling van broncode, runtime componenten, verbindingen met andere systemen en de uitrol op hardware. Architectuur dient overzicht te houden en te sturen op doelmatige implementatie van functionele en niet-functionele eisen. Juist ontkoppelde componenten in een goed gekozen structuur bieden de kans om een applicatie zonder veel moeite aan te passen aan veranderende omstandigheden.

CODE-­RAAMWERK

De ‘Model-code-­gap’ werd in 2010 door George Fairbanks geïntroduceerd in het boek Just enough software architecture. De term beschrijft dat architectuurmodellen en code de structuur dermate verschillend uitdrukken dat er sprake is van een kloof.

De grammatica van gangbare programmeertalen biedt nauwelijks mogelijkheden om de ordening van architecturele componenten aan te duiden. Het vereist het creatief toepassen van design patterns of gebruik van frameworks.

Een effectieve manier om structuur aan te brengen is door een klein team de architectuur om te laten zetten in een coderaamwerk. Dit raamwerk drukt structuur uit middels sleutelcomponenten met een herleidbare naamgeving. Tevens bevat het end-to-end gecodeerde functionaliteit in de vorm van een referentie-implementatie. Het is vervolgens aan een groter ontwikkelteam om aanvullende features te implementeren.

De configuratie en orkestratie, die deze componenten aan elkaar verbinden, laten zich bij voorkeur lezen als een handleiding hoe het systeem functioneel en technisch in elkaar steekt. Ontwikkelaars die een onderdeel aanpassen, moeten zich kunnen concentreren op het betreffende stuk broncode. Ze moeten aanpassingen kunnen doorvoeren, zonder dat ze daarvoor de werking van het hele systeem hoeven te overzien of schade kunnen aanrichten.

De introductie van het begrip architectuur in de IT is nuttig geweest, omdat architectuur onderscheid aanbrengt tussen ontwerpcomponenten op verschillende niveaus. Maar de invulling in expliciete rollen van architect en ontwikkelaar – de laatste bij de overheid aangeduid als ‘bouwer’ – heeft ook een kloof veroorzaakt tussen ontwerp en implementatie. Softwarearchitectuur overbrugt deze kloof.

Stuurmiddel

Klanten en management willen kunnen sturen bij de ontwikkeling van maatwerksoftware. Architectuur is hiervoor bij uitstek een geschikt middel, mits zij een passende vertaling vormt van klantwaarde en bedrijfsdoelstellingen naar een realiseerbare technische oplossing.

Structuur broncode is doorgaans een flauwe afspiegeling van de architectuur

Wil architectuur deze rol als stuurmiddel daadwerkelijk vervullen, dan is het vanzelfsprekend dat broncode gestructureerd is conform de architectuur. En dat de architectuur gedurende het ontwikkelproces mee-evolueert met de structuur van de code. Dit veronderstelt een voortdurende interactie tussen codeontwikkeling, architectuurfunctie en stakeholders. In beginsel is het zo dat elk stuk code in een maatwerkoplossing naar waardetoevoeging en bedrijfsdoelstellingen is te traceren.

De praktijk is echter dat de structuur van broncode doorgaans een flauwe afspiegeling is van de veronderstelde architectuur. De architectuur is niet meer dan een gedeeld conceptueel beeld dat veel ruimte biedt voor eigen interpretatie. Met als consequentie dat applicaties verworden tot een monoliet in plaats van een samenstelling van ontkoppelbare componenten. De discrepantie tussen ontwerp en geïmplementeerde structuur wordt wel de ‘model-code-gap’ genoemd.

Softwarearchitectuur onzichtbaar & onderbelicht

 

Figuur MeetsmaDe kwaliteit van software is deels verborgen. Stakeholders ervaren de werking van een applicatie positief in de vorm van features, of negatief in de vorm van gebreken. Agile is sterk gefocust op de zichtbare aspecten van software: het toevoegen van features en het oplossen van bugs.

Door gebruik van tools is ook achterstallig onderhoud of technische schuld beter zichtbaar geworden. Softwarearchitectuur is relatief onderbelicht.

Tools om codekwaliteit te meten, zoals bijvoorbeeld SonarQube, Fortify en Findbugs raken ingeburgerd in het ontwikkelproces. Ze wijzen ontwikkelaars op functies die te lang of complex zijn, constructies die mogelijk slechte performance opleveren of een lage graad van testdekking hebben. Ze geven daarmee weliswaar een indicatie van mogelijk gebrekkige kwaliteit, maar ze constateren slechts issues op microniveau. Dit levert een eenzijdig beeld op. Elk stuk broncode wordt tegen dezelfde meetlat aangelegd, zonder onderscheid te maken naar functie of relevantie.

Ook de mate waarin aan de code wordt gewerkt of hoe vaak deze in productie wordt aangeroepen, speelt geen rol.

Structurele verbeteringen zijn niet zichtbaar en worden uitgesteld.

Softwarescans zullen doorgaans een positieve score geven aan code die goed modulair is opgezet; code die compact en leesbaar is. Dit wil niet zeggen dat code met een hoge score onderhoudbaar is: ‘doing things right’ is nog niet ‘doing the right things’. Ontwikkelaars die ijverig alle issues wegwerken, maken de code daarmee niet per se robuust of begrijpelijk voor anderen. Verbetering van de code op basis van statische codeanalyse is in feite symptoom­bestrijding.

Impact van agile

Een iteratieve, agile benadering van het ontwikkelen van software adresseert het aanbrengen van architectuur in code, althans in theorie. Het principe heet emergent design. Men neemt enkele aanvankelijke ontwerpbeslissingen en vervolgens komt de architectuur gaandeweg tot stand. Men veronderstelt dat ontwikkelaars voldoende vaardigheid in refactoring of herstructurering hebben om bij voortschrijdend inzicht of wijzigende eisen de structuur zo aan te passen dat deze de werking van de software reflecteert.

In de praktijk valt dat tegen. Agile methodieken houden ontwikkelaars voortdurend bij de les als het gaat om het ontwikkelen van features. Standup meetings, planningsessies en met name sprintdemo’s zorgen ervoor dat een ontwikkelaar voortdurend voortgang moet laten zien. Dat doen ontwikkelaars dan ook. Ze concentreren zich op alles dat zichtbaar is: meer functionaliteit, minder SonarQube-issues en hoge unittestdekking. Structurele verbeteringen zijn niet zichtbaar en worden uitgesteld. Herstructurering remt bovendien de zichtbare voortgang van andere ontwikkelaars. Niet alleen productiecode moet worden aangepast. In veel gevallen moet een aanzienlijke hoeveelheid unittestcode worden herschreven.

5 misinterpretaties van statische code-analyse

Statische code-analyse maakt het vakmanschap van programmeurs tastbaar. Gemeten karakteristieken geven echter ook een te simplistisch beeld van de onderhoudbaarheid van broncode. Zonder duiding gaan de cijfers een eigen leven leiden.

Misinterpretaties:

1. Er is weer veel code bijgekomen, dus de ontwikkelaars zijn productief.

2. We hebben een hoge rating, dus de software is goed.

3. We hebben een unittestdekking van 90 procent; de code is robuust.

4. Als we alle gemeten issues wegwerken, is de code onderhoudbaar.

5. Productkwaliteit is voldoen aan metriekwaarden.

Als er al aandacht voor architectuur is, dan is er een andere tegenwerkende factor. In agile projecten is het gangbaar dat hiërarchie afwezig is en dat ‘het team’ beslist welke zaken worden opgepakt en hoe. Dat betekent dat een team het ook eens moet zien te worden over kwesties van architectuur. Dit leidt in de praktijk tot veel discussie en compromissen. Deze vorm van architectuur laat zich omschrijven als design by committee.

Kloof

Softwarearchitectuur en de implementatie daarvan in broncode verdienen meer aandacht. Een ontwikkelteam moet in staat zijn om de implementatie synchroon te houden met een ontwerp en daarmee de ‘model-code-gap’ te dichten. Om geïmplementeerde structuur te visualiseren en om ontwerpbeslissingen te herleiden naar klantwaarde, zodat architectuur een aanvullend stuurmiddel is voor management. Een onvolwassen agile team zal deze verantwoordelijkheid niet kunnen dragen. Dit veronderstelt een hernieuwde invulling van de rol van architect. Een architect die niet alleen top-down ontwerpt, maar ook broncode kan interpreteren en de feedbackcyclus rond maakt. Een architect die ingrijpt wanneer structurele verbeteringen in de broncode niet langer meer kunnen worden uitgesteld. Af en toe moet het ontwikkelen van features wijken ten gunste van herstructurering. Dit kan worden ingepland in aparte technische sprints waarbij de codebase tijdelijk wordt bevroren.

5 valkuilen agile software-ontwikkeling

Agile softwareontwikkeling heeft zijn wortels in een manifest met een aantal best practices die ‘excellente’ teams hanteren om productief te zijn. Agile is nu vooral synoniem met de ernaar vernoemde methoden en processen.

Valkuilen:

1. Zichtbare klantwaarde is het enige dat telt.

2. Het proces levert altijd resultaat op; sturen op tijd of budget is overbodig.

3. Elk team is in staat gezamenlijk de beste beslissing te nemen.

4. Een middelmatig team kan exceller­en door Scrum strikt te volgen.

5. De architectuur komt wel goed gedurende het proces.

Het softwareontwikkelproces is met de komst van agile verbeterd, omdat het bijsturing mogelijk maakt. Daarbij is softwarearchitectuur onderbelicht geraakt. Maar agile heeft ons verlost van rigide technische ontwerpen die op den duur een obstakel vormen voor ontwikkeling. Het biedt in feite een kans om de model-code-gap te dichten, het laatste obstakel voor productiviteit.

Net als functionaliteit moet architectuur een onderdeel zijn van de iteratieve ontwikkelcyclus. Door bewust de zichtbaarheid van architectuur te vergroten en structuur op te nemen in het ontwikkelproces krijgt het een plaats als stuurmiddel naast functionaliteit en algemene codekwaliteit.

Zie ook Development op AG Connect Intelligence
Reactie toevoegen