Wat is software-architectuur?

Definitie: Software-architectuur is de hoofdstructuur van een softwaresysteem: uit welke onderdelen het bestaat, welke taak elk onderdeel heeft en hoe die onderdelen met elkaar en met andere systemen samenwerken. Het legt de belangrijke technische keuzes vast die later moeilijk te veranderen zijn, zoals de opbouw van de applicatie, de opslag van gegevens en de manier van koppelen.

In het kort

• Software-architectuur is de blauwdruk van een applicatie op hoofdlijnen, vergelijkbaar met de bouwtekening van een gebouw.
• Bekende architectuurstijlen zijn de monoliet, microservices, serverless en een gebeurtenisgestuurde opzet.
• Goede architectuur maakt een applicatie begrijpelijk, veilig, onderhoudbaar en uitbreidbaar. Een slechte keuze is achteraf duur om te herstellen.
• Voor de meeste zakelijke webapplicaties is een goed opgebouwde monoliet de logische start.

Wat is software-architectuur?

Software-architectuur beschrijft hoe een applicatie in elkaar zit, zonder in te gaan op elke regel code. Het gaat om de grote lijnen: welke onderdelen zijn er, wat doet elk onderdeel, waar staan de gegevens, hoe praat de applicatie met andere systemen en hoe wordt het geheel beveiligd en uitgerold.

AppMaster omschrijft het als een blauwdruk op hoog niveau die de structuur, het ontwerp en het gedrag van een softwaresysteem vastlegt. Die vergelijking met een bouwtekening klopt goed. Een aannemer kan een muur verplaatsen, maar het fundament veranderen als het huis er al staat is lastig en duur. In software werkt het net zo: een knop of scherm aanpassen is eenvoudig, de manier waarop gegevens zijn opgeslagen of de opsplitsing in onderdelen omgooien is dat niet.

Software-architectuur gaat daarom vooral over keuzes die moeilijk terug te draaien zijn. Denk aan:

• De opbouw van de applicatie: één geheel of losse services.
• De programmeertaal en het framework.
• De database en de structuur van de gegevens.
• De manier waarop gebruikers inloggen en rechten krijgen.
• Koppelingen met andere systemen.
• Hosting, uitrol en monitoring.
• Hoe taken op de achtergrond worden uitgevoerd.

Waarom is software-architectuur belangrijk?

Architectuur bepaalt hoe makkelijk een applicatie zich later laat aanpassen. Een duidelijke opzet maakt het mogelijk om functies toe te voegen zonder dat andere onderdelen breken. Een rommelige opzet leidt tot technische schuld: elke wijziging kost meer tijd, en fouten duiken op onverwachte plekken op.

Goede architectuur helpt bij:

• Onderhoud. Een andere ontwikkelaar begrijpt sneller hoe het werkt en kan verder bouwen.
• Beveiliging. Rechten, toegang en gevoelige gegevens zijn op één plek goed geregeld.
• Prestaties. Zware taken draaien op de achtergrond en blokkeren de gebruiker niet.
• Schaalbaarheid. De applicatie kan groeien in gebruikers en gegevens zonder volledig opnieuw te bouwen.
• Koppelingen. Andere systemen sluiten aan via vaste, gedocumenteerde ingangen.
• Kosten. Fouten in de basis zijn vroeg goedkoop en laat duur om te herstellen.

Welke architectuurstijlen zijn er?

Er zijn verschillende hoofdstijlen. Elke stijl heeft eigen sterke punten en nadelen.

Daarnaast zijn er patronen op een lager niveau, zoals het MVC-patroon (model, view, controller) dat veel webframeworks gebruiken, en een gelaagde opbouw met een presentatielaag, een laag met bedrijfslogica en een datalaag.

Monoliet of microservices?

Dit is een van de bekendste architectuurvragen. Atlassian zet de verschillen helder op een rij.

Een monoliet is volgens Atlassian eenvoudig te implementeren, makkelijker te debuggen en geeft in een vroege fase een hoge ontwikkelsnelheid. De nadelen komen bij groei: onderdelen kunnen niet los worden geschaald, een fout in één module kan de hele applicatie raken en elke wijziging vraagt een volledige nieuwe uitrol.

Microservices kunnen onafhankelijk worden ontwikkeld, uitgerold en geschaald. Daar staat tegenover dat beheer, monitoring en afstemming tussen teams veel meer werk vragen, en dat fouten zoeken lastiger wordt omdat logs over meerdere services verspreid staan.

