Szybki jak Low Code

Na konferencjach Low Code rozmawiamy dziś przede wszystkim o szybkości dostarczania aplikacji – mówi Manoj Nair, Head of Digital Transformation w C&F. To właśnie skokowy przyrost szybkości dostarczania aplikacji – a więc i efektywności pracy programisty – decyduje o coraz większej popularności Low Code, także w silnie regulowanych sektorach gospodarki.

Czy z perspektywy C&F obecna fala wdrożeń platform Low Code ma charakter przełomowy? Czy ich czas nadszedł ze względu na deficyt pracowników w IT, cyfryzację środowiska pracy i procesów biznesowych, popyt na przestrzeń do szybkich zmian, wprowadzanych również przez biznes?

Myślę, że jest nawet więcej czynników, które powodują, że rozwiązania Low Code spotykają się z zainteresowaniem firm. Pracujemy z tą technologią już 8 lat i owszem, zawsze wśród jego głównych zalet wymienia się właśnie szybkość wytwarzania oprogramowania. Ale Low Code to znacznie więcej: zdecydowanie niższy poziom kosztów wdrożenia, licencji i utrzymania, a także dużo prostszy sposób zarządzania zmianami i aktualizacjami, co jest znakomitą receptą na dług technologiczny.

Te obserwacje zdecydowały zresztą o podjęciu przez naszą firmę poszukiwań alternatywy dla rozwiązań powstających w tradycyjnych, wysokokodowych językach programowania. Nasze poszukiwania ostatecznie zwieńczyły współpracę z firmą OutSystems.

Co wyróżnia ofertę tego dostawcy?

Gotowy produkt i nastawienie na szybkie budowanie aplikacji – tak, żeby biznes mógł wykorzystać swoje pomysły, dopóki są świeże. Takim wyróżnikiem jest więc m.in. radykalne przyspieszenie tzw. Time to Market. OutSystems pozwalał również od początku budować aplikacje bezpieczne i skalowalne, co dziś jest standardem w kategorii Low Code, ale 7-8 lat temu nie było tak oczywiste.

Najważniejsza jednak w Low Code jest szybkość budowania aplikacji…

Zdecydowanie – za pomocą takich rozwiązań aplikacje powstają 4-5 razy szybciej, niż przy użyciu tradycyjnych narzędzi i języków programowania. Gdyby chcieć utrzymać takie tempo tradycyjnymi metodami – i gdyby to było możliwe – to kolejne etapy życia aplikacji, a więc utrzymanie i rozwój, pochłonęłyby nieporównanie więcej zasobów zespołu IT. Mówiąc krótko – nie wystarczyłoby programistów i specjalistów od utrzymania.

Może zatem jeszcze lepiej byłoby, gdyby zamiast na Low Code postawić na No Code?

Niekoniecznie. Koncepcja No Code ma bardziej ograniczone zastosowanie. Trudno sobie przecież wyobrazić wytworzenie przez citizen developerów większego systemu o znaczeniu krytycznym. Trudno też wyobrazić sobie, że nagle masowo zaczną powstawać fragmenty procesów, albo i całe procesy, osadzone poza ramami zdefiniowanej, zrównoważonej i zabezpieczonej architektury. Low Code ma służyć zwiększeniu efektywności pracy deweloperów, a nie namaszczaniu na deweloperów osób, które nie mają do tego odpowiednich kompetencji, ani nie mają na to czasu, ponieważ już realizują inne zadania. Chwila prawdy przychodzi również w momencie testów takich produktów i ich integracji – aplikacje powstałe w Low Code integrowane są w zasadzie automatycznie i natychmiastowo.

Jak to udoskonalenie odbierają sami programiści?

Opór wewnątrz firmy jest na początku niekiedy silniejszy niż zewnętrzna konkurencja, oferująca inne rozwiązanie. Programiści obawiają się, że platforma Low Code zabierze im pracę. Jednak dość szybko okazuje się, że to środowisko nie tyle zabiera pracę, co po prostu mocno ją zmienia. Z reguły na lepsze, bo eliminuje z niej elementy powtarzalne i żmudne.

