At få sammensat bank til at fungere

Da jeg først startede min karriere inden for bankteknologi i 80'erne, arbejdede jeg oprindeligt med mainframes.

Dengang havde vi teams af "hovedkontorbrugere", der specificerede vores krav. Disse var mellemmænd, der repræsenterede de faktiske brugere af systemet. Vi havde ingen direkte kontakt med de faktiske brugere.

Et par år senere ville banken prøve det, man i dag ville kalde agile, men dengang var Rapid Application Development. Målet var at fremskynde, hvordan vi leverede vores løsninger. Vi var de første inden for IT, der var bevæbnet med bærbare computere og endda mobiltelefoner. Vi blev taget ud af IT-kontoret og fik et kontor i en af ​​forretningsenhederne.

Samtidig fik vi lov til at arbejde hjemmefra, eller hvor vi nu følte, at vi kunne være produktive. Min tidsplan var typisk at stå op kl. 6 og kode til kl. 2, så pause for at spise frokost og en eftermiddagskip. Jeg var tilbage ved mit skrivebord fra omkring kl. 6/7 og ville typisk kode indtil midnat. Dette virkede for mig.

Bortset fra dette var den største ændring faktisk at få krav fra slutbrugere i filialer. Dette gjorde en kæmpe forskel for at få løsningens anvendelighed og funktioner rigtigt.

Spol 30 år frem, og dette er normen nu. I løbet af de sidste 30 år har vi set en stigende integration af erhvervsbrugere og IT. Selv softwareudbydere har bevæget sig hen imod en model, hvor kunderne er dybt involveret i nye produkter.

Men generelt for forretningsspecifikke krav dokumenterer en analytiker dem, og en udvikler skriver koden. Dette har været modellen i årtier.

Der har været forsøg på at ændre dette, for at give forretningsbrugere mulighed for at skrive deres egne løsninger ved hjælp af lav-kode eller ingen-kode løsninger. Faktisk var mit sidste firma, edgeIPK, en pioner inden for at skabe en kodefri platform til udvikling af web-/mobilapps. Gartner kalder brugere af sådanne værktøjer for "borgerudviklere". Dette reducerede adskillelsen af ​​krav og udvikling, men jeg tør godt påstå, at det genererede en masse løsninger, som var svære at vedligeholde og fremmede lidt genbrug. Derfor er sådanne værktøjer ikke rigtig blevet brugt på virksomhedsniveau til missionskritiske løsninger.

Dette kan dog ændre sig med sammensat bankvirksomhed, hvor vægten er at udvikle, publicere og forbruge byggeklodser fra en markedsplads, og så lade en anden "komponere" disse blokke til en komplet løsning. Men det er tydeligvis ikke så enkelt som det. Yefim Natis, anerkendt VP-analytiker og forskningsstipendiat hos Gartner, definerer følgende fem roller i sammensat bankvirksomhed:

1. Enterprise architect (EA): en person, der styrer den overordnede løsning på et højt niveau, hvilket sikrer maksimal genbrug og konsistens. BIAN-arkitekturen er et godt eksempel på noget, som en EA kunne skabe. BIAN giver en fantastisk model til anvendelse af komponerbare "byggeklodser" til en komplet bankarkitektur.
2. Skabere: udviklere, der skaber og udgiver byggestenene til individuel beregning, funktionalitet eller forretningskapacitet.
3. Kuratorer: en rolle til at styre "biblioteket" eller markedspladsen af ​​byggeklodser. Dette bibliotek bør også omfatte alle proprietære eller tredjepartskøbte løsninger.
4. Komponister: teams, der sammensætter en løsning ud fra byggeklodser, ved hjælp af applikationssammensætningsplatforme og værktøjer, men ikke nødvendigvis.
5. Forbrugere: de faktiske brugere af applikationen.

For flere detaljer, se Yefims seneste webinar, 'The Core Principles of Composability: Thrive Through Business Change'.

Jeg siger bare, at "sammensat bankvirksomhed" ikke kun er et IT-problem, da det involverer forretningsbrugerne. Det er ikke kun standardudvikling med et genbrugsbibliotek, det er en organisatorisk ændring, og virksomheder vil kæmpe for at se de fulde fordele uden dette skift.

Tidligere var en virksomhedsarkitekts rolle ekstremt vanskelig, da det krævede et stærkt kendskab til forretningen og teknologien, for at kunne gennemskue hundredvis, hvis ikke tusindvis af systemer, og give en plan for et bedre landskab. BIAN har gjort dette enormt nemmere, selvom opgaven med at kortlægge eksisterende systemer stadig ikke er så let.

Som jeg har fremhævet i tidligere indlæg, kan sammensat bankvirksomhed løse en række problemer for banker, men det vil kræve en organisatorisk ændring og bør understøttes af en strategi for at uddanne og adoptere en ny måde at arbejde på understøttet af nye roller. Som altid er værktøjerne og teorien let tilgængelige, djævelen er i detaljen. Der er stærke eksempler på organisationer, der får dette til at fungere, og jeg håber snart at kunne skrive om dem.

Om forfatteren

Dharmesh Mistry har været i banksektoren i mere end 30 år og har været på forkant med bankteknologi og innovation. Fra de allerførste internet- og mobilbankapps til kunstig intelligens (AI) og virtual reality (VR).

Han har været på begge sider af hegnet, og han er ikke bange for at dele sine meninger.

Han er administrerende direktør for AskHomey, som fokuserer på oplevelsen for husholdninger, og en investor og mentor inden for proptech og fintech.

Følg Dharmesh på Twitter @dharmeshmistry , LinkedIn.

Læs alle hans "Jeg siger bare" overvejelser link..