Formål
Formålet med Gap analysen er at analysere forskellene på den nuværende arkitektur (”as-is”) og den fremtidige arkitektur, (”to-be”), for derved at påbegynde planlægningen af denne migrering.
Input
Den nuværende og fremtidige arkitektur, som defineret i
- C1. Informationsarkitektur, C2. Applikationsarkitektur, C3. Servicearkitektur og C4. Teknologiarkitektur
- A2. EA governance strategi
- D1. Restriktioner, D2. Muligheder
Output
Output er Gap analyse (D3.1).
For hver at de fire hovedområder i den teknologiske del af arkitekturen – information, applikation, service og teknologi – beskrives hvilke forskelle, der er i det nuværende og det fremtidige; og hvordan man – i store træk – kunne tænke sig at komme fra ”as-is” til ”to-be”. Der vil typisk være flere måder at lukke gap’et på, og her er det vigtigt med en grundig analyse af fordele og ulemper af hver af disse, samt en klar anbefaling.
Metode
For hver at de fire hovedområder i den teknologiske del af arkitekturen – information, applikation, service og teknologi – skal man analysere forskellen på den nuværende og den fremtidige arkitektur. Denne analyse kræver ofte en lang række arkitekter og tekniske eksperter, og en egentlig metode er svær at skitsere.
Det er vigtigt at undersøge forskellige måder at komme fra ”as-is” til ”to-be”, og at analysere fordele og ulemper ved disse. Typisk vil der være:
- ”Big bang”. Eksempel: Man implementerer et helt nyt system og fjerner mainframen.
- ”Evolution”. Eksempel: Man migrerer gradvist applikationerne 1:1 fra mainframen til decentrale systemer. Det vil sige at applikationerne overføres til en ny platform, men fortsætter enkeltvis som de var, blot på ny teknologi.
- Komponentopdeling. Eksempel: Man søger at komponentopdele de eksisterende mainframe applikationer. Kun derefter begynder man at gå over til at lade mainframe-versionen af en komponent erstattes af en tilsvarende web service.
- Co-eksistens. Eksempel: Man migrerer visse mainframe applikationer, men lader andre leve.
Gode råd
Gap analysen kan med fordel overveje hvilke afhængigheder der er i forskellene mellem ”as-is” og ”to-be”. Altså eksempelvis om en evolution overhovedet er mulig, eller om man står med en ”brændende platform”, hvor kun data kan videreføres, mens applikationerne med fordel kan skrottes, frem for at udvikles.