Applicatie moderniseren: wat is de juiste aanpak?

Publicatiedatum: afbeelding bij

Eerder bespraken we waarom het cruciaal is verouderde bedrijfsapplicaties aan te pakken. Dit helpt uw organisatie flexibeler, onafhankelijker en meer schaalbaar te worden. Moderniseren is hierbij vaak aantrekkelijker dan vervangen. Maar hoe pakt u zo’n modernisering nu precies aan? In deze blog vertellen we op basis van onze ervaring welke transities er zijn en waarmee u allemaal rekening moet houden.

Soorten transities: welke aanpak past bij uw organisatie?

Allereerst kunt u ervoor kiezen om de nieuwe applicatie naast het oude systeem te creëren. Deze aanpak is minder complex en daardoor minder tijdrovend. Het risico: het kan lang duren voordat het nieuwe systeem “af” is waardoor de aandacht vaak verloren gaat. Ook duurt het lang voordat een organisatie kan profiteren van de nieuwe business waarde. Daarnaast zal de release wel een stuk ingrijpender zijn (big bang) dan een geleidelijke overgang.

Een alternatief is een meer gefaseerde aanpak, waarbij u telkens stukjes uit het huidige systeem haalt om deze naar een nieuwe architectuur om te zetten. Dit kunnen complexe ingrepen zijn waarbij de continuïteit gewaarborgd moet blijven. De overgang is daarentegen geleidelijk en er kan al snel geprofiteerd worden van nieuwe business waarde. Prioritering vind plaats op basis van business waarde en onderdelen die niet (meer) gebruikt worden zullen dus niet over hoeven.

Het is ook mogelijk om naast uw monolithische systeem te bouwen aan nieuwe functionaliteit op basis van een nieuwe architectuur. Zo werkt u eigenlijk aan een soort Proof of Concept. Het nadeel is dat u het probleem hiermee niet verhelpt: de basis van uw applicatie blijft verouderd en niet-wendbaar. Deze aanpak is daarom geschikter als voorbereiding op een van de bovenstaande transitievormen.

Soepele transitie: de belangrijkste aandachtspunten op een rij

Voor welke transitie u ook kiest, het is altijd belangrijk om rekening te houden met bepaalde elementen. Wij zetten er vijf voor u op een rij:

  • Trek grenzen om domeinen af te bakenen. In eerste instantie kunt u uw huidige applicatie opdelen in grote blokken, die u in een volgende stap eventueel kunt opsplitsen in kleinere blokken. Stel de grootste pijnpunten vast en start met die onderdelen die de meeste business waarde bevatten.
  • Werk met roulerende teams. Daarmee voorkomt u dat het ene team door-ontwikkelt op oude applicatie terwijl het andere altijd met de nieuwe onderdelen werkt. Zo raakt niemand gefrustreerd en maakt iedereen kennis met de nieuwe technologie.
  • Bedenk hoe u de verschillende applicatieonderdelen met elkaar laat communiceren. Wat steeds meer voorkomt is asynchrone communicatie. Dit betekent dat er meer wordt losgekoppeld, zodat u diverse services tegelijk kunt verlenen. Zorg hierbij wel voor een betrouwbare en robuuste afhandeling van foutsituaties.
  • Bepaal hoe u omgaat met database en opslag. Als u kiest voor een moderne architectuur gebaseerd op Microservices dient u aandacht te besteden aan database en opslag. Microservices hebben hun eigen opslag, waardoor ze geheel onafhankelijk kunnen opereren. Tijdens een transitie kan dit echter lastig zijn, omdat u ook nog (deels) met een monolithisch systeem werkt. Data synchronisatie zou in dat geval een tijdelijke oplossing zijn om beide systemen in de lucht te houden.
  • Pas DevOps technieken toe zodat DevOps processen worden geautomatiseerd en u meer tijd kunt besteden aan de transitie van uw applicatie.

Profiel Delta-N

Delta-N

Innovatief Onderwijs mogelijk maken via de inzet van moderne technologie. Dat is waar Delta-N voor staat. Wij zijn een Microsoft specialist met ruime ervaring binnen het onderwijs. Wij zorgen dat ICT oplossingen zoals Office 365 snel en vakkundig geïmplementeerd worden, zodat uw onderwijsinstelling de mogelijkheden optimaal kan benutten.

Profiel Delta-N ›