Att få sammansatt bank att fungera

När jag började min karriär inom bankteknik på 80-talet, arbetade jag först med stordatorer.

På den tiden hade vi team av "företagsanvändare på huvudkontoret" som specificerade våra krav. Dessa var mellanhänder som representerade de faktiska användarna av systemet. Vi hade ingen direkt kontakt med de faktiska användarna.

Några år senare ville banken testa det som idag skulle kallas agilt, men då var Rapid Application Development. Målet var att påskynda hur vi levererade våra lösningar. Vi var de första inom IT som var beväpnade med bärbara datorer och till och med mobiltelefoner. Vi togs ut från IT-kontoret och fick ett kontor i en av affärsenheterna.

Samtidigt fick vi jobba hemifrån eller där vi kände att vi kunde vara produktiva. Mitt schema var vanligtvis att vakna klockan 6 och kod till 2, sedan pausa för att äta lunch och en eftermiddagskip. Jag var tillbaka vid mitt skrivbord från runt 6/7 och skulle vanligtvis koda till midnatt. Det här fungerade för mig.

Bortsett från detta var den största förändringen faktiskt att få krav från slutanvändare i filialer. Detta gjorde en enorm skillnad för att få lösningens användbarhet och funktioner rätt.

Spola framåt 30 år och detta är normen nu. Under de senaste 30 åren har vi sett en ökande integration av företagsanvändare och IT. Även mjukvaruleverantörer har gått mot en modell där kunderna är djupt involverade i nya produkter.

Men generellt för affärsspecifika krav dokumenterar en analytiker dem och en utvecklare skriver koden. Detta har varit modellen i decennier.

Det har gjorts försök att ändra detta, för att ge företagsanvändare möjlighet att skriva sina egna lösningar med hjälp av lösningar med låg kod eller ingen kod. Mitt senaste företag, edgeIPK, var faktiskt en pionjär i att skapa en kodfri plattform för utveckling av webb-/mobilappar. Gartner kallar användare av sådana verktyg för "medborgarutvecklare". Detta minskade åtskillnaden mellan krav och utveckling, men jag vågar påstå att det genererade många lösningar som var svåra att underhålla och främjade lite återanvändning. Därför har sådana verktyg inte riktigt använts på företagsnivå för affärskritiska lösningar.

Detta kan dock förändras med sammansatt bankverksamhet, där tyngdpunkten är att utveckla, publicera och konsumera byggstenar från en marknadsplats, och sedan låta någon annan "komponera" dessa block till en komplett lösning. Men det är helt klart inte så enkelt. Yefim Natis, framstående VP-analytiker och forskare på Gartner, definierar följande fem roller inom sammansatt bankverksamhet:

1. Enterprise architect (EA): någon som styr den övergripande lösningen på hög nivå, vilket säkerställer maximal återanvändning och konsekvens. BIAN-arkitekturen är ett bra exempel på något som en EA skulle kunna skapa. BIAN ger en utmärkt modell för tillämpning av komponerbara "byggstenar" för en komplett bankarkitektur.
2. Skapare: utvecklare som skapar och publicerar byggstenarna för individuell beräkning, funktionalitet eller affärskapacitet.
3. Kuratorer: en roll för att hantera "biblioteket" eller marknadsplatsen för byggstenar. Detta bibliotek bör också innehålla alla patentskyddade eller tredjepartsförvärvade lösningar.
4. Kompositörer: team som komponerar en lösning från byggstenar, med hjälp av applikationssammansättningsplattformar och verktyg, men inte nödvändigtvis.
5. Konsumenter: de faktiska användarna av applikationen.

För mer information, se Yefims senaste webbseminarium, "The Core Principles of Composability: Thrive Through Business Change".

Jag säger bara att "sammansatt bankverksamhet" inte bara är en IT-fråga eftersom det involverar affärsanvändarna. Det är inte bara standardutveckling med ett återanvändningsbibliotek, det är en organisatorisk förändring och företag kommer att kämpa för att se de fulla fördelarna utan denna förändring.

Tidigare var rollen som en företagsarkitekt extremt svår då det krävdes stark kunskap om verksamheten och tekniken, för att kunna sålla igenom hundratals om inte tusentals system och ge en plan för ett bättre landskap. BIAN har gjort detta oerhört enklare, även om uppgiften att kartlägga befintliga system fortfarande inte är så lätt.

Som jag har markerat i tidigare inlägg, sammansatt bankverksamhet kan lösa ett antal problem för banker, men det kommer att kräva en organisatorisk förändring och bör stödjas av en strategi för att utbilda och anta ett nytt sätt att arbeta med stöd av nya roller. Som alltid är verktygen och teorin lättillgängliga, djävulen finns i detaljen. Det finns starka exempel på organisationer som gör det här, och jag hoppas kunna skriva om dem snart.

Om författaren

Dharmesh Mistry har varit i banksektorn i mer än 30 år och har legat i framkanten av bankteknik och innovation. Från de allra första internet- och mobilbanksapparna till artificiell intelligens (AI) och virtuell verklighet (VR).

Han har varit på båda sidor om staketet och är inte rädd för att dela sina åsikter.

Han är VD för FrågaHomey, som fokuserar på hushållens upplevelse, och en investerare och mentor inom proptech och fintech.

Följ Dharmesh på Twitter @dharmeshmistry och LinkedIn.

Läs alla hans "Jag säger bara" funderingar här..