Verouderde systemen: van tikkende tijdbommen naar digitale transformatie

Als gegevensverwerkende organisatie heb je te maken met verouderde registratieve systemen. Als operationeel manager, marketeer en commercieel verantwoordelijke heb je daar last van. Het is hierdoor namelijk lastig om wijzigingen in producten of processen door te kunnen voeren. Bijvoorbeeld bij productintroducties of wijzigingen in wet- en regelgeving. Organisaties maken tegelijkertijd een digitale transformatie door. Hoe ga je in deze transformatie om met de verouderde systemen en wat zijn de alternatieven?

ICT-managers hebben ook last van deze legacy-applicaties. Ze houden de kosten in stand die in de loop van de tijd steeds verder toenemen. Het gaat hier om informatiesystemen die in de vorige eeuw zijn gebouwd, in een programmeertaal waar nu nog nauwelijks ICT’ers voor te vinden zijn. Degenen die ooit de business rules hebben aangegeven, zijn vaak niet meer binnen de organisatie werkzaam.

Alternatieven in de digitale transformatie

Tegelijk zijn organisaties volop bezig met de digitale transformatie. Klanten verwachten dat je op ieder tijdstip online bereikbaar bent, met informatie op maat en de mogelijkheid om direct zaken te doen.

Tot nu waren de alternatieven als volgt. Of je zet een nieuw systeem naast het bestaande, met alle nadelen voor kosten en doorlooptijd van dien. Of je blijft gebonden aan de beperkingen van de oude systemen. Dat is nu niet meer nodig. Met moderne applicatieplatformen wordt het mogelijk om het bestaande systeem in korte tijd en tegen lage kosten realtime naar online en mobiel over te zetten.

Lastige onderhoudbaarheid van verouderde systemen

Voorbeelden van dit soort verouderde systemen zijn de polis- en claimadministraties van verzekeraars in Cobol, Uniface of AIX. Of denk aan casemanagementsystemen in Lotus Notes, Sharepoint of ontwikkelomgevingen van regionale leveranciers. Vaak is het niet zozeer het probleem dat de platformversie verouderd is, maar veel meer dat de onderhoudbaarheid door de destijds gekozen opzet erg lastig is.

De systemen zijn lastig aan te passen aan veranderende wet- en regelgeving en de nieuwe wensen van klanten en gebruikers. Vaak zie je dan dat nieuwe producten en diensten in andere informatiesystemen worden ondergebracht, waardoor het totale applicatielandschap steeds complexer wordt. En het bovendien steeds meer geld en aandacht kost om al die verouderde informatiesystemen in stand te houden, te testen en door te ontwikkelen.

Vaak zie je dan dat nieuwe producten en diensten in andere informatiesystemen worden ondergebracht, waardoor het totale applicatielandschap steeds complexer wordt.

De risicos om verouderde informatiesystemen in stand te houden nemen ook steeds verder toe. Je wordt als organisatie afhankelijker van individuen, specifieke licenties en infrastructuren. Om over de security-risico’s van verouderde informatiesystemen nog maar niet te spreken. Je zit dan als organisatie op een tikkende tijdbom.

Vaak wil je zo’n verouderd systemen best ontmantelen, maar het voelt toch een beetje als de rommel van je voorgangers opruimen. Dat kost je dan wel behoorlijk wat moeite en levert je het je ook wel wat op?

Waarom opheffen?

De belangrijkste redenen om legacy-applicaties op te heffen zijn:

1. Het in stand houden van de legacy-systemen is veel te duur

Als de systemen verouderen, worden de kosten voor de inhuur van steeds schaarser wordende specialisten en de verouderde eigen infrastructuur steeds hoger. Zo maakt cloudhosting het vele malen goedkoper om van een professionele schaalbare infrastructuur gebruik te kunnen maken.

2. Het aanpassen van de oude systemen gaat véél te langzaam

In de verouderde ontwikkeltalen duurt het vaak maanden voordat een wijziging is gerealiseerd. Dat is niet meer van deze tijd. Aanpassingen moeten binnen enkele dagen gerealiseerd kunnen zijn. Systemen moeten bovendien standaard schaalbaar zijn, zodat ze ook gemakkelijk met toenemende piekbelasting om kunnen gaan.

3. De oude systemen zijn te groot en je kunt ze niet goed koppelen

Veel legacy-applicaties zijn gebouwd met één hoofddoel, zoals polisadministratie, klantsysteem of financiële administratie. Het aanpassen en koppelen van dergelijke systemen kost veel moeite omdat ze daar oorspronkelijk niet voor zijn bedoeld. Modernere applicatieplatformen zijn juist opgezet vanuit samenwerkende kleinere bouwstenen die standaard als microservices kunnen worden gekoppeld aan andere systemen.

