Han opfandt microservices: Nu forudser han kæmpe skifte i finanssektoren

250 millioner linjer kode på en mainframe

James Lewis, der oprindelig er uddannet i astrofysik, hvor han lærte at kode i Fortran, har som en af arkitekterne bag microservices-begrebet ellers gjort sit for at ændre på it-tænkningen. 

I mange år har han været fortaler for principper om små uafhængige services, domæneopdelte teams og automatiseret deployment. Men mange organisationer står stadig tilbage med ældre og komplekse kernesystemer. 

“Jeg har været i en stor bank, hvor core banking-platformen bestod af 250 millioner linjer kode på en mainframe."

"I en anden virksomhed var der kun tre personer tilbage, der vidste, hvordan kernesystemet hang sammen – to af dem boede på plejehjem,” siger han.

James Lewis peger på, at der også har været en vis træthed i forhold til modernisering: Mange organisationer har gennem årene brugt titusindvis af timer og millioner på forandringsprojekter, der ikke nødvendigvis førte til de store gevinster.

Det skaber blot mere modstand og skepsis.

Gamechanger

Nu oplever han allerede, at der er begyndt at ske noget nyt i moderniseringsprojekterne. Nye AI-baserede analysemetoder og værktøjer kan give langt hurtigere indsigt i forretningslogik og systemstruktur.

"Vi har et værktøj, der læser din kodebase og visualiserer, hvordan begreber som ‘transaction ID’ bruges på tværs af systemet. Det giver dig et fundament, du kan handle på.”

En stor spansk bank, han arbejdede med, lykkedes med at migrere hele deres betalingsinfrastruktur fra mainframe til skyen.

"Det tog 18 måneder og krævede godkendelser fra myndigheder og compliance, men de gjorde det. Det viser, at det kan lade sig gøre” siger han.

Det kræver ifølge James Lewis, at man ikke kun tænker det som en teknisk øvelse.

Det handler om at forstå arkitekturen og systemerne så grundigt, at man kan lave forretningsmæssige afgrænsninger, hvor man løsriver og moderniserer lidt ad gangen. Det er her, hvor de nye AI-værktøjer især kan hjælpe.

“Kan du identificere, hvor betalingsmotoren begynder og slutter? Kan du skille den ud og flytte den? Det er sådan, man gør det – ét domæne ad gangen.”

Den virkelige flaskehals er ikke kode

Selvom teknologien tegner lovende, er det ikke et mirakelmiddel, der med et par trylleslag kan bygge et moderne it-landskab, pointerer James Lewis.

“Vi er ikke dér endnu, hvor man bare kan skrive et kravdokument og få færdig software ud i den anden ende. Og i hvert fald ikke i regulerede miljøer. Du kan ikke bare sige: ‘Det virker vist nok’.”

“Du har stadig arkitektur-review boards, projektstyringskomitéer, compliance-lag og kravspecifikationer. Selv hvis koden bliver skrevet på en time, tager hele forløbet stadig mange måneder.”

Ægte modernisering handler derfor ikke om teknologien, men om at ændre den måde, organisationen tænker forandring, risiko og samarbejde på, siger han.

Hans anbefaling er en struktur med små, tværfunktionelle teams, der er ansvarlige for hele domæner – og som har alle kompetencerne til at levere.

“Det er dét, der skal til for at få ting gjort.”

Men hvad med fremtiden for de mange udviklere og specialister i finanssektoren? Er der stadig brug for dem, hvis AI bliver endnu bedre til arkitektur og programmering?

“Hvis du havde spurgt mig for tre år siden, havde jeg helt bestemt sagt, at COBOL-folk havde en fremtid, for ingen andre kan læse det. Det har altid været en af de store barrierer for modernisering – at forstå, hvad de her systemer egentlig gør. Men den nye generation af værktøjer er virkelig gode til det.”

“De her værktøjer er kun så gode som de input og rammer, du giver dem. Erfarne udviklere kan få noget fantastisk ud af dem. Men de skal vide, hvordan god software ser ud.”