Grote bedrijven zijn overgestapt omdat hun monoliet de groei niet meer aankon. Atlassian beschrijft hoe Netflix vanaf 2009 overging op microservices in de cloud, en hoe Atlassian zelf in 2018 Jira en Confluence omzette. Dat zijn grote organisaties met zeer veel gebruikers en ontwikkelteams. Voor een applicatie met tientallen of honderden gebruikers geldt een andere afweging. Ook AppMaster adviseert om eenvoudig te beginnen met een monoliet en pas later onderdelen af te splitsen als daar een reden voor is.

Hoe ziet de architectuur van een webapplicatie eruit?

Een typische zakelijke webapplicatie, zoals een klantportaal of interne tool, bestaat uit een paar vaste lagen:

1. De voorkant (frontend). De schermen in de browser, waarmee gebruikers werken.
2. De achterkant (backend). De applicatielogica: regels, berekeningen, rechten en processen. Hier draait bijvoorbeeld een framework als Laravel.
3. De database. Waar klanten, opdrachten, documenten en statussen worden opgeslagen.
4. Achtergrondtaken. Een wachtrij voor taken die tijd kosten, zoals e-mails versturen, bestanden verwerken of een AI-model aanroepen.
5. Geplande taken. Processen die op vaste momenten draaien, zoals een dagelijkse rapportage.
6. Koppelingen. API’s naar boekhouding, CRM, betaalsystemen of andere software.
7. Bestandsopslag. Voor uploads, documenten en afbeeldingen.
8. Hosting en monitoring. De server of het platform, met back-ups, logbestanden en meldingen bij fouten.

Niet elke applicatie heeft alle onderdelen nodig. Een eenvoudige rekentool heeft misschien geen wachtrij, een portaal met veel documenten wel.

Uitgewerkt voorbeeld: een serviceportaal

Stel dat een installatiebedrijf een portaal wil waarin klanten storingen melden en de status volgen, en waarin planners monteurs inzetten. Een passende architectuur ziet er dan zo uit:

1. Eén webapplicatie met modules voor klanten, meldingen, planning en rapportage. Een monoliet volstaat, omdat het aantal gebruikers overzichtelijk is.
2. Rollen en rechten in de basis: een klant ziet alleen zijn eigen meldingen, een planner ziet alles van zijn regio, een beheerder ziet alles.
3. Een relationele database met tabellen voor klanten, locaties, meldingen, afspraken en monteurs, met vaste relaties ertussen.
4. Een wachtrij voor het versturen van bevestigingen en statusberichten, zodat de klant niet hoeft te wachten.
5. Een geplande taak die elke ochtend een overzicht maakt van openstaande meldingen.
6. Een koppeling met het boekhoudpakket voor de facturatie na afronding.
7. Bestandsopslag voor foto’s die klanten bij een melding uploaden.

Elke keuze volgt uit een vraag over het proces. Dat maakt de opzet uitlegbaar, ook aan iemand die niet technisch is.

Wat doet een software-architect?

In grote organisaties is software-architect een aparte functie. De architect bewaakt de samenhang tussen systemen, kiest technologieën, legt richtlijnen vast en adviseert ontwikkelteams. Hij vertaalt eisen van de organisatie, zoals beveiliging, beschikbaarheid en kosten, naar technische keuzes.

Bij kleinere projecten is architectuur geen aparte rol, maar een taak van de ontwikkelaar. De vragen blijven hetzelfde. Vraag daarom bij het laten bouwen van een applicatie altijd hoe de opbouw eruitziet en waarom voor die opzet is gekozen.

Architectuur en kwaliteitseisen

Naast functies stelt een applicatie eisen aan kwaliteit. Die worden ook wel niet-functionele eisen genoemd, en ze sturen de architectuur sterk:

• Beschikbaarheid. Moet de applicatie altijd bereikbaar zijn, of is kort onderhoud buiten kantooruren acceptabel?
• Snelheid. Hoe snel moet een scherm laden, ook met veel gegevens?
• Privacy. Welke persoonsgegevens worden verwerkt, en moeten die in Europa blijven?
• Herstel. Hoe snel moet de applicatie terug zijn na een storing, en hoe oud mag de laatste back-up zijn?

Leg die eisen vroeg vast. Ze bepalen mee welke hosting, database en opbouw passen.

Hoe leg je architectuur vast?

Architectuur die alleen in het hoofd van één ontwikkelaar zit, is een risico. Een paar vormen van documentatie helpen:

