W tym odcinku dowiesz się czym jest no-code i low-code development, a także w jakich sytuacjach korzystać z tych metod tworzenia oprogramowania w swojej organizacji.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 41 – Jak to jest tym no-codem? W tym odcinku zajmiemy się tematem, który już parę razy pojawiał się na łamach podcastu. Mowa właśnie o technologii no-code, ale też low-code, bo naturalnie te dwa pojęcia są mocno ze sobą związane, natomiast w sumie nie było takiego stricte odcinka właśnie tym zagadnieniom, tym technologiom poświęconego, jest to trend w obu przypadkach, można powiedzieć już tak zbiorczo traktując, którym na pewno warto się zainteresować.

Wynika to z faktu, że w ostatnich latach po czasach pandemii, ale też nie da się ukryć pewnych zmian zachodzących w ciągu ostatniego roku w branży IT, kontekst oprogramowania jakby to powiedzieć bezkodowego czy niskokodowego, w sumie nie brzmi to najgorzej, staje się coraz istotniejszy.
W tym odcinku właśnie opowiem o tym, ile i jakie są rodzaje tych technologii, to znaczy właśnie czym się no-code od low-codu różni. Opowiem też trochę o takim szerszym kontekście i genezie tych technologii. Natomiast w jednym z najbliższych odcinków, nie wiem jeszcze czy to będzie następny, czy jeden z następnych, ale na pewno niedługo, opowiem już o też o konkretnych technologiach i takich bardziej dokładnych przykładach zastosowań.

Zacznijmy jak zawsze zresztą od definicji. No-code development, czyli tworzenie właśnie aplikacji bezkodowych to metoda tworzenia oprogramowania, w trakcie której nie używa się, nie tworzy się kodu źródłowego, kodu oprogramowania i co zatem idzie też, nie korzysta się z języków programowania. Nie jest to takie pojęcie powiedzmy ściśle naukowe, czasami gdzieś tam w tym podcaście podchodzimy do definicji bardziej poważnie, czasami są to pojęcia w pewnym sensie biznesowe, marketingowe i tutaj raczej mówimy o tym drugim pojęciu, więc jest to takie, powiedziałbym, pojęcie parasolowe zbiorcze. Krótko mówiąc, jeżeli jesteśmy w stanie uzyskać oprogramowanie w wyniku naszej pracy i w trakcie procesu tworzenia tego oprogramowania nie używaliśmy, nie tworzyliśmy żadnego kodu, to możemy mówić o takiej aplikacji no-codowej. Low-code z kolei, jakby to ta różnica między low a no, to po prostu kwestia tego, że w takich aplikacjach niewielka ilość kodu pojawić się może. Natomiast jest to z reguły zauważalnie znacząco mniejsza ilość kodu niż w przypadku tych aplikacji takich powiedziałbym tradycyjnych, tworzonych właśnie w językach programowania w uznanych już technologiach, które istnieją od dziesięcioleci.

Naturalnie definicja ta jest mocno nieprecyzyjna, mówimy tu o takich pojęciach względnych, co znaczy niewielka ilość kodu, brak kodu, to jeszcze może można uznać za chyba w miarę dokładne pojęcie, ale to czy kodu jest niewiele czy wiele w aplikacji to jest rzecz mocno względna. Można powiedzieć, że gdybyśmy wyciągnęli, tak przenieśli w czasie programistę/programistkę z lat 70 czy 80 i go tak tutaj umieścili w obecnych czasach to biorąc pod uwagę, jak czasami niewiele kodu trzeba napisać, aby uzyskać naprawdę dość skomplikowane efekty, na przykład nawiązać połączenie internetowe, pobrać dane z bazy danych, to taka osoba z przeszłości uznałaby, że w zasadzie wszystko, co teraz się dzieje to jest jedno wielkie low-code development, bo gdyby chcieli uzyskać takie efekty, właśnie te parędziesiąt lat temu to trzeba by poświęcić dużo więcej czasu i dużo więcej kodu, aby uzyskać taki efekt.

