in gesprek met Chris Beukers, Systeemspecialist bij ICU IT Services

Zo ik heb het gezegd! Met regelmaat hoor ik in discussies met collega’s of op allerlei internetfora ook het tegenovergestelde: “Dat kan niet op een mainframe!”. JA, het mainframe werkt technisch gezien fundamenteel anders. Dit benadrukte mijn collega Bobby ook al in zijn blog over Modern gebruik van het mainframe:

“Het mainframe is op cruciale details toch echt een ander beestje, denk aan big-endian architectuur, EBCDIC coded character set, UNIX compliant maar geen Linux distro.”

Anders … maar aangepast aan de standaarden van vandaag

Maar, dat iets anders is, betekent niet dat het minder kan of dat het moeilijker is. Het betekent alleen dat voordelen en eventuele nadelen zorgvuldig gewogen moeten worden.

Ben je belast met het onderhoud en beheer van bestaande toepassingen dan moet je je veelal aansluiten bij de manier waarop e.e.a. indertijd is bedacht en opgezet. Maar als je vandaag de dag een nieuw project begint, doe je dat toch met de standaarden van tegenwoordig. Dat betekent dat je binnen je manier van werken waarschijnlijk gebruik maakt van:

• Infrastructuur als code
• Pipelines
• Containers
• GIT
• Automatische testen
• etc.

De beperkende factor …

Als bepaalde onderdelen van je applicatie- en/of infrastructuurlandschap al jaren draaien en met andere uitgangspunten zijn opgezet, dan kan het een uitdaging zijn om te migreren naar deze nieuwe manier van werken. Dit kan enerzijds het geval zijn omdat projecten vroeger anders werden opgezet, ze misschien onduidelijk afgebakend waren, maar anderzijds vanwege een menselijke factor:

“Zo draait het al 30 jaar …”   “Zo doen we dat niet op het Mainframe  …. “ of “Deden we het vroeger dan verkeerd …”

In dit soort discussies zou de conclusie getrokken kunnen worden dat een ‘nieuwe manier’ van werken niet mogelijk is op een mainframe. Of dat een nieuwe manier ongewenst zou zijn op een mainframe.

Bij deze wil ik die fabel uit de wereld helpen: ALLES¹ kan op een mainframe!

Want laten we wel wezen: Een mainframe is in de basis maar gewoon een computer. Als iemand een oplossing kan bouwen of programmeren dan kan het op een mainframe draaien. We hebben tegenwoordig genoeg tools op het mainframe om moderne developmentstrategieën mogelijk te maken, waaronder:

• Ansible
• Python
• ZOWE
• GIT
• Z Container extensions

Ook de ‘oude’, gangbare mainframetechnologieën als CICS en COBOL zijn gewoon met de tijd meegegaan en kunnen bijvoorbeeld prima meedraaien in een “restAPI”-wereld.

Proces, tool, mens

Zoals zo vaak ligt deze discussie juist niet in de techniek maar ergens anders. Vaak is het zo dat een technisch product wordt vervangen door iets ‘moderns’ maar de manier van werken moet voor het gemak van migratie exact hetzelfde blijven. Dit maakt dat het nieuwe, moderne systeem dusdanig aangepast dient te worden dat het exact hetzelfde doet als het oude systeem. Waar zit dan je winst? Je hebt een duur product vervangen door een ander, hopelijk goedkoper product. Maar pluk je er nu ook echt de vruchten van en is het nu stabieler dan het vorige systeem? De kans is juist groot dat het totale werkproces op de achtergrond alleen maar complexer is geworden zonder dat je er een echt voordeel uit haalt.

Aandachtspunten

Sta je voor een moderniseringsproject of een nieuw (mainframe)softwaretraject houdt de onderstaande punten dan in gedachten:

1. Wees kritisch t.o.v. het proces en de manier van werken die je wilt moderniseren
   • Leer van het verleden maar laat dit geen belemmering zijn voor vooruitgang
   • Betrek andere disciplines om tunnelvisie te voorkomen bij je technische proces
2. Maak gebruik van POC-opstellingen om naast de technische opzet ook proceswijzigingen te verifiëren en vervolmaken
   • Maak gebruik van 2 of meerdere verschillende tools om wijzigingen te testen zodat je ook een goede afweging kan maken na de POC
   • Voldoen de bestaande tools niet, overweeg dan zelfbouw
   • Betrek alle stakeholders erbij: neem ze mee in je gedachteproces!!
   • Zoek sponsors voor met name de aanpassing van de manier van werken zodat je ook kunt laten zien waar de voordelen zitten.
3. Evalueer of je wijzigingen van techniek en manier van werken het gewenste effect hebben
   • Zo niet, fail fast
   • Zo ja, implementeer en migreer

Dus DevOps op het Mainframe

Natuurlijk is het bovenstaande van toepassing op alle migratie- en softwaremoderniseringstrajecten. Maar ik focus vooral op het mainframe. Juist het mainframe (of het nou Linux draait op een LinuxOne of z/OS op een z16) is een bijzonder platform met bijzondere eigenschappen die het geschikt maakt voor toepassingen met zeer hoge (non-functional) eisen op het gebied van stabiliteit, beschikbaarheid, performance en veiligheid. Toch hoeft dat absoluut niet te betekenen dat adoptie van een DevOps- of Scrumwerkwijze niet van toepassing kunnen zijn. Juist als ontwikkelaars en specialisten daar voor open staan, kunnen de tools ervoor gemaakt worden en werkwijzen worden aangepast. Dan is op een mainframe alles mogelijk!

¹   Oké misschien zijn grafische applicaties geen goed idee. Mocht je me het tegendeel alsnog willen bewijzen, ik kon nog geen DOOM port vinden voor z/OS… 😉

Deel dit bericht op LinkedIn