To tylko obawy o utratę pracy, czy także o możliwości sprawowania kontroli nad wytwarzaniem oprogramowania i w efekcie – utratą bezpieczeństwa i spójności przez całość?

Oczywiście, obawy dotyczą również ryzyka chaosu, jaki może wywołać Low Code za sprawą zbyt dużej szybkości wytwarzania aplikacji. Z drugiej strony, spotykamy się często z niedowierzaniem, że w tym narzędziu można wytworzyć, przykładowo, system do obsługi kilkuset tysięcy użytkowników.

Aby przekonać potencjalnych klientów do możliwości Low Code, zabiegamy zawsze o zgodę na przeprowadzenie projektu PoC, który pozwoli zweryfikować, czy wskazane zadanie da się wykonać — i w jakim czasie. Pamiętam wiele projektów PoC, kiedy w ciągu kilku godzin byliśmy w stanie przedstawić rozwiązanie, którego wytworzenie przy tradycyjnym podejściu wymagałoby kilku dni pracy, a na bieżąco zgłaszane ewentualne zmiany w zakresie wprowadzaliśmy na bieżąco.

Na kanwie takich wniosków możemy szybko dojść do porozumienia z doświadczonymi programistami. Dla nich będzie to narzędzie automatyzacji pracy, przyspieszenia jej, ale także sposób na wprowadzanie do zespołu młodszych programistów. Co więcej, praca w Low Code to również sposób na rozwinięcie skrzydeł w nowych obszarach, np. w zakresie budowy aplikacji webowych i mobilnych, lokowania nowych aplikacji w chmurze, czy tworzenia aplikacji typu Cloud Native bez dodatkowych etatów dla specjalisty od sieci, chmury czy bezpieczeństwa.

Podejście niskokodowe w naturalny sposób wspiera też koncepcję DevOps, a poszczególne platformy Low Code najczęściej pozwalają na łatwe zarządzanie rozwiązaniami wytworzonymi przy ich użyciu, a także monitorowanie ich wydajności. Możliwość szybkiej identyfikacji ewentualnych błędów oraz ich usuwania w celu doskonalenia wydajności jest istotą podejścia Low Code.

Wiele firm oczekuje jednak możliwości dostosowania rozwiązań do specyficznych, często unikalnych potrzeb. Jak odnajduje się tu podejście Low Code?

Bardzo dobrze. Jeśli chodzi o możliwości dostosowywania rozwiązań do potrzeb i pomysłów biznesu na nowoczesnej platformie Low Code, to nie ma w zasadzie żadnych ograniczeń. Podstawowe elementy można dowolnie, na własne potrzeby oprogramować. Inaczej jest w przypadku No Code, gdzie producent platformy zapewnia najczęściej mocno ograniczoną liczbę szablonów dla danej usługi.

Od czego zależy efektywność podejścia Low Code?

Takich czynników jest kilka, ale najważniejsze znaczenie ma skala użycia. Proszę pamiętać, że w projektach IT, a takimi są projekty aplikacyjne, chodzi o uzyskanie jak najlepszej stopy zwrotu z inwestycji. W przypadku platform Low Code wskaźnik ROI jest sensowny, gdy osiągnie się pewną skalę ich wykorzystania. Przykładowo, nie ma sensu zaprzęganie platformy Low Code w celu zbudowania i rozwoju pojedynczej aplikacji. Korzyści zaczynają się wtedy, gdy wpiszemy tę technologię w strategię rozwoju środowiska aplikacyjnego, określając np., że większość aplikacji wewnętrznych ma powstawać w modelu niskokodowym. Należy przy tym pamiętać, że aplikacje zbudowane w podejściu Low Code powinny dobrze obsługiwać wewnętrzne procesy, automatyzować obszary pracy manualnej, zwiększać produktywność klienta wewnętrznego oraz poziom jego samoobsługi. Z drugiej strony, ich zadaniem niekoniecznie powinno być np. podnoszenie poziomu doświadczeń klienta (Customer Experience).

