Ostatnio na jednym z portali społecznościowych trafiłem na dyskusję dotyczącą rozwiązań low-code/no-code. Jak zazwyczaj, w dowolnej dziedzinie, tak i to podejście ma zarówno zagorzałych zwolenników jak i żarliwych przeciwników. Ja osobiście jestem raczej (choć nie maniakalnie) „za” chociaż dostrzegam tu też pewne problemy czy wyzwania – o tym później. Ponieważ jednak bliżej mi do „sympatyków” z dość dużym zainteresowaniem przyglądałem się głosom „przeciw”. We wspomnianej dyskusji udało mi się wytypować trzy typy opinii, które dotyczyły potencjalnych słabości low-code.
Na poziomie ogólnym – oprogramowanie no-code ma za zadanie dostarczyć funkcjonalność bez konieczności znajomości jakiegokolwiek języka programowania. Całość „składania” aplikacji sprowadza się jedynie do jej konfiguracji – często z użyciem metody „przeciągnij i upuść”. I tak np. popularny system CMS WordPress używany do tworzenia stron internetowych możemy traktować jako no-code w zakresie „wykilkania” prostej strony internetowej, czy nawet z użyciem kilku pluginów, sklepu online. Zatem koncepcja no-code jest adresowana przede wszystkim do odbiorców nietechnicznych. Jeśli zaś chodzi o low-code – to podejście zakłada, że użytkownik takiej platformy ma podstawową wiedzę programistyczną gdyż poza samą konfiguracją, jak w przypadku no-code, potrzebne może być również „oskryptowanie” jakiejś części funkcjonalności – i ponownie, wracając do WordPress’a, możemy tam utworzyć własny plugin w języku PHP, który np. wyświetli prognozę pogody. Oczywiście w tym celu nie będziemy „tworzyć” algorytmów prognozy pogody a po prostu wykorzystamy kawałek kodu dostawcy, który tym się zajmuje a my dopasujemy jego wygląd do szaty graficznej naszego www.
No dobrze, ale gdzie tu biznes? Przecież strona internetowa w biznesie to nie wszystko, to nawet nie początek. Sam biznes, czym by się nie zajmował, zawsze generuje określone dane, pracuje na tych danych czyli je procesuje. Na podstawie tych danych zawsze powstają jakieś procedury – najprostszy przykład – obieg faktury kosztowej w firmie. Faktura trafia do sekretariatu (dane to kontrahent, kwota, nr rachunku bankowego itd.). W tej konkretnej firmie sekretariat „wrzuca” FV do kuwetki szefa działu, który dany koszt wygenerował. Szef działu na odwrocie FV zapisuje notatki dla księgowości i przekłada FV do kuwetki prezesa. Prezes podbija pieczątkę „zaakceptowano” i kieruje „papier” do działu księgowości. Księgowość reguluje należność i chowa „papier” do odpowiedniego segregatora. Czy obieg FV kosztowej w każdej firmie tak wygląda – oczywiście nie. Może różnić się zarówno ilością kroków jaki i ich kolejnością. Dla biznesu właśnie w takich miejscach, świetnie sprawdzą się systemy typu low-code. Za ich pomocą można łatwo zamodelować dane oraz ich przepływy pomiędzy użytkownikami – i nie chodzi tylko o wspomnianą FV kosztową, to mogą być dowolne dane i dowolne procesy od wniosku urlopowego, poprzez wsparcie zamówień i rozliczeń z dostawcami czy obsługi reklamacji do bardzo specyficznych branżowych przypadków użycia.
Wracając do zaczerpniętych od społeczności opinii na temat potencjalnych słabości low-code:
To pewnie zależy od konkretnego narzędzia. Jeśli przyjrzymy się np. formularzom google to tak, faktycznie, możemy wydać użytkownikowi formularz (nawet dość złożony) i jak go wypełni to dane zapiszą się w arkuszu na dysku google – przydatne np. jak szybko jakąś ankietę potrzeba „wyklikać”, ale zgoda, funkcjonalność raczej ograniczona (i nie to żebym krytykował, bardzo lubię google formy.
Natomiast jeśli, jak we FlowDog, oddzielimy warstwę modelu dziedziny od warstwy logiki biznesowej (procesów) i do tego dodamy warstwę raportową to okazuje się, że potrafimy pomóc biznesom w planowaniu produkcji, zarządzaniem kolejką załadunku/rozładunku towarów, obsługiwać procesy reklamacji w sieci supermarketów, zarządzać usługami projektowania wnętrz, rozliczać z NFZ wnioski refundacyjne łącznie ze składaniem zleceń przelewów w banku. To zdecydowanie nie są proste systemy, mają swoje rozbudowane dziedziny i swoje logiki, czasem wymagają reakcji w określonym czasie, niektóre zmieniają się w czasie. Za pomocą FlowDog nasz zespól wdrożeniowy zrealizował takie (i inne też) projekty bez udziału programistów (tych co napisali samego FlowDoga). Cóż, krótko, na podstawie zrealizowanych przez nas projektów ja się z tą opinią nie zgadzam.
Ponownie to zależy, tym razem jednak nie tylko od narzędzia, a przede wszystkim od biznesu. Kiedyś budowałem system estymacji w czasie szkód spowodowanych przez trzęsienia ziemi na zadanym obszarze na podstawie prognoz przewidywalności skali trzęsień z dostępnych danych historycznych. Hmm, w zasadzie, do tej pory chyba nie całkiem rozumiem tą domenę, głównie z powodu jej abstrakcji i złożoności. I nie chodzi o przepływy danych, chodzi o algorytmikę. Kluczowe jest tu pytanie – czym jest specyficzny biznes? Czy np. oprogramowanie dla autonomicznych pojazdów warto (da się?) wykonać za pomocą low-code? Pewnie się da tylko po co? Natomiast inną sprawą jest skonsumowanie wyników działania poszczególnych algorytmów. We FlowDog możemy je w dość prosty sposób włączyć w system raportowy lub w jakiś przepływ procesowy. Z drugiej strony, kiedyś zrealizowaliśmy projekt <link do filmu>, w którym nasze urządzenie IoT zamontowane w balonie meteorologicznym dostarczało do naszego systemu pozycję tego balonu, a FlowDog rysował trasę przelotu, co ostatecznie doprowadziło do tego, że łatwo dało się namierzyć balon i całą jego elektronikę pomiarową (kilka kilo EUR), po tym jak spadł. Więc jeśli chodzi o tą opinie to, jak na wstępie, to zależy.
We wspomnianej dyskusji pojawiały się głosy dotyczące bezpieczeństwa rozwiązań low-code. Głownie dotyczyły poziomu zabezpieczeń oferowanych przez poszczególne rozwiązania w odniesieniu do poziomu zabezpieczeń, które można uzyskać tworząc dedykowaną aplikację.
To jak sądzę nie do końca musi być prawda. Tworząc dedykowane oprogramowanie należy zaimplementować kwestie autentykacji i autoryzacji dostępu do poszczególnych danych. W systemach low-code – ta warstwa jest dostępna od razu do wykorzystania, już zaimplementowana, przetestowana. We FlowDog istnieje możliwość użycia MFA a dostęp do danych może być ograniczony z dokładnością do konkretnego pola. O możliwości wymuszenia okresowej zmiany hasła nie wspominam.
Inne spojrzenie na bezpieczeństwo, kieruje wzrok na miejsce przechowywania danych – platformy low-code zazwyczaj pracują w modelu SaaS co oznacza, że są hostowane gdzieś na zewnątrz. Mogą pojawić się wątpliwości czy moje dane są bezpieczne, kto ma do nich dostęp? We FlowDog mamy własną chmurę w profesjonalnym datacenter, dostęp do niej ma zaledwie garstka wysoko kwalifikowanych specjalistów. A jeżeli takie jest życzenie klienta, FlowDog może działać w jego infrastrukturze do której w ogóle nie mamy dostępu.
W zasadzie wspomniałem o tym przy okazji opinii nr. 2 powyżej. Są to wszelkiego rodzaju systemy ekspertowe, rządzące się swoimi bardzo specyficznymi logikami i algorytmiką często wykorzystującą mechanizmy sztucznej inteligencji. Sama implementacja takich systemów za pomocą low-code (wspierającego procesowość/przepływ danych) to raczej wyzwanie, chociaż istnieją dedykowane rozwiązania low-code do tworzenia i uruchamiania modeli AI – więc może to bardziej miejsce na wypracowanie integracji.
Innym wyzwaniem związanym z rozwiązaniami low-code jest granica dostosowania. Umożliwiając konfigurację poszczególnych elementów w pewnym momencie dochodzimy do punktu, w którym albo staje się ona mocno złożona/rozbudowana (przez co komplikuje zastosowanie) albo godzimy się na brak możliwości dostosowania specyficznych elementów.
Na koniec, warto też przyjrzeć się korzyściom jakie niesie ze sobą podejście low-code.
Czas dostarczenia wartości biznesowej – za pomocą narzędzi low-code prototyp można otrzymać w czasie liczonym w godzinach. Ale, moment, prototyp to prototyp – to nie działające rozwiązanie – zgoda, ale w narzędziach low-code prototyp możemy łatwo przekształcić w działające rozwiązanie – bez potrzeby przepisywania wszystkiego od początku. Krótki czas realizacji wymagań sprawia, że biznes chętnie angażuje się w rozwój.
Łatwość zmiany i dopasowania do nowych warunków – firmy ewoluują, zmieniają się w czasie, powodów tych zmian jest wiele, niektóre są wymuszone przez zmieniające się przepisy, niektóre są inicjowane z wewnątrz – co istotne, zazwyczaj te zmiany ciągną ze sobą zmiany w systemach. Gdy znika konieczność programowania nowej wersji bo jest zastąpiona konfiguracją, czas realizacji zmian skraca się i biznes szybko otrzymuje potrzebne narzędzia pasujące do jego otoczenia. Wpływa to również na koszt wprowadzenia zmian.
Elastyczność zastosowań – raz wdrożona platforma low-code w jednym określonym obszarze firmy daje doskonały punkt wyjścia do rozszerzenia o nowe pola działania. Posiadając platformę low-code, która realizuje np. proces realizacji zamówień, bez dodatkowych kosztów można ją rozbudować np. o procesy backoffice.
I na koniec – chyba moje ulubione – zmienia się postrzeganie działu IT w firmie. Dział IT zarządzający oprogramowaniem daje platformę na której biznes szybko realizuje swoje potrzeby. Nowe projekty mogą być uruchamiane od razu bez konieczności szukania wykonawcy czy negocjacji umów.
Kamienie milowe wdrożenia. Wymagania klienta. Oczekiwania na produkcji. I change request, który nagle może zmienić wiele... Jak wygląda wdrożenie FlowDoga z perspektywy Dyrektora Działu Developerskiego? Sprawdź!
Czy opcje no-code i low-code staną się odpowiedzią na problemy organizacji z niedoborem programistów?
Zrób audyt cyberbezpieczeństwa Twojego sklepu internetowego -> Zadbaj o właściwy system cyberbezpieczeństwa IT -> Wykorzystaj profesjonalny system do przetwarzania transakcji -> Wymagaj używania złożonych haseł i uwierzytelniania wieloskładnikowego
Czym jest automatyzacja procesów? Jakie są zalety i wady optymalizacji procesów? W jakim obszarze najszybciej zoptymalizować procesy w firmie?
Czy nowe technologie zmieniły sposób pracy w organizacjach podczas pandemii? Jakie procesy najczęściej wymagały automatyzacji i na co warto zwrócić uwagę przy wdrażaniu nowego oprogramowania? A także o [...]
