Wat is minimalist software architecture?

Minimalisme verwijst meestal naar een simpele oplossing zonder extra opsmuk. Wat softwarearchitectuur betreft, betekent dit dus een eenvoudig, rechtlijnig ontwerpproces.

Softwareontwikkelaars die in een minimalistisch kader werken, proberen overbodige complexiteit, ontwerpen, afhankelijkheden, functies en code zo veel mogelijk te vermijden. Door minimalisme te omarmen, kun je de wrijving verminderen die tijdens het ontwikkelproces ontstaat wanneer er veel beperkingen van bovenaf worden opgelegd. Het staat teams vrij om te ontwerpen en implementeren wat zij nodig vinden.

In dit artikel gaan we dieper in op minimalistische software architectuur en hoe je minimalistische principes op je eigen architectuur kunt toepassen. 

Wat is een minimalistische benadering van softwarearchitectuur?

Een minimalistische aanpak betekent in feite het ontwerpen van een architectuur die niet onnodig ingewikkelder is dan de omvang van het project. Hier noemen we een paar nuttige uitgangspunten voor softwarearchitecten die een minimalistische aanpak nastreven:  

• Gefocust en doelgericht: Elk onderdeel van de architectuur moet gefocust zijn op scherp omlijnde projectdoelstellingen en een duidelijk oogmerk dienen. 
• Best practices: Houd tijdens het ontwerpproces alle basisprincipes van softwarearchitectuur in acht en pas deze toe. Vermijd ontwerppraktijken waarvan bekend is dat ze de kwaliteit van de code verminderen en tot onnodige afhankelijkheden leiden.
• Geen redundantie: Code en ontwerp mogen niet repetitief zijn. Redundantie zorgt voor meer code en afhankelijkheden zonder extra waarde op te leveren.
• Toegankelijk: Een strakke, overzichtelijke architectuur die anderen goed kunnen begrijpen, gebruiken en aanpassen. Zorg ervoor dat teamleden later naar je werk kunnen verwijzen zonder daarin onconventionele code te vinden.

Voordelen en valkuilen van een minimalist software architecture aanpak

Een minimalistisch software  ontwerp brengt verschillende voordelen met zich mee, zoals: 

• Samenwerken met andere teams: Nadat de softwarearchitectuur is gedefinieerd, werken andere teams aan de ontwikkeling van domeinen, toepassingen en/of componenten. Een minimalistische aanpak geeft deze ontwikkelaars en ontwerpers de vrijheid om zelf beslissingen te nemen.
• Vrijheid en flexibiliteit, ook in de toekomst: De behoeften en prioriteiten van de organisatie veranderen na verloop van tijd. Een minimalistisch ontwerp geeft bedrijven de nodige flexibiliteit om de architectuur aan te passen.
• Naleving van wetgeving: Architectuur die zich op systeembehoeften richt, moet aan systeembrede naleving kunnen voldoen.
• Onderhoud blijft realistisch: Hoe groter en complexer de architectuur is, hoe moeilijker het wordt om al deze elementen te onderhouden. Door je architectuur simpel te houden, beperk je het onderhoud ervan tot de belangrijkste afhankelijkheden en definities.
• Meer wendbaarheid: Ontwerpen met een kleinere voetafdruk hebben minder middelen nodig en zijn dus wendbaarder.
• Betere gebruikerservaring: Dankzij betere prestaties en meer flexibiliteit binnen de software  architectuur kunnen ontwikkelteams zich richten op het verbeteren van de gebruikerservaring.

Ondanks alle bovengenoemde voordelen zijn er toch een paar dingen die je moet zien te vermijden als je een minimalistische softwarearchitectuur ontwerpt:

• Te veel beperkingen: Als je te veel zaken van bovenaf regelt en definieert, levert dit een onnodig aantal beperkingen op.
• Ongedefinieerde architectuur: Als de architectuur niet duidelijk omlijnd en op de behoeften van de organisatie afgestemd is, kunnen ontwikkelaars zich gedwongen voelen om hiaten in de architectuur zelf in te vullen.
• Oplossen van problemen buiten de scope: Door problemen op te lossen die buiten de beoogde doelen vallen, kan het evenwicht binnen je architectuur worden verstoord, met systeembrede gevolgen.

