En leverandør av stormaskin-teknologi (eller mainframe) ryddet selv unna teknisk gjeld, og hjelper nå andre med å modernisere stormaskin-systemer. Les om erfaringene og gode råd.
Når gamle systemer blir nevnt i danske Version2s artikkelserie om modernisering eller nyutvikling, nevnes stormaskiner ofte som eksempel på gammel teknologi.
Stormaskinen vet ikke at den er død
For eksempel da sjefsarkitekt Peter Greifenstein fra det danske Rigspolitiet fortalte om hvordan politiet forholder seg til modernisering kontra nyutvikling, blant annet basert på erfaringene fra politiets administrasjonssystemer Polsas og Polsag.
«Dette kan være gammel teknologi, noe som gjør det vanskelig å få det vedlikeholdt om 20 år, for eksempel stormaskin-teknologi», sa Peter Greifenstein blant annet.
Dette fikk en del lesere til å kommentere.
Kunnskap forsvinner
For eksempel Morten Bøgh, som skrev:
«Vi mangler en god forklaring på at «Stormaskinteknologi» neppe kan vedlikeholdes om 20 år … Er det «de unge menneskene» som i dag er litt kresne på hva de vil beskjeftige seg med; har de om 20 år blitt helt umulige? Er det de kritiske massene av stormaskiner, som om 20 år har nådd et lavmål hvor kunnskap om systemet vil være i ferd med å forsvinne?»
Morten Bøgh stiller også spørsmålstegn ved premissene om stormaskin-teknologi; at den er gammel:
«Det andre forklaringsproblemet er den rutinemessige påstanden om at en stormaskin er identisk med «gammel teknologi». Selve maskinvaren i en stormaskin er vanligvis ganske ny».
Eller som Version2-leseren Ditlev Petersen elegant og spydig oppsummerer:
«Stormaskiner døde også på 90-tallet, de oppdaget det bare ikke. De dør igjen i dag. Og summer fremdeles».
En smidig utvikling
Forsvaret for de trofaste stormaskinene, som for eksempel håndterer mesteparten av transaksjonene i den finansielle sektoren, støttes av CEO for Compuware, Chris O'Malley.
Det er kanskje ikke overraskende, siden Compuware lever av å selge programvare til stormaskin-installasjoner. Men han har en rekke interessante betraktninger som baserer seg på Compuwares egen modernisering av interne systemer, bekjempelse av teknisk gjeld og hvordan man kan gjøre «de helt umulige» 2000-tallsfolkene interesserte i stormaskin-utvikling.
– Da jeg begynte hos Compuware for 5 år siden, hadde vi en prosjektmodell basert på fossefallsmodellen, så vi innførte smidig utvikling og en devops-filosofi for å få en mer smidig organisasjon, forteller Chris O'Malley under et kort besøk i Danmark.
Eclipse
Denne endringen koblet sammen med bruk av et utviklingsmiljø basert på Eclipse, har gjort Compuware mer interessant som arbeidssted for unge utviklere – til tross for at det dreier seg om stormaskin-programvare.
– Hvis du ikke endrer fra fossefallsmodellen og ikke gir dem devops-verktøy, men bruker et utviklingsmiljø som ligner noe som NASA brukte i 1965, blir det vanskelig å tiltrekke seg dem.
–Hvis du har utviklingsverktøy basert på Eclipse, gir du dem et utviklingsmiljø som den nye generasjonen ønsker, sier Chris O'Malley med henvisning til Compuwares Eclipse-baserte Topaz-utviklingsmiljø.
– Hvis du titter over skulderen deres, skjønner du ikke at de jobber på en stormaskin, sier Chris O'Malley, som opplyser at 40% av utviklerne i Compuware er i 20-årene.
50 prosent til teknisk gjeld
Før omstillingen til en agil utviklingsorganisasjon var det et etterslep i form av en massiv teknisk gjeld i Compuwares kildekode som måtte reduseres.
– I Compuware var det så mye teknisk gjeld at vi satte av mer enn 50 prosent av tiden til å rydde opp i et kvartal, forteller Chris O'Malley.
Han innser at omkring 20 prosent av koden var årsak til 90 prosent av problemene, noe som selvfølgelig reiser spørsmålet om hvordan man identifiserer disse viktige 20 prosentene av koden.
Compuware har nylig annonsert at det kommer maskinlæring til zAdviser-verktøyet, slik at verktøyet kan identifisere kodeområder som er problematiske. Men hvis man introduserer agile teknikker som Continuous Improvement med god feedback, kommer man også langt.
Problemene
– «Scrum masters» og «product owners» blir raskt oppmerksomme på hvilke deler av koden som er problematiske og gir problemer, sier Chris O'Malley, som også framhever den agile metoden som en metode for å få involvert ledelsen.
– Det kan være vanskelig for dem å forstå hvorfor det må brukes tid på gammel kode. Den agile metoden er med på å gjøre ledelsen mer oppmerksom på det når de er involverte som product owners, og ser problemene daglig, sier han, selv om han erkjenner at det kan være vanskelig å få toppledelsen involvert hos kundene.
– Det er ikke alltid at toppledelsen, som CEO og CFO, forstår at bedriften bør følge agile metoder og devops-filosofien, sier Chris O'Malley. Men han har et godt råd.
Hvis man ser på stormaskin-systemene som vedlikehold, og har en backlog fylt med utbedring av defekter, er det vanskelig å få ledelsens interesse. Hvis man derimot snakker om nye egenskaper (features), så er ledelsen mye mer fokusert på å skape framdrift – og man vil indirekte kvitte seg med den tekniske gjelden.
– Teknisk gjeld forhindrer en god flyt. Hvis det er fokus på nye egenskaper, vil det også automatisk bli et fokus på å sikre framdrift i utviklingen, slik at egenskaper kan bli utviklet raskere. Derfor blir ledelsen engasjert i å redusere den tekniske gjelden, er rådet fra Chris O'Malley.
Artikkelen er levert av vår samarbeidspartner Version2.dk, en del av Teknologiens Mediehus.
