Architectuurbeschrijving
De architectuurbeschrijving is de formele beschrijving van de solution: de bouwstenen waaruit ze bestaat, hun verantwoordelijkheden en grenzen, en hoe ze onderling samenwerken.
Beschrijving
De architectuurbeschrijving is de formele beschrijving van de solution en het centrale stuurmiddel voor ontwerp, realisatie en toetsing. Ze legt vast uit welke bouwstenen de oplossing bestaat, welke verantwoordelijkheden en grenzen deze bouwstenen hebben en hoe ze onderling samenwerken, zodat structurele keuzes zichtbaar worden en gedurende het project kunnen worden beoordeeld en bewaakt.
De architectuurbeschrijving beschrijft zowel de relevante delen van de huidige als de gewenste situatie, maar uitsluitend voor zover nodig om de verandering te begrijpen: onderdelen die ongewijzigd blijven, worden niet opnieuw uitgewerkt. De uitwerking groeit mee met de voortgang van het project — vroege fasen bevatten alleen wat nodig is voor richtinggevende keuzes, latere fasen worden verder gedetailleerd tot het niveau dat nodig is om te realiseren en te toetsen. De onderbouwing van de gemaakte keuzes maakt geen deel uit van de architectuurbeschrijving zelf, maar wordt apart vastgelegd in architectuurbeslissingen.
De architectuurbeschrijving wordt uitgewerkt volgens het C4-model: van contextniveau (de grenzen van de solution en haar omgeving) via containerniveau (de bouwstenen en hun onderlinge gegevensuitwisseling — voor de meeste solutions het niveau waarop governance haar oordeel vormt) tot component- en codeniveau, die alleen worden uitgewerkt waar een architectuurbepalende eis, een risico of een ontwerpbeslissing dat vereist. De architectuurbeschrijving is bedoeld voor iedereen die verantwoordelijk is voor of betrokken is bij de architectuur: de architectuureigenaar, het deliveryteam, de Enterprise architect, leveranciers en reviewers. De componenten van de architectuurbeschrijving worden opgenomen in de architectuurrepository, zodat de structurele opbouw van de solution op dezelfde autoritatieve plek terug te vinden is als de overige architectuurartefacten.
Voorbeeld van een applicatielandschap
Onderstaand voorbeeld toont een applicatielandschap voor het proces Cliëntenregistratie. Het diagram brengt de belangrijkste gebruikers, applicaties, externe systemen en hun onderlinge interacties in beeld. Zo wordt duidelijk welke applicaties onderdeel zijn van de solution, hoe gegevens worden uitgewisseld en waar de systeemgrenzen (en verantwoordelijkheden) liggen. Het diagram is opgesteld volgens het C4-model en ondersteunt het maken, communiceren en toetsen van architectuurbeslissingen.
Detailniveaus
-
1. Context
Op dit detailniveau blijft de interne opbouw van de solution een black box. De interne gegevensstructuur wordt nog niet beschreven; uitsluitend de gegevensuitwisselingen over de systeemgrenzen heen worden vastgelegd, bijvoorbeeld 'levert FHIR-resources (primair gebruik)' of 'verstuurt meetgegevens'. Deze weergave laat daarmee zien welke gegevens worden uitgewisseld, met welke partijen en via welke systeemgrenzen, zonder in te gaan op de interne opslag of verwerking van gegevens.
Dit detailniveau is van belang zodra de architectuur moet aantonen dat de grenzen van de solution duidelijk zijn afgebakend en dat de belangrijkste buy-, build- en reuse-keuzes op hoofdlijnen zijn gemaakt. Het betreft een van de eerste architectuurweergaven die met de opdrachtgever en de eigenaren van omliggende systemen wordt besproken. Omdat deze weergave de scope van de oplossing vastlegt, verandert zij gedurende het project doorgaans weinig. Een wijziging op contextniveau duidt meestal op een wijziging van de projectscope en niet op een verdere uitwerking van de architectuur.
Onderstaand voorbeeld toont een contextdiagram op dit detailniveau. Het diagram laat zien welke personen, software- en externe systemen onderdeel uitmaken van de solution en welke gegevens over de systeemgrenzen worden uitgewisseld. De interne opbouw van de afzonderlijke systemen blijft daarbij buiten beschouwing; de nadruk ligt volledig op de context van de oplossing en haar interacties met de omgeving.
✓
-
2. Container Voldoende
Op dit detailniveau wordt voor het eerst concreet vastgelegd welke bouwsteen verantwoordelijk is voor welke gegevens en op welke wijze gegevens tussen de bouwstenen worden uitgewisseld. Daarbij wordt niet alleen bepaald waar gegevens worden beheerd, maar ook in welke vorm zij worden uitgewisseld, bijvoorbeeld als een real-time gebeurtenis, batchbestand, query of FHIR-resource. In het voorbeeld van het Health Data Platform is dit het niveau waarop de Clinical Data Repository wordt onderscheiden als de persistente bron voor klinische gegevens en de OMOP Datastore als afgeleide onderzoeksdataset. Ook wordt op dit niveau de scheiding tussen primair en secundair gegevensgebruik expliciet gemaakt.
Dit is het detailniveau waarop de meeste architectuurbeslissingen daadwerkelijk kunnen worden beoordeeld. De verantwoordelijkheden van de verschillende bouwstenen zijn duidelijk afgebakend, de belangrijkste interfaces en gegevensstromen zijn vastgelegd en architectuurprincipes, zoals de scheiding tussen primair en secundair gebruik, kunnen worden getoetst. Voor de meeste solution-architecturen is dit daarom het niveau waarop architectuurgovernance haar oordeel kan vormen en goedkeuring kan geven. Verdere detaillering is doorgaans alleen nodig voor onderdelen waarvan de interne werking of implementatie onderwerp van ontwerp of besluitvorming is.
Onderstaand voorbeeld toont een containerdiagram op dit detailniveau. Het diagram laat zien hoe de solution is opgebouwd uit afzonderlijke applicaties, services, databases en andere technische bouwstenen, welke verantwoordelijkheden zij hebben en hoe gegevens tussen deze bouwstenen worden uitgewisseld. Hiermee vormt het containerdiagram voor de meeste projecten de belangrijkste architectuurweergave voor ontwerp, implementatie en conformance-toetsing.
✓
-
3. Component
Dit detailniveau wordt alleen uitgewerkt voor containers waarvoor een architectuurbepalende eis, een aanzienlijk technisch risico of een belangrijke ontwerpbeslissing bestaat. Het is daarom geen standaardonderdeel voor iedere container binnen de solution, maar wordt alleen toegepast wanneer verdere detaillering noodzakelijk is om ontwerpkeuzes te kunnen onderbouwen, implementeren of toetsen.
Op dit niveau wordt de interne structuur van de container zichtbaar. De architectuur beschrijft hoe de container intern is opgebouwd, welke componenten daarin samenwerken en hoe gegevens binnen de container worden opgeslagen, verwerkt en uitgewisseld. Daarbij kunnen onder andere interne componenten, gegevensstructuren, berichtkanalen, API-contracten en andere technische bouwstenen worden gemodelleerd, voor zover deze architectuurbepalend zijn.
De uitwerking van dit detailniveau vindt plaats wanneer dit voor een specifieke container noodzakelijk is. Dit gebeurt doorgaans later in het project, zodra de realisatie van de container wordt voorbereid of wanneer technische risico's of kwaliteitseisen daarom vragen. De detaillering wordt veelal in samenwerking met het ontwikkelteam opgesteld, waarbij de architectuureigenaar verantwoordelijk blijft voor het bewaken van de architectuurkaders en de samenhang met de rest van de solution.
✓
-
4. Code
Dit detailniveau maakt slechts in uitzonderlijke gevallen onderdeel uit van de Architectuurbeschrijving. Het wordt alleen toegepast wanneer een architectuurbeslissing uitsluitend op code- of implementatieniveau eenduidig kan worden vastgelegd, bijvoorbeeld bij een verplicht gegevensschema, een beveiligingspatroon of een technisch protocol dat bepalend is voor de architectuur.
Op dit niveau betreft het de fysieke implementatie, zoals databaseschema's, tabeldefinities, berichtformaten of andere implementatieartefacten. Dit wordt doorgaans vastgelegd in UML-diagrammen op klassen- of objectniveau, zoals sequence- of class-diagrammen, die het gedrag of de structuur van de implementatie in detail tonen. Deze diagrammen maken formeel onderdeel uit van de Architectuurbeschrijving op detailniveau Code, maar worden alleen opgenomen wanneer de erin vastgelegde keuze daadwerkelijk architectuurbepalend is; voor gewone implementatiedetails volstaat de broncode zelf. Hierdoor blijft de Architectuurbeschrijving gericht op de structurele opbouw van de solution en wordt onnodige duplicatie van ontwerp- en implementatie-informatie voorkomen.
✓