Roadmap opstellen
Develop Roadmap
Tijdens deze activiteit wordt een architectuurroadmap opgesteld die de overgang van de huidige naar de gewenste situatie beschrijft. De roadmap bestaat uit een reeks logisch opeenvolgende transitiestaten, waarbij elke transitiestaat een stabiele en operationeel werkende situatie oplevert. Daarnaast worden de belangrijkste afhankelijkheden, risico's en randvoorwaarden vastgelegd, zodat de implementatie gecontroleerd kan verlopen en de roadmap als basis kan dienen voor de projectplanning en de architectuurgovernance.
Beschrijving
Tijdens deze activiteit wordt de overgang van de huidige situatie naar de beoogde solution gepland. Het doel is een haalbare, beheersbare en verdedigbare volgorde van transitiestappen vast te stellen, waarbij de organisatie gedurende het gehele traject kan blijven functioneren. Elke transitiestaat moet een operationeel werkende situatie opleveren; tijdelijke situaties waarin de bedrijfsvoering of dienstverlening niet goed functioneert, worden voorkomen.
De roadmap beschrijft de architectuurtransitie als een opeenvolging van transitiestaten (plateaus) tussen de huidige en de gewenste architectuur. Elke transitiestaat geeft aan welke functionaliteit op dat moment beschikbaar is, welke onderdelen van de solution zijn gerealiseerd, welke bestaande voorzieningen nog in gebruik zijn, en welke systemen of integraties tijdelijk naast elkaar functioneren. Ook wordt zichtbaar welke onderdelen zijn uitgefaseerd en welke vervolgstappen nodig zijn om de volgende transitiestaat te bereiken.
De invulling van de roadmap hangt af van de aard van de oplossing. Bij een migratietraject ligt de nadruk op de volgorde waarin gegevens, functionaliteit en systemen worden gemigreerd. Bij de implementatie van een standaardsoftwarepakket beschrijft de roadmap bijvoorbeeld wanneer het pakket wordt ingevoerd, op welk moment koppelingen worden gerealiseerd of aangepast, en wanneer bestaande systemen buiten gebruik kunnen worden gesteld. In alle gevallen verbindt de roadmap de architectuur met de project- of releaseplanning.
Naast de volgorde van de transitiestappen worden ook de belangrijkste afhankelijkheden, risico's en randvoorwaarden per stap vastgelegd. Zo kan worden beoordeeld of elke overgang technisch uitvoerbaar en organisatorisch verantwoord is, en kunnen de noodzakelijke architectuurbeslissingen tijdig worden genomen.
Het resultaat van deze activiteit is een door stakeholders afgestemde architectuurroadmap: een reeks logisch opeenvolgende en operationeel verantwoorde transitiestaten. De roadmap vormt het uitgangspunt voor de verdere projectplanning, implementatie en architectuurgovernance, en toont aantoonbaar aan dat de doelarchitectuur op een gecontroleerde wijze kan worden gerealiseerd.
Aanpak
Breng de huidige en de gewenste situatie in beeld
Begin met het vaststellen van de uitgangssituatie en de beoogde eindsituatie. Maak duidelijk welke functionaliteit, gegevens, systemen en integraties veranderen, en welke ongewijzigd blijven. Bij een migratie gaat het onder meer om de onderdelen die naar een nieuw systeem worden overgezet. Bij de invoering van een standaardsoftwarepakket wordt vastgesteld welke bestaande systemen en koppelingen vervallen, welke blijven bestaan, en welke nieuwe integraties nodig zijn. Een heldere afbakening van de huidige en de gewenste situatie vormt de basis voor een realistische transitieplanning.
Definieer transitiestaten
Werk de overgang uit als een reeks opeenvolgende transitiestaten, ofwel plateaus. Elke transitiestaat beschrijft een stabiele en operationele situatie waarin de oplossing bruikbaar is en de bedrijfsvoering ongestoord kan doorgaan. Tijdens een transitiestap kunnen oude en nieuwe systemen tijdelijk naast elkaar bestaan, mits die situatie beheersbaar en functioneel compleet is. De roadmap beschrijft per transitiestaat welke onderdelen van de solution beschikbaar zijn, welke voorzieningen nog parallel functioneren, en welke veranderingen ten opzichte van de voorgaande situatie zijn gerealiseerd.
Bepaal de volgorde van de transitie
Bepaal daarna de meest logische volgorde van de transitiestappen, waarbij verschillende soorten afhankelijkheden in samenhang worden beoordeeld.
Gegevensafhankelijkheden bepalen vaak welke systemen eerst worden gerealiseerd: systemen die eigenaar zijn van gegevens of de bron van waarheid vormen, gaan doorgaans vóór systemen die deze gegevens gebruiken of verwerken.
Daarnaast tellen technische afhankelijkheden tussen systemen en integraties mee: sommige koppelingen of voorzieningen kunnen pas worden gerealiseerd nadat andere onderdelen beschikbaar zijn.
Ook risico's spelen een rol bij de volgorde van de implementatie. Onderdelen met een hoog technisch of organisatorisch risico kunnen bewust eerder worden gerealiseerd, zodat eventuele problemen tijdig zichtbaar worden en kunnen worden opgelost.
Tot slot telt de organisatorische realiteit mee: beschikbare capaciteit, contractuele verplichtingen, releasekalenders, wet- en regelgeving, en de veranderbereidheid van de organisatie. De technisch optimale volgorde is immers niet altijd de meest uitvoerbare.
Onderbouw de gekozen volgorde
Leg per overgang tussen twee transitiestaten vast waarom voor deze volgorde is gekozen. Beschrijf welke afhankelijkheden, risico's of organisatorische overwegingen daarbij de doorslag gaven. Zo ontstaat een navolgbare onderbouwing van de roadmap, en kunnen afwijkingen tijdens het project bewust worden beoordeeld en verantwoord.
Werk migraties gecontroleerd uit
Wanneer de roadmap een migratietraject bevat, wordt per migratiestap bepaald hoe de overgang plaatsvindt. Afhankelijk van de risico's en de aard van de oplossing kan worden gekozen voor een directe overgang, of voor een gefaseerde migratie waarbij oude en nieuwe voorzieningen tijdelijk naast elkaar functioneren. Leg daarbij expliciet vast wanneer systemen parallel blijven draaien, wanneer gegevens worden gemigreerd, en op welk moment de oude voorziening definitief buiten gebruik wordt gesteld.
Plan de introductie van standaardsoftware
Bij de implementatie van een standaardsoftwarepakket wordt onderscheid gemaakt tussen verschillende soorten integraties. Eerst komen de voorzieningen die nodig zijn om het pakket in gebruik te nemen, zoals authenticatie, autorisatie en de uitwisseling van stamgegevens. Daarna worden tijdelijke koppelingen ingericht waarmee bestaande systemen tijdens de overgang kunnen blijven functioneren. Pas wanneer het nieuwe systeem de rol van bronvoorziening heeft overgenomen, worden de definitieve integraties gerealiseerd en kunnen de tijdelijke koppelingen worden uitgefaseerd. Eventuele afwijkingen van de doelarchitectuur worden expliciet vastgelegd, met een motivatie en een einddatum.
Houd de roadmap op het juiste detailniveau
De roadmap beschrijft de architectuurtransitie op hoofdlijnen. Het detailniveau is voldoende om de transitiestappen, afhankelijkheden en belangrijkste risico's inzichtelijk te maken, maar bevat nog geen gedetailleerde technische ontwerpen. Verdere detaillering volgt in latere fasen van het project, zodra de betreffende transitiestaat wordt voorbereid.
Stem de roadmap af
Sluit de activiteit af door de roadmap af te stemmen met de opdrachtgever, de betrokken stakeholders, de Enterprise Architect en de project- of releaseplanning. Controleer daarbij of elke transitiestaat een stabiele en operationeel verantwoorde situatie oplevert, of de roadmap aansluit op de enterprise-architectuur, en of de gekozen volgorde uitvoerbaar en beheersbaar is. Na deze afstemming vormt de roadmap het uitgangspunt voor de verdere uitvoering van het project en de architectuurgovernance.
Acties
- Lezen Architectuurmodel Werkproduct
- Aanmaken Solution Roadmap & Transition States Werkproduct
Werkproducten
Voltooiingscriteria
- Opportunity Solution Needed
Rol
Rol die deze activiteit uitvoert.
Architectuureigenaar
De meest technisch ervaren persoon in het team (conform Disciplined Agile Delivery). Voert het solution-spoor uit binnen de door de Enterprise Archite…