Podczas spotkania CXO HUB 19 czerwca odbyła się debata oksfordzka z tezą „W ciągu 3 – 5 lat większość systemów core’owych w firmach powstanie w paradygmacie Low Code”. Tezy broniła drużyna w składzie: Adam Kasperowicz (Grupa VAN), Michał Jurowski VSoft) i Przemysław Staniszewski (Pretius Low Code). W kontrze do tezy argumentowała drużyna Michała Głowińskiego (EG), Jacka Chmiela (Avenga Lab) i Sławomira Panasiuka (KDPW).
Przedstawiamy skrócony zapis argumentacji i polemik, którym przysłuchiwała się i które na koniec oceniła zebrana publiczność. Wybór publiczności na spotkaniu: drużyna KONTRA. A czyje argumenty przekonują Państwa?
RUNDA I: otwarcie debaty
Adam Kasperowicz (Drużyna PRO)
Szanowni Państwo, Droga Publiczności, Nasi Szanowni Oponenci.
Dziś w debacie oksfordzkiej chcemy przekonać, że w ciągu 3 – 5 lat większość systemów core’owych w firmach powstanie w paradygmacie Low Code. Czy to odważna teza? Osobiście uważam, że dużo mniej karkołomna, niż próba, którą zdecydowali się podjąć nasi szanowni Oponenci.
A zatem po pierwsze: w ciągu 3 do 5 lat większość systemów core’owych w firmach powstanie w paradygmacie LowCode dlatego, że pozwala użytkownikom biznesowym zbliżyć się do IT.
Low Code pozwala pracować wspólnie – znamy wówczas i ograniczenia, i korzyści. Po początkowych tarciach, można uzyskać takie porozumienie, że można wspólnie decydować jakie parametry powinien mieć rozwiązanie, które powstaje. Takie podejście – takie porozumienie w firmie, taka synergia – nie są możliwe do uzyskania kodując tradycyjnie. To spowoduje, że coraz więcej firm będzie przekonywać się do Low Code. W 3-5 lat w efekcie większość systemów ma szansę być wytwarzana w tym paradygmacie.
Secundo: Low Code zwycięży, bo rozwiązuje temat utrzymania zespołu. W moim przypadku dzięki Low Code udało się zintegrować pracę zewnętrznego zespołu doświadczonego w Low Code i mojego, który przyswoił sobie te zasady i metody, a dodatkowo – użytkowników biznesowych oraz stażystów, którzy z niego dziś korzystają. To sprawia, że przyrosty wytwarzania naszego rozwiązanie pochodzą z wielu źródeł. To zapewnia nam bezpieczeństwo, stabilność w obecnej sytuacji niedostatku wykwalifikowanych pracowników na rynku.
Wybierając inne rozwiązanie niż LowCode musielibyśmy nieuchronnie doprowadzić do zmian osobowych w zespole na osoby biegłe w nowym języku czy technologii w jakiej miałby powstać system TMS. Osoby z nowego zespołu musiałyby za to długo poznawać arkana naszego biznesu.
Tertio: LowCode to uproszczenie stosu technologicznego.
Mogę to udowodnić na własnym przykładzie, przejście na platformę Low Code pozwoliło nam zmniejszyć liczbę serwerów aplikacyjnych i uprościć architekturę. Platforma może być bowiem kompletnym środowiskiem: bazą danych, środowiskiem programistycznym i serwerem aplikacyjnym.
To zarazem trzeci element równania, które po drugiej stronie znaku równości ma słowo „oszczędność”: uproszczenie architektury, to zmniejszenie licencji, uproszczenie to standaryzacja, to wspomniane zbliżenie z użytkownikami, którzy owocuje szybszym dostarczaniem i mniejszą liczbą błędów we współpracy. Szybciej i bez pośrednictwa analityków – zaspokajamy potrzeby informatyczne firmy.
Na koniec jeszcze odwołam się do horyzontu 3-5 lat. Czy to mało, czy dużo na przełom? Przypomnę, że na spotkaniu tej społeczności, jeszcze około 5 lat temu dyskutowaliśmy inną, wówczas kontrowersyjną tezę: czy są przykłady komercyjnych zastosowań AI. Wówczas jeszcze wiele firm próbowało, testowało – ale o zastosowaniu w biznesie niespecjalnie mógł ktoś powiedzieć. Te 5 lat zmieniło bardzo wiele – to prawie epoka w adaptacji AI w biznesie.
Dlatego uważamy, że także większość core’owych systemów wykorzystywanych przez firmy będzie w perspektywie 3-5 lat powstawać w paradygmacie Low Code.
Jacek Chmiel, (Drużyna Kontra)
Szanowni Państwo, droga publiczności, drodzy ambasadorowie LowCode. My także lubimy Low Code, ale stosowany do małych rzeczy. Ta strona, ta drużyna, przekona Państwa, że teza debaty jest z gruntu fałszywa.
Po pierwsze – to teza wtórna. Zacznijmy od początku, czyli od lat 90., bo wówczas także podobne debaty się odbywały. Prze te 35 lat Low Code miał szansę udowodnić wszystkie swoje zalety. Powstaje pytanie: skoro przez te trzy dekady nic takiego się nie wydarzyło, dlaczego miałoby się zmieścić w ciągu 3 lat?
LowCode ma swoje miejsce, ale systemy core’owe mają nam służyć przez lata. System legacy to system, który był potrzebny i przydał się do biznesu. Pomimo negatywnej konotacji, to sprawdzone, stabilne rozwiązania, które przetrwały lata. Od tego jesteśmy, aby takie systemy budować. Trzeba podkreślić, że i Low Code, i hard code się rozwija. Nie mówimy o sytuacji, że na scenę wstępuje nowe podejście do programowania z powodu wyczerpania możliwości poprzedniego. One się rozwijają równolegle – do różnych zastosowań.
Java .NET, Python poszły w ciągu trzech lat zdecydowanie do przodu. Siła ekspresji tych frameworków sprawia, że w dobrych rękach praca jest tak samo szybka jak w Low Code, a jednocześnie nie ma tych wszystkich minusów, które obciążają konto podejścia niskokodowego.
Osobna, ale bolesna kwestia dotyczy dostępności osób znających rozwiązania Low Code. Obecnie na świecie miliony ludzi zmagają się z tym, żeby zapewnić organizacjom programistów, którzy będą chcieli dobrze pracować. To wyzwanie towarzyszy informatyzacji – cyfryzacji chyba od zawsze. A w tym oceanie programistów bardzo trudno jest złowić programistów Low Code, ponieważ jest ich może tysiąc, może dwa tysiące a może pięć tysięcy mniej niż pozostałych programistów. Mówimy więc o absolutnej niszy w niszy, ponieważ Low Code budzi odrazę programistów, zwłaszcza tych najlepszych. Co oczywiście jest ze stratą dla wszystkich, bo gdyby było inaczej, może i nasze zdanie o Low Code byłoby lepsze.
Za mocne? To chciałbym zapytać Państwa: a z czego korzystają start-upy? Bo pewnie wszyscy głęboko wierzymy, że spośród nich wyłonią się niebawem twórcy przełomowych systemów core’owych. Obserwuję start-up’y na co dzień i mam teraz przyjemność pracować w gronie prawdziwych komandosów start-up’owych. Oni używają nowoczesnych metodyk, używają Rusta, ale – wstydziliby się zrobić system, kiedy jego ocena decyduje o kontynuacji finansowania ich pomysłu, który ma być dowodem, że ich praca jest dobrej jakości, wytrzyma lata, jest bezpieczna – oni właśnie wstydziliby się go robić w LowCode. Tak więc proszę Państwa – na pewno start-up’y, i na pewno banki, nie korzystają z LowCode do robienia systemów core’owych.
Platformy Low Code – które mimo wszystko bardzo lubimy – mają ten problem, że trzeba szybko uczyć się je lubić, bo prędko odchodzą. Miałem takie doświadczenie, że przymierzaliśmy się do jednej z nich, ale widocznie za długo trwał namysł, bo kiedy już decyzja zapadła, nadeszła informacja, że ją wyłączają. Platformy Low Code są także świetną ilustracją problemu dużej fragmentacji rynku technologii – przy małym wycinku rynku oznacza, że trudno im osiągnąć break even point a tym samym ryzyko zamknięcia jest wysokie. Rzecz w przypadku Javy, .Net w praktyce pomijalna jako kategoria ryzyka.
W tej chwili mam też nowe doświadczenie z generatywnym AI. Języki dużej ekspresji, jak Python czy Java, wsparte silnikiem typu ChatGPT pozwalają kończyć projekty zdecydowanie przed czasem. Nie widzę żadnej potencjalnej przewagi LC w szybkości.
Za to chętnie pomówię o kastomizacji. Weźmy tylko kwestię UI. Jeszcze nie widziałem przypadku, żeby nie było z tym problemu. Customer facing, działy wszelkiej maści, przychodzą i w ciągu pół roku żądają aby zmienić aplikację – bo klienci się nudzą. Low Code, który jest skróconym zbiorem reguł i szablonów z całą pewnością nie udźwignie tej kreatywnej strony biznesu – chyba, że dział IT odpowiedzialny za Low Code dostanie do ręki uprawnienia „super usera” w kontekście całej firmy.
Mamy cały przemysł oprogramowania, metodyki DevOps, DevSecOps, których zadaniem jest uporać się z podobnymi wyzwaniami i zapewnić, że dostarczone rozwiązanie będzie spójne, stabilne, bezpieczne. To wiedza, która decyduje o elastyczności biznesu. Nie wyobrażam sobie, aby miała trafić do kosza.
Kolejny problem, w tej wyliczance problemów Low Code, dotyczy złożoności. Każdy by chciał ją zmniejszać – ale jest to niemożliwe. Można natomiast lepiej nią zarządzać, tylko że w tym lepsze są dojrzałe języki programowania a nie Low Code. Możemy oczywiście to zarządzanie przenieść na platformę Low Code, ale bardzo szybko przyjdzie rozczarowanie, biorąc pod uwagę złożoność biznesu i cykl życia aplikacji.
Dlatego uważamy, że jeśli przez 30 lat się nie udało, to przez następne 3 czy 5 lat także się nie uda.
RUNDA II: POLEMIKA
Michał Jurkowski (Drużyna PRO)
Trudne to zadanie, odpowiedzieć na tak poważne zarzuty wobec Low Code, ale zasadnicza ich część jest szpetnie chybiona.
Chciałem szczególnie podziękować koledze, za argument, że od lat 80. nic się nie zmieniało, jeśli chodzi o możliwości Low Code. Otóż właśnie zmieniło się bardzo dużo. Co prawda nie istniała nazwa Low Code, ale nie mamy dziś do czynienia z nowym, dziwnym zjawiskiem. To w istocie, jak słusznie zauważyli nasi oponenci, kontynuacja nurtu, który dążył do uproszczenia i przyspieszenia programowania.
Co zatem się zmienia w procesie wytwarzania oprogramowania? Po prostu wzrasta poziom abstrakcji. Rozwija się biznes – systemy robią się coraz trudniejsze i bardziej złożone. Za tym musi właśnie iść wzrost abstrakcji poziomu wytwarzania oprogramowania.
Zaczynaliśmy od kodu maszynowego, potem pojawił się asembler – ale nadal programiści musieli znać kod binarny, budowę sprzętu, sposób alokacji w pamięci. Rozmowa programisty z analitykiem biznesowym w banku była wówczas w zasadzie niemożliwa.
Coś się zmieniło, kiedy pojawił się język C. Był trochę bardziej zrozumiały, choć nadal trzeba było grzebać w pamięci. Pojawił się C++, było już o to łatwiej i wreszcie powstała Java. To była rewolucja. Programiści Java byli gotowi iść na wojnę z programistami C – używając tych samych argumentów, które obecnie usłyszeliśmy w odniesieniu do platformy Low Code.
Rozwój postępował w stronę wizualizacji, aby operować na wyższym poziomie abstrakcji. Co więcej – inaczej, niż twierdzą nasi oponenci – to się udawało. Początkowo zapisywaliśmy kod w notepadzie, potem w edytorach, które kolorem wyróżniały elementy składni, podpowiadały prawidłowy zapis i wręcz kolejne linijki kodu. Potem pojawił się RAD – zaczęliśmy rysować, zamiast pisać. Potem Turbo Pascal, Visual Studio –wciąż rysowaliśmy a pod spodem kodowaliśmy, ale już nie wszystko. Gotowe komponenty pochodziły z bibliotek zewnętrznych. I tak można mniej lub bardziej szczegółowo snuć tę historię.
Po co ją opowiadam? Chcę, żebyśmy sobie uświadomili, że Low Code nie jest anomalią, ale kolejnym etapem zwiększenia poziomu abstrakcji procesu wytwarzania oprogramowania. Kiedy będziemy za chwilę tworzyli systemy obejmujące cały świat, wspierające jeszcze bardziej złożone modele biznesowe – udostępnianie możliwości ich abstrakcyjnego opisu i planowania będzie postępowało.
Programiści będą musieli jeszcze bardziej zbliżyć się do biznesu, wręcz oddać użytkownikom biznesowym część pisania, a w zasadzie rysowania, szkicowania systemów. Low Code znosi ostatecznie barierę między przedstawicielami działów biznesowych i programistami.
Mógłbym poprzestać na tym – bo to już wystarczająco wspiera tezę debaty. Ale nasi koledzy z przeciwnej drużyny przytoczyli jeszcze argument o dostępności specjalistów. Kolega wspomniał, że więcej jest programistów Java, że to języki wysokokodowe prężniej się rozwijają. Ale to przecież dokładnie ta sama sytuacja, jaka miała miejsce, kiedy pojawiła się Java. Wówczas także mieliśmy tysiące programistów C++ i kilku Javy. I także były dyskusje, debaty podobne do dzisiejszej, wątpliwości, czy wystarczy „dżawowców”. Dziś jest ich więcej niż programistów C++, dla których jednak też jest miejsce. Co więcej, nadal swoje miejsce mają też programiści asemblera, ale robią już inne rozwiązania. Z Low Code będzie podobnie: nie nadaje się do wszystkiego, np. do programowania systemu embedded – to zrozumiałe, jeszcze nie, ale to kwestia czasu.
Czy kwestią czasu będzie także zdolność kastomizacji w Low Code? Odpowiem przewrotnie: zdarza się w firmach nadmiernie asertywne podejście do UI. Czy to się firmie rzeczywiście opłaca? Są firmy, które zainwestują w możliwość przesuwania przycisku w aplikacji o ten symboliczny piksel w górę czy w dół, ale większość firm będzie wolała zapłacić mniej i przystanie na lokalizację według frameworku.
I to jest sedno platform Low Code: wyższy poziom, niższe koszty, szybsze dostarczanie. To właśnie decyduje, że za 3 do 5 lat większość core’owych systemów powstawać będzie w paradygmacie Low Code.
Michał Głowiński, (Drużyna KONTRA)
Proszę Państwa, uważam, że teza o tym, że w ciągu 3-5 lat większość systemów core’owych zostanie stworzona w paradygmacie Low Code, jest nieprawdziwa.
Chciałbym przedstawić kilka istotnych argumentów, które wspierają stanowisko przedstawione przez Jacka. Jednocześnie nie pozostawię bez odpowiedzi argumentów naszych kolegów z drużyny, którzy popierają tę tezę.
Na początek, zwrócę uwagę na podniesione tutaj argumenty dotyczące tego, że Low Code eliminuje złożoność i skraca dystans między analitykami a programistami. Mogę to ująć prościej: jeśli buduję dom, to nie muszę samemu mieszać betonu czy układać cegieł. Podobnie, kiedy kupuję samochód, nie muszę samodzielnie składać go w fabryce. Uważam, że istnieje wiele różnych sposobów osiągnięcia porozumienia, niekoniecznie poprzez wspólne robienie tego samego. Ważne jest, aby wykorzystać nasze indywidualne kompetencje. Na podstawie mojego doświadczenia mogę stwierdzić, że większość problemów w procesie tworzenia oprogramowania wynika nie tyle z braku współpracy, ile z braku komunikacji i porozumienia. Warto również zastanowić się, czy zwiększenie liczby programistów po stronie biznesowej jest korzyścią. Przykładem są specjaliści od platform Net Suite czy SalesForce, których trudno znaleźć obecnie na rynku. Jeśli brakuje takich specjalistów, to osoby opanowujące Low Code bardzo szybko odkryją, jak cenne mogą być dla firm. Dodatkowo, każda platforma Low Code powstaje przede wszystkim w celu osiągnięcia zysku. Nawet jeśli tworzona jest wokół niej społeczność, to często z myślą o ewentualnym jej wykupieniu.
Kolejny istotny aspekt to brak możliwości pełnej personalizacji w przypadku Low Code. Systemy Low Code skupiają się na szablonach i narzucaniu prostych schematów. Oczywiście, takie podejście jest skuteczne w przypadku prostych wyzwań. Jednak większe i bardziej złożone rozwiązania wymagają elastyczności i dostosowania. W przypadku Low Code, próba takiego dostosowania prowadzi do nieprzewidywalności i ryzyka porażki. Oczywiście, można korzystać z Low Code, gdy wszystko idzie zgodnie z planem i nie ma konfliktów ani potrzeby dostosowania. Jednak warto pamiętać, że Low Code nie zastępuje procesu myślowego. Jest to narzędzie dla entuzjastów, takich jak ci, których znamy od czasów Accessa. To jest pewnego rodzaju demokratyzacja cyfrowa. Ich twórczość i samodzielnie stworzone rozwiązania zostają zapamiętane na długie lata. Warto również wspomnieć, że nie tylko Access, ale także Lotus Notes, to przykłady rozwiązań tworzonych przez entuzjastów. Każdy, kto miał okazję przenosić dane Lotus do Outlooka, doskonale rozumie o czym mówię. To właśnie “pasjonaci” Low Code tworzyli takie rozwiązania.
Na koniec, chciałbym poruszyć kwestię sezonowości frameworków. W ostatnich latach widzieliśmy wiele frameworków i uniwersalnych platform. Ile z nich przetrwało dłużej niż 3 lata i nadal działa w zadowalającym stopniu? Oczywiście można wskazać pewne przypadki, ale im dłużej framework przetrwa, tym bardziej kosztowny staje się jego rozwój.
Przykładem może być Xamarin z 2011 roku, który umożliwiał pisanie kodu raz i korzystanie z niego na platformach Android i iOS. Dwa lata później pojawił się Ionic, którego dzisiaj prawie nikt nie pamięta. Następnie mieliśmy Fluttera i REACTa, które nadal są stosowane, ale głównie do prostych zastosowań, z wykluczeniem rozwiązań o wysokim poziomie bezpieczeństwa. Nawet jeśli jakieś frameworki przetrwają, nie zawsze nadążają za dynamicznym rynkiem, często ze względu na konkurencję i niechęć producentów.
Przyjrzenie się tym kwestiom skłania mnie do refleksji: czy naprawdę świat musi ulec większym zmianom? Czy faktycznie musimy budować kluczowe systemy przy użyciu Low Code, tak jak sugerują nasi koledzy? Mam poważne wątpliwości. Aby użyć analogii: czy zmiany w silnikach samochodowych wpływają na istotę samego pojazdu? Oczywiście, mamy hybrydy, silniki elektryczne, wodorowe i auta autonomiczne, podczas gdy większość Afryki jeździ jeszcze na silnikach diesla z lat 80-tych i prawdopodobnie długo jeszcze to się nie zmieni, bo tam zmiany te nie są potrzebna lub są zbyt kosztowne. Czasem w rzeczywistości nie potrzebujemy większych zmian – samochód ma cztery koła od czasów Forda T, i niewiele na zmianie zyska, nawet jeśli może jeździć samodzielnie. To tylko wariacje dla leniwych, na których można dobrze zarobić.
Podsumowując, tych kilka przytoczonych argumentów sprawia, że mam poważne wątpliwości czy teza naszej debaty ma szansę się ziścić.
RUNDA III. KONLUZJE
Przemysław Staniszewski (Drużyna PRO)
Bardzo się cieszę, że dzisiaj o Low Code nie rozmawiamy tak, jak jeszcze kilka lat temu, na zasadzie „czy to ma sens”. Ponieważ i świat, i biznes dowiodły, że ten sens jest. Nie rozmawiamy też na zasadzie, że Low Code nadaje się wyłącznie do prostych aplikacji i makro z Excela, tylko rozważamy, kiedy Low Code znajdzie zastosowanie do budowy większości core’owych systemów.
Z wielu przykładów jasno widać, że rozwiązania wytworzone w Low Code nadają się do obsługi poważnych procesów, na przykład w firmach logistycznych czy farmaceutycznych – bo takie dzisiaj m.in. przykłady przytaczaliśmy na spotkaniu.
I może jeszcze kilka miesięcy temu zgodziłbym się z naszymi oponentami, że może nie „większość”, i może jeszcze nie „za 3 do 5 lat”, gdyby nie to, że byłem w październiku na konferencji CloudWorld w Stanach Zjednoczonych. Szef Oracle, Larry Ellison przez dobre 30 minut opowiadał ze sceny o Low Code. Nie dlatego, że w Oracle wynaleźli nowego Excell-killera i chcieliby, podobnie jak Microsoft sprzedać trochę dodatkowych licencji, tylko dlatego, że mają już tę platformę gotową – od dobrych 15 lat. To tak a ‘propos argumentu, jak szybko znikają platformy – sam Apex powstał w 1999 r.
Oracle uświadomił sobie podczas pandemii COVID-19, jak cenny skarb posiada, dotąd niedoceniany. W ciągu 60 dni stworzyli w LowCode aplikację, z której codziennie korzystało 140 milionów dorosłych Amerykanów, żeby monitorować stan zdrowia po szczepionce. Prawie każdy dorosły w Stanach Zjednoczonych miał to na swoim telefonie – wystarczy zapytać znajomych Amerykanów, będą wiedzieli, co to jest v-safe.
To oczywiście nie koniec. Oracle w ubiegłym roku kupił także największego dostawcę oprogramowania dla health care – Cerner. Wszystkie jej aplikacje są obecnie przenoszone na platformę Low Code. 70% aplikacji, które robi dziś Oracle powstaje w oparciu o platformę Oracle Express a docelowo wszystkie jej SaaS systemy będą napisane na platformie Low Code. Jeśli oni to robią – nie widzę powodu, aby inni nie mieli podążyć podobną drogą.
Może jeszcze nie dość jasno rozstrzygnęliśmy też kwestię dostępu do kompetencji Low Code. Czy w istocie nie ma milionów programistów Low Code? Pozornie może rzeczywiście wydawać się, że przytłaczająca większość programistów nie pracuje w Low Code – jeżeli poszukując ich np. w LinkedIn wpiszemy „citizen developer” czy „LowCode developer”. Ale to iluzja. Nikt tak tego bowiem nie nazywa – wszystkie platformy Low Code są stworzone w oparciu o pewien język, więc jeśli ktoś chce używać Apexa, to prawdopodobnie zna SQL’a, jak ktoś używa Outsystems, to zapewne zna .NET’a – itd. Tak właśnie należy dziś szukać programistów do Low Code, a nie „Outsystems specialist” albo „Mendix specialist”. I wówczas także odkopiemy ten „milion programistów”, którzy będą chcieli zareagować na naszą ofertę dołączenia do zespołu.
Nie rozumiem także argumentu ze start-up’ami, trzeba koniecznie się z nim rozprawić. Mam całkowicie odmienne doświadczenie współpracy ze start-up’ami. Co jest ważna dla nich? Niski koszt na początku i szybka walidacja. Co może lepiej się sprawdzić niż platforma LowCode, którą uruchomimy sobie w chmurze. Ten problem – odrzucenie Low Code przez start-up’y nie istnieje.
Pragnę więc odnieść się jeszcze do tezy naszej debaty: za 3-5 lat większość core’owych systemów będzie powstawała w paradygmacie Low Code. Większość – nie oznacza, że wszystkie, będzie zawsze miejsce dla hardcode. Co nie zmienia faktu, że w Low Code da się zrobić bardzo dużo rzeczy już dziś a tempo rozwoju gwarantuje, a co najmniej usprawiedliwia wyjściowe założenie. Ja także z moim własnym zespołem robiłem core’ową aplikację dla największej na świecie firmy mleczarskiej. Jeśli ktoś lubi serki President, to wie o czym mówię; stworzyliśmy core’owa aplikację dla największego na świecie reasekuratora, niemieckiej firmy i dla wielkiej firmy budowlanej, która w Polsce wykonała przekop Mierzei Wiślanej. To wszystko są działające dzisiaj kluczowe aplikacje. Naprawdę, nie widzę więc powodu, dla którego już dzisiaj za ich przykładem nie miałyby pójść inne firmy.
Ponadto, „większość” nie znaczy „wszystkie” i „wszystko”. Jeśli myślicie o jakimś dowolnym systemie kluczowym w waszej firmie, to prawdopodobnie możecie spojrzeć n niego przez pryzmat modułów, które obejmuje. My patrzymy na niego podobnie: nic nie stoi na przeszkodzie, aby migrować części, moduły tego systemu do Low Code, a nie od razu całość. To także są działające, chętnie realizowane przez naszych klientów strategie. Prowadzą one do tego, że uzyskamy stan większości, choć nie całości, kluczowych aplikacji w Low Code.
To koresponduje z ważnym przesłaniem: adaptacja Low Code, to nie musi być rewolucja, tylko ewolucja. W perspektywie 3 do 5 lat w waszych core’owych systemach, zapewne wiele się zmieni. Warto rozważyć, czy tych zmian nie wprowadzać już w Low Code.
Sławomir Panasiuk, (Drużyna KONTRA)
Chciałem na wstępie powtórzyć: w ciągu najbliższych 3-5 lat większość systemów core’owych nie będzie stworzona na Low Code, nawet jeśli większość stworzonych na Oracle – tak. Ale to przecież jeszcze nie cały świat.
Przede wszystkim, w ciągu 3-5 najbliższych lat większość core’owych systemów pozostanie takimi, jakimi są. Systemy kluczowe w przedsiębiorstwach zmieniamy bowiem nie częściej niż raz na 10 – 15 lat. Już choćby dlatego teza jest nieprawdziwa. W ciągu 3-5 lat nie nastąpi tsunami, które zmyje całkowicie krajobraz aplikacyjny w firmach.
Systemy core’owe są bardzo różne, łączy je to, że są oparte na przetwarzaniu danych, a nie tylko ich wizualizacji. Nową wizualizację można dodać do bazy danych, podobnie jak różne mechanizmy automatyzacji, ale nie jest to tworzenie nowego systemu. Nie dla większości systemów core’owych zresztą takie zmiany są możliwe do wprowadzenia. Choćby dlatego, że używamy różnych baz danych – Oracle, DB2, itd. a nie do wszystkich baz istnieją platformy Low Code.
Jest jeszcze kwestia kadr, która przewijała się w toku naszej debaty. Jeśli miałbym szukać programistów do Low Code wśród biznesu, to z doświadczenia mojej kariery 35 letniej mogę powiedzieć, że zdecydowanie więcej jest osób „kumatych” w kwestiach rozumienia procesów itechnologii wśród programistów niż wśród ludzi biznesu. Dlatego może być problem z zachęceniem biznesu do przejmowania na siebie programowania w Low Code większych czy mniejszych elementów. To się zdarza, ale wcale nierzadkie są sytuacje, kiedy biznes wcale nie garnie się do brania spraw w swoje ręce. I to symboliczne już przesunięcie przycisku na stronie o kilka pikseli staje się problemem – zrozumiała jest obawa, że popełni się błąd, dlatego niedoszli programiści wolą zapłacić dowolną wskazaną kwotę – byle nie brać za to odpowiedzialności. Wiele osób nie potrafi w pełni obsłużyć przecież smartfona, co zrozumiałe. W tej sytuacji nie można sobie wyobrazić, że większość systemów IT powstanie w Low Code nie dlatego, że nie znajdziemy „kumatych” ludzi w IT, ale nie znajdziemy ich dość w biznesie.
W dużej części systemów kluczowych ważna jest efektywność przetwarzania, nie ważne czy on-premise, czy w chmurze. Jeśli w chmurze – dużo przetwarzania wymaga dużego budżetu opex, jeśli on premise – uprzednich nakładów capex albo odpowiednio nastrojonego systemu. W platformie Low Code natomiast bazujemy na gotowym schemacie. Z pewnością są takie platform Low Code, które specjalizują się w przetwarzaniu, nie mam jednak pewności czy pisanie w niskopoziomowym języku nie będzie jednak wydajniejsze. Są takie rozwiązania w przedsiębiorstwach telekomunikacyjnych, finansowych, logistycznych, rządowych, które wymagają największych poziomów wydajności. W takim wypadku rezygnuję nawet z najpopularniejszego SQL, bo w dostępie do baz jest za mało wydajny.
I wreszcie, podsumowując już ten rosnący katalog przeciw zastosowaniu Low Code do wytwarzania systemów kluczowych, chciałbym wspomnieć o kwestii IT Governance. Nie widzę żadnych problemów z IT Governance w kontekście Low Code, o ile mamy do czynienia z dojrzałymi organizacjami. Trzeba bowiem tego od początku bardzo pilnować. W zasadzie nie chciałbym używać tego argumentu, że biznes coś robi bez nadzoru IT – w przypadku core’owych systemów są bowiem dużo większe wymagania, nie chodzi tylko o CyberSec, RODO. Wszystko w systemie kluczowym musi podlegać dobrze osadzonej i sprawdzonej konstrukcji. To z kolei nie jest dziś udziałem większości firm, które chciałyby budować w Low Code rozwiązania, także core’owe. Mam nadzieję, że tego nie zaryzykują, a jeśli zaryzykują, to obstawiam, że takie rozwiązania nie powstaną albo zawiodą. Co także sprowadza się do wsparcia naszej tezy.
Zbierając te wszystkie argumenty – teza, jakoby w ciągu 3 do 5 lat większość rozwiązań miała powstać w paradygmacie Low Code – jest nieprawdziwa.
