Architectuurmodel
Architecture Model
Maak de minimale set bouwstenen, relaties en grenzen zichtbaar waarop stakeholders nu moeten handelen.
Beschrijving
Het Architectuurmodel is de formele beschrijving van de solution en vormt het centrale stuurmiddel voor ontwerp, realisatie en toetsing. Het legt vast uit welke bouwstenen de oplossing bestaat, welke verantwoordelijkheden en grenzen deze bouwstenen hebben en hoe zij onderling samenwerken. Daarmee maakt het model inzichtelijk welke structurele keuzes voor de oplossing zijn gemaakt en biedt het de basis om deze keuzes gedurende het project te beoordelen en te bewaken.
Het model beschrijft zowel de relevante delen van de huidige situatie als de gewenste situatie. De bestaande architectuur wordt echter uitsluitend opgenomen voor zover dit noodzakelijk is om de verandering te begrijpen en te kunnen beoordelen. De daadwerkelijke scope van het project wordt immers bepaald door het verschil tussen de huidige en de gewenste situatie. Onderdelen die ongewijzigd blijven, worden daarom niet opnieuw uitgewerkt. Hierdoor blijft het Architectuurmodel beperkt tot datgene wat nodig is om de voorgenomen verandering te onderbouwen en besluitvorming mogelijk te maken.
De uitwerking van het Architectuurmodel groeit gedurende het project mee met de voortgang van de architectuur. In de vroege fasen bevat het model uitsluitend de informatie die nodig is om richtinggevende keuzes te maken. Naarmate meer ontwerpbeslissingen worden genomen, wordt het model verder uitgewerkt tot het detailniveau dat nodig is om de oplossing te realiseren en te toetsen. Ook per architectuurweergave geldt dat alleen de verschillen tussen de huidige en de gewenste situatie worden gemodelleerd wanneer deze onderdeel zijn van de te nemen beslissing.
Het Architectuurmodel geeft antwoord op vragen als:
- Welke structurele keuzes vormen de oplossing?
- Hoe hangen de bouwstenen in de huidige en de gewenste situatie samen?
- Wat verandert er?
- Tot welk detailniveau moeten deze keuzes op dit moment worden vastgelegd om ontwerp, realisatie en toetsing mogelijk te maken?
De onderbouwing van de gemaakte architectuurbeslissingen maakt geen onderdeel uit van het Architectuurmodel zelf. Deze wordt vastgelegd in afzonderlijke Architectuurbeslissingen (ADR's), zodat het model zich uitsluitend richt op de architectuur en de structuur van de oplossing, terwijl de motivatie en afwegingen achter de keuzes afzonderlijk worden beheerd.
Het Architectuurmodel is bedoeld voor alle betrokkenen die verantwoordelijk zijn voor of betrokken zijn bij de architectuur van de oplossing, waaronder de architectuureigenaar, het deliveryteam, de Enterprise Architect, leveranciers en reviewers. Hierdoor vormt het gedurende de gehele levenscyclus van het project het gemeenschappelijke referentiekader voor ontwerp, implementatie en conformance-toetsing.
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'. Het model 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 het Architectuurmodel. 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 het Architectuurmodel op detailniveau Code, maar worden alleen opgenomen wanneer de erin vastgelegde keuze daadwerkelijk architectuurbepalend is; voor gewone implementatiedetails volstaat de broncode zelf. Hierdoor blijft het Architectuurmodel gericht op de structurele opbouw van de solution en wordt onnodige duplicatie van ontwerp- en implementatie-informatie voorkomen.
✓