Co ważne, z uwagi na to, że ten podział między nauką a low-code nie jest też jakiś bardzo ścisły te definicje, tak jak wspomniałem, mają charakter biznesowy. To tak naprawdę wiele z technologii, o których będę mówił niebawem w zasadzie można przypisać do obu grup, bo często zdarza się po prostu tak, że niektóre aplikacje, jeżeli chcemy stworzyć to zaczynamy od aplikacji no-codowej i po prostu w pewnym momencie docieramy do momentu, kiedy na przykład dodanie jakiejś bardzo specyficznej funkcji do takiej aplikacji, wymaga napisania jakiejś drobnej ilości kodu. No i można powiedzieć, że wtedy formalnie nasza aplikacja staje się low-codowa, natomiast nie da się ukryć, że co do zasady użycie kodu przy takim podejściu niskokodowym jest w pewnym sensie ostatecznością.

Tak jak wspominałem, nie będę dzisiaj bardzo wchodził w przykłady technologii, ale warto zauważyć, że byście mieli chociaż jakiś taki kontekst, bardzo podstawowy, że stary dobry Microsoft Access część pakietu Office od czasów niepamiętnych obok Worda, Excela, Power Pointa, Outlooka oczywiście właśnie w tym elementem był Access. Tak naprawdę od kilku dziesięcioleci pozwala na nie tylko tworzenie prostych baz danych, ale także formularzy, raportów do nich. Co w praktyce i to nie jest jakaś taka naciągana teoria, można uznać Accessa, nie wiem czy pierwsze, bo to jest zawsze dyskusyjne, natomiast jedno z najważniejszych i najstarszych też narzędzi do tworzenia aplikacji no-codowych, które powstało zanim jeszcze ten trend na nowo został gdzieś odkryty. Choć oczywiście Access też miał sporo ograniczeń, bo Access pracował na plikach lokalnych, czyli tak naprawdę tutaj jakaś praca rozproszona nie wchodziła w grę, też w związku z tym praca wielu osób jednocześnie w zasadzie coś, co nie miało miejsca w Accessie, ale nie da się ukryć, że sama metodyka tworzenia aplikacji, to że naprawdę sporo ciekawych efektów funkcjonalnych dało się uzyskać w takim Accessie to jest coś, co pokazuje, że sam koncept istnienia aplikacji bezkodowych czy niskokodowych nie jest wcale taki nowy.

W tym odcinku chciałbym jednak wspomnieć o genezie, o przyczynie istnienia tego rodzaju technologii. Natomiast nie chodzi tutaj o rys historyczny, choć historię lubię, natomiast z tej genezy wynika też właśnie zastosowanie i przeznaczenie takich aplikacji. Idea istnienia technologii już tak w skrócie będę mówił bezkodowych, żeby wciąż się nie powtarzać. Więc idea istnienia tych technologii polega na tym, że kiedy tworzymy systemy informatyczne, aplikacje czy większe systemy, w taki tradycyjny sposób, ja tak się śmieje, że to tradycyjna metoda, to wciąż mówimy o technologiach, które mają kilkanaście, maksymalnie kilkadziesiąt lat, ale jest to względnie tradycyjna metoda. To jeżeli tworzymy oprogramowanie właśnie programując to wiele z takich typowych znanych funkcji systemów działa, funkcjonuje w bardzo podobny czy wręcz identyczny sposób. Weźmy pod uwagę choćby pierwszą z brzegu funkcję, jednocześnie też pierwszą funkcję, z którą z reguły styka się użytkownik niemalże dowolnego systemu informatycznego, jaką jest formularz logowania, czy też formularz rejestracji. Oczywiście dwa powiązane ze sobą mechanizmy i  myślę, że każdy z was widział jakiś, korzysta z jakiegoś formularza, natomiast logowanie może przebiegać oczywiście na wiele sposobów. Możemy się logować jakimś loginem czy mailem i hasłem, możemy się logować społecznościowo czy przez jakiegoś Facebooka, Google, Apple, LinkedIn, możemy się też logować na przykład numerem telefonu z kodem SMS, też jest to opcja. Więc choć jest tych metod trochę, to warto zauważyć, że tak naprawdę niezależnie od tego czy korzystamy z systemu księgowego, z poczty elektronicznej, z banku czy z jeszcze innej jakiejś ważnej aplikacji czy też mniej ważnej, to w zasadzie to logowanie przebiega bardzo podobnie. Można mieć jedno z kilku tych wariantów, które opisałem, ale tak naprawdę od strony można powiedzieć takiej merytorycznej, od strony domeny, dziedziny biznesowej to się w zasadzie niczym od siebie nie różni.