• Architectuurdiagrammen. Volgens Lucid laat een architectuurdiagram de structuur van het systeem zien, met de verbanden en grenzen tussen de onderdelen. Lucid onderscheidt onder meer applicatie-, integratie-, deployment- en datadiagrammen.
• Een vaste notatie. Atlassian noemt UML en het C4-model als gestandaardiseerde manieren om diagrammen te tekenen, zodat iedereen ze op dezelfde manier leest.
• Beslissingen met onderbouwing. Noteer belangrijke keuzes en waarom ze zijn gemaakt. Een korte notitie per beslissing, met de context, de opties en de keuze, voorkomt dat een volgende ontwikkelaar dezelfde discussie opnieuw voert.
• Een overzicht van koppelingen. Welke systemen praten met de applicatie, via welke ingang en met welke sleutels?

Houd documentatie kort en actueel. Een diagram van één pagina dat klopt, is waardevoller dan een uitgebreid document dat al een jaar niet is bijgewerkt.

Hoe kies je de juiste architectuur?

AppMaster noemt een reeks factoren die een rol spelen. De belangrijkste voor zakelijke applicaties zijn:

• Omvang en complexiteit. Hoeveel processen, rollen en uitzonderingen moet de applicatie aankunnen?
• Verwachte groei. Gaat het om tien gebruikers of tienduizend?
• Ervaring van het team. Een architectuur die het team niet goed kent, leidt tot fouten.
• Bestaande systemen. Met welke software moet de applicatie samenwerken?
• Beveiliging en regelgeving. Welke gegevens worden verwerkt en waar moeten die staan?
• Budget en snelheid. Hoeveel tijd en geld is er voor de eerste versie en voor beheer?
• Onderhoud. Wie beheert de applicatie straks, en hoe makkelijk kan een ander het overnemen?

Veelgemaakte fouten in software-architectuur

• Te zwaar beginnen. Microservices, meerdere databases en complexe infrastructuur voor een applicatie met twintig gebruikers.
• Geen structuur aanbrengen. Alle logica door elkaar, zodat elke wijziging onverwachte gevolgen heeft.
• Rechten als bijzaak. Wie wat mag zien en doen hoort in de basis, niet in losse controles achteraf.
• Koppelingen vergeten. Een applicatie die later met de boekhouding moet praten, vraagt nu al om een duidelijke datastructuur.
• Geen documentatie. Alleen de bouwer weet hoe het werkt.
• Afhankelijk van één aanbieder zonder dat bewust te kiezen, bijvoorbeeld door diep in te bouwen op een specifiek platform.

Wat betekent dit voor jouw project?

Architectuur begint voor mij bij het proces, niet bij de techniek. Wat komt binnen, wie moet ermee verder en welke informatie heeft die persoon nodig? Uit die vragen volgt welke gegevens er zijn, welke rollen, welke koppelingen en welke stappen op de achtergrond moeten draaien.

Een voorbeeld uit mijn eigen werk is Mailyooo, mijn e-mailmarketingsoftware. Verzenden is daar een keten met keuzes: welke contacten, welke selectie, wanneer een bericht wordt klaargezet en hoe zichtbaar blijft wat er is gebeurd. Een verzendwachtrij en uitschrijffilters zijn dan geen detail, maar onderdeel van de opzet.

In de betaalde blauwdruk leg ik de afhankelijkheden vast voordat er gebouwd wordt: welke systemen, welke gegevens en welke volgorde. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Dan kan de architectuur eenvoudig blijven waar het kan, en stevig zijn waar het moet.

Vraag? Stuur me wat de applicatie moet doen, wie ermee werkt en met welke systemen het moet samenwerken. Dan bepalen we samen de logische eerste stap. Lees ook wat er komt kijken bij een webapplicatie bouwen.

Veelgestelde vragen over software-architectuur

Wat is software-architectuur?

Software-architectuur is de hoofdstructuur van een softwaresysteem: de onderdelen, hun taken en de manier waarop ze samenwerken. Het legt de belangrijke technische keuzes vast, zoals de opbouw, de opslag van gegevens en de koppelingen.

Wat is het verschil tussen software-architectuur en softwareontwerp?

Software-architectuur gaat over de hoofdlijnen en keuzes die moeilijk te veranderen zijn, zoals de opbouw in onderdelen en de database. Softwareontwerp gaat over de uitwerking binnen die onderdelen, zoals klassen, functies en ontwerppatronen.

Is een monoliet verouderd?

Nee. Een monoliet is eenvoudig te ontwikkelen, testen en uitrollen, en past bij de meeste kleine en middelgrote applicaties. Microservices worden vooral interessant bij grote teams en sterk wisselende belasting per onderdeel.

Verwante termen

Technische schuld · Laravel · API · API-koppeling · Database · Webapplicatie · Vendor lock-in · Broncode