Uczynienie bankowości komponowalnej pracy

Kiedy w latach 80-tych zaczynałem swoją karierę w technologii bankowej, początkowo pracowałem na komputerach mainframe.

W tamtych czasach mieliśmy zespoły „użytkowników biznesowych z centrali”, którzy określali nasze wymagania. Byli to pośrednicy reprezentujący rzeczywistych użytkowników systemu. Nie mieliśmy bezpośredniego kontaktu z rzeczywistymi użytkownikami.

Kilka lat później bank chciał wypróbować coś, co dziś nazwano by agile, ale wtedy było to Rapid Application Development. Celem było przyspieszenie procesu dostarczania naszych rozwiązań. Jako pierwsi w IT uzbroiliśmy się w laptopy, a nawet telefony komórkowe. Zabrano nas z biura IT i dano nam biuro w jednej z jednostek biznesowych.

Jednocześnie pozwolono nam pracować z domu lub gdziekolwiek uznaliśmy, że możemy być produktywni. Mój harmonogram to zazwyczaj pobudka o 6 rano i kodowanie do 2, a następnie przerwa na lunch i popołudniowy kip. Wróciłem do biurka około 6-7 i zwykle kodowałem do północy. To zadziałało dla mnie.

Poza tym największą zmianą było pozyskiwanie wymagań od użytkowników końcowych w oddziałach. Miało to ogromny wpływ na poprawę użyteczności i funkcji rozwiązania.

Przewińmy 30 lat do przodu i to jest teraz normą. W ciągu ostatnich 30 lat obserwujemy rosnącą integrację użytkowników biznesowych i IT. Nawet dostawcy oprogramowania przeszli w kierunku modelu, w którym klienci są głęboko zaangażowani w nowe produkty.

Jednak generalnie w przypadku specyficznych wymagań biznesowych analityk dokumentuje je, a programista pisze kod. To był model od dziesięcioleci.

Podejmowano próby zmiany tego, aby umożliwić użytkownikom biznesowym pisanie własnych rozwiązań przy użyciu rozwiązań nisko-kodowych lub bez-kodowych. Rzeczywiście, moja ostatnia firma, edgeIPK, była pionierem w tworzeniu platformy bez kodu do tworzenia aplikacji internetowych/mobilnych. Gartner nazywa użytkowników takich narzędzi „twórcami obywatelskimi”. Zmniejszyło to rozdział wymagań i rozwoju, ale śmiem twierdzić, że wygenerowało wiele rozwiązań, które były trudne w utrzymaniu i sprzyjały niewielkiemu ponownemu wykorzystaniu. Dlatego takie narzędzia nie były tak naprawdę wykorzystywane na poziomie przedsiębiorstwa do rozwiązań o znaczeniu krytycznym.

Może się to jednak zmienić w przypadku bankowości komponowalnej, gdzie nacisk kładziony jest na opracowywanie, publikowanie i konsumowanie bloków konstrukcyjnych z rynku, a następnie pozwalanie komuś innemu na „skomponowanie” tych bloków w kompletne rozwiązanie. Ale najwyraźniej nie jest to takie proste. Yefim Natis, wybitny wiceprezes analityka i pracownik naukowy w firmie Gartner, definiuje następujące pięć ról w bankowości komponowalnej:

1. Architekt korporacyjny (EA): osoba, która zarządza całym rozwiązaniem na wysokim poziomie, zapewniając maksymalne ponowne wykorzystanie i spójność. Architektura BIAN jest dobrym przykładem czegoś, co może stworzyć EA. BIAN zapewnia świetny model do zastosowania komponujących się „cegiełek” w kompletnej architekturze banku.
2. Twórcy: programiści, którzy tworzą i publikują elementy składowe indywidualnych obliczeń, funkcjonalności lub możliwości biznesowych.
3. Kuratorzy: rola w zarządzaniu „biblioteką” lub rynkiem klocków. Ta biblioteka powinna również zawierać wszelkie rozwiązania zastrzeżone lub nabyte przez osoby trzecie.
4. Kompozytorzy: zespoły, które komponują rozwiązanie z bloków konstrukcyjnych, korzystając z platform i narzędzi do komponowania aplikacji, ale niekoniecznie.
5. Konsumenci: rzeczywiści użytkownicy aplikacji.

Aby uzyskać więcej informacji, zobacz ostatnie webinarium Yefim „Podstawowe zasady komponowania: prosperuj dzięki zmianom biznesowym”.

Mówię tylko, że „bankowość komponowana” to nie tylko kwestia IT, ponieważ dotyczy użytkowników biznesowych. To nie tylko standardowy rozwój z biblioteką do ponownego wykorzystania, to zmiana organizacyjna, a firmy będą miały trudności z dostrzeżeniem pełnych korzyści bez tej zmiany.

W przeszłości rola architekta korporacyjnego była niezwykle trudna, ponieważ wymagała dużej wiedzy biznesowej i technologicznej, aby móc przesiać setki, jeśli nie tysiące systemów i stworzyć plan lepszego krajobrazu. BIAN znacznie to ułatwił, chociaż zadanie mapowania istniejących systemów wciąż nie jest takie proste.

Jak podkreśliłem w Poprzednie posty, bankowość komponowana może rozwiązać szereg problemów dla banków, ale będzie wymagała zmiany organizacyjnej i powinna być wspierana strategią edukacji i przyjęcia nowego sposobu pracy wspieranego przez nowe role. Jak zawsze narzędzia i teoria są łatwo dostępne, diabeł tkwi w szczegółach. Istnieją mocne przykłady organizacji, które sprawiają, że to działa i mam nadzieję, że wkrótce o nich napiszę.

O autorze

Dharmesh Mistry działa w bankowości od ponad 30 lat i jest liderem technologii i innowacji bankowych. Od pierwszych aplikacji bankowości internetowej i mobilnej po sztuczną inteligencję (AI) i wirtualną rzeczywistość (VR).

Stał po obu stronach płotu i nie boi się dzielić swoimi opiniami.

Jest dyrektorem generalnym ZapytajHomey, która skupia się na doświadczeniu dla gospodarstw domowych oraz inwestora i mentora w proptech i fintech.

Śledź Dharmesh na Twitterze @dharmeshmistry. i LinkedIn.

Przeczytaj wszystkie jego przemyślenia „Po prostu mówię” tutaj.