Te mechanizmy są powtarzalne, to jest takie słowo, które w kontekście właśnie tych systemów i przejścia do aplikacji bezkodowych jest absolutnie kluczowe. Jeżeli dany mechanizm niezależnie od aplikacji działa tak samo czy niemal tak samo, to po co wynajdywać koło na nowo, po co programować to raz po raz wręcz jest to można powiedzieć ryzyko związane z tym, że nie wiem, przy dziesiątym implementowaniu takiego mechanizmu ktoś się pomyli i zaimplementuje go źle.

Tego rodzaju ogólnych funkcji, które mogą być reużywalne, jest znacznie więcej. Możemy mówić chociażby o bramkach płatności, niezależnie od tego czy mamy jakiś wielki sklep i e-commerce platformę, za którą stoją rozbudowane systemy magazynowe czy jakiś prościutki sklepik na Wordpressie za pomocą wtyczki WooCommerce zrealizowany, a może mamy jakiś dedykowany system do umawiania wizyt i też obsługi płatności. Niezależnie od tego, co jest na tapecie, bramka płatności wygląda z grubsza tak samo. Oczywiście takie bramki płatności miewają różne opcje, szybkie płatności bankiem, obsługa płatności kartą, wirtualne portfele jak Google Play czy Apple Pay, Blik oczywiście naturalnie są tu opcje do ustawienia, do skonfigurowania, natomiast sam proces płatności przebiega praktycznie zawsze tak samo. Nawet na poziomie obsługi płatności mogą być pewne różnice, bo chociażby możemy mówić o płatnościach jednorazowych i płatnościach subskrypcyjnych, natomiast to jest niezależne można powiedzieć od konkretnego sklepu, od konkretnego systemu, tutaj tylko już ewentualnie model biznesowy związany z tym, w jaki sposób płatności powinny funkcjonować, decyduje, ale sama już powiedzmy branża czy rodzaj systemu znacznie ma mniejszy wpływ na to.

Jeszcze innym przykładem mogą być na przykład dashboardy, czyli taki dashboard-pulpit można powiedzieć, to co widzimy po zalogowaniu się do systemu, najczęściej w formie jakiś takich kafelków prezentujących podsumowania kluczowych informacji, często jakieś wykresy, jakieś tabelki z zestawieniami, taki widok executive summary, czyli najważniejsze informacje, które widzimy po zalogowaniu. Dashboardy są już ciekawym przykładem, bo to nie jest do końca coś, co można kopiować i wklejać pomiędzy systemami, bo jednak to jakie wykresy wyświetlamy czy to jakie informacje wyświetlamy w tabelkach to już wymaga pewnego dostosowania do systemu, ale wciąż mówimy raczej o dopasowaniu pod konkretne informacje, które są w tym systemie aniżeli nie daj Boże tworzenia mechanizmów, które rysują wykresy od zera, to nie powinno mieć miejsca. Więc jak widać, czasami jest to proste kopiuj wklej, czasami jest to kopiuj wklej i jeszcze coś tam podmień natomiast mówimy o funkcjach, które co do zasady nie powinny być implementowane od zera za każdym razem.

