Er was eens ….
Zo beginnen sprookjes. Deze blog is geen sprookje. Deze blog gaat over harde werkelijkheid en over zware management besluiten.
Er was eens een software systeem. Dat software systeem deed het goed. Zo goed, niemand peinsde erover het te vervangen. Het was in Cobol geschreven. Geen dialect, gewoon puur en standaard Cobol. Onderhoud was schaars en zelden nodig. Eigenlijk was het een lief systeem dat nooit om aandacht vroeg.
Het systeem werd ouder en ouder. En de laatst overgebleven Cobol programmeur werd ouder en ouder. Die wilde met pensioen. En toen werd dat software systeem plots een management probleem.
Strategische systemen, daarvan is het kenmerk dat zij lang in productie blijven, soms meer dan tien of twintig jaar. Zo’n lange levensduur maakt het zinvol veel tijd te besteden aan het nadenken over requirements, en een gedegen ontwerp te maken. Flexibiliteit en aanpasbaarheid staan voorop. Niemand weet tenslotte hoe de toekomst zich ontwikkelt.
Voor de programmeertaal gelden dezelfde afwegingen. Cobol is decennia lang een betrouwbare taal gebleken, waarin van oudsher veel strategische systemen gebouwd zijn. Systemen met bewezen betrouwbaarheid en robuustheid.
Tegenwoordig hoor je niet meer van Cobol. Het is een vergeten taal. Wordt niet meer onderwezen. Zijn geen diploma’s voor. Als je wilt meetellen doe je Java, Python, Perl, C#, Ruby of een nog meer esoterische taal. Voor onbelangrijke en snel vervangbare apps, voor flitsende games, voor Internet of Things dingen en voor strategische systemen. Dat roept de vraag op: Zijn nieuwe strategische systemen dan wel net zo betrouwbaar en robuust als “20e-eeuwse legacy” toepassingen? Dat is een vraag waar ons topmanagement mee worstelt.
Voor we ingaan op deze, op zich interessante, vraag, er is een gegronde reden om afscheid te nemen van de steunpilaren van ons bedrijfsleven. Dat is niet omdat Cobol verouderd is, het is omdat de technologische omgeving verandert. Simpel gezegd, we zien steeds sneller steeds snellere ontwikkelingen op ons afkomen. Met traditionele programmeeraanpakken en met traditionele programmeertalen valt dat niet bij te benen.
Dat is de kern: strategische systemen moeten na verloop van jaren toch vervangen worden, hoe goed ze ook werken. Dat heeft niet te maken met de leeftijd van de programmeurs, niet met de toepassing, het heeft alles te maken met wat de maatschappij verwacht van ICT.
3D-printing, nu nog iets waarover de meeste mensen slechts lezen. Visionairs verwachten binnen 6 jaar toepassingen om producten thuis met een 3D-printer af te leveren, als het dan al niet met een drone gebeurt. Want dat wordt over vier jaar verwacht. Zo onvoorspelbaar is het. Apparatuur hangt aan Internet; grasmaaien zet je vanuit de autostoel aan, koffie wordt gezet als je de auto parkeert. De voordeur gaat open als je intelligente huisbel je gezicht herkent en met je mobiel contact maakt.
Leuk of niet, dit is de wereld waarin wij gaan leven. Een wereld waarin altijd en overal software systemen om ons heen zijn. In zo’n wereld past een strategisch, voor één groep gebruikers bedoeld, gecentraliseerd systeem niet. De toekomst is aan gedistribueerde systemen die geïntegreerde diensten leveren aan een breed publiek.
De vraag waar topmanagement mee worstelt is breder geworden. Het is niet alleen of hun komende systeem flexibel, betrouwbaar en robuust genoeg is. De vraag is ook niet of de programmeertaal geschikt is, van deze tijd. En zelfs niet of er programmeurs voor te vinden zijn. De vraag is hoe een bestaand strategisch systeem, ongeacht of dat een Cobol- of Java systeem is, gemigreerd kan worden naar de toekomst.
Wat maakt een systeem migreerbaar?
De belangrijkste asset is: informatie over het strategische systeem. Wat doet het, welk probleem lost het op, hoe doet het dat? Zijn er randvoorwaarden waaraan voldaan moet worden?
Als de documentatie daar geen antwoord op geeft helpt een onderzoek aan de source code. Met source code onderzoek kan vrij snel nagegaan worden of een strategisch systeem nog een tijd mee kan. De condities waaronder dat zo is zijn dan bekend bij topmanagement en zij kan een gedegen beslissing nemen.
De beslissing over het lot van een strategisch systeem stijgt uit boven het mondaine: krijgen we een betrouwbaar genoeg systeem. Natuurlijk, dat blijft ontzettend belangrijk en daar kan tijdens de realisatie op getoetst worden. Belangrijker kwestie zal zijn hoe de toekomstige mogelijkheden verwezenlijkt kunnen worden – in een veranderende wereld kan niet meer alles op voorhand besloten worden. De kracht van een software architectuur helpt die zekerheid in te bouwen, Dat het nieuwe strategische systeem voldoend aanpasbaar is en geschikt om langdurig diensten te blijven leveren waar de klanten of de maatschappij om vragen.
Management ziet natuurlijk ook de kostenkant. Onderzoeken, architectuur en begeleiding van de totstandkoming vergen middelen die niet voor andere doeleinden beschikbaar komen. Dat maakt het lastig.
Een oplossing voor het middelenprobleem is om een strategisch systeem te beoordelen vanuit het perspectief Total Cost of Ownership, TCO. Met TCO kan topmanagement de afweging tussen initiële investering (CAPEX) en operationele kosten (OPEX) op een transparante en inzichtelijke manier maken.
In een volgende blog wil ik ingaan op het gebruik van de methodiek van TCO bij strategische systemen.