Czy platformy Low Code nadają się do modernizacji i integracji krytycznych systemów, opartych na starszych technologiach?

Oczywiście – i często są do tego wykorzystywane. Nie bez powodu. Proszę zauważyć, że dostawcy oprogramowania biznesowego coraz częściej postanawiają przenieść swoje rozwiązanie do chmury i zachęcają, a czasem wręcz zmuszają klientów, aby przeszli na model cloud computing. Klienci są w takiej sytuacji postawieni pod ścianą, a do tego okazuje się, że migracja nie jest – bo przecież nigdy nie jest – bezproblemowa. Koszty rosną.

Low Code oferuje tu alternatywę. Pozwala bowiem na łatwe skopiowanie funkcjonalności i integracji do nowych aplikacji. Rok temu zrealizowaliśmy projekt dla klienta, który na całym świecie miał ponad 15 systemów instalacji SAP i musiał przenieść je do środowiska SAP HANA, odtwarzając połączenia z kilkudziesięcioma kluczowymi systemami dla każdej instancji SAP. Po przekalkulowaniu czasu, kosztów i zasobów, niezbędnych do realizacji takiego projektu w tradycyjnym podejściu, zdecydowano się na obudowanie standardowej implementacji SAP HANA własnymi, wytworzonymi z użyciem podejścia Low Code aplikacjami, które zapewniają niezbędne, dostosowane do biznesu funkcje i integracje. Dzięki temu możliwe było istotne skrócenie czasu realizacji projektu. Osiągnięto także znaczące oszczędności na kosztach licencji SAP.

Aplikacje Low Code często zastępują w ten sposób klastry funkcjonalne złożone z wielu, często przestarzałych systemów zbudowanych na przestrzeni lat do obsługi jakiegoś procesu. Często służą też do realizacji innowacyjnych pomysłów, które jeszcze nie są gotowym produktem. Aplikacja Low Code powstaje szybko i ma przez to większą szansę przeistoczyć się w faktyczny produkt, zdążyć przed konkurencją i wpisać się w rynkowy timing.

Zapewne koszty takich eksperymentów produktowych są również mniejsze – podobnie jak obawy przed ich zamknięciem w razie niepowodzenia…

To prawda. Takie jest generalnie nastawienie. Za sprawą podejścia Low Code możliwa jest też zmiana struktury kosztów w środowiskach aplikacyjnych.

Dawna struktura budżetu przy wdrożeniach systemów zakładała przeznaczenie 80% środków na utrzymanie i wsparcie, a jedynie 20% na rozwój aplikacji. Dziś te proporcje się odwróciły, również za sprawą Low Code. Innowacja stała się kluczowa z punktu widzenia klienta.

Czy aplikacje zbudowane na podstawie koncepcji Low Code można przenosić pomiędzy różnymi platformami?

To ważna kwestia dla wielu firm. Dlatego od początku szukaliśmy rozwiązania, które zapewnia taką możliwość. W 2015 roku w zasadzie jedynie OutSystems pozwalał na budowę aplikacji, które można przenieść do .NET lub Javy. Obecnie nadal wspierana jest transkrypcja do .NET. Sprawdzaliśmy jego możliwości dla dużego systemu i w ciągu 4-5 dni udało się uzyskać bardzo przyzwoity wynik.

Jest to oczywiście ważna opcja w przypadku tworzenia kluczowych systemów. Dotychczas jednak nie mieliśmy jeszcze okazji asystowania klientowi w takim powrocie. Żaden z naszych klientów nie zrezygnował z implementacji OutSystems ani wytworzonych na platformie systemów.

Decydująca była z pewnością kwestia komfortu, wygody, jaką oferuje ta platforma. Jest to bardzo ważny element całej układanki: platformyLow Code oferują zwykle katalog gotowych konektorów z  popularnymi systemami i usługami. Jeżeli więc pojawia się pomysł na użycie ChatGPT, to można zrealizować od ręki. W ramach platformy OutSystems można także samemu budować konektory do innych środowisk i platform. Wówczas elementy naszego rozwiązania możemy wykonywać w technologiach, takich jak: .NET, HTML,CSS czy JavaScript – w efekcie powstają rozwiązania, które znacznie wykraczają ponad to, co oferuje platforma Low Code.

