diff --git a/NL/asciidoc/arc42-template.adoc b/NL/asciidoc/arc42-template.adoc
new file mode 100644
index 0000000..ef1bbe8
--- /dev/null
+++ b/NL/asciidoc/arc42-template.adoc
@@ -0,0 +1,96 @@
+// header file for arc42-template,
+// including all help texts
+//
+// ====================================
+
+= image:arc42-logo.png[arc42] Template
+// toc-title definition MUST follow document title without blank line!
+:toc-title: Inhoudsopgave
+
+//additional style for arc42 help callouts
+ifdef::backend-html5[]
+++++
+<style>
+.arc42help {font-size:small; width: 14px; height: 16px; overflow: hidden; position: absolute; right: 0; padding: 2px 0 3px 2px;}
+.arc42help::before {content: "?";}
+.arc42help:hover {width:auto; height: auto; z-index: 100; padding: 10px;}
+.arc42help:hover::before {content: "";}
+@media print {
+	.arc42help {display:none;}
+}
+</style>
+++++
+endif::backend-html5[]
+
+// configure EN settings for asciidoc
+include::src/config.adoc[]
+
+
+include::src/about-arc42.adoc[]
+
+// horizontal line
+***
+
+[role="arc42help"]
+****
+[NOTE]
+====
+Deze versie van de template bevat hulp en uitleg.
+Het is bedoel om bekend te raken met arc42 en om de concepten te begrijpen.
+Om uw eigen sytemen te documenteren adviseren we om de _kale_ versie te gebruiken.
+====
+****
+
+
+// numbering from here on
+:numbered:
+
+<<<<
+// 1. Introduction and Goals
+include::src/01_introduction_and_goals.adoc[]
+
+<<<<
+// 2. Architecture Constraints
+include::src/02_architecture_constraints.adoc[]
+
+<<<<
+// 3. System Scope and Context
+include::src/03_system_scope_and_context.adoc[]
+
+<<<<
+// 4. Solution Strategy
+include::src/04_solution_strategy.adoc[]
+
+<<<<
+// 5. Building Block View
+include::src/05_building_block_view.adoc[]
+
+<<<<
+// 6. Runtime View
+include::src/06_runtime_view.adoc[]
+
+<<<<
+// 7. Deployment View
+include::src/07_deployment_view.adoc[]
+
+<<<<
+// 8. Concepts
+include::src/08_concepts.adoc[]
+
+<<<<
+// 9. Architecture Decisions
+include::src/09_architecture_decisions.adoc[]
+
+<<<<
+// 10. Quality Requirements
+include::src/10_quality_requirements.adoc[]
+
+<<<<
+// 11. Technical Risks
+include::src/11_technical_risks.adoc[]
+
+<<<<
+// 12. Glossary
+include::src/12_glossary.adoc[]
+
+
diff --git a/NL/asciidoc/src/01_introduction_and_goals.adoc b/NL/asciidoc/src/01_introduction_and_goals.adoc
new file mode 100644
index 0000000..329f5f1
--- /dev/null
+++ b/NL/asciidoc/src/01_introduction_and_goals.adoc
@@ -0,0 +1,91 @@
+[[section-introduction-and-goals]]
+== Introductie en Doelen
+
+[role="arc42help"]
+****
+Beschrijft de relevante requirements en het krachtenveld waar software architecten en het development team rekening mee moeten houden.
+Die bestaan onder ander uit
+
+* het begrijpen van de achterliggende doelen van de business, 
+* essentiele features,
+* essentiele functionele requirements, 
+* kwaliteits doelen voor de architectuur en
+* relevante belanghebbenden en hun verwachtingen
+****
+
+=== Requirements Overzicht
+
+[role="arc42help"]
+****
+.Inhoud
+Korte beschrijven van de functionele requirements, drijvende krachten, uittreksel (of samenvatting) van de requirements.
+Verwijzing naar de (hopelijk bestaande) requirements documentatie (met versie nummer en informatie waar deze te vinden is).
+
+
+.Motivatie
+Vanuit het perspectief van de eind gebruikers is een systeem ontwikkeld of aangepast om een business activiteit beter te ondersteunen en/of om de kwaliteit van die activiteit te verbeteren.
+
+.Vorm
+Korte textuele beschrijving, mogelijk in use-case tabel formaat.
+Dit overzichts document moet naar het requirements document verwijzen (als dat bestaat).
+
+Houd deze uittreksels zo kort mogelijk. 
+Zoek een evenwicht tussen leesbaarheid van dit document en mogelijke dubbelingen met betrekking tot het requirements document.
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-1/[Introductie en Doelen] in de arc42 documentatie.
+
+****
+
+=== Kwaliteits Doelen
+
+[role="arc42help"]
+****
+.Inhoud
+De top drie (max vijf) kwaliteits doelen aan de architectuur waarvan het behalen van het grootste belang is voor de primaire belanghebbenden.
+
+We bedoelen hier echt kwaliteits doelen voor de architectuur.
+Niet te verwarren met project doelen.
+
+Overweeg dit overzicht met mogelijke onderwerpen (gebaseerd op de ISO 25010 standaard):
+
+image::01_2_iso-25010-topics-EN.png["Categorieen van mogelijke Kwaliteits Requirements"]
+
+.Motivatie
+Het is belangrijk de kwaliteits doelen van je belangrijkste belanghebbenden te kennen omdat deze invloed hebben op fundamentele architectuur keuzes.
+Denk eraan heel concreet te zijn over deze kwaliteiten, vermijd modewoorden.
+Alsof je als architect niet weet hoe de kwaliteit van je werk beoordeeld zal worden...
+
+.Vorm
+Een tabel met kwaliteits doelen en concrete scenarios, gesorteerd op prioriteit.
+****
+
+=== Belanghebbenden
+
+[role="arc42help"]
+****
+.Inhoud
+Expliciet overzicht van belanghebbenden van het systeem, dat wil zeggen alle personen, rollen of oranisaties die
+
+* de architectuur moeten kennen
+* van de architectuur overtuigd moeten worden
+* met de architectuur of code moeten werken
+* de documentatie van de architectuur nodig hebben voor hun werk
+* beslissingen moeten maken over het systeem of de ontwikkeling daarvan
+
+.Motivatie
+Alle partijen die betrokken zijn bij de ontwikkeling of anderzinds geraakt worden door het systeem moeten bekend zijn.
+Anders kan dat later in het ontwikkelings proces tot nare verassingen zorgen.
+Deze belanghebbenden bepalen in een grote mate de omvang en het detail niveau van de werkzaameheden en de resultaten.
+
+.Vorm
+Tabel met de rollen, personen en hun verwachting met betrekking tot de architectuur en haar documentatie.
+****
+
+[options="header",cols="1,2,2"]
+|===
+|Rol/Naam|Contact persoon|Verwachtingen
+| _<Rol-1>_ | _<Contact-1>_ | _<Verwachting-1>_
+| _<Rol-2>_ | _<Contact-2>_ | _<Verwachting-2>_
+|===
diff --git a/NL/asciidoc/src/02_architecture_constraints.adoc b/NL/asciidoc/src/02_architecture_constraints.adoc
new file mode 100644
index 0000000..8732cc3
--- /dev/null
+++ b/NL/asciidoc/src/02_architecture_constraints.adoc
@@ -0,0 +1,23 @@
+[[section-architecture-constraints]]
+== Architectuur Beperkingen
+
+
+[role="arc42help"]
+****
+.Inhoud
+Iedere requirement die de sofware architecten in hun vrijheid met betrekking tot ontwerp, implementatie of het ontwikkel proces beperken.  
+Het kan zijn dat deze beperkingen verder gaan dan de individuele systemen en van toepassing zijn op hele organisaties of bedrijven.
+
+.Motivatie
+Architecten moeten weten waar ze vrij zijn in de ontwerp keuzes en waar ze zich aan beperkingen moeten houden.
+Beperkingen moeten altijd onder ogen worden gezien; echter, het kan zijn dat er over te onderhandelen valt.
+
+.Vorm
+Simpele tabellen met beperkingen en bijbehorende uitleg.
+Zo nodig opgedeeld in technische, organisatorische en politieke beperkingen en conventies (bijv. programmeer of versionering guidelines, documentatie of naamgevings conventies).
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-2/[Architectuur Beperkingen] in de arc42 documentatie.
+
+****
diff --git a/NL/asciidoc/src/03_system_scope_and_context.adoc b/NL/asciidoc/src/03_system_scope_and_context.adoc
new file mode 100644
index 0000000..b2e8598
--- /dev/null
+++ b/NL/asciidoc/src/03_system_scope_and_context.adoc
@@ -0,0 +1,76 @@
+[[section-system-scope-and-context]]
+== Systeem Scope en Context
+
+
+[role="arc42help"]
+****
+.Inhoud
+De systeem scope en context maakt - zoals de naam suggereert - een onderscheid tussen het eigen systeem (d.w.z. de scope van het systeem dat wordt beschreven) en alle partners waarmee wordt gecommuniceerd (buur systemen en gebruikers, met andere woorden, de context van het systeem).
+Hiermee worden externe interfaces gedefineerd.
+
+Maak, als het nodig is, onderscheid tussen business context (domein specifieke inputs en outputs) en technische context (kanalen, protocollen, hardware).
+
+.Motivatie
+De domein en technische interfaces met communicatie partners horen bij meest kritieke aspecten van het systeem.
+Wees er zeker van dat deze volledig te doorgronden.
+
+.Vorm
+Verschillend opties:
+
+* Context diagrammen
+* Lijst van communicatie partners en bijbehorende interfaces.
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-3/[Context en Scope] in de arc42 documentatie.
+
+****
+
+
+=== Business Context
+
+[role="arc42help"]
+****
+.Inhoud
+Specificatie van *alle* communicatie partners (gebruikers, IT-systemen, ...) met uitleg van domein specifieke inputs en outputs of interfaces.
+Het is eventueel mogelijk om domein specifieke formaten of communicatie protocollen toe te voegen.
+
+.Motivatie
+Alle belanghebbenden moeten begrijpen welke data er uitgewisseld wordt met de omgeving van het systeem.
+
+.Vorm
+Alle soorten diagrammen die het systeem als een black box weergeven en die de domein interfaces naar communicatie partners laten zien. 
+
+Een tabel vorm zou als alternatief (of toevoeging) gebruikt kunnen worden.
+De naam van het systeem is de titel van de tabel.
+De drie kolommen bevatten de naam van de communicatie partner, de inputs en de outputs.
+
+****
+
+**<Diagram of Tabel>**
+
+**<optioneel: Uitleg van de externe domein interfaces>**
+
+=== Technische Context
+
+[role="arc42help"]
+****
+.Inhoud
+Technische interfaces (kanalen en mechanismen) die het systeem met haar omgeving verbind.
+Naast een mapping van domein specifieke input/output naar kanalen, dat wil zeggen, een uitleg welke I/O welke kanalen gebruikt.
+
+.Motivatie
+Veel belanghebbenden maken beslisisingen met betrekkeing tot de architectuur gebaseerd op de technische interfaces tussen het systeem en haar context.
+Met name infrastructuur of hardware ontwerpers beslissen aan de hand van deze technische interfaces.
+
+.Vorm
+Bijvoorbeeld UML deployment diagrammen die de kanalen naar naburige systemen beschrijven, gecombineerd met mapping tabellen die de relatie tussen de kanalen en de input/output tonen.
+
+****
+
+**<Diagram of Tabel>**
+
+**<optioneel: Uitleg van technische interfaces>**
+
+**<Mapping Input/Output naar kanalen>**
diff --git a/NL/asciidoc/src/04_solution_strategy.adoc b/NL/asciidoc/src/04_solution_strategy.adoc
new file mode 100644
index 0000000..525ab26
--- /dev/null
+++ b/NL/asciidoc/src/04_solution_strategy.adoc
@@ -0,0 +1,31 @@
+[[section-solution-strategy]]
+== Oplossing Strategie
+
+
+[role="arc42help"]
+****
+.Inhoud
+Een korte samenvatting en uitleg van de fundamentele beslissingen en oplossings strategieen die de systeem architectuur vormen.
+Die bestaan uit onder andere
+
+* beslissingen met betrekking tot technologie
+* beslissingen over de top-level decompositie van het systeem, bijvoorbeeld het gebruik van een architectuur pattern of een design pattern
+* beslissingen over hoe de meest belangrijke kwaliteits doelen behaald zullen worden
+* relevante organisatorische beslissingen, bijvoorbeeld de keuze van een onwikkel proces of het delegeren van bepaalde taken aan derden.
+
+.Motivatie
+Deze beslissingen vormen het fundament van de architectuur.
+Ze vormen de basis waarop vele andere gedetailleerde beslissingen of implemenatie regels worden gebaseerd.
+
+.Vorm
+Hou de uitleg van deze fundamentele beslissingen kort.
+
+Leg de motivatie en reden waarom van de beslissingen zo zijn genomen vast, gebaseerd op een probleem beschrijving, kwaliteitsdoelen en de belangrijkste kaders.
+Verwijs naar details in de volgende secties.
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-4/[Solution Strategy] in de arc42 documentatie.
+
+****
diff --git a/NL/asciidoc/src/05_building_block_view.adoc b/NL/asciidoc/src/05_building_block_view.adoc
new file mode 100644
index 0000000..3e75bed
--- /dev/null
+++ b/NL/asciidoc/src/05_building_block_view.adoc
@@ -0,0 +1,203 @@
+[[section-building-block-view]]
+
+
+== Bouwstenen View
+
+[role="arc42help"]
+****
+.Inhoud
+De bouwstenen view toont de statische decompositie van het systeem in bouwstenen (modules, componenten, subsystemen, classes, interfaces, packages, libraries, frameworks, lagen, partitions, lagen, functies, macros, operaties, data structuren, ...) en hun onderlinge afhankelijkheden (relaties, associaties, ...).
+
+Deze view is verplicht voor iedere architectuur documentatie.
+In termen van een huis is dit het _grond plan_.
+
+.Motivatie
+Hou een overzicht van de source code bij door de structuur begrijpelijk te maken door middel van abstracties.
+
+Dit zorgt ervoor dat het mogelijk is om op een abstract niveau te communiceren met de belanghebbenden zonder daarbij op implementatie details in te hoeven gaan.
+
+.Vorm
+De bouwstenen view is een hiërarchische verzameling van 'black boxes' en 'white boxes' (zie het onderstaande plaatje) met de bijbehorende beschrijvingen.
+
+image::05_building_blocks-EN.png["Hiërarchie van bouwstenen"]
+
+*Niveau 1* is een 'white box' beschijving van het gehele systeem gecombineerd met 'black box' beschrijvingen van alle ingesloten bouwstenen.
+
+*Niveau 2* zoomt in op sommige bouwstenen uit niveau 1.
+Zodoende bevat het de 'white box' beschrijving van specifieke bouwstenen uit niveau 1, gecombineerd met 'black box' beschrijvingen van hun interne bouwstenen.
+
+*Niveau 3* zoomt in op geslecteerde bouwstenen uit niveau 2, en zo verder.
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-5/[Building Block View] in de arc42 documentatie.
+
+****
+
+=== Gehele whitebox Systeem
+
+[role="arc42help"]
+****
+Hier wordt de decompositie van het gehele systeem beschreven aan de hand van het volgende 'white box' template.
+Die bestaat uit
+
+* een overzichts diagram
+* een motivatie voor de decompositie
+* 'black box' beschrijvingen van ingesloten bouwstenen.
+Hiervoor zijn er verschillende alternatieven:
+  ** gebruik _één_ tabel for een korte en pragmatisch overzicht van alle ingesloten bouwstenen en hun interfaces.
+  ** gebruik een lijst met 'black box' beschrijvingen van de bouwstenen aan de hand van het 'black box' template (zie hieronder).
+  Afhankelijk van de gebruikte tool kan deze lijst in de vorm van een sub-hoofdstuk (in tekst bestanden), sub-pagina's (in een Wiki) of geneste elementen (in een modelleer tool) zijn.
+
+* (optioneel:) belangrijke interfaces die niet in de 'black box' templates van de bouwstenen worden uitgelegd maar desondanks van belang zijn om de 'white box' goed te kunnen begrijpen.
+Omdat er zo veel verschillende manieren zijn om interfaces te specificeren wordt er geen specifiek template aangeboden.
+In het ergste geval moeten syntax, semantiek, protocollen, error afhandeling, beperkingen, versies, kwaliteits attributen, benodigde compatibiliteit en vele andere zaken gespecificeerd en beschreven worden.
+In het beste geval zijn voorbeelden of simpele beschrijvingen voldoende.
+
+****
+
+_**<Overzichts Diagram>**_
+
+Motivatie::
+
+_<tekstuele uitleg>_
+
+
+Ingesloten bouwstenen::
+_<Beschrijving van ingesloten bouwstenen ('black boxes')>_
+
+Belangrijke Interfaces::
+_<Beschrijving van belangrijke interfaces>_
+
+[role="arc42help"]
+****
+Voeg hier de uitleg van de 'black boxes' van niveau 1 toe:
+
+In tabel vorm moeten hier enkel de 'black boxes' met hun naam een verantwoordelijkheden worden beschreven:
+
+[cols="1,2" options="header"]
+|===
+| **Naam** | **Verantwoordelijkeid**
+| _<black box 1>_ | _<Tekst>_
+| _<black box 2>_ | _<Tekst>_
+|===
+
+
+In het geval er een lijst met 'black box' beschrijvingen wordt gebruikt, vul dan een aparte 'black box' template in voor iedere belangrijke bouwsteen.
+De kop bij die sectie is dan de naam van de specifieke 'black box'.
+****
+
+
+==== <Naam black box 1>
+
+[role="arc42help"]
+****
+Beschrijf hier <'black box' 1>
+Aan de hand van de onderstaande 'black box' template:
+
+* Doel/Verantwoordelijkheid
+* Interface(s), als ze niet als aparte paragraven worden geadresseerd.
+Deze interface beschrijvingen kunnen kwaliteit en prestatie karakteristieken bevatten.
+* (Optioneel) Kwaliteits-/Prestatie karakteristieken van de 'black box', bijvoorbeeld beschikbaarheid, run time gedrag, ....
+* (Optioneel) directories/bestand locaties
+* (Optioneel) Vervulde requirements (als er traceerbaarheid van de requirements is vereist)
+* (Optioneel) Open issues/problemen/risico's
+****
+
+_<Doel/Verantwoordelijkheid>_
+
+_<Interface(s)>_
+
+_<((Optioneel) Kwaliteits-/Prestatie karakteristieken>_
+
+_<(Optioneel) directories/bestand locaties>_
+
+_<(Optioneel) Vervulde requirements>_
+
+_<(Optioneel) Open issues/problemen/risico's>_
+
+
+=== <Naam black box 2>
+
+_<black box template>_
+
+==== <Naam black box n>
+
+_<black box template>_
+
+
+==== <Naam interface 1>
+
+...
+
+==== <Naam interface m>
+
+
+
+=== Niveau 2
+
+[role="arc42help"]
+****
+Hier kunnen de innerlijke structuren van (sommige) bouwstenen uit niveau 1 als 'white boxes' worden gespecificeerd.
+
+Er moet een keuze gemaakt worden voor welke bouwstenen het gerechtvaardigd is om zo'n gedetailleerde beschrijving te maken.
+Geeft de voorkeur aan relevantie boven compleetheid.
+Beschrijf belangrijke, verassende, risicovolle, complexe of vluchtige bouwstenen.
+Laat normale, simpele, saaie of gestandardiseerde delen van het systeem buiten beschouwing.
+****
+
+==== White Box _<bouwsteen 1>_
+
+[role="arc42help"]
+****
+...beschrijft de interne structuur van _bouwsteen 1_.
+****
+
+_<white box template>_
+
+==== White Box _<bouwsteen 2>_
+
+
+_<white box template>_
+
+...
+
+==== White Box _<bouwsteen m>_
+
+
+_<white box template>_
+
+
+
+=== Niveau 3
+
+[role="arc42help"]
+****
+Hier kan de interne structuur van (sommige) niveau 2 bouwstenen als 'white boxes' worden beschreven.
+
+Als er meer gedetailleerde niveaus van de architectuur nodig zijn, kopieer dan dit deel van arc42 voor aanvullende niveaus.
+****
+
+
+==== White Box _<bouwsteen x.1>_
+
+[role="arc42help"]
+****
+Specificeer de interne structuur van _bouwsteen x.1_.
+
+****
+
+
+_<white box template>_
+
+
+==== White Box _<bouwsteen x.2>_
+
+_<white box template>_
+
+
+
+==== White Box _<bouwsteen y.1>_
+
+_<white box template>_
diff --git a/NL/asciidoc/src/06_runtime_view.adoc b/NL/asciidoc/src/06_runtime_view.adoc
new file mode 100644
index 0000000..50d8fe9
--- /dev/null
+++ b/NL/asciidoc/src/06_runtime_view.adoc
@@ -0,0 +1,52 @@
+[[section-runtime-view]]
+== Runtime View
+
+
+[role="arc42help"]
+****
+.Inhoud
+De runtime view beschrijft concreet gedrag en de interacties tussen de bouwstenen van het systeem vanuit de volgende gebieden:
+
+* belangrijke use cases of eigenschappen: op welke manier voeren de bouwstenen deze uit?
+* interactie bij kritieke externe interfaces: hoe werken bouwstenen samen met gebruikers en aanpalende systemen?
+* operations en administrie: uitvoeren, starten, stoppen
+* error en uitzonderlijke (exception) scenarios
+
+NOTE: Het primaire criterium bij de keuze van mogelijke scenarios (sequences, workflows) is de relevantie met betrekking tot de architectuur.
+Het is uitdrukkelijk *niet* van belang om een groot aantal scenarios te beschrijven.
+Beschrijf liever een representatieve doorsnede.
+
+
+.Motivatie
+Beschrijft hoe (instanties van) bouwstenen van het systeem hun taken uitvoeren en hoe ze 'at runtime' communiceren.
+
+De scenarios zullen hoofdzakelijk beschreven worden om de architectuur aan belanghebbenden te communiceren die minder behoefte of kunde hebben om statische modellen (bouwstenen view, deploy view) te lezen en te doorgronden.
+
+.Vorm
+Er zijn meerdere manieren om de schenarios vast te leggen, bijvoorbeeld
+
+* (uitgeschreven) opsomming van de stappen
+* activiteiten of flow diagrammen
+* sequence diagrammen
+* BPMN of EPCs (event process chains)
+* state machines
+* ...
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-6/[Runtime View] in de arc42 documentatie.
+
+****
+
+=== <Runtime Scenario 1>
+
+
+* _<voeg een runtime diagram of een tekstuele beschrijving van het scenario toe>_
+* _<voeg een beschrijving toe van bijzondere aspecten van de interactie tussen de instanties van de bouwstenen die in dit diagram worden weergegeven>_
+
+=== <Runtime Scenario 2>
+
+=== ...
+
+=== <Runtime Scenario n>
diff --git a/NL/asciidoc/src/07_deployment_view.adoc b/NL/asciidoc/src/07_deployment_view.adoc
new file mode 100644
index 0000000..907c0e4
--- /dev/null
+++ b/NL/asciidoc/src/07_deployment_view.adoc
@@ -0,0 +1,95 @@
+[[section-deployment-view]]
+
+
+== Deployment View
+
+[role="arc42help"]
+****
+.Inhoud
+De deployment view beschrijft:
+
+1. de benodigede technische infrastructuur om het systeem uit te kunnen voeren, met infrastructurele elementen zoals geografische locatie, omgeving, computers, processors, kanalen en netwerk topologie als ook andere infrastructurele elementen; 
+2. mapping van (software) bouwstenen naar infrastructuur elementen.
+
+Vaak worden systeem in verschillende omgevingen gedraaid, e.g. ontwikkel omgeving, test omgeving, productie omgeving.
+In zulke gevallen moeten alle relevevante omgevingen worden gedocumenteerd.
+
+In het bijzonder als de software wordt uitgevoerd op een gedistribueerd systeem, met meer dan een computer, processor, server of container _of_ als er gebruik wordt gemaakt van zelf ontworpen hardware en/of chips, is het van belang om de deployment view vast te leggen.
+
+Vanuit een software perspectief is het voldoende om alleen die elementen van de infrastrucuur vast te leggen die nodig zijn om de deployment view van de bouwstenen te tonen.
+Hardware architecten kunnen verder gaan en de infrastruur beschrijven tot het detail niveau dat voor hun passend is.
+
+.Motivatie
+Software draait niet zonder hardware.
+Deze onderliggende infrastructuur heeft invloed om het systeem en/of sommige cross-cutting concepten.
+Daarom is het van belang kennis te hebben van de infrastructuur.
+
+.Vorm
+
+Mogelijk is er op het hoogste niveau al een deployment diagram opgenomen in paragraaf 3.2. als technische context met de eigen infrastructuur als 1 "black box".
+
+In deze paragraaf kan worden ingezoomd op deze "black box" met aanvullende deployment diagrammen:
+
+* UML bied deployment diagrammen om die view weer te geven.
+Gebruik deze, eventueel met geneste diagrammen, als de infrastructuur ingewikkelder is.
+* Als de (hardware) belanghebbenden er de voorkeur aan geven kunnen ander type diagrammen gebruikt worden.
+Gebruik passende diagrammen om de nodes en kanalen van de infrastructuur weer te geven.
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-7/[Deployment View] in de arc42 documentatie.
+
+****
+
+=== Infrastructuur Niveau 1
+
+[role="arc42help"]
+****
+Beschrijf (normaliter in een combinatie van diagrammen, tabellen en text):
+
+* distributie van het systeem over meerdere locaties, omgevingen, computers, processors, .., als ook de fysieke verbindingen ertussen
+* verantwoording of motivatie voor deze deployment strucuur
+* kwaliteit en/of performance attributen van deze infrastructuur
+*  mapping van software artifacten naar elementen van deze infrastructuur
+
+Als er sprake is van meerdere omgevingen of alternatieve deployments kopieer en pas deze paragraaf van arc42 aan voor alle relevente omgevingen. 
+
+****
+
+_**<Overzichts Diagram>**_
+
+Motivatie::
+
+_<uitleg in tekstuele vorm>_
+
+Kwaliteit en/of Performance Eigenschappen::
+
+_<uitleg in tekstuele vorm>_
+
+Mapping van Bouwstenen naar Infrastructuur::
+_<beschrijving van de mapping>_
+
+
+=== Infrastructuur Niveau 2
+
+[role="arc42help"]
+****
+Hier kunnen de interne structuren van (sommige) infrastructuur elementen uit niveau 1 worden toegevoegd.
+
+Kopieer de structuur van niveau 1 voor ieder geselecteerd element.
+****
+
+==== _<Infrastructuur Element 1>_
+
+_<diagram + uitleg>_
+
+==== _<Infrastructuur Element 2>_
+
+_<diagram + uitleg>_
+
+...
+
+==== _<Infrastructuur Element n>_
+
+_<diagram + uitleg>_
diff --git a/NL/asciidoc/src/08_concepts.adoc b/NL/asciidoc/src/08_concepts.adoc
new file mode 100644
index 0000000..3c712a9
--- /dev/null
+++ b/NL/asciidoc/src/08_concepts.adoc
@@ -0,0 +1,70 @@
+[[section-concepts]]
+== Cross-cutting Concepten
+
+
+[role="arc42help"]
+****
+.Inhoud
+Dit deel beschrijft uitgangspunten en concepten die relevant zijn voor meerdere delen (=cross-cutting) van het systeem.
+Dergelijke concepten zijn vaak van toepassing op meerdere bouwstenen.
+Ze kunnen meerdere onderwerpen beslaan, zoals
+
+* modellen, in het bijzonder domein modellen
+* architectuur of design patterns
+* regels om specifiek technologie te gebruiken
+* uitgangspunten, vaak technische afspraken van overkoepelende aard (= cross-cutting) aard
+* implementatie regels
+
+
+.Motivatie
+Concepten vormen de basis van _conceptuele integriteit_ (consistentie en homogeniteit) van de architectuur.
+Zodoende vormen ze een belangrijk hulpmiddel om de innerlijke kenmerken van de architectuur vast te leggen.
+
+Sommige van deze concepten kunnen niet toegekend worden aan individuele bouwstenen, e.g. security of veiligheid.
+
+.Vorm
+De vorm kan varieeren:
+
+* concept papers die een structuur beschrijven 
+* cross-cutting model uittreksels of scenarios waarbij gebruik wordt gemaakt van architectuur views
+* voorbeeld implementaties, specifiek voor technische concepten
+* referenties naar typerend gebruik van standaard frameworks (e.g. Hibernate gebruiken voor object/relational mapping)
+
+.Structuur
+Een mogelijke (maar niet verplicht) structuur van deze paragraaf zou kunnen bestaan uit:
+
+* Domein concepten
+* User Experience concepten (UX)
+* Veiligheid en security concepten
+* Architectuur en design patterns
+* "Under-de-motorkap"
+* ontwikkel concepten
+* operationele concepten
+
+NOTE: het kan moeilijk zijn om individuele concepten toe te kennen aan een specifiek onderwerp van deze lijst
+
+image::08-Crosscutting-Concepts-Structure-EN.png["Mogelijke onderwerpen voor cross-cutting concepten"]
+
+
+
+.Verdere informatie
+
+Zie https://docs.arc42.org/section-8/[Concepts] in de arc42 documentatie.
+****
+
+
+=== _<Concept 1>_
+
+_<uitleg>_
+
+
+
+=== _<Concept 2>_
+
+_<uitleg>_
+
+...
+
+=== _<Concept n>_
+
+_<uitleg>_
diff --git a/NL/asciidoc/src/09_architecture_decisions.adoc b/NL/asciidoc/src/09_architecture_decisions.adoc
new file mode 100644
index 0000000..218ae99
--- /dev/null
+++ b/NL/asciidoc/src/09_architecture_decisions.adoc
@@ -0,0 +1,31 @@
+[[section-design-decisions]]
+== Architectuur Beslissingen
+
+
+[role="arc42help"]
+****
+.Inhoud
+Belangrijke, kostbare, ver reikende of risicovolle beslissingen die betrekking hebben op de architectuur met bijbehorende motivering.
+Met "beslissingen" wordt bedoeld dat, op basis van gegeven criteria, een alternatief wordt gekozen.
+
+Beoordeel zelf of de architectuur keuze op deze centrale plek moet worden vastgelegd of in de gespecialiseerde context (bijvoorbeeld binnen een "white box" template van een bouwsteen).
+
+Vermijd doublures.
+Verwijs naar hoodstuk 4 als daar al belangrijke architectuur beslissingen zijn vastgelegd.
+
+.Motivatie
+Belanghebbende van het systeem moeten in staat zijn om de gemaakte keuzes te begrijpen en te herleiden.
+
+.Vorm
+Er zijn verschillende opties:
+
+* ADR ((https://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions[Architecture Decision Record])) voor iedere belangrijke beslissing;
+* Lijst of tabel, gesorteerd op belang en consequenties of;
+* meer gedetaileerd in de vorm van een paragraaf per gemaakte beslissing
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-9/[Architecture Decisions] in de arc42 documentatie.
+Daar zijn ook links en voorbeelden van een ADR te vinden.
+
+****
diff --git a/NL/asciidoc/src/10_quality_requirements.adoc b/NL/asciidoc/src/10_quality_requirements.adoc
new file mode 100644
index 0000000..cd4f6b7
--- /dev/null
+++ b/NL/asciidoc/src/10_quality_requirements.adoc
@@ -0,0 +1,70 @@
+[[section-quality-scenarios]]
+== Kwaliteits Requirements
+
+
+[role="arc42help"]
+****
+
+.Inhoud
+Dit hoofdstuk bevat alle kwaliteits requirements als een kwaliteits boom met scenarios.
+De belangrijkste zijn al beschreven in paragraaf 1.2 (kwaliteits doelen.)
+
+Op deze plaats kunnen ook lagere prioriteit kwaliteits requirements worden vastgelegd die, als ze niet (volledig) worden gerealiseerd, geen hoog risico vormen.
+
+.Motivatie
+Omdat kwaliteits requirements grote invloed invloed hebben op architectuur beslissingen is het van belang om voor iedere belanghebbende, in concrete en meetbare termen, te begrijpen wat echt van belang is. 
+
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-10/[Quality Requirements] in de arc42 documentatie.
+
+****
+
+=== Kwaliteits Boom
+
+[role="arc42help"]
+****
+.Inhoud
+De kwaliteits boom (zoals gedefinieerd in ATAM - Architecture Analysis Method) met kwaliteit/evaluatie scenarios als bladeren.
+
+.Motivatie
+De geprioriteerde boomstructuur bied overzicht over, een mogelijk groot aantal, kwaliteits requirements.
+
+.Vorm
+De kwaliteitsboom is een hoog niveau overzicht van de kwaliteits doelen en requirements:
+
+* verdieping van de term "kwaliteit" in de vorm van een boom structuur
+Gebruik daarbij "kwaliteit" als de root van de boom.
+* een mind map met kwaliteit categorieen als eerste takken
+
+De boom moet in elk geval verwijzingen/links bevatten naar de scenarios in de volgende paragraaf.
+
+
+****
+
+=== Kwaliteits Scenarios
+
+[role="arc42help"]
+****
+.Inhoud
+Het concreet maken van (soms vage of impliciete) kwaliteits requirements gebruik makend van (kwaliteits) scenarios.
+
+Deze scenarios beschrijven wat er moet gebeuren als het systeem wordt geconfronteerd met een stimulus.
+
+Voor architecten zijn er twee soorten scenarios van belang:
+
+* Gebruik scenarios (ook wel applicatie scenarios of use case scenarios genoemd) beschrijven het runtime gedrag van het systeem naar aanleiding van een bepaalde stimulus.
+Dit is inclusief scenarios die de efficientie of performance van het systeem beschrijven.
+Bijvoorbeeld: Het systeem reageert binnen een seconde op een request.
+* Verander scenarios beschrijven modificaties aan het systeem, of aan haar onmiddelijke omgeving
+Bijvoorbeeld: Er moet aanvullende functionaliteit geimplementeerd worden of de eis voor een kwaliteitskenmerk verandert.
+
+.Motivatie
+Scenarios maken kwaliteits requirements concreet en maken het daarmee eenvoudiger om te meten of te bepalen of ze vervuld worden.
+
+Vooral als er methodes als ATAM worden gebruikt is het van belang om de kwaliteits doelen (uit paragraaf 1.2) tot op het niveau van scenarios die besproken en bediscussieerd kunnen worden, te beschrijven.
+
+.Vorm
+Lijst of vrije tekst vorm.
+****
diff --git a/NL/asciidoc/src/11_technical_risks.adoc b/NL/asciidoc/src/11_technical_risks.adoc
new file mode 100644
index 0000000..3d0f32a
--- /dev/null
+++ b/NL/asciidoc/src/11_technical_risks.adoc
@@ -0,0 +1,23 @@
+[[section-technical-risks]]
+== Risico's en Technical Debt
+
+
+[role="arc42help"]
+****
+.Inhoud
+Een op prioriteit gesorteerde lijst, met bekende technische risico's en technical dept.
+
+.Motivatie
+“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)
+
+Dit zou het motto moeten zijn bij het systematisch bepalen en evalueren van risico's en technical dept in de architectuur.
+Management stakeholder (bijvoorbeeld project managers of project owners) hebben dit inzicht nodig om keuzes te kunnen maken met betrekking tot risico en planning.
+
+.Vorm
+Lijst van risico's en/of technical dept eventueel aangevuld met maatregelen om deze te minimaliseren, verzachten of te vermijden.
+
+.Verdere Informatie
+
+Zie https://docs.arc42.org/section-11/[Risks and Technical Debt] in de arc42 documentatie.
+
+****
diff --git a/NL/asciidoc/src/12_glossary.adoc b/NL/asciidoc/src/12_glossary.adoc
new file mode 100644
index 0000000..767bbe2
--- /dev/null
+++ b/NL/asciidoc/src/12_glossary.adoc
@@ -0,0 +1,37 @@
+[[section-glossary]]
+== Woordenlijst
+
+[role="arc42help"]
+****
+.Inhoud
+De belangrijkste domein en technische termen die belanghebbenden gebruiken tijdens het bespreken van het systeem.
+
+De woordenlijst kan ook als bron voor vertaalde termen worden gebruikt bij meertalige teams.
+
+.Motivatie
+Termen moeten helder worden gedefinieerd zodat alle belanghebbenden
+
+* een gemeenschappelijk en eenduidig begrip hebben van deze termen
+* geen gebruik maken van synoniemen of homoniemen
+
+.Vorm
+* Een tabel met kolommen <Term> en <Definitie>.
+* Eventueel meerdere kolommen als er vertalingen nodig zijn.
+
+
+.Verdere Informatie
+
+See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation.
+
+****
+
+[cols="e,2e" options="header"]
+|===
+| Term | Definitie
+
+| <Term-1>
+| <definitie-1>
+
+| <Term-2>
+| <definitie-2>
+|===
diff --git a/NL/asciidoc/src/about-arc42.adoc b/NL/asciidoc/src/about-arc42.adoc
new file mode 100644
index 0000000..8bc32aa
--- /dev/null
+++ b/NL/asciidoc/src/about-arc42.adoc
@@ -0,0 +1,16 @@
+:homepage: https://arc42.org
+
+:keywords: software-architecture, documentation, template, arc42
+
+:numbered!:
+**Over arc42**
+
+[role="lead"]
+arc42, de Template voor documentatie van software en systeem architectuur.
+
+Gecreeerd en onderhouden door Dr. Peter Hruschka, Dr. Gernot Starke en bijdragers.
+
+Template Revisie: 8.0 NL (based on asciidoc), February 2022
+
+(C)
+We erkennen dat dit document materiaal gebruikt van de arc 42 architectuur template, https://arc42.org.
diff --git a/NL/asciidoc/src/config.adoc b/NL/asciidoc/src/config.adoc
new file mode 100644
index 0000000..28c6bab
--- /dev/null
+++ b/NL/asciidoc/src/config.adoc
@@ -0,0 +1,9 @@
+// asciidoc settings for NL (Nederlands)
+// ==================================
+:toc-title: inhoudsopgave
+
+// enable table-of-contents
+:toc:
+
+// where are images located?
+:imagesdir: ./images
diff --git a/NL/asciidoc/src/termen.adoc b/NL/asciidoc/src/termen.adoc
new file mode 100644
index 0000000..446fd6f
--- /dev/null
+++ b/NL/asciidoc/src/termen.adoc
@@ -0,0 +1,18 @@
+
+.Vertalingen
+
+|===
+| EN term | NL term
+
+| Abstract | Beschrijving
+| Building block | Bouwsteen
+| Constraints | Beperkingen
+| Channel | Kanaal
+| Excerpt(s) | Uittreksel(s)
+| Extract | Samenvatting
+| Feature | Eigenschap
+| Key quality goals | Meest balangrijke kwaliteits doelen
+| Level | Niveau
+| Stakeholder(s) | Belanghebbende(n)
+
+|===
\ No newline at end of file