Heeft u ook nog oud ijzer staan? En ziet u tegen vervanging op omdat er nog tal van nuttige applicaties op draaien? Wees dan gerust: niet voor elk technisch probleem is een technische oplossing nodig. Alleen maatwerkprogrammeurs zullen balen.
Niet voor elk technisch probleem is een technische oplossing nodig. Een klant van mij had nog een mainframe staan. U weet wel, zo'n ding dat zalen vult en meer CO2-uitstoot genereert dan een P.C. Hooftstraat vol met SUV's. Daar wou hij vanaf. Het probleem was echter dat er nog een polisadministratie op draaide. Deze applicatie was geschreven in een obscure variant van Cobol die niet meer zo lang zou worden ondersteund. Los nog van de kosten van het mainframe, was het softwareonderhoud duur omdat daarvoor maar enkele schaarse specialisten beschikbaar waren in de markt. De omzet in deze levensverzekeringen nam ook niet toe, omdat het een verouderd product was.
Hoe kon deze applicatie worden omgezet naar een modernere programmeertaal, zodat men van het dure mainframe en de dure programmeurs afscheid kon nemen? Nu is het probleem met levensverzekeringen dat polissen erg lang lopen. Sommige polissen waren meer dan twintig jaar geleden verkocht, en de software moest precies bijhouden welke rechten en plichten nog van toepassing waren, terwijl de wetgeving regelmatig werd aangepast. Vandaar het dure onderhoud.
Zakelijk inzicht
In eerste instantie keken we naar de mogelijkheid van softwaremigratie. In India kon men de sourcecode wel laten omzetten naar een modernere programmeertaal. Dat kostte niet alleen wat, maar een van de openstaande vragen bleef hoe we nu zeker konden weten dat de vernieuwde software precies hetzelfde deed als de oude software.
Toen kwamen we op een geheel andere aanpak. Los het probleem niet op met techniek, maar aan de zakelijke kant. In plaats van de software te converteren tegen een serieus bedrag per polis, konden we in plaats daarvan de polissen converteren naar een vergelijkbaar product. De klanten kregen dan weliswaar iets andere voorwaarden, maar met het bespaarde geld kon dat verschil ruimschoots in het voordeel van de klant worden goedgemaakt. Iedereen blij, behalve natuurlijk de maatwerkprogrammeurs.
Geachte heer van Eijk,
De de door u geschetste oplossing is een zeer elegante maar verdient wel enkele kanttekeneningen.
Niet ieder proces laat zich eenvoudig omzetten naar een alternatief proces. Bovendien wil wil o.a. de belastingdienst graag zien dat u de geschiedenis 5 jaar kunt raadplegen.
Met de moderne compacte energiezuinige mainframes is het mogelijk meerdere klantomgevinging op een machine te consolideren en zodoende kosten te besparen.
Als dit bij een betrouwbare dienstverlener in een modern datacenter gebeurt kan dit enorme schaalvoordelen opleveren wat resulteert
in lage kosten en een verhoging servicegraad.
De dienstverlener heeft dan de tijd om de de gewenste expertise leveren om tot een verantwoorde migratie over te gaan.
Kortom, wanneer u uw it-geschiedenis kent weet u dat het delen van kennis en resources al decennia lang tot uitstekende oplossing in IT/mainframe-land leidt.
Peter van Eijk geeft in zijn colum van 25 april een oplossing voor een technisch probleem.
Ik heb bij zijn oplossing nog wel een paar opmerkingen.
Allereerst suggereert hij dat een mainframe meer energie verstookt dan de P.C. Hooftstraat vol met SUV’s, dat lijkt mij sterk overdreven. Oudere mainframes gebruikten inderdaad veel energie, maar die (kunnen) zijn bij de meeste bedrijven (worden) vervangen door moderne exemplaren die als “groen” kunnen worden beschouwd. Deze machines kunnen op gebied van energie en techniek de concurrentie met servers van andere partijen prima aan. Bovendien als er nog een mainframe staat die inderdaad zoveel ruimte inneemt als de heer van Eijk suggereert zal het een machine zijn met relatief weinig rekenkracht en kan door een modern “instap” mainframe relatief goedkoop worden vervangen.
Wat mijns inziens veel meer het kernpunt is of een bedrijf door wil blijven gaan op programmeertechnieken uit de jaren 60