Minimalist software architecture: hoe pak je het aan?

Nu je weet wat een minimalistische aanpak is, noemen we hieronder vier stappen die je kunt nemen om deze structuur op je eigen architectuur toe te passen.

1. Focus op essentiële afhankelijkheden

Je moet er vanaf het begin van je ontwerp rekening mee houden dat niet alle afhankelijkheden volledig vermeden kunnen worden. Richt je dus op de belangrijkste basisafhankelijkheden die je nodig hebt om je systeem goed te laten functioneren.

Als minimalist moet je strategisch omgaan met de code-afhankelijkheden die je in je architectuur opneemt. Als je dit niet doet, loop je het risico op slecht werkende toepassingen of dat je dure systeemrevisies moet uitvoeren.

Code-afhankelijkheden

Code waarvoor specifieke inhoud nodig is of die naar een externe toepassing verwijst, noemen we een afhankelijkheid. Hoe meer afhankelijkheden, hoe complexer je systeem en hoe waarschijnlijker het wordt dat dit later extra beperkingen of onderhoudsproblemen voor je team oplevert.

Nauw verbonden code is vaak onderling afhankelijk van andere bibliotheken en codecomponenten. Verstoringen kunnen je architectuur danig in de war schoppen, dus wees hier erg voorzichtig mee. Talen, platforms, kaders en bibliotheken kunnen in de verkeerde context allemaal een zwak punt vormen.

Ontwikkelaars die tijdelijke oplossingen en aanpassingen voor architecturale beslissingen aanbrengen, voegen daardoor extra elementen toe die het risico op een dure verbouwing van je architectuur vergroten. Zowel monolithische als microservicearchitecturen kunnen code-afhankelijkheden hebben.

Houd daarom goed rekening met deze afhankelijkheidstypen bij het plannen van je architectuur. Als je het aantal afhankelijkheden kunt beperken of vereenvoudigen, doe dat dan. Hier zijn een paar veelvoorkomende afhankelijkheden die je moet zien te vermijden:

• Nesting: Dit komt voor wanneer een deel van de code of toepassing binnen een andere code of toepassing is geplaatst, zodat het zonder deze andere code niet kan functioneren. Als er iets met de code gebeurt, dan werkt de oorspronkelijke toepassing niet meer.
• Aanroepen: Het gebruik van externe code of toepassingen in je architectuur creëert aanroepafhankelijkheden. Als de externe code wordt bijgewerkt, moeten andere toepassingen ook worden bijgewerkt, anders werken ze niet meer.
• Bundelen: Als een toepassing afhankelijk is van code die binnen een andere toepassing is geplaatst (genesteld), worden beide toepassingen samengevoegd en kunnen ze beide, of elk afzonderlijk, van de ander afhankelijk zijn.
• Transitiviteit: Op dezelfde manier kunnen drie of meer toepassingen overlappende afhankelijkheidsrelaties hebben, en daardoor meer complexiteit aan je architectuur toevoegen.

Probeer dit soort afhankelijkheden zo veel mogelijk te beperken, tenzij ze absoluut noodzakelijk voor je architectuur zijn, omdat ze later anders voor problemen kunnen zorgen.

2. Houd rekening met naleving

Op ontwerpniveau moeten er vaak beslissingen over naleving worden genomen. Er kunnen vereisten zoals HIPAA, AVG en PCI op je systeem van toepassing zijn. De manier waarop je je softwarearchitectuur inricht, is van grote invloed op je mogelijkheid om aan al deze vereisten te voldoen. Als je geen rekening houdt met naleving, loop je het risico dat er delen van je systeem niet aan de vereisten voldoen.

