Werkproduct

Migratiescenario

Het migratiescenario is de onderbouwde, geordende reeks stabiele tussentoestanden waarlangs de solution van de huidige naar de gewenste architectuur beweegt.

Alpha: Uitdaging Solution architectuur
01

Beschrijving

Het migratiescenario is een onderbouwde, geordende reeks stabiele tussentoestanden — plateaus — die de overgang beschrijft van de huidige naar de gewenste architectuur van de solution. Elk plateau is operationeel verdedigbaar: de solution functioneert als geheel, ook al is de doelarchitectuur nog niet volledig gerealiseerd, en tussen plateaus in mag nooit een half werkende toestand ontstaan die de bedrijfsvoering breekt. Dat onderscheidt het migratiescenario van een planning of taaklijst: het beschrijft niet wát er moet gebeuren, maar in welke volgorde de solution stabiel van de ene naar de andere toestand beweegt, en waarom die volgorde de juiste is.

Het migratiescenario wordt in stappen scherper: Beschrijf de architectuurvisie schetst het voor het eerst, op strategisch niveau — scope, globale doorlooptijd en bedrijfsdoelen. Bestuur de architectuurverandering werkt dat uit tot tactisch niveau, als enterprise-brede reeks horizons. Maak high-level design vertaalt dat kader naar een eerste, solution-specifieke versie waarin alleen de eerstvolgende transitiestaat scherp wordt ingevuld en latere staten bewust globaal blijven; Maak low-level design werkt die eerstvolgende stap vervolgens verder uit tot operationeel niveau zodra de technische detaillering concreet genoeg is. Vanaf dat moment dient het migratiescenario als referentie voor Bestuur levering en Toets werking governance om afwijkingen tijdens de uitvoering te herkennen en te beoordelen, voor Bewaak conformance om de voortgang te volgen, en voor de Enterprise architect om het migratiescenario te toetsen aan de enterprise-brede horizons.

Per transitiestaat legt het migratiescenario vast wat op dat moment werkt en operationeel is, wat eventueel nog tijdelijk parallel loopt, welke integraties bestaan en welke daarvan tijdelijk zijn, en de belangrijkste afhankelijkheden en risico's. De volgorde van de plateaus wordt onderbouwd langs vier lijnen: data-afhankelijkheid, technische afhankelijkheid tussen integratiepunten, risico, en niet-technische realiteit zoals budget, contracten of organisatorische gereedheid — zodat de prioritering navolgbaar is in plaats van impliciet.

Sjabloon
migratiescenario.docx
Sjabloon voor Migratiescenario
⬇ Download DOCX
02

Detailniveaus

  1. 1. Strategisch niveau

    Dit niveau informeert management en bestuur over de grote lijnen van de migratie: de scope, het budget, de globale doorlooptijd, de eindmilestones en de bedrijfsdoelen die ermee gediend zijn. De centrale vraag is niet hóe wordt gemigreerd, maar wát er verandert en waaróm — vergelijkbaar met de manier waarop TOGAF's Architecture Roadmap op enterprise-niveau de opeenvolgende stappen van baseline- naar doelarchitectuur aan stakeholders communiceert, zonder de onderliggende technische uitwerking. Dit niveau is nooit voldoende om op te sturen: het ontbreekt de systeem- en afhankelijkheidsdetails die projectleiders en leveranciers nodig hebben, en dient daarom uitsluitend om richting en draagvlak te geven aan wat volgt.

  2. 2. Tactisch niveau Voldoende

    Dit niveau stemt af tussen projectleiders, leveranciers en afdelingshoofden: in welke volgorde systemen of afdelingen migreren, hoe capaciteit wordt ingepland en welke risico's en verantwoordelijkheden (RACI) bij elke stap horen. Het komt overeen met wat TOGAF in Phase E en F uitwerkt als een reeks Transition Architectures: elke tussentoestand krijgt een eigen set werkpakketten, samengesteld op basis van een analyse van gaps, mogelijke oplossingen en onderlinge afhankelijkheden — wat TOGAF de Consolidated Gaps, Solutions and Dependencies Matrix noemt. Dit is doorgaans het niveau waarop een migratiescenario voldoende is om als besturingsinstrument te dienen: het legt vast wie wat doet en wanneer welke component aan de beurt is, zonder al af te dalen naar de technische uitvoering zelf.

  3. 3. Operationeel niveau

    Dit niveau stuurt de techneuten rechtstreeks tijdens de uitvoering: systeemconfiguraties, datamappings, netwerkwijzigingen en testscripts, met de technische randvoorwaarden en validaties die per stap moeten kloppen. TOGAF benoemt op dit detailniveau vergelijkbare factoren via de Implementation Factor Assessment and Deduction Matrix — risico's, aannames, afhankelijkheden en de acties die daaruit volgen — maar werkt ze in de ADM zelf niet uit tot op configuratieniveau; de ADM blijft steken op portfolio- en projectniveau. Dit operationele niveau vult dat gat voor deze werkwijze in: het maakt de tactische werkpakketten concreet genoeg om daadwerkelijk uit te voeren en te toetsen.

  4. 4. Draaiboek niveau

    Dit niveau geeft strakke regie tijdens het daadwerkelijke migratievenster — vaak een avond of weekend — met een chronologische checklist op minuutbasis, expliciete go/no-go-momenten en terugvalprocedures (rollback) voor het geval iets misgaat. TOGAF beschrijft dit uitvoeringsdetail niet: de ADM eindigt bij het geprioriteerde en geaccordeerde Implementation and Migration Plan uit Phase F, en laat de daadwerkelijke uitvoering — inclusief het bewaken van architectuurconformiteit — over aan Phase G, Implementation Governance. Het draaiboek is daarmee het meest gedetailleerde niveau van het migratiescenario: het doel is minimale downtime en directe escalatielijnen zodra zich tijdens het venster een storing voordoet.

03

Bronnen

  • The Open Group, TOGAF® Series Guide: A Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF® ADM (2025) — hoofdstukken over baseline/target/transition states en Transition Architecture
  • The Open Group, TOGAF® Standard, 10th Edition — ADM Phase E: Opportunities & Solutions en Phase F: Migration Planning (Architecture Roadmap, Transition Architectures, werkpakketten, Implementation and Migration Plan), en de Migration Planning Techniques (Implementation Factor Assessment and Deduction Matrix, Consolidated Gaps, Solutions and Dependencies Matrix, Architecture Definition Increments Table)

Open practice. Deze practices zijn open voor bijdragen van de community. Open een GitHub-issue om een verbetering aan een bestaande practice voor te stellen, een nieuwe practice te introduceren of een sjabloon bij te dragen — issues zijn het startpunt voor elke wijziging.