Debatt

Banker behöver omvärdera sina föreställningar om risker

Bankerna har långt kvar när det gäller att bidra till communityn om öppen källkod. Det är synd, för det finns väldigt mycket för dem att hämta om de tar det steget, skriver Fredrick Ericson på Red Hat.

Uppdaterad 2020-07-24
Publicerad 2020-07-21

Öppen källkod har gjort ett stort avtryck inom bank- och finansvärlden. I en färsk undersökning bland IT-chefer i branschen svarar 93 procent att de mjukvara byggd på öppen källkod är avgörande för deras organisation. 

Sättet öppen källkods-lösningar utvecklas på, med en global ”informell” utvecklingsavdelning med många tusen deltagare där många arbetar ideellt, säkerställer att öppen källkod faktiskt idag betraktas som säkrare än inlåsta, proprietära system. Det leder till att eventuella fel och säkerhetsluckor både kan upptäckas, hanteras öppet och rättas till i förväg, medan proprietära system kan ha svagheter som tar lång tid att upptäcka, inte är kända för kunden, och tar lång tid att rätta till.

Att utvecklingstakten också är snabbare och att förändrade behov från användarna fångas upp och förverkligas snabbare är också en självklar fördel.

Att bidra till communityn innebär att banken får tillgång till de idéer och den resursstyrka som de tusentals utvecklare som bidrar till de olika öppen källkodsprojekten sitter inne på. Företaget bidrar med sina egna utvecklares tid och resurser och kanske går de in och stöttar projekt med exempelvis pengar, men de får möjlighet att dra nytta av resultatet från flera hundra utvecklares insatser på den aktuella koden. 

Genom att inte bara ta del av, utan även bidra till, öppen källkodsprojekten får bankerna möjlighet att vara med och påverka hur projektet utvecklas. På sistone har jag exempelvis sett en stor spansk bank bidra med utvecklingsresurser i ett existerande middleware-projekt och ta en aktiv roll i styrningen av projektet. När mjukvaran blivit testad och säkrad av deras samarbetspartner kan de driftsätta den i sina egna system. Med en traditionell leverantör hade de varit helt utlämnade till leverantörens goda vilja att implementera liknande förändringar – eller, om man ska vara krass, sin egen förmåga att betala det pris som leverantören sätter på att göra det.

Jag ser framförallt tre konkreta sätt som banker och andra bolag i finansbranschen kan stärka sin position i communityn, bli bättre på att bidra och därigenom få tillgång till de vinster jag gått igenom här.

Det första är kanske det mest traditionella – de kan bidra med ekonomiska resurser. Till exempel genom att anställa en community manager på heltid, sponsra ett event, eller en utvecklar-meetup. För organisationer som inte har möjlighet att avvara kompetenta utvecklare, som ju är en bristvara i de flesta branscher, kan det här vara ett utmärkt sätt att bidra. Det är också ett utmärkt sätt för dem att stärka sin position för framtida rekryteringar.

För organisationer som har kompetens internt och möjlighet att bidra med utvecklartid till projekten är det naturligtvis det enklaste steget. Men banker kan också bidra med värdefullt ledarskap och ovärderlig branschkunskap för att exempelvis ta en aktiv roll i att kvalitetssäkra den kod som produceras eller hjälpa till att hålla uppe tempot i utvecklingen genom att ge kontinuerlig återkoppling och uppmuntran.

Men om de potentiella fördelarna är så stora, och de faktiska insatserna som skulle krävas inte är särskilt stora – hur kommer det sig att bankerna inte flockas för att ta en mer aktiv roll i utvecklarcommunityn? Ofta handlar det om att de omvärdera sina föreställningar om de risker det skulle kunna innebära. För en bank, verksam i en hårt konkurrensutsatt bransch, kan det framstå som konkurrensmässigt självmord att låta sina egna utvecklare bidra till något som även konkurrenterna kan få möjlighet att ta del av.

I verkligheten är det ofta i det yttre laget – det som kunderna interagerar med – som de största möjligheterna att sticka ut finns. Om den underliggande plattformen bygger på välfungerande, säkra öppna källkodslösningar som Red Hat Open Shift eller Kubernetes spelar mindre roll. En annan faktor är att det tar väldigt lång tid att utveckla applikationer internt – inte sällan handlar det om flera år från idé till produktionsfärdig kod.

Att bidra till öppen källkods-communityn blir alltså helt enkelt ett sätt att säkerställa en snabbare innovationshastighet – på ett säkert sätt – och få både nya tjänster och nöjdare slutkunder som konkurrensfördel. 

Fredrick Ericsson
Nordenchef, Red Hat
 

Platsannonser