• Ingebouwde naleving: Geef je architectuur vorm rond de nalevingsnormen voor je branche en gebruikte toepassingen.
• Gebruik nalevingscontroles voor je architectuur (ACC's): Voer na de bouw van je architectuur een ACC (Architecture Compliance Check) uit om ervoor te zorgen dat deze aan de normen voldoet.
• Pas op voor afhankelijkheidsverstoringen: Code-afhankelijkheden en nauwe verbondenheden kunnen ook van invloed zijn op de naleving.

3. Bekijk je architectuur vanuit het perspectief van de gebruiker

Uiteindelijk maak je je systeem en toepassingen voor je gebruikers. Een gebruikersgericht perspectief richt zich op de architectuur die het beste op de behoeften van de gebruikers aansluit. Ontwikkelaars en architecten kunnen soms geneigd zijn om zich op hun eigen behoeften te richten, en niet op die van de gebruiker, maar creëren zo bijvoorbeeld het risico dat een systeem niet aan de scope voldoet.

Kwaliteitskenmerken die van invloed zijn op de UX

Op architectonisch niveau zijn jouw beslissingen rechtstreeks van invloed op de kwaliteitskenmerken van het hele systeem. Door je op de belangrijkste afhankelijkheden te richten, zorg je ervoor dat je systeem over de juiste kwaliteitskenmerken beschikt, geen beperkingen oplegt aan andere ontwikkelaars en ontwerpers, of een slechte gebruikerservaring oplevert.

• Bruikbaarheid: Flexibiliteit en de mate waarin het systeem aan de UX-vereisten voldoet
• Betrouwbaarheid: Uptime en in hoeverre het systeem betrouwbare prestaties levert
• Beschikbaarheid: Functionaliteit en lokaal herstel
• Beveiliging: Gegevensbescherming, verificatie, toegang en kwetsbaarheid
• Compatibiliteit: Ondersteuning voor de systemen en toepassingen die je organisatie gebruikt en nodig heeft
• Onderhoudbaarheid: Het gemak waarmee het systeem onderhouden en ondersteund kan worden
• Schaalbaarheid: Het vermogen van je systeem om nu en in de toekomst op te schalen

4. Architecturale controle

Als software architect heb jij aanzienlijke potentiële controle over hoe het uiteindelijke systeem eruit komt te zien. Als je deze controle effectief gebruikt, kun je problemen voor de hele organisatie oplossen die toepassingen alleen niet voor elkaar kunnen krijgen. Een te grote architecturale controle kan echter wel tot spanningen leiden als jouw beslissingen de beoogde doelen van andere stakeholders ondermijnen.

Als je een grote architectuur opbouwt, kan elke extra beslissing minder impact hebben. Jij moet dus de juiste balans zien te vinden tussen controle en creatieve vrijheid in je softwarearchitectuur.

Hoe houd je je architectuur in balans?

• Lokaal versus internationaal bereik: Sommige beslissingen zijn niet geschikt voor lokale toepassingen. Hier kun je via je architectuur op inspelen.
• Denk aan je stakeholders: Beslissingen over architectuur zijn op verschillende manieren van invloed op stakeholders. Houd er dus rekening mee hoeveel controle je stakeholders kunnen of willen tolereren.
• Creëer een robuuste architectuur: Hoewel minimalisme belangrijk is, moet je een structuur opbouwen die tegen een stootje kan en de kans verkleint dat je je architectuur later grondig moet herzien.

Hoe vereenvoudigde softwareontwikkeling je architectuur kan verbeteren

Door een minimalist software architecture aanpak te kiezen, kun je je organisatie helpen om belangrijke bedrijfsresultaten te behalen en moeilijke problemen op systeemniveau aan te pakken.

Als je de ontwikkeling van je software simpel houdt, kun je je beter op de hoofdzaken en bedrijfsdoelstellingen richten. Minimalisme geeft softwarearchitecten de mogelijkheid om vorm te geven aan het hele systeem zonder dat dit ten koste gaat van andere organisatiedoelen.