4. De oude systemen zijn een hindernis is de weg naar volledige digitalisering

Sinds de huidige legacy-applicaties werden ontwikkeld, is er een grote ontwikkeling in technologie en bedrijfsprocessen geweest. Productontwikkeling, marketing, sales en fulfillment zijn enorm veel efficiënter geworden.

Vaak wil je als manager zo’n verouderd systemen wel ontmantelen, als dat maar niet zoveel moeite zou kosten. Dat kan ook anders: je kunt de verouderde systemen opheffen en er meteen een pareltje voor je digitaliseringsstrategie van maken. Als je dat dan ook nog eens met minder tijd en kosten kan en de selfservice-mogelijkheden voor klanten verbetert, krijg je de handen er in je organisatie al snel voor op elkaar.

Moderne platformen zetten digitale transformatie in gang

Nieuwe low code-platforms passen prima in die strategie. Deze maken het mogelijk om de business rules modelmatig op te nemen, met een korte time to market. Bovendien bieden deze platforms ook standaard connectiviteit met andere informatiesystemen. De oude legacy-systemen transformeer je dan naar systemen die 24/7 beschikbaar zijn. Hiervan zijn de onderdelen waarvoor je dat wil direct voor klanten beschikbaar. Denk aan selfservice functies voor op de mobiele telefoon.

Alternatieven low code-platforms zijn het vervangen van de systemen door standaardpakketten. Dit zie je bijvoorbeeld bij webshops in het kader van online verkoop. Ook kan er gekeken worden of het mogelijk is het bestaande systeem en de processen te outsourcen. Bijvoorbeeld in de hypothekenadministraties is dit een mogelijkheid.

Met moderne low code-platformen verbetert de ontwikkelsnelheid en aanpasbaarheid van informatiesystemen enorm. Business rules worden in de modelleringlaag ondergebracht. Ze zijn geen onderdeel van de programmacode zoals bij de legacy-applicaties het geval was.

Daardoor blijft het systeem aanpasbaar en onderhoudbaar. Je wordt voor het onderhoud van de productregels niet meer afhankelijk van ICT’ers die de code kunnen begrijpen.

Het nieuwe systeem kan naast online ook direct op een native manier op mobiele devices gebruikt kan worden. Niet alleen als website op de telefoon, maar je kunt dan ook echt gebruikmaken van alle mogelijkheden van dat device, zoals bijvoorbeeld de camera.

Door op deze manier te migreren maak je ook direct de slag naar microservices. Dit geeft invulling aan de trend dat je steeds vaker services aan business partners ter beschikking stelt, in plaats van volledige applicaties. Door op deze manier te migreren maak je dus meteen het pad vrij voor de volledige digitale transformatie. Je zorgt ervoor dat je als organisatie kunt voldoen aan de eisen van de 24-uurseconomie. Hierin verwachten klanten dat je op ieder tijdstip multichannel bereikbaar bent en informatie op maat kunt bieden.

Hoe gaat zo’n migratie in zijn werk?

In het geval je het bestaande systeem en proces wil outsourcen, zul je je product en proces deels moeten aanpassen aan de mogelijkheden van de outsourcingspartner. Ook in het geval je voor de vervanging door een standaardpakket kiest, zul je deels concessies moeten doen aan je eigen product- of dienstkenmerken.

Als je kiest voor herbouw, is het aan te bevelen om eerst na te gaan welk deel van de programmacode kan worden hergebruikt. Je kunt dan denken aan herbruikbare processen, business rules, formulieren en rapportages. Maar ook aan de documentatie en testware die nog beschikbaar is en nog kan worden gebruikt. Ook is het in dit voortraject belangrijk om na te gaan hoe de gegevens uit het bestaande systeem gehaald kunnen worden.

Vervolgens bepaal je hoe je wil dat het systeem in de nieuwe situatie opgebouwd is. Bijvoorbeeld welke functies je op een native manier op mobiele devices beschikbaar wil stellen. En waarvoor je voortaan wil koppelen met externe services.

De realisatie en uitrol van de nieuwe situatie kan vervolgens in sprints plaatsvinden. Of het nu om outsourcing, een pakketvervanging of herbouw naar een modern platform gaat. Je kunt dan geprioriteerd werken, direct feedback geven en in zo’n kort mogelijke tijd tot een te gebruiken systeemversie komen. Hiermee zullen de voordelen van de digitale transformatie zo snel mogelijk voor klanten en gebruikers ter beschikking komen.

Ik ben benieuwd, hoe ontmantel jij je tikkende tijdbommen?