← Kennisbank · Infrastructure Architecture

Waarvan is mijn digitale dienst afhankelijk?

Infrastructure Dependency Map

Verbind een gebruikersdienst aan technische afhankelijkheden en onderzoek wat er gebeurt bij uitval.

Uitleg en hulpmiddelen · v1.0 · Gepubliceerd

Download template (.pptx)Download ingevuld voorbeeld (.pptx)Download samenvatting (.png)

Wanneer gebruik je dit?

  • Bij wijziging of vervanging van infrastructuur.
  • Bij onderzoek naar uitval en voorbereiding van herstel.

Wat heb je nodig?

Dienst, gebruikersuitkomst en omgeving.

Een voorbeeld uit de praktijk

Fictieve casus: Noordhaven Servicebureau

Noordhaven wil dat gebruikers online een nieuwe aanvraag kunnen indienen. Daarvoor zijn het portaal, de gegevensopslag en de identiteitsdienst nodig. De kaart laat zien welk onderdeel een ander onderdeel nodig heeft en waarom.

Valt de identiteitsdienst uit, dan kunnen nieuwe gebruikers niet aanmelden. Of bestaande sessies blijven werken, is nog onbekend. Ook moet het beheerteam onderzoeken of portaal en opslag dezelfde netwerkvoorziening gebruiken.

Het herstelvoorstel eindigt met een proef: een testgebruiker meldt aan, dient een aanvraag in en ontvangt een bevestiging. De opslag moet precies één aanvraag bevatten. Hersteltijd en toegestaan gegevensverlies moeten nog worden vastgesteld.

Bekijk de visuele samenvattingVisuele samenvatting van Infrastructure Dependency MapOpen op volledig formaat (nieuw tabblad)

Aan de slag

  1. Baken dienst, omgeving en gebruikersuitkomst af.
  2. Leg componenten en afhankelijkheden met richting vast.
  3. Onderzoek gedeelde foutoorzaken en alternatieven.
  4. Werk één uitvalscenario uit en bepaal benodigd bewijs.
Naar de downloads ↑

Controleer je resultaat

  • Iedere relatie heeft een richting, reden en bronstatus.
  • Gedeelde foutoorzaken en onbekende afhankelijkheden zijn zichtbaar.
  • Een hersteldoel is onderscheiden van een bewezen herstelresultaat.
  • Scenario, eigenaar en acceptatiebewijs verwijzen naar dezelfde dienst.
Verdieping en begrippen
EAW-codes
Lokale verwijzingen die kaart, register, scenario en besluit met elkaar verbinden.

Wat beschrijft dit model?

Een EAW Infrastructure Dependency Map beschrijft welke technische voorzieningen een afgebakende dienst nodig heeft, waarom die relaties bestaan en welke gevolgen uitval kan hebben. De kaart combineert een afhankelijkheidsdiagram met component-, relatie- en scenarioregisters.

Afbakening

Dit product verklaart afhankelijkheid en uitval. De Solution Deployment View blijft de plaats voor de toewijzing van oplossingsonderdelen aan uitvoeromgevingen. Een getekende reservevoorziening bewijst nog geen onafhankelijke foutoorzaak of uitvoerbaar herstel.

Zo lees je de werkbladen

De codes zijn EAW-werkafspraken. Gebruik dezelfde codes in de kaart, registers en besluiten. De template bevat vier werkbladen; het voorbeeld vult precies dezelfde velden in.

Dienst en afhankelijkheden

Dienst, gebruikersuitkomst en omgeving. Expliciete uitsluitingen en raakvlakken. Gebruik vaste codes. Noteer per lijn welke bron welk doel nodig heeft. Versie, peildatum en herkomst van de kaart.

Componenten en gedeelde foutoorzaken

Naam, functie, omgeving, beheerder en relevante foutoorzaak. Naam, functie, omgeving, beheerder en relevante foutoorzaak. Naam, functie, omgeving, beheerder en relevante foutoorzaak. Welke componenten kunnen door dezelfde gebeurtenis uitvallen? Onderscheid waargenomen, opgegeven, aangenomen en onbekend.

Afhankelijkheidsregister

Broncode, doelcode, reden, conditie, alternatief en eigenaar. Broncode, doelcode, reden, conditie, alternatief en eigenaar. Broncode, doelcode, reden, conditie, alternatief en eigenaar. Bronreferentie en bewijsstatus per relatie. Wat moet opnieuw worden onderzocht als een component verandert?

