← Kennisbank · Data Architecture

Hoe plan ik veranderingen in mijn data-architectuur?

Data Architecture Roadmap

Verbind verbeteringen aan werkpakketten, afhankelijkheden en duidelijke voorwaarden voor ingebruikname.

Uitleg en hulpmiddelen · v1.0 · Gepubliceerd

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

Wanneer gebruik je dit?

  • Na een gevalideerde data-impact- en gap-analyse.
  • Bij samenhangende wijzigingen in contracten, platform en datagebruik.
  • Bij fasering van migratie en uitfasering.
  • Wanneer planning afhankelijk is van nog open besluiten of capaciteit.

Wat heb je nodig?

Een gecontroleerde gap-analyse, een gewenste situatie en zicht op open besluiten en afhankelijkheden.

Een voorbeeld uit de praktijk

Fictieve casus: Noordhaven Servicebureau

Het fictieve Noordhaven Servicebureau wil de dagelijkse aanvragenlijst gecontroleerd gaan publiceren. Er is een acceptatieprobleem (GP-01), een ontbrekend beheerd contract (GP-02) en onzekerheid over herlevering (GP-03). Het leveringscontract heet in de werkbladen CT-01.

Eerst worden het contract en de herstelafspraken onderzocht en vastgesteld. Daarna volgt een proefpad dat leveringen controleert. Vervolgens draait dat pad parallel aan de bestaande werkwijze. Uitfasering volgt pas nadat de afnemers de overgang hebben geaccepteerd.

Omschakelen vereist drie controles: een onvolledige lijst vervangt de vorige geaccepteerde lijst niet (AC-01); het contract heeft een bevestigde eigenaar en versie (AC-02); een identieke herlevering heeft geen tweede effect en een conflicterende levering stopt voor onderzoek (AC-03). De bevoegde afnemer beoordeelt het bewijs en besluit over de overgang.

Deze voorwaarden zijn nog niet getest. Capaciteit, budget en kalenderdata staan open. De roadmap beschrijft daarom een voorgestelde volgorde, geen toegezegde planning.

Bekijk de visuele samenvattingVisuele samenvatting van Data Architecture RoadmapOpen op volledig formaat (nieuw tabblad)

Aan de slag

  1. Neem gaps, doeltoestand en open besluiten over met versie.
  2. Definieer aantoonbare transitietoestanden.
  3. Koppel werkpakketten aan gaps en overgangscriteria.
  4. Leg afhankelijkheden en aannames van de planning vast.
  5. Werk migratie, terugval en uitfasering uit op architectuurniveau.
  6. Plan verificatie, beslismandaat en herijking van de roadmap.
Naar de downloads ↑

Controleer je resultaat

  • Gaps en gewenste situatie zijn met versie en status gekoppeld.
  • Elke tussenstap beschrijft een bruikbare, verifieerbare toestand.
  • Werkpakketten hebben resultaat, eigenaarstatus en sluitingscriterium.
  • Afhankelijkheden hebben een type en bevatten geen cirkel.
  • Onbekende capaciteit, budget en datums zijn expliciet open.
  • Parallel gebruik beschrijft leidende bron en vergelijking en afstemming van de gegevens.
  • Omschakeling heeft bewijs, beslisser en mandaatstatus.
  • Terugval noemt trigger, gegevensgevolg en herstelbewijs.
  • Uitfasering controleert afnemers, kopieën en levenscyclus.
  • Herijking heeft triggers en een versieerbaar besluitspoor.
Verdieping en begrippen
Transitietoestand
Een bruikbare tussenstap waarvan je kunt aantonen dat de voorwaarden zijn bereikt.
WP / TS / ML
Templatecodes voor werkpakket, transitietoestand en mijlpaal.
GP / CT / AC
Verwijzingen naar een gap, leveringscontract en acceptatiecriterium, hierboven uitgelegd.

Wat is het?

De Data Architecture Roadmap beschrijft hoe een organisatie van een vastgelegde beginsituatie via verifieerbare tussenstappen naar een gewenste data-architectuur kan bewegen. Zij verbindt gaps met werkpakketten, beslismomenten en voorwaarden voor ingebruikname en uitfasering.

EAW-werkwijze

De roadmap gebruikt eigen EAW-conventies en claimt geen verplichte fasering uit een standaard. TS is een transitietoestand, WP een werkpakket, ML een mijlpaal, DP een afhankelijkheid, AC een acceptatiecriterium en DD een besluit. Een werkpakket levert een resultaat. Een transitietoestand beschrijft wat op dat moment samenhangend werkt. Een mijlpaal bevestigt een beoordeeld resultaat of besluit, niet alleen het verstrijken van een datum.

Van gap naar transitie

Begin met bronversies en onderscheid gevalideerde gaps van onderzoeksvragen. Geef iedere beoogde toestand een ingang, een uitgang en het bewijs dat het gebruik verantwoord kan doorgaan. Een tussentoestand kan extra beheersing vragen omdat oude en nieuwe werkwijzen naast elkaar bestaan. Maak zichtbaar welke bron leidend is en hoe reconciliatie plaatsvindt. Een afgerond werkpakket betekent niet automatisch dat de transitie is geaccepteerd.

Afhankelijkheden en planning

Leg vast welk resultaat van een voorganger nodig is voordat de opvolger kan beginnen of afronden. Controleer op cirkels en ontbrekende externe afhankelijkheden. Gebruik relatieve volgorde wanneer capaciteit, budget of mandaat nog onbekend zijn. Eventuele kalenderdata krijgen een status en onderbouwing. Een doelmaand is geen commitment. Het EAW-voorbeeld bevat daarom voorwaarden en volgorde, zonder verzonnen doorlooptijden of opbrengsten.

Migratie en uitfasering

Beschrijf welke gegevens verhuizen, welke versies naast elkaar bestaan en wie beslist over omschakeling. Leg reconciliatie vast op betekenis, populatie en peilmoment. Een terugvalplan noemt trigger, autoriteit, gegevensgevolg en herstelbewijs. Uitfaseren vraagt bevestiging dat geen noodzakelijke afnemer achterblijft en dat lifecycleverplichtingen zijn behandeld. Een geslaagde nieuwe levering maakt oude kopieën niet vanzelf overbodig.

Sturen en herijken

Werk per WP eigenaarstatus, capaciteit, kostenbasis, afhankelijkheid en open besluit uit. Als informatie ontbreekt, noteer open met een vervolgactie. Herijk bij wijziging van contract, target, prioriteit of beschikbaarheid van mensen. Bewaar eerdere versies zodat een verschoven volgorde verklaarbaar blijft. De roadmap bepaalt architectuurtransities; detailplanning en feitelijke voortgang krijgen een eigen beheerproces.

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.

EAW-werkafspraken. Codes, views en statussen zijn lokale modelconventies. Alle casusgegevens, rollen, normen en planning zijn fictief. Open punten blijven expliciet open.

Versie 1.0 · Gepubliceerd