Efekt low. Wszystko o rozwiązaniach typu low-code

Anna Jabłońska: Coraz częściej słyszę o rozwiązaniach no-code i low-code. Czy mógłbyś wyjaśnić, na czym polegają?

Kamil Toszek: U podstaw obu tych technologii leży to samo. Bazują na platformach, które są udostępniane przez dostawcę narzędzia. Taka platforma low-code pozwala tworzyć oprogramowanie na podstawie gotowych elementów. To tak, jakbyś miała klocki Lego – w tym wypadku „klocki” to gotowe fragmenty kodu, z których użytkownik buduje np. aplikację.

Czym się od siebie różnią technologie no-code i low-code?

W przypadku no-code w ogóle nie ma programowania. Jest tylko interfejs graficzny, w którym wybiera się dostępne komponenty, takie jak „tabelka”, „przycisk”. Narzędzie nie wymaga od użytkownika znajomości jakiegokolwiek języka programowania, ale – oczywiście – nadal trzeba posługiwać się logiką programowania, to znaczy umieszczać te elementy – klocki – w określonym porządku, który zapewni aplikacji prawidłowe działanie.

Patrząc z mojej perspektywy analityka biznesowego: projektant musi wiedzieć, jaki dokładnie algorytm chce wprowadzić do aplikacji, tak samo jak w przypadku kodowania klasyczną metodą. W klasycznej metodzie potem do pracy przystępują programiści, którzy od zera kodują każdy element.

Tak, a tutaj korzystają z gotowych komponentów. Low-code działa podobnie, ale dodatkowo mamy możliwość dopisania fragmentów kodu – to taka hybryda między wyłącznie graficznym podejściem do budowy aplikacji a klasycznym kodowaniem od zera.

Mniej kodowania to krótszy czas pracy. Technologia low-code jest szybsza, więc w efekcie znacznie tańsza od klasycznego podejścia. To korzyści. Jakie są minusy?

Wadą takich rozwiązań jest konieczność związania się z jedną platformą, z jednym dostawcą. Platformy powstają jak grzyby po deszczu i część z nich z czasem może upaść. W przypadku tych stabilnych również jest ryzyko: jeśli w przyszłości dostawca zmieni cennik, możemy albo zaakceptować wyższe koszty, albo stworzyć aplikację od nowa gdzie indziej. Nie ma możliwości przeniesienia jej do innej firmy.

Zatrzymajmy się przy tym, co mówisz. Decydujemy się na korzystanie z usług platformy, która dostarcza gotowe elementy kodu i udostępnia interfejs graficzny do zarządzania nimi. Ryzyko jest takie, że aplikacja, którą stworzymy, jest przywiazana do tej konkretnej platformy. Czy to jest porównywalne do postawienia sklepu internetowego, np. na Shoperze?

Tak, to działa w podobny sposób.

Zatem, chcąc zmienić dostawcę usługi, nie mogę zabrać gotowego produktu, ale mogę zabrać dane, które tam umieściłam?

Dane, które tam wprowadziłaś, zazwyczaj można wyciągnąć, ale aplikacji nie przeniesiesz. Musisz zrobić ją od zera w innym miejscu.

To istotne ryzyko. Można je ominąć?

Szukając rozwiązania, stworzyliśmy własną platformę low-code do tworzenia aplikacji dla klientów jako narzędzie dla naszych deweloperów. Klientów nie obciążało to w żaden sposób, ponieważ dołączaliśmy tę „bazę klocków” jako dodatkową paczkę w ich gotowej aplikacji. Dzięki bazie elementów (np. formularz, tabelka) deweloperzy mogli szybciej budować narzędzia, głównie aplikacje biznesowe, do wewnętrznego użytku w firmie. Trudno było jednak znaleźć do tego programistów. Doświadczeni mówili: chcę programować, a nie wyklikiwać! Natomiast ktoś, kto zupełnie nie zna się na programowaniu, nie był w stanie z tego narzędzia korzystać, bo było low-code, czyli wymagało jednak pewnej umiejętności kodowania. Zrezygnowaliśmy z tego pomysłu i poszliśmy w stronę budowania bazy komponentów.