Za i przeciw platformom Low Code – głos praktyków

Adam Kasperowicz, Grupa VAN

Low Code pozwala pracować wspólnie – znamy wówczas zarówno ograniczenia jak i korzyści tego rozwiązania Po początkowych tarciach, można uzyskać takie porozumienie, które pozwoli wspólnie decydować jakie parametry powinien mieć rozwiązanie, które powstaje. Takie podejście – takie porozumienie w firmie i 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 efekcie, w okresie 3-5 lat większość systemów ma szansę być wytwarzana w tym paradygmacie.

Po trzecie Low Code zwycięży, bo rozwiązuje temat utrzymania zespołu. Przykładowo, w moim wypadku dzięki Low Code udało się zintegrować pracę zewnętrznego zespołu doświadczonego w Low Code oraz 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ą. Po pierwsze sprawia to, że przyrosty wytwarzania naszego rozwiązanie pochodzą z wielu źródeł. A po drugie, zapewnia nam bezpieczeństwo, stabilność w obecnej sytuacji niedostatku wykwalifikowanych pracowników na rynku.

Trzeci element to fakt, że LowCode upraszcza stos technologiczny. 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.

Platformy Low Code to również „oszczędność”: uproszczenie architektury to zmniejszenie licencji, uproszczenie to standaryzacja, to wspomniane zbliżenie z użytkownikami, które owocuje szybszym dostarczaniem i mniejszą liczbą błędów we współpracy. Finalnie szybciej i bez pośrednictwa analityków zaspokajamy potrzeby informatyczne firmy. Dlatego uważam, że większość core’owych systemów wykorzystywanych przez firmy będzie w perspektywie 3-5 lat powstawać w paradygmacie Low Code.

Jacek Chmiel, dyrektor Avenga Labs

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.

Weźmy taki start-up’y, obserwuję je 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 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.

Obecnie 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.

Warto wspomnieć też 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.

Michał Jurkowski, VSoft

Low Code to kontynuacja nurtu, który dążył do uproszczenia i przyspieszenia programowania. Co zatem zmienia się 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 słyszymy w odniesieniu do platformy Low Code.

Rozwój postępował w stronę wizualizacji, aby operować na wyższym poziomie abstrakcji. Co więcej, 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.

A co do argumentu o dostępności specjalistów. Owszem, więcej jest programistów Java, a 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 – 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 tylko 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, CIO EG

Co do argumentów, ż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.

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ć.

Przemysław Staniszewski, CEO Pretius Low Code

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.

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ą.

Co do 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ślimy o jakimś dowolnym systemie kluczowym w naszej firmie, to prawdopodobnie możemy spojrzeć na 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, VP i CIO KDPW

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.

Jest jeszcze kwestia kadr. 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 i technologii 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.