Samenstelbaar bankieren laten werken

Toen ik in de jaren 80 mijn carrière in banktechnologie begon, werkte ik aanvankelijk met mainframes.

In die tijd hadden we teams van 'zakelijke gebruikers op het hoofdkantoor' die onze vereisten specificeerden. Dit waren tussenpersonen die de daadwerkelijke gebruikers van het systeem vertegenwoordigden. We hadden geen direct contact met de daadwerkelijke gebruikers.

Een paar jaar later wilde de bank uitproberen wat vandaag agile zou heten, maar toen was dat nog Rapid Application Development. Het doel was om de manier waarop we onze oplossingen leverden, te versnellen. We waren de eersten in de IT die gewapend waren met laptops en zelfs mobiele telefoons. We werden uit het IT-kantoor gehaald en kregen een kantoor in een van de business units.

Tegelijkertijd mochten we thuis werken of waar we ook maar productief konden zijn. Mijn schema was meestal om 6 uur 's ochtends wakker worden en coderen tot 2 uur, dan pauze om te lunchen en 's middags een kip. Ik was rond 6/7 uur terug aan mijn bureau en codeerde meestal tot middernacht. Dit werkte voor mij.

Afgezien hiervan was de grootste verandering het krijgen van eisen van eindgebruikers in branches. Dit maakte een enorm verschil om de bruikbaarheid en functies van de oplossing goed te krijgen.

Snel vooruit 30 jaar en dit is nu de norm. In de afgelopen 30 jaar hebben we een toenemende integratie van zakelijke gebruikers en IT gezien. Zelfs softwareleveranciers zijn overgestapt op een model waarbij klanten diep betrokken zijn bij nieuwe producten.

Over het algemeen documenteert een analist deze echter voor bedrijfsspecifieke vereisten en schrijft een ontwikkelaar de code. Dit is al decennia het model.

Er zijn pogingen gedaan om dit te veranderen, om zakelijke gebruikers in staat te stellen hun eigen oplossingen te schrijven met behulp van low-code of no-code-oplossingen. Mijn laatste bedrijf, edgeIPK, was inderdaad een pionier in het creëren van een no-code platform voor de ontwikkeling van web/mobiele apps. Gartner noemt gebruikers van dergelijke tools “citizen developers”. Dit verminderde de scheiding van eisen en ontwikkeling, maar ik durf te zeggen dat het veel oplossingen opleverde die moeilijk te onderhouden waren en weinig hergebruik bevorderden. Daarom zijn dergelijke tools niet echt op bedrijfsniveau gebruikt voor missiekritieke oplossingen.

Dit kan echter veranderen met composable banking, waar de nadruk ligt op het ontwikkelen, publiceren en consumeren van bouwstenen van een marktplaats, en vervolgens iemand anders deze blokken te laten 'componeren' tot een complete oplossing. Maar zo simpel is het duidelijk niet. Yefim Natis, onderscheiden VP-analist en research fellow bij Gartner, definieert de volgende vijf rollen in composable banking:

1. Enterprise architect (EA): iemand die de totaaloplossing op hoog niveau regisseert en zorgt voor maximaal hergebruik en consistentie. De BIAN-architectuur is een goed voorbeeld van iets dat een EA zou kunnen creëren. BIAN biedt een geweldig model voor de toepassing van samen te stellen "bouwstenen" voor een complete bankarchitectuur.
2. Creators: ontwikkelaars die de bouwstenen van individuele berekeningen, functionaliteit of zakelijke mogelijkheden creëren en publiceren.
3. Curatoren: een rol om de "bibliotheek" of marktplaats van bouwstenen te beheren. Deze bibliotheek moet ook alle eigen of door derden verworven oplossingen bevatten.
4. Composers: teams die een oplossing samenstellen uit bouwstenen, met behulp van applicatiecompositieplatforms en -tools, maar niet noodzakelijk.
5. Consumenten: de daadwerkelijke gebruikers van de applicatie.

Zie voor meer details Yefim's recente webinar, 'The Core Principles of Composability: Thrive Through Business Change'.

Ik zeg alleen dat 'composable banking' niet alleen een IT-kwestie is, maar ook de zakelijke gebruikers. Het is niet alleen standaardontwikkeling met een bibliotheek voor hergebruik, het is een organisatorische verandering en bedrijven zullen moeite hebben om de volledige voordelen te zien zonder deze verschuiving.

In het verleden was de rol van een enterprise-architect buitengewoon moeilijk omdat het een sterke kennis van het bedrijf en de technologie vereiste om honderden, zo niet duizenden systemen te kunnen doorzoeken en een blauwdruk te bieden voor een beter landschap. BIAN heeft dit enorm eenvoudiger gemaakt, al is het nog niet zo eenvoudig om bestaande systemen in kaart te brengen.

Zoals ik heb benadrukt in vorige berichtenComposable banking kan een aantal problemen voor banken oplossen, maar het vereist een organisatorische verandering en moet worden ondersteund door een strategie om een ​​nieuwe manier van werken te onderwijzen en te adopteren, ondersteund door nieuwe rollen. Zoals altijd zijn de tools en theorie direct beschikbaar, de duivel zit in de details. Er zijn sterke voorbeelden van organisaties die dit laten werken, en ik hoop er binnenkort over te schrijven.

Over de auteur

Dharmesh Mistry zit al meer dan 30 jaar in het bankwezen en loopt voorop op het gebied van banktechnologie en innovatie. Van de allereerste apps voor internet en mobiel bankieren tot kunstmatige intelligentie (AI) en virtual reality (VR).

Hij heeft aan beide kanten van het hek gestaan ​​en is niet bang om zijn mening te geven.

Hij is CEO van Vraag het aan Homey, dat zich richt op de ervaring voor huishoudens, en een investeerder en mentor in proptech en fintech.

Volg Dharmesh op Twitter @harmeshmistry en LinkedIn.

Lees al zijn "ik zeg alleen" mijmeringen hier.