Uitvalscenario en besluit

Gebeurtenis, geraakte component en gebruikersgevolg. Herstelbehoefte, maximaal gegevensverlies en bevoegde vaststeller. Voorwaarden, volgorde, eigenaar en alternatief. Welke test toont aan dat de gebruikersuitkomst weer werkt? Besluit, rationale, eigenaar en herijkmoment.

Fictief voorbeeld: Noordhaven

Alle toewijzingen en maatregelen zijn voorstellen binnen een verzonnen oefencasus. Zij zijn geen bewezen productiegedrag.

Dienst en afhankelijkheden

Scope — D-01: nieuwe aanvraag indienen bij fictief loket Noordhaven. Alleen productie-indiening.

Buiten scope — Inhoudelijke beoordeling en betaling vallen buiten deze kaart.

Kaart lezen — D-01 vereist C-01. C-01 gebruikt C-02 voor opslag en C-03 voor identiteit.

Status en bron — Fictieve ontwerpcasus v1.0. Alle relaties zijn casusgegevens, geen gemeten productiefeiten.

Componenten en gedeelde foutoorzaken

C-01 — Portaal; ontvangt aanvragen; productie; team Portaal. Netwerkafhankelijkheid nog te onderzoeken.

C-02 — Gegevensopslag; bewaart aanvragen; productie; team Data. Geen bewezen alternatieve opslagroute.

C-03 — Identiteitsdienst; controleert identiteit; externe partij. Contact loopt via leveranciersmanager.

Gedeelde foutoorzaak — Onbekend of C-01 en C-02 dezelfde netwerkvoorziening gebruiken. Infrabeheer onderzoekt dit vóór ontwerpbesluit.

Bronstatus — Functies en rollen: fictief opgegeven. Netwerkdeling: onbekend. Geen onafhankelijkheid verondersteld.

Afhankelijkheidsregister

R-01 — D-01 vereist C-01 voor iedere nieuwe aanvraag. Geen alternatief in scope. Dienstverantwoordelijke beheert R-01.

R-02 — C-01 vereist C-02 voor bewaren en bevestigen. Geen bewijs dat een lokale wachtrij bestaat. Team Portaal onderzoekt uitvalgedrag.

R-03 — C-01 vereist C-03 bij nieuw aanmelden. Gedrag van bestaande sessies is onbekend. Identitybeheer zoekt dit uit.

Herkomst — R-01–R-03 komen uit deze fictieve casus. Er is nog geen technische meting of hersteltest.

Wijzigingsgevolg — Vervanging van C-03 vraagt opnieuw onderzoek van R-03 en het aanmeldscenario van D-01.

Uitvalscenario en besluit

S-01 — C-03 is onbereikbaar. Nieuwe aanmelding lukt niet. D-01 kan voor nieuwe gebruikers niet starten.

Doel en grens — Nog niet vastgesteld. Dienstverantwoordelijke bepaalt de behoefte. Geen uren of percentages verzonnen.

Herstelvoorstel — Leveranciersmanager laat C-03 herstellen. Identitybeheer controleert aanmelden, daarna test team Portaal een nieuwe aanvraag.

Bewijs — Nieuwe testgebruiker meldt aan, dient in en ontvangt een herleidbare bevestiging. Controleer dat C-02 precies één aanvraag bevat.

Besluit en open punt — Voorstel nog niet goedgekeurd. Dienstverantwoordelijke beslist na herstelproef en onderzoek naar de gedeelde netwerkafhankelijkheid.

Gebruik het resultaat

Controleer de kwaliteitscriteria. Bespreek ontbrekend bewijs met de genoemde eigenaar en leg vast wanneer het model opnieuw wordt beoordeeld. Een ingevulde template is nog geen goedgekeurd ontwerp.

Verder werken

Gebruik een verwant onderwerp om een volgend deel van je vraag uit te werken.

Je accountvoorkeuren worden geladen.

Achtergrond en bronnen

EAW-werkwijze en werktemplate. Voorbeeldcasussen zijn fictief.

Codes en modelstructuur zijn EAW-werkafspraken; geen formele notatiestandaard.

Versie 1.0 · Gepubliceerd

NIST SP 800-34 Rev. 1
Parafrase: contingency planning helpt herstelbehoeften en prioriteiten bepalen. Het EAW-afhankelijkheidsmodel en de codes hieronder zijn eigen werkafspraken.