To wymóg ważny w przypadku dużych organizacji, potrzebujących skalowalnych aplikacji, które można łatwo dostosowywać do potrzeb i od podstaw rozwijać w architekturze kontenerowej lub chmurowej. Platformy, które zaspokajają podobne potrzeby, są dziś niezwykle pożądane na rynku, ponieważ dzięki nim można skupić się na logice biznesowej aplikacji, a nie na upewnianiu się, że będzie w danym środowisku działać.

W dyskusji podczas spotkania CXO HUB pojawił się zarzut, że platformy Low Code mają krótki czas życia, a więc istnieje duże ryzyko wyboru takiej, której rozwój zakończy się w ciągu kilku lat. Ile jest dziś na rynku pewnych, stabilnych platform Low Code, spomiędzy których można wybierać?

Obecnie możemy mówić o kilku najbardziej stabilnych – i najlepiej prosperujących – rozwiązaniach, które wymienia także Gartner: OutSystems, Mendix, Microsoft, Salesforce. Platformy te obecne są na rynku od ponad 10 lat i mają wciąż rosnący portfel klientów.

Jakich wzrostów efektywności pracy deweloperów można oczekiwać od rozwiązań Low Code?

Aplikację, która w tradycyjny sposób powstaje w 6-12 miesięcy, w podejściu Low Code można zakończyć w 2-3 miesiące. Oczywiście nawet w tak krótkim czasie może się zdarzyć, że klient końcowy zażyczy sobie zmian w trakcie projektu. Low Code doskonale sobie z taką dynamiką projektową radzi — implementacja pojedynczych zmian zajmuje minuty, zaś tworzenie nowych funkcjonalności to kwestia godzin, maksymalnie tygodni.

Jak złożony jest proces aktualizacji platformy Low Code, na której przecież opierają się aplikacje biznesowe?

Firmy bardziej konserwatywne, które decydują się na wykorzystanie platformy Low Code w modelu on-premise, same decydują o czasie i trybie aktualizacji, oczywiście przy wsparciu dostawcy.

Sytuacja doskonale się upraszcza, kiedy mamy do czynienia z platformą Low Code działającą w modelu chmury obliczeniowej. Wówczas utrzymanie jest całkowicie pomijalne, a klient i my, jako partner wdrożenia, otrzymujemy tylko informację o planie wdrożenia aktualizacji. Jeśli nie zgłosimy uwag, to stosowna zmiana zostanie automatycznie wprowadzona w określonym czasie.

Jednocześnie, gdyby po takiej aktualizacji pojawił się problem, można natychmiast cofnąć się do kopii zapasowej sprzed wdrożenia. Te funkcje są opłacone w kosztach licencji – nie wymagają dodatkowych kosztów ani stresu związanego z wielką migracją. Najczęściej raz na 1-2 lata pojawia się nowa wersja platformy, ale wówczas jej aktualizacja także nie jest bardzo czasochłonna ani ryzykowna – zajmuje przeciętnie 12–24 godziny. To zupełnie inna skala, niż przy migracjach standardowego oprogramowania.

Każda migracja kojarzy mi się jednak z ryzykiem – w jaki sposób systemy zbudowane w Low Code mogą je niwelować?

Zawsze jest ryzyko, ale w Low Code jest też możliwość natychmiastowej reakcji. Platforma sama identyfikuje obszary i elementy, które źle przeniosły się do nowej wersji i wymagają naprawy. Najczęściej są to po prostu obszary i elementy, które zostały wytworzone poza szablonem i wobec tego wymagają ręcznej interwencji.

Takie podejście zdecydowanie skraca czas i problemy związane z migracją – wszelkie błędy obsługuje się w praktyce na bieżąco. Trudniejsze zmiany mogą być też eskalowane do producenta, ale ciągle jest to nieporównanie mniejsze odciążenie niż przy tradycyjnym podejściu. De facto nie testujemy też kodu aplikacji, ale całe procesy biznesowe.

