Jak popularność platform no-code / low-code wpłynęła na branżę IT? O tym rozmawiamy z Pawłem Fronczakiem, który przez ponad dziesięć lat pracował jako programista Salesforce’a. O czym za mało mówi się w kontekście no-code? Co mogłoby wesprzeć w popularyzacji tego podejścia? Tego dowiecie się z naszej rozmowy.
Co Twoim zdaniem jest głównym powodem awersji programistów do platform no-code?
Myślę, iż głównym problemem jest to, iż nie kojarzy im się to już z programowaniem. My programiści mamy ten niewątpliwy przywilej, iż większość z nas naprawdę lubi swoją pracę. I nie jej efekty, zarobki czy benefity, ale samą pracę – fakt rozbijania problemów i pisania kodu. A dodatkowo krajobraz na rynku przez ostatnich kilkanaście lat był tak korzystny, iż mogliśmy sobie dodatkowo wybierać najbardziej interesujący nas w danym momencie stack, technologie, branżę, wielkość firmy itd.
Więc jeżeli ci programiści widzą potem coś, co na pierwszy rzut oka programowania nie przypomina (ba, choćby w nazwie ma przecież “no-code”, czy “low-code”), to myślą, iż to bez sensu, bo odbierze im główny składnik “fun”-u w ich pracy.
Niektórzy boją się też zamknięcia na jeden ekosystem, jedną platformę. Obawiają się, iż nie będą konkurencyjni, iż będą mogli zatrudnić się już tylko w danej technologii “low-code”-owej. Z jednej strony rozumiem to – firmy zawsze chętniej wezmą kogoś, kto od kilku lat robi dokładnie to, w czym one się specjalizują, niż kogoś, kto nie zna danego stacku, ale obiecuje, iż gwałtownie to nadrobi. Natomiast to bolączka całej branży – choćby wybierając dany framework (powiedzmy React) jakoś się już profilujemy i łatwiej nam będzie znaleźć kolejną pracę w podobnym stacku.
Mówisz, iż korzystanie z rozwiązań typu co-code/low-code nie kojarzą się programowaniem. Jak jest więc w rzeczywistości? Jak od środka wygląda korzystanie z takich rozwiązań?
Tu mały “disclaimer”, iż większość mojego doświadczenia to w tej dziedzinie Salesforce, więc to o tej platformie głównie będzie odpowiedź na to pytanie, ale z tego co się orientuję w konkurencyjnych rozwiązaniach typu MS Power Platform, czy Appian wygląda to dość podobnie.
Po pierwsze, nasza low-code-owa aplikacja potrzebuje jakiegoś modelu danych do przechowywania informacji, więc mamy tu elementy projektowania schematu bazy danych (relacyjnej, czy obiektowej) – najczęściej bez zagadnień “infrastrukturalnych” typu replikacje, “shardy” itp., samo modelowanie encji.
Z drugiej strony, mamy interfejs użytkownika – prosty CRUD będzie najczęściej wbudowany w platformę, ale już jakieś bardziej skomplikowane przepływy, kreatory, wizualizacje trzeba będzie stworzyć samemu. Dla prostych ekranów wystarczą pewnie narzędzia typu drag-and-drop, bardziej skomplikowane będą programowane np. w Javascripcie (w Salesforce jest do tego dedykowany framework oparty na Web Componentach).
Gdzieś pomiędzy będzie jeszcze logika backendowa. I znów – najprostsze CRUD-owe API do bazy danych mamy dane “z pudełka”, nie trzeba go programować. Jakieś bardziej skomplikowane przepływy danych, czy integracje już tak – znowu, w prostych przypadkach “deklaratywnie” – rysując diagramy procesów, w bardziej skomplikowanych programując, w dedykowanym języku platformy (jak Apex w Salesforce), lub w jakimś uniwersalnym (JS i C# w Azure Logic Apps).
Także jest tu tak naprawdę sporo programowania – tylko takiego bardziej przypominającego rozwiązania “serverless”. To znaczy, iż realizujemy konkretną logikę biznesową, kawałek interfejsu, czy przepływy danych. Z kolei “bazę” w postaci infrastruktury, uwierzytelniania, podstawowych operacji (wspomniany CRUD) dostarcza nam platforma.
Poziom dojrzałości organizacji ma wpływ na postrzeganie rozwiązań typu no-code / low-code?
To trochę zależy czy pytasz o dostawców czy klientów. jeżeli chodzi o dostawców, to raczej częściej widzę stawianie na konkretną platformę, czy stack. jeżeli jesteśmy firmą zajmującą się wdrażaniem rozwiązań low-code, to będziemy je bardzo promować. jeżeli software housem tworzącym dedykowane oprogramowanie na zlecenie, to raczej będziemy uważali te rozwiązania za zbyt ograniczające.
Jeśli chodzi o klientów natomiast, to tak – wydaje mi się, iż dojrzałość organizacji, a dokładniej dojrzałość procesów w tej organizacji będzie miała duży wpływ na postrzeganie rozwiązań low-code/no-code. Bo te platformy (jak np. Salesforce), to nie tylko sam proces wytwarzania systemu, ale też często konkretne gotowe rozwiązania dedykowane różnym branżom, czy pionom w firmie (sprzedaż, obsługa klienta itp.).
Organizacje młodsze będą częściej zdania, iż “u nich to się robi trochę inaczej” (często słusznie) i taka platforma będzie dla nich ograniczająca. Organizacje większe, dojrzalsze, a szczególnie takie, które powstały przez serię akwizycji, czy fuzji i siłą rzeczy musiały zmierzyć się z problemem pogodzenia i uspójnienia swoich procesów, częściej dojdą do wniosku, iż w sumie to taką na przykład obsługę klienta, wszyscy na jakimś meta poziomie robią bardzo podobnie. Może wtedy lepiej zainwestować w jakiś sprawdzony proces, który dostosujemy pod nas?
Od kiedy i do czego używasz platformy no-code?
Przez ponad 10 lat pracowałem jako programista Salesforce. Ta platforma przeżyła w tym czasie dość ciekawą ewolucję swojej tożsamości tak naprawdę. Kiedy zaczynałem, mieli wręcz w swoim logo przekreślony znaczek “software” (tu przykład) i promowali się zdecydowanie jako platforma “no-code”. W praktyce wychodziło to różnie i w większości wdrożeń jednak sporo tego kodu powstawało.
Sam Salesforce też to w końcu zauważył i trochę zmienił swoje podejście, zaczął pracować dużo nad tzw. “developer experience”. Przykładem może być organizacja dużej, corocznej konferencji z myślą o deweloperach – TrailheaDX. Zaczął też promować się jako “platforma do tworzenia systemu w chmurze” już choćby nie jako “low-code”, chociaż moim zdaniem to była i jest platforma, gdzie duże ilości kodu dość gwałtownie stają się trudne w zarządzaniu. w tej chwili znowu widać zwrot w stronę “low-code” i automatyzacji procesów, które tworzy się nie kodem, ale przez wizualne edytory (tzw. flow).
A do czego go używałem? Ta platforma służy najczęściej do tworzenia systemów wsparcia sprzedaży i obsługi klienta. Nie znaczy to jednak, iż nie zdarzyło się budować całych systemów ERP a choćby portali dla użytkowników końcowych. Większość tej pracy to jednak była obsługa tego typu procesów wewnętrznych.
O czym za mało mówi się w kontekście no-code? Co mogłoby wesprzeć w popularyzacji tego podejścia?
Myślę, iż jeżeli chodzi o biznes / klientów, to takie podejście jest już dość popularne. Są to jednak rozwiązania, które drastycznie skracają tzw. “time to market”. Projekty wdrożenia aplikacji liczy się raczej w miesiącach niż latach.
Wśród programistów natomiast, tak jak wspomniałem wcześniej, warto popularyzować wiedzę, iż to nie jest zwykłe “przeciąganie strzałek”, ale iż często wymaga po prostu kodu, albo minimum programistycznego podejścia do analizy problemów. Bo, moim zdaniem mitem jest głoszona czasem przez twórców platform low-code teza, iż to są tak przyjazne narzędzia, iż każdy użytkownik będzie mógł swoje rozwiązanie low-code rozwijać sam – bez udziału IT. To nie jest “rocket science”, ale wymaga tak naprawdę dość programistycznego mindsetu, żeby działało.
Myślę, iż warto byłoby też pokazywać rozwiązania low-code na różnych konferencjach, czy meetupach dla programistów (bo w tej chwili te platformy mają raczej swoje własne konferencje, często bardzo biznesowe w swej naturze) – żeby przypominać, iż to też jest jedno z dostępnych nam narzędzi.
Na początku rozmowy poruszyłeś interesujący wątek profilowania się poprzez wybór “ulubionego” języka programowania. Da się coś zrobić, by uniknąć tego szufladkowania się?
Myślę, iż po pierwsze dobrze jest sobie uświadomić, iż to niekoniecznie jest “szufladkowanie się”. Trudno oczekiwać, iż przez całą naszą karierę programisty będziemy poruszać się w ramach tej samej technologii. Myślę, iż większość programistów wcale by tego nie chciała.
Nauka nowego narzędzia nie czyni z nas gorszych inżynierów – wręcz przeciwnie. Myślę więc, iż tak długo, jak traktujemy kolejne języki, platformy, frameworki jako narzędzia właśnie, a nie obiekty kultu, “wypadnięcie z obiegu” nam tak gwałtownie nie grozi (a przynajmniej taką mam sam nadzieję ;)). Mody się zmieniają, ale dobra inżynieria systemu i umiejętności miękkie pozostają zawsze aktualne.
Swój udział w tej obawie mają też niestety pracodawcy. Nie tak dawno temu szukałem właśnie ofert dla programistów front-end i mam wrażenie, iż spora część ogłoszeń wygląda trochę jak “poszukujemy osoby, która od 2-3 lat pracuje w dokładnie takim stacku technologicznym, jak my akurat teraz” – łącznie z frameworkami i narzędziami do budowania. Rozumiem, iż taka osoba będzie produktywna dużo szybciej i (szczególnie mniejsze) firmy niekoniecznie chcą inwestować w kandydata, który “nadrobi”. Niemniej w ten sposób tworzy się klimat, w którym pracownicy “boją się” zmieniać technologie i sięgać po rzeczy spoza swojej “bańki”. Na takim podejściu tracimy prawdopodobnie wszyscy.
Paweł Fronczak. Software Engineer w box. Inżynier z wykształcenia i zamiłowania. Pasjonat dobrego rzemiosła (nie tylko programistycznego). Prywatnie miłośnik natury.
