Ik krijg vaak de vraag hoe je een IT-project goed plant en structureert. Tot verbazing van veel mensen is dat in principe vrij eenvoudig, maar in de praktijk een stuk lastiger. Een IT-systeem levert niet vanzelf waarde op door alleen maar te bestaan (oké, misschien Bitcoin :-)). Meestal dient het een doel, in ieder geval bij zakelijke B2B-applicaties.
1. Begrijp de context#
Bekijk deze stap in de illustratie ↗
Een goed begin is om de kernprocessen van de organisatie die de toepassing gaat gebruiken volledig te begrijpen. Kijk in deze fase vooral niet te beperkt. Probeer het grotere geheel te begrijpen en ga tekenen. Stem dit af met de organisatie en leg het vast in bijvoorbeeld een Mermaid-diagram, BPMN 2.0 (als je, net als ik, de twintig al een tijdje voorbij bent :-)), draw.io of een ander hulpmiddel dat je prettig vindt.
Stem dit af met de belangrijkste stakeholders, zodat duidelijk is wat de toepassing doet en in welke processen zij wordt ingebed. Dat klinkt eenvoudig, maar is voor veel organisaties al behoorlijk lastig.
Bespreek ook nu al welke wettelijke verplichtingen en compliance-eisen voor de organisatie gelden, zodat je vanaf het begin rekening houdt met wetgeving en beveiliging. Kijk naar de AVG, NIS2, de EU AI Act, de CRA en andere relevante wetgeving, waar van toepassing. Betrek de juridische afdeling of een jurist als dat nodig is.
2. Bepaal de eisen#
Bekijk deze stap in de illustratie ↗
Na deze stap zouden we goed moeten begrijpen wat de organisatie nodig heeft. Dat kunnen we nu vertalen naar een set eisen. Daaronder vallen functionele eisen, dus wat het systeem moet doen, maar ook niet-functionele eisen zoals prestaties, beschikbaarheid, beveiliging, schaalbaarheid en onderhoudbaarheid.
Probeer die eisen zo concreet en meetbaar mogelijk te maken. Een eis als “het systeem moet snel zijn” helpt bijvoorbeeld niet. Wat betekent snel? 100 milliseconden? 2 seconden? En onder welke omstandigheden?
Vergeet ook niet dat eisen elkaar kunnen tegenspreken. De business wil misschien een hoog beschikbaar systeem met realtimeverwerking, maar heeft tegelijkertijd nauwelijks budget voor infrastructuur.
Die gesprekken moet je vroeg voeren, niet wanneer het systeem al voor de helft is geïmplementeerd.
Het resultaat moet een duidelijke set eisen, beperkingen en verwachte resultaten zijn waar de organisatie achter staat.
3. Kies ontwerppatronen#
Bekijk deze stap in de illustratie ↗
Er zijn problemen. Dit is het moment waarop we oplossingen nodig hebben!
Je kunt problemen het beste oplossen met bewezen oplossingen die hun waarde in de praktijk hebben laten zien: ontwerppatronen, bijvoorbeeld de Cloud Design Patterns (het liefst die van Microsoft :-)). Gebruik gevestigde ontwerppatronen waar ze zinvol zijn. Lees ze, begrijp ze, pas ze toe en bouw je ontwerp erop voort. Meestal is er geen reden om het wiel opnieuw uit te vinden.
Als je bijvoorbeeld een systeem moet bouwen dat events verwerkt, historische wijzigingen opslaat en verschillende weergaven van dezelfde gegevens biedt, kun je naar Event Sourcing en CQRS kijken. Heb je externe diensten die tijdelijk kunnen uitvallen, kijk dan naar de patronen Retry en Circuit Breaker.
Natuurlijk heeft niet ieder systeem een ingewikkelde architectuur nodig. Soms is een eenvoudige applicatie met een relationele database prima. Het gaat erom dat je eerst het probleem begrijpt en daarna beoordeelt welke bestaande oplossingen geschikt zijn. Leg ook vast waarom je een bepaald patroon hebt gekozen en waarom je alternatieven hebt afgewezen. Dat is heel belangrijk als een andere architect het overneemt. Die kan dan zien dat je ontwerpkeuzes bewust zijn gemaakt en je redenering begrijpen.
4. Selecteer de technologie#
Bekijk deze stap in de illustratie ↗
Als dat duidelijk is, weten we welke ontwerppatronen we moeten implementeren om de concrete problemen en uitdagingen aan te pakken. Nu kunnen we beoordelen welke technologie geschikt is en welke misschien niet. Dat onderscheid is belangrijk, want ik heb projecten gezien waar de technologie al vaststond voordat iemand de eisen goed begreep.
“We willen Kubernetes.”
“We willen microservices.”
“We willen alles in Azure.”
Prima, maar waarom?
Technologie moet volgen uit de eisen en de architectuur, niet andersom. Als we bijvoorbeeld kiezen voor Event Sourcing met CQRS, zouden we Azure Cosmos DB als event store kunnen gebruiken, Azure Functions voor eventverwerking en Azure SQL voor leesprojecties.
Dat is natuurlijk maar één mogelijke implementatie. We moeten ook kijken naar de kosten, bestaande infrastructuur, beschikbare kennis binnen de organisatie, afhankelijkheid van leveranciers en onderhoud op de lange termijn. Een technisch prachtig systeem heeft weinig waarde als niemand binnen de organisatie het daarna kan onderhouden.
Aan het einde van deze stap moeten we een haalbare technologiekeuze hebben die ons ontwerp ondersteunt.
5. Ontwerp de waarborgen#
Bekijk deze stap in de illustratie ↗
Nu weten we wat we willen bouwen en welke technologieën we daarvoor willen gebruiken.
Maar voordat we alles gaan implementeren, moeten we zorgen dat het systeem veilig en betrouwbaar wordt en aan de toepasselijke eisen voldoet. Weet je nog welke wettelijke verplichtingen en compliance-eisen we in de eerste stap hebben vastgesteld? Die moeten we nu vertalen naar concrete technische maatregelen, rekening houdend met wat we in de eerdere ontwerpstappen al hebben bepaald.
Eisen uit de AVG kunnen bijvoorbeeld invloed hebben op hoe we persoonsgegevens opslaan, wie er toegang toe heeft, hoelang we ze bewaren en hoe we ze kunnen verwijderen. Eisen die voortvloeien uit NIS2 kunnen, waar van toepassing, invloed hebben op beveiligingsmaatregelen, incidentafhandeling en beheerprocedures. Voor AI-systemen kan de EU AI Act aanvullende eisen stellen, afhankelijk van de classificatie en het beoogde gebruik van het systeem.
Hier bepalen we ook zaken als authenticatie, autorisatie, logging, monitoring, versleuteling, back-ups en herstel. En verwar het schrijven van een beveiligingsbeleid alsjeblieft niet met het daadwerkelijk implementeren van beveiliging. Een document waarin staat dat de toegang beperkt is, beperkt die toegang niet. De maatregelen moeten in het systeem aanwezig zijn en idealiter kunnen we aantonen dat ze werken. Hoe afzonderlijke regelingen doorwerken in architectuurbeslissingen, lees je uitgebreider onder Compliance & Governance.
6. Stem de architectuur af#
Bekijk deze stap in de illustratie ↗
Nu hebben we de bedrijfscontext, de eisen, de ontwerppatronen, de technologiekeuze en de technische waarborgen.
Tijd om alles bij elkaar te brengen. En met alles bedoel ik alles wat relevant is voor het ontwerp.
Maak een goed architectuurontwerpdocument (ADD) en bespreek het met de betrokken stakeholders. Dat betekent niet dat je een Word-document van 200 pagina’s moet schrijven dat niemand ooit leest. Houd het beknopt, maar neem wel alles op wat nodig is.
Gebruik architectuurdiagrammen, gegevensstroomdiagrammen, interfacedefinities en Architecture Decision Records (ADR’s) waar ze waarde toevoegen. Zelf geef ik de voorkeur aan visuele weergaven, omdat die het veel makkelijker maken om complexe systemen met mensen met verschillende achtergronden te bespreken. Laat je architectuur ook kritisch beoordelen of bespreek die met vrienden of andere architecten. Misschien heb je iets gemist. Gebruik AI om je redenering te controleren en uit te dagen, maar verifieer de conclusies. Je hebt nog tijd om zaken te corrigeren, en daar hoef je je niet voor te schamen.
Wat gebeurt er als een dienst niet beschikbaar is? Wat als de database uitvalt? Hoe herstellen we het systeem? Wat gebeurt er als de hoeveelheid gegevens vertienvoudigt? En wie gaat dit eigenlijk allemaal onderhouden?
Die vragen lijken misschien vanzelfsprekend, maar worden vaak over het hoofd gezien. Het doel is overeenstemming over een ontwerp dat realistisch en onderhoudbaar is en aansluit op de eisen.
7. Begeleid de realisatie#
Bekijk deze stap in de illustratie ↗
Nu kunnen we eindelijk het systeem gaan bouwen.
Maar hier houdt het werk van de architect niet op. Een goede architectuur op papier heeft weinig waarde als de daadwerkelijke implementatie er heel anders uitziet.
Blijf betrokken tijdens de implementatie, werk samen met de ontwikkelteams en beoordeel belangrijke technische beslissingen.
Zorg dat de afgesproken patronen en beveiligingsmaatregelen ook echt worden geïmplementeerd. Ik zou niet aanraden om het implementatieteam voortdurend over de schouder te kijken, maar als architect moet je wel controleren of wat er wordt gebouwd overeenkomt met het afgesproken plan.
Gebruik waar passend geautomatiseerde tests, CI/CD-pipelines, codereviews en infrastructure as code.
Maak van architectuur tegelijkertijd geen bureaucratische nachtmerrie waarin ontwikkelaars voor iedere kleine wijziging toestemming nodig hebben.
Ontwikkelaars moeten voldoende vrijheid hebben om binnen de afgesproken architectuurkaders technische beslissingen te nemen. En als iets niet werkt zoals verwacht, pas het dan aan! Een ADD kan en moet een levend document zijn, binnen redelijke grenzen.
Er is geen reden om een architectuurkeuze te verdedigen alleen omdat die zes maanden geleden is gemaakt.
8. Beheer, leer en verbeter#
Bekijk deze stap in de illustratie ↗
Het systeem draait nu in productie.
Mooi, maar we zijn nog niet klaar.
Dit is juist het moment waarop we ontdekken of veel van onze aannames daadwerkelijk klopten.
Misschien is het systeem langzamer dan verwacht. Misschien zijn de beheerkosten hoger. Misschien gebruiken mensen de applicatie op een heel andere manier dan we oorspronkelijk hadden voorzien.
Daarom zijn monitoring, logging en feedback uit het beheer zo belangrijk. Vergelijk het daadwerkelijke gedrag van het systeem met de eisen die we eerder hebben opgesteld. Werkt iets niet, onderzoek dan waarom. Blijf je aannames kritisch toetsen.
Misschien moeten we een database optimaliseren, een integratie aanpassen, een bedrijfsproces verbeteren of zelfs een architectuurkeuze heroverwegen. Bovendien blijven eisen niet hetzelfde. Organisaties veranderen, wetgeving verandert en technologie verandert.
De architectuur moet zich kunnen aanpassen.
Houd de kringloop open#
Nog één laatste punt: deze acht stappen zijn niet bedoeld als een strikt watervalproces. Ik weet dat die term tegenwoordig niet populair is, maar probeer agile te werken.
Je rondt stap één niet af om er daarna nooit meer naar om te kijken en blind door te gaan tot stap acht.
In de praktijk ga je heen en weer. Pak een whiteboard of een iPad en begin een architectuur uit te tekenen met pen en “papier”. Dat helpt enorm.
Tijdens de implementatie kun je ontdekken dat een eis niet klopte. Tijdens het testen kan blijken dat een ontwerppatroon niet geschikt is. Tijdens het beheer kun je ontdekken dat het bedrijfsproces zelf moet veranderen.
Dat is heel normaal. En eerlijk gezegd: als niemand tijdens een project ooit een aanname ter discussie stelt of een architectuurkeuze bevraagt, zou ik me gaan afvragen of we wel kritisch genoeg kijken naar wat we bouwen.
Het belangrijkste is om de kringloop open te houden en aannames vroeg te toetsen.
Koppel wat je tijdens ontwikkeling en beheer leert terug naar de eisen en de architectuur. Uiteindelijk is het plannen en structureren van een IT-project in principe niet bijzonder ingewikkeld.
Begrijp de organisatie, bepaal de eisen, gebruik bewezen ontwerppatronen, selecteer geschikte technologieën, implementeer de nodige maatregelen en zorg dat het systeem daadwerkelijk werkt.
De uitdaging is om dat consequent te blijven doen terwijl je te maken hebt met budgetten, deadlines, verschillende stakeholders en veranderende eisen.
En daar begint het echte werk. :-)