Czy największej konkurencji dla podejścia Low Code nie stanowią dziś rozwiązania oparte na generatywnej AI? Dlaczego programista miałby korzystać z platformy Low Code, skoro wirtualny asystent może wygenerować kod aplikacyjny za niego?

Moim zdaniem przyszłość to właśnie Low Code plus AI. Sztuczna inteligencja już dziś bardzo dobrze pomaga platformom Low Code w budowie aplikacji. Podpowiada gotowe fragmenty, które powinna zawierać. To wydatnie przyspiesza pracę. Szczególnie początkującym programistom. Pozwala również na zachowanie pełnej kontroli nad sposobem działania aplikacji.

Do czego na pewno nie nadaje się Low Code?

Na pewno nie nadaje się do tworzenia gier. Nie pomoże też w tworzeniu zaawansowanych rozwiązań do zarządzania danymi. Nie ma również sensu tworzyć w Low Code samych modeli i narzędzi AI – choć aplikacje powstałe w Low Code w naturalny sposób z takimi rozwiązaniami współpracują.

Co można powiedzieć o podejściu do koncepcji Low Code w Polsce?

Mam wrażenie, że o możliwość użycia Low Code zabiegają zwłaszcza firmy z sektorów silnie regulowanych. Przykładowo, szczególnie po doświadczeniu wojny na Ukrainie, widzimy wiele zapytań dotyczących wykorzystania Low Code w modelu chmurowym ze strony sektora bankowości.

Jest to o tyle istotne, że Low Code pozwala szybko wytwarzać aplikacje, które będą natywne w środowisku chmurowym. Oznacza to podwójną korzyść. Po pierwsze – jest to możliwość szybkiego wytworzenia działających narzędzi, które przejmować będą funkcje od starzejących się  monolitycznych systemów on-premise. Po drugie, umieszczenie nowych aplikacji w chmurze pozwala zniwelować ryzyka zatrzymania biznesu wskutek, dajmy na to, sabotażu infrastruktury centrum danych.

Również rynki farmaceutyczny, medyczny – nawet silniej regulowane niż bankowy – mają coraz więcej doświadczeń i z ich strony pojawia się coraz więcej zapytań o Low Code. W ich przypadku podejście niskokodowe oznacza szansę nadrobienia opóźnień w transformacji cyfrowej.

Co ciekawe, na polskim rynku coraz częściej padają pytania o środowisko Low Code zintegrowane z AI. Prowadzimy rozmowy z klientami z branży spożywczej, którzy poszukują ciekawych scenariuszy użycia dla takich rozwiązań.

Wszystko to jedynie potwierdza prognozy Gartnera dla rynku Low Code, który z ok. 15 mld USD przed 5 laty urosnąć ma nawet do 50 mld w ciągu 2-3 kolejnych lat. Jest na to rynek, także w Polsce.

Jakie nowe kompetencje związane z podejściem Low Code są potrzebne, aby efektywnie z tego podejścia korzystać?

Jako dostawca, zapewniamy platformę, pomagamy zbudować pierwszą aplikację i wspieramy lokalny zespół. Może to być początek drogi do uruchomienia własnego centrum kompetencji Low Code, ale widać, że polskie firmy nie są zainteresowane tym, żeby utrzymywać powstające aplikacje we własnym zakresie. Nie jest zatem potrzebny liczny zespół czy specjalne kompetencje.

Na początku wystarczy doświadczony programista, znający architekturę i jeden czy dwóch deweloperów na poziomie nawet juniora. Praktyka pokazuje, że po kilku miesiącach będą oni w stanie samodzielnie dostarczać i utrzymywać aplikacje, zastępując de facto cały liczny dział oprogramowania.

Efektywność, która jest znakiem firmowym Low Code, ma dwa oblicza. Z jednej strony jest to zdecydowanie większa szybkość dostarczania aplikacji, a z drugiej — o wiele większa łatwość utrzymania wielu aplikacji przez nawet pojedynczego programistę.