I tu dochodzimy do sedna, bo jeżeli takie dodatkowe funkcje może nie poboczne, ale funkcje, które siłą rzeczy stanowią tylko część systemu informatycznego, no właśnie nie wypełniają nam całej  treści tego systemu, jeżeli mamy do zaimplementowania pewne bardzo nietypowe procesy logiki biznesowej, jeżeli skala systemu sprawia, że konieczne jest jego nietypowe wdrożenie, niestandardowe wdrożenie w jakiejś chmurze, to wtedy być może rozsądniejszym podejściem byłoby stworzenie takiego systemu w sposób dedykowany i na przykład użycie pewnych programistycznych komponentów. Które pozwolą na to, żebyśmy tych wykresów nie musieli robić od zera, tych mechanizmów logowania, takie rzeczy też się dzieją, takie rzeczy też są możliwe. Tutaj wracam do takiego pojęcia, które już się w tym podcaście pojawiały, jak biblioteka, czyli najczęściej, kiedy tworzymy system, chcemy stworzyć na przykład, skorzystać z jakiegoś już opracowanego przez kogoś mechanizmu logowania to możemy pozyskać taką bibliotekę. Czasem są one darmowe, czasem są one płatne, natomiast nie musimy tego wynajdywać od zera. Ale co jeżeli system, aplikacja, którą chcemy stworzyć poza tymi funkcjami, o których mówiłem takimi powtarzalnymi, ma jedynie proste jak konstrukcja cepa zasady związane, z tym że mamy kilka jakichś tabelek na przykład informacje o klientach, o fakturach, o płatnościach, o pracownikach, mamy takich zbiorów danych, tabel kilka, może jakieś kilkanaście i jedyne co chcemy to po prostu skorzystać z nich, umożliwić jakąś prostą edycję, zarządzanie, dodawanie, czasami oczywiście też dodać jakieś proste zależności biznesowe, ale bez zbyt wyszukanych reguł i bez tego wszystkiego, co właśnie uzasadnia tworzenie systemów dedykowanych.

Jeżeli jesteśmy w takiej sytuacji, ale ja bym to porównał, że jeżeli dane, którymi chcemy się zajmować, można by zwizualizować sobie na kilku arkuszach w Excelu  i takie proste zarządzanie nimi na zasadzie wykonywania takich podstawowych operacji jak dodawanie, edycja, przeglądanie, filtrowanie czy też usuwanie to jest wszystko to, czego potrzebujemy to tak naprawdę może być, tak że tworzenie systemu informatycznego od podstaw nie będzie miało sensu. To jest właśnie taki moment, w którym warto się przyjrzeć technologiom no-codowym, low-codowym, bo one pozwolą nam na stworzenie takich źródeł danych, ich niejaką automatyczną obsługę za pomocą gotowych mechanizmów szybciej i z reguły taniej pozwolą na uzyskanie działającej aplikacji. Co ciekawe, mogłoby się wydawać, że ja jako osoba z firmy tworzącej oprogramowani dedykowane nie powinienem mówić takich rzeczy, ale tutaj to jest ciekawe, że nawet programiści  jeżeli no już tak się zdarzy, że mają taką aplikację stworzyć, to wcale tego nie lubią. Bo  to jest takie, jak to się mówi  to już nie jest tworzenie aplikacji, tylko klepanie ich, tak jakby to były jakieś aplikacje sprzedawane na kilogramy i jeżeli kogoś tak z doświadczenia wrzuci się do projektu, gdzie tylko takie operacje się wykonuje, to po dłuższym czasie można spodziewać się po prostu marudzenia, że jest to projekt nie rozwijający, że niewiele się z niego można uczyć.
I jakkolwiek, niekiedy marudzenie ludzi w branży IT i jest trochę przesadzone to akurat tu rozumiem to też jestem programistą, też takie aplikacje robiłem i to naprawdę na dłuższą metę jest po prostu strasznie nużące, także nawet od tej strony wdrożenie takiej prościutkiej aplikacji, rozwiązań typu no-code może mieć sporo sensu. Jednocześnie muszę też uczciwie przyznać, że no-code nie jest rozwiązaniem bez wad. Przede wszystkim mamy bardzo różne rozwiązania no-codowe na różnych licencjach, na różnych jakby zasadach funkcjonowania, natomiast z reguły prędzej czy później są to jakieś rozwiązania płatne i kwestia płatności, modelu w ogóle płatności, modelu licencjonowania i kontroli nad tym oprogramowaniem, które wytwarzamy jest dużym wyzwaniem. No bo w przypadku oprogramowania dedykowanego jak się ktoś dogada z firmą tworzącą takie oprogramowanie  to można się umówić na przekazanie praw majątkowych, praw autorskich i potem jak tak naprawdę firma, klient się rozliczy z takim dostawcą to z tym programem może zrobić wszystko. Natomiast w przypadku tych aplikacji no-codowych jest to znacznie rzadsza sytuacja i z reguły kontrola nad tym programem jest mniejsza. Trzeba się też liczyć z tym, że na przykład po wytworzeniu takiej aplikacji będą pewne koszty stałe koszty na przykład, per użytkownik czy per baza danych, czy per jakiś tam gigabajt transferu, różne są opcje. Jeżeli bardzo dużo osób zacznie korzystać z takich rozwiązań, ono mogą stać się naprawdę dość drogie, więc przede wszystkim też jakby pewnym problemem staje się potencjalnie migracja danych. Jeżeli na przykład uznamy nagle, że konieczne jest wyłączenie aplikacji, jej szybkie przeniesienie do innego systemu też trzeba się zorientować uprzednio czy w przypadku danej technologii no-codowej będzie to możliwe.

