Funcționarea composable banking

Când mi-am început cariera în tehnologia bancară în anii 80, inițial lucram cu mainframe.

În acele vremuri, aveam echipe de „utilizatori de afaceri de la sediul central” care ne specificau cerințele. Aceștia erau intermediari care reprezentau utilizatorii efectivi ai sistemului. Nu am avut contact direct cu utilizatorii reali.

Câțiva ani mai târziu, banca a vrut să încerce ceea ce astăzi s-ar numi agil, dar pe atunci era Dezvoltarea rapidă a aplicațiilor. Scopul a fost să accelerăm modul în care ne-am livrat soluțiile. Am fost primii în IT care au fost înarmați cu laptopuri și chiar telefoane mobile. Am fost scoși din biroul IT și ni s-a dat un birou într-una dintre unitățile de afaceri.

În același timp, ni s-a permis să lucrăm de acasă sau oriunde am simțit că putem fi productivi. Programul meu era, de obicei, să mă trezesc la ora 6 dimineața și să codific până la 2:6, apoi să fac o pauză pentru a lua masa de prânz și o băutură după-amiază. M-am întors la birou în jurul orei 7/XNUMX și, de obicei, codificam până la miezul nopții. Asta a funcționat pentru mine.

În afară de aceasta, cea mai mare schimbare a fost de fapt obținerea cerințelor de la utilizatorii finali din sucursale. Acest lucru a făcut o diferență uriașă în obținerea corectă a gradului de utilizare și a funcțiilor soluției.

Înainte rapid 30 de ani și aceasta este norma acum. În ultimii 30 de ani, am observat o integrare tot mai mare a utilizatorilor de afaceri și IT. Chiar și furnizorii de software s-au îndreptat către un model prin care clienții sunt profund implicați în produse noi.

Cu toate acestea, în general, pentru cerințe specifice afacerii, un analist le documentează și un dezvoltator scrie codul. Acesta a fost modelul de zeci de ani.

Au existat încercări de a schimba acest lucru, de a permite utilizatorilor de afaceri să-și scrie propriile soluții folosind soluții low-code sau fără cod. Într-adevăr, ultima mea companie, edgeIPK, a fost un pionier în crearea unei platforme fără cod pentru dezvoltarea de aplicații web/mobile. Gartner numește utilizatorii unor astfel de instrumente „dezvoltatori cetățeni”. Acest lucru a redus separarea cerințelor și dezvoltare, dar îndrăznesc să spun că a generat o mulțime de soluții greu de întreținut și a favorizat puțină reutilizare. Prin urmare, astfel de instrumente nu au fost cu adevărat utilizate la nivel de întreprindere pentru soluții critice.

Cu toate acestea, acest lucru s-ar putea schimba cu composable banking, unde accentul este de a dezvolta, publica și consuma blocuri de construcție dintr-o piață și apoi permite altcuiva să „compune” aceste blocuri într-o soluție completă. Dar clar că nu este atât de simplu. Yefim Natis, distins VP analist și cercetător la Gartner, definește următoarele cinci roluri în composable banking:

1. Architect Enterprise (EA): cineva care guvernează soluția generală la un nivel înalt, asigurând reutilizare și coerență maxime. Arhitectura BIAN este un bun exemplu de ceva ce ar putea crea un EA. BIAN oferă un model excelent pentru aplicarea „blocurilor de construcție” componabile pentru o arhitectură bancară completă.
2. Creatori: dezvoltatori care creează și publică elementele de bază ale calculului individual, al funcționalității sau al capacității de afaceri.
3. Curatori: un rol de a gestiona „biblioteca” sau piața de blocuri. Această bibliotecă ar trebui să includă și orice soluții proprietare sau achiziționate de terți.
4. Compozitori: echipe care compun o soluție din blocuri, folosind platforme și instrumente de compunere a aplicațiilor, dar nu neapărat.
5. Consumatori: utilizatorii efectivi ai aplicației.

Pentru mai multe detalii, consultați recentul webinar al lui Yefim, „Principiile de bază ale composibilității: prosperă prin schimbarea afacerii”.

Spun doar că „composable banking” nu este doar o problemă IT, deoarece implică utilizatorii de afaceri. Nu este doar o dezvoltare standard cu o bibliotecă de reutilizare, este o schimbare organizațională, iar firmele se vor lupta să vadă beneficiile complete fără această schimbare.

În trecut, rolul unui arhitect de întreprindere a fost extrem de dificil, deoarece necesita cunoștințe solide despre afaceri și tehnologie, pentru a putea trece prin sute, dacă nu mii de sisteme și pentru a oferi un plan pentru un peisaj mai bun. BIAN a făcut acest lucru extrem de ușor, deși sarcina de a mapa sistemele existente încă nu este atât de ușoară.

După cum am subliniat în postări anterioare, composable banking poate rezolva o serie de probleme pentru bănci, dar va necesita o schimbare organizațională și ar trebui susținută de o strategie de educare și adoptare a unui nou mod de lucru susținut de noi roluri. Ca întotdeauna, instrumentele și teoria sunt ușor disponibile, diavolul este în detalii. Există exemple puternice de organizații care fac acest lucru și sper să scriu despre ele în curând.

Despre autor

Dharmesh Mistry este în domeniul bancar de mai bine de 30 de ani și a fost în fruntea tehnologiei și inovației bancare. De la primele aplicații de internet și mobile banking până la inteligență artificială (AI) și realitate virtuală (VR).

El a fost de ambele părți ale gardului și nu se teme să-și împărtășească părerile.

El este CEO al Întrebați Acasă, care se concentrează pe experiența pentru gospodării și un investitor și mentor în proptech și fintech.

Urmați Dharmesh pe Twitter @dharmeshmistry și LinkedIn.

Citiți toate gândurile sale „spun doar”. aici.