Maak Low-Level Design
Define the solution building blocks
Tijdens deze activiteit wordt het High-Level Design uitgewerkt tot een technisch ontwerp dat als basis dient voor de realisatie van de solution. Alleen de onderdelen waarvoor verdere detaillering noodzakelijk is, worden uitgewerkt, waarbij de interne structuur, componenten, interfaces, gegevensverwerking en technische voorzieningen worden beschreven. Het resultaat is een samenhangend en realiseerbaar Low-Level Design dat de implementatie richting geeft en aansluit op de architectuurbepalende eisen, architectuurbeslissingen en enterprise-architectuurkaders.
Beschrijving
Tijdens deze activiteit wordt het High-Level Design verder uitgewerkt tot een gedetailleerd en realiseerbaar ontwerp. Het doel is om voor de onderdelen van de solution die nadere technische uitwerking vereisen, vast te leggen hoe zij intern zijn opgebouwd, hoe zij samenwerken en op welke wijze zij worden gerealiseerd. Het Low-Level Design vormt daarmee de directe basis voor implementatie, configuratie, bouw, integratie en technische toetsing.
De uitwerking richt zich niet automatisch op ieder onderdeel van de solution. Alleen bouwstenen waarvoor een architectuurbepalende eis, een aanzienlijk technisch risico, een complexe integratie of een belangrijke ontwerpbeslissing bestaat, worden verder verdiept. Voor overige onderdelen volstaat het detailniveau van het High-Level Design, of de standaarddocumentatie van het gekozen product of platform. Zo blijft het ontwerp beperkt tot de onderdelen waarvoor detaillering daadwerkelijk nodig is.
Per geselecteerd onderdeel wordt beschreven hoe de interne structuur eruitziet, welke componenten of modules worden onderscheiden, welke verantwoordelijkheden zij hebben en hoe zij onderling communiceren. Ook worden relevante API-contracten, berichtformaten, gegevensstructuren, opslagvormen, foutafhandeling, beveiligingsmaatregelen en technische configuraties uitgewerkt. Waar nodig wordt vastgelegd hoe niet-functionele eisen — zoals beschikbaarheid, performance, schaalbaarheid, privacy, logging en beheerbaarheid — in het ontwerp worden gerealiseerd.
Het Low-Level Design maakt tevens inzichtelijk hoe gegevens binnen een onderdeel worden opgeslagen, verwerkt en uitgewisseld. Daarbij kan het logische datamodel worden vertaald naar concretere gegevensstructuren, zoals tabellen, berichten, topics, API-resources of configuraties. Fysieke implementatiedetails worden alleen opgenomen wanneer ze noodzakelijk zijn om een architectuurbeslissing eenduidig te realiseren of te toetsen. Gedetailleerde code, volledige databaseschema's en andere implementatieartefacten worden doorgaans beheerd in het Architectuurmodel, de technische documentatie of de broncode zelf; het Low-Level Design verwijst hiernaar zonder deze informatie onnodig te dupliceren.
De uitwerking vindt plaats in nauwe samenwerking tussen de solution architect, ontwikkelaars, engineers, leveranciers, beheerders en security- en dataspecialisten. Het ontwikkelteam brengt de technische kennis en realiseerbaarheid in, terwijl de solution architect bewaakt dat het ontwerp aansluit op het High-Level Design, de architectuurbepalende eisen, de vastgestelde architectuurbeslissingen en de geldende enterprise-architectuurkaders. Afwijkingen worden expliciet gemaakt, onderbouwd en waar nodig als nieuwe architectuurbeslissing vastgelegd.
Het resultaat van deze activiteit is een samenhangend en uitvoerbaar Low-Level Design waarin de technisch relevante onderdelen voldoende gedetailleerd zijn beschreven om te worden gerealiseerd en getest. Het ontwerp is gereed wanneer de verantwoordelijkheden, interne structuur, gegevensverwerking, interfaces en technische randvoorwaarden eenduidig zijn vastgelegd, de belangrijkste risico's zijn geadresseerd, en het ontwikkelteam kan aantonen dat de oplossing op basis van dit ontwerp realiseerbaar is.
Aanpak
Gebruik het High-Level Design als uitgangspunt
Het Low-Level Design bouwt voort op het High-Level Design. De architectuur van de solution, zoals vastgelegd in de containerindeling, vormt het uitgangspunt voor de verdere uitwerking. Tijdens deze activiteit worden de containers niet opnieuw ontworpen, maar intern verder uitgewerkt. Blijkt dat de gekozen containerstructuur onvoldoende aansluit bij de gewenste oplossing, dan wordt eerst het High-Level Design aangepast voordat de detaillering wordt voortgezet.
Werk de interne structuur van de containers uit
Werk per container uit hoe deze intern is opgebouwd. Beschrijf welke componenten worden onderscheiden, welke verantwoordelijkheden zij hebben en hoe zij met elkaar en met andere containers communiceren. Leg de belangrijkste interfaces, gegevensuitwisselingen en technische afhankelijkheden vast. Bij gebruik van standaardsoftware of andere bestaande bouwstenen wordt beschreven hoe deze binnen de solution worden gepositioneerd en hoe zij invulling geven aan de architectuurbepalende eisen. Het detailniveau is voldoende om ontwikkelaars, beheerders en leveranciers de oplossing te laten realiseren en configureren, zonder de implementatie onnodig voor te schrijven.
Detailleer alleen waar dat noodzakelijk is
Niet ieder onderdeel hoeft tot implementatieniveau te worden uitgewerkt. Verdere detaillering vindt uitsluitend plaats als dit noodzakelijk is om een architectuurbepalende eis te realiseren of te toetsen — bijvoorbeeld voor beveiligingsmechanismen, verplichte ontwerpprincipes of interfacecontracten. Voor de meeste componenten, en zeker voor standaardsoftware, blijft de implementatie de verantwoordelijkheid van het ontwikkelteam of de leverancier. Leg expliciet vast welke onderdelen verder zijn uitgewerkt en waarom dat noodzakelijk is.
Werk de technische infrastructuur uit indien relevant
Als de oplossing dit vereist, wordt naast de logische architectuur ook de technische infrastructuur beschreven. Hierbij wordt vastgelegd hoe de verschillende containers worden uitgerold over infrastructuurvoorzieningen, zoals servers, cloudomgevingen, containerplatformen of netwerkzones. Verschilt de topologie per omgeving — bijvoorbeeld tussen ontwikkel-, test- en productieomgevingen — dan wordt dit afzonderlijk beschreven. Een deploymentmodel wordt alleen opgenomen wanneer de infrastructuur van invloed is op de architectuur, bijvoorbeeld vanwege eisen aan beschikbaarheid, schaalbaarheid, beveiliging of netwerksegmentatie. Gedetailleerde configuraties van infrastructuurvoorzieningen horen niet bij het architectuurontwerp, maar bij de implementatie.
Bovenstaand voorbeeld toont een C4-deploymentdiagram voor een aanvraagplatform. Het diagram laat zien hoe de containers (webapplicatie, API en database) worden uitgerold over de productie-infrastructuur, inclusief netwerkzones, load balancing en de gebruikte Azure-voorzieningen.
Leg architectuurbeslissingen vast
Zodra tijdens de uitwerking wordt afgeweken van de geldende architectuurstandaarden of enterprise-richtlijnen, wordt deze keuze expliciet vastgelegd als architectuurbeslissing. Daarbij worden de overwogen alternatieven, de motivatie voor de gekozen oplossing en de gevolgen van de afwijking beschreven. Zo blijft inzichtelijk waarom van de standaard is afgeweken, en kan de afwijking worden beoordeeld binnen de architectuurgovernance.
Controleer het detailniveau
Sluit de activiteit af door te beoordelen of het Low-Level Design het juiste detailniveau heeft bereikt. Het ontwerp moet voldoende informatie bevatten om de oplossing te kunnen realiseren, configureren en toetsen, zonder onnodige implementatiedetails of broncode voor te schrijven. Daarmee blijft een duidelijke scheiding bestaan tussen architectuur en implementatie, en behoudt het Low-Level Design zijn rol als technisch ontwerp dat de realisatie van de solution richting geeft.
Acties
- Aanmaken Architectuurbeslissingen (ADRs) Werkproduct
- Bijwerken Architectuurmodel Werkproduct
- Lezen Paved Road Werkproduct
Werkproducten
Architectuurbeslissingen (ADRs)
Bewaar de rationale achter een significante keuze zodat die later gevalideerd, herzien of vervangen kan worden.
Architectuurmodel
Maak de minimale set bouwstenen, relaties en grenzen zichtbaar waarop stakeholders nu moeten handelen.
Voltooiingscriteria
- System Architecture Selected
Rol
Rol die deze activiteit uitvoert.
Architectuureigenaar
De meest technisch ervaren persoon in het team (conform Disciplined Agile Delivery). Voert het solution-spoor uit binnen de door de Enterprise Archite…