Software platform migratie patronen

 
03 januari 2009

Sogyo heeft inmiddels over de jaren diverse migratietrajecten begeleid voor klanten die zelf software bouwen. Denk hierbij aan migratie van applicaties ontwikkeld in Delphi, Visual Basic (6 of eerder) of Microsoft Access (in combinatie met VBA) naar een modern ontwikkelplatform als Microsoft .NET of een Java gebaseerd platform.

Er wordt vaak gekozen om op een bepaald moment een applicatie niet verder uit te breiden op het huidige platform maar te beginnen met een volledig nieuwe versie op het nieuwe platform. Dit soort trajecten neemt vaak jaren in beslag en kan voor softwareleveranciers de nekslag betekenen. De nieuwe versie van de software kan pas uitgeleverd worden als alle functionaliteit uit de oude applicatie omgezet is in de nieuwe. Daarnaast heeft de applicatie een tijdlang stilgestaan: nieuwe features zijn waarschijnlijk maar minimaal meegenomen.

Wij adviseren vaak een meer stapsgewijze benadering voor migratie. Vaak is er – ook in de systemen gebouwd op ‘verouderde’ platformen – wel degelijk nagedacht over opdeling van de software in componenten. Als deze componenten minder evident zijn zou je kunnen denken aan de verschillende schermen waar een applicatie uit bestaat.

Onderstaande figuur illustreert deze identificatie van de bestaande onderdelen in stap 1 en 2. Stap 1 is vaak al erg snel uit te voeren; de fysieke structuur van de applicatie is vaak evident. De logische structuur binnen de fysieke componenten die in stap 2 gezocht wordt is vaak een moeilijkere taak. De praktijk wijst echter uit dat deze componenten eigenlijk altijd wel in een bepaalde verschijningsvorm aanwezig zijn.

Als de tweede stap genomen is en de bestaande logische onderdelen zijn gekend kan er gekeken worden naar een roadmap voor de te nemen stappen om de componenten te gaan vervangen. Er moet hierbij vooraf wel een aantal keuzes gemaakt worden: bijvoorbeeld of (in het bovenstaande voorbeeld) de client tier gehost gaat worden in een runtime op basis van het oude platform of op basis van het nieuwe platform. Zo heb je er nog een aantal meer.
Vervolgens kan gekeken worden wat er met de onderkende componenten in welke iteratieslag gaat gebeuren. Zo kan je er bijvoorbeeld voor kiezen om bepaalde componenten te laten voor wat ze zijn of bepaalde componenten uit het oude platform te ‘wrappen’ in een laag zodat de logica beschikbaar is voor componenten gebouwd in het nieuwe platform (bijvoorbeeld het wrappen van een Win32 DLL in een .NET DLL). Ook kan er gekozen worden voor het fysiek omgooien van de structuur: bijvoorbeeld het bouwen van een component die service gebaseerd opgezet is en bepaalde functionaliteit dus naar een fysiek andere tier brengen. Het hier gegeven voorbeeld suggereert opdeling van de server tier uit de oude situatie in twee verschillende tiers.

Daarnaast kan tijdens het migratietraject bij een dergelijke strategie ook uitbreiding van de applicatie plaatsvinden. Dit betekent dat voor de klantenkring van de betreffende applicatie er wel degelijk gewoon doorontwikkeld wordt tijdens het migratietraject.

Tot slot som ik nog even een aantal patronen op (immers, de titel belooft wat) die we inmiddels tegen zijn gekomen (deze lijst is nog lang niet compleet):

– Database level koppeling
– Legacy component wrapping (code component)
– Legacy component wrapping (service component)
– Dotnet component hosting
– XML Data exchange
– Batch based integratie (niet real-time)
– Web service consuming
– Stored Procedure migratie (vanaf en naartoe)

Zo zie je dat er een aantal verschillende technieken zijn om een migratie in te richten. Uiteraard veel afhankelijk van het oorspronkelijke platform en de tools die daarvoor beschikbaar zijn.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development

Tags: ,