Kiedy więc stosować technologię no-codowe? Na pewno wtedy, kiedy mamy dość prosty problem do rozwiązania, niedużo budżetu i niedużo czasu. Dla mnie no-code jest świetnym rozwiązaniem tam gdzie mamy jakiś pomysł, mamy jakąś hipotezę i chcemy bardzo szybko zweryfikować czy ona ma sens, więc naturalnie kojarzy się to z takimi dwoma niby różnymi, ale jednak podobnymi środowiskami, czyli z jednej strony weryfikacją pomysłów, które powstały w korporacjach często oddolnie, bo na przykład uzyskanie dużego budżetu i czasu na development jest często wtedy niemożliwe albo uzyskanie mniejszego budżetu, mniejszego czasu po to żeby wdrożyć rozwiązanie na start i potencjalnie, jeżeli ono zacznie przynosić efekty, zacznie spełniać jakieś KPI, czyli wskaźniki skuteczności to jest szansa wtedy na porządny rozwój oprogramowania. Z drugiej strony startupy, chodź tutaj ja bym powiedział, że raczej mówimy o bardzo wczesnym etapie rozwoju startupów, bo dla startupów ważną wartością jest posiadanie praw własności intelektualnej, co w przypadku aplikacji no-codowych, ich zależności od dostawcy może być trudne, ale jeżeli na przykład chcemy szybko zrobić jakiś proof of concept, pokazać coś inwestorom, żeby zyskać kolejną rundę finansowania to już jest zupełnie inna kwestia i wtedy to może mieć sens. Także nie wykluczam oczywiście tego, że można stworzyć aplikację no-codową, która będzie sobie funkcjonować produkcyjnie, nawet dla wielu użytkowników przez lata natomiast na pewno, to czym no-code jest w stanie pokonać takie tradycyjne aplikacje dedykowane, to jest właśnie sytuacja dużych ograniczeń a jednocześnie chęci weryfikacji jakiegoś pomysłu biznesowego, który został opracowany.

Na tym kończymy dzisiejszy odcinek, mam nadzieję, że co nieco rozjaśniłem kwestie technologii niskokodowych, choć zdaję sobie sprawę, że mógłbym powiedzieć jeszcze o tym i owym. Natomiast nie jest to nasze ostatnie spotkanie w tym kontekście, będę chciał omówić konkretne technologie przy okazji jednego z najbliższych odcinków. Bardzo możliwe, że jeszcze wtedy coś mi przyjdzie do głowy z takiego wprowadzenia i pozwolę sobie wtedy od tego zacząć. Natomiast ten jeden z kolejnych odcinków będzie już nastawiony na to, które technologie warto wybrać w swoich organizacjach, a tutaj też mamy do czynienia z dużą różnorodnością modeli biznesowych, koncepcji, od strony technologicznej też podejścia. Technologii jest bardzo wiele, bardzo różnorodnych, natomiast w zasadzie one wszystkie mają spełnić ten cel, jakim jest tworzenie aplikacji szybciej i często bez tak dużej wiedzy technologicznej, jak w przypadku tworzenia aplikacji dedykowanych.

A teraz pozostaje mi podziękować za uwagę. Kłaniam się nisko i do usłyszenia.

KONIEC