7 błędów, których należy unikać przy wdrożeniach low-code

Korzystanie z narzędzi typu low-code i no-code wiąże się z pewnymi obostrzeniami. Gartner przewiduje, że low-code jako ogólny ruch społeczny i technologiczny będzie się nadal znacząco rozwijał.

7 błędów, których należy unikać przy wdrożeniach low-code

Cristian Storto /Getty Images

Przedsiębiorstwa wdrażają coraz więcej narzędzi i procesów low code bądź no code, dążąc do zwiększenia efektywności tworzenia oprogramowania i wspierania cyfrowych działań biznesowych. Kluczem do sukcesu w tej technologii jest nauka unikania typowych błędów.

Gartner prognozuje, że światowy rynek rozwoju oprogramowania lwo-code osiągnie wartość 13,8 miliarda dolarów w 2021 roku, co stanowi wzrost o 23% w porównaniu z rokiem 2020. Gwałtowny wzrost zdalnego rozwoju w czasie pandemii nadal napędza adopcję low-code. Jak zauważa Gartner, tworzenie aplikacji o niskim kodzie nie jest niczym nowym, ale zbieg „cyfrowych zakłóceń, hiperautomatyzacji i wzrostu złożoności biznesu” doprowadził do napływu narzędzi i rosnącego popytu.

Zobacz również:

  • Automatyzacja pozbawi pracy miliony osób. Kto jest zagrożony?
  • Mendix: programista obywatelski sposobem na braki kadrowe w IT

Rynek obejmuje produkty takie jak platformy aplikacyjne o niskim kodzie, inteligentne zestawy do zarządzania procesami biznesowymi, automatyzację procesów robotycznych oraz platformy do automatyzacji i rozwoju obywateli. Cyfrowe przyspieszenie biznesu wywiera presję na liderów IT, aby radykalnie zwiększyć szybkość dostarczania aplikacji, a narzędzia typu low-code są odpowiedzią na ten problem. Wzrost zapotrzebowania na niestandardowe programy wspierające transformację cyfrową spowodował pojawienie się twórców oprogramowania spoza działu IT, co z kolei wpłynęło na rozwój narzędzi typu low-code, twierdzi Gartner.

Wdrażanie produktów i procesów o niskim kodzie może być jednak obarczone błędami, a organizacje muszą być ich świadome, aby mogły ich uniknąć lub zminimalizować ich wpływ na działania rozwojowe.

Rezygnacja z podstawowych praktyk programistycznych

„Największe problemy, z jakimi się spotkałam, wynikają z niezrozumienia tego, co tak naprawdę zapewnia strategia low-code” - mówi Mandy Andress, CISO w Elastic, dostawcy produktów do wyszukiwania online. „Wiele organizacji przyjmuje strategię low-code jako szansę na zaoszczędzenie pieniędzy lub przyspieszenie rozwoju. Ale jest to skuteczne tylko wtedy, gdy rozumieją, jakie koszty strategia low-code może poprawić”.

Strategia low-code może pomóc obniżyć koszty programistów potrzebnych do realizacji projektu, umożliwiając mniej doświadczonym programistom tworzenie zaawansowanych funkcjonalności, mówi Andress. Szybkość rozwoju może być również zaletą, szczególnie jeśli komponenty są ponownie wykorzystywane w różnych aplikacjach. „To, czego najbardziej brakuje, to szersze procesy biznesowe i procesy zarządzania niezbędne do zapewnienia, że aplikacja jest tworzona w celu spełnienia potrzeb biznesowych” - mówi Andress. „Jakie są wymagania biznesowe? Jakie są kluczowe kontrole biznesowe, które musimy wdrożyć, takie jak rozdzielenie obowiązków?”. Na poprzednim stanowisku pracy Andress została sprowadzona do pomocy przy projekcie low-code, ponieważ istniały obawy, że w aplikacji brakowało kluczowych kontroli biznesowych. Po zapoznaniu się z ich wysiłkami odkryła, że w aplikacji brakowało krytycznych reguł biznesowych, ponieważ zespół nie widział potrzeby stosowania się do zdefiniowanego przez siebie procesu SDLC (Software Development Lifecycle - cykl życia oprogramowania) dla działań związanych z rozwojem low-code, a także nie posiadał w pełni udokumentowanych i zweryfikowanych wymagań biznesowych. Ponowne wykonanie aplikacji potroiło czas potrzebny na jej ukończenie, eliminując wszelkie oszczędności, jakie zespół uzyskał dzięki przyjęciu podejścia low-code.

Niedopasowane umiejętności

Jedną z zalet narzędzi typu low-code jest to, że mogą one zmniejszyć zapotrzebowanie na doświadczonych programistów w celu ukończenia projektów. Nie oznacza to jednak, że potrzeba wykwalifikowanych specjalistów zniknie. „Zespoły zajmujące się tworzeniem oprogramowania o niskim kodzie muszą być bardzo biegłe w obsłudze odpowiednich platform o niskim kodzie, posiadać odpowiednie certyfikaty produktowe i wiedzę o tym, co robić, a czego nie robić” - uważa Vinay Mummigatti, wiceprezes i główny specjalista ds. automatyzacji w LexisNexis Legal & Professional, firmie świadczącej usługi w zakresie danych prawnych i konsumenckich. „Z mojego doświadczenia wynika, że wdrażanie inżynierów oprogramowania, którzy są dobrzy w pisaniu aplikacji na zamówienie, wymagających intensywnego kodowania, do opracowywania rozwiązań o niskim kodzie jest błędem” - mówi Mummigatti. „Najczęściej piszą oni tysiące linii kodu i kończą z wysoce niestandardowymi aplikacjami, które są trudne do utrzymania lub skalowania. A to nie jest to, co platforma low-code robi najlepiej”. Na przykład w LexisNexis zespół inżynierów J2EE został przeszkolony na wiodącej platformie automatyzacji low-code, aby dostarczyć aplikację „przetwarzania zamówień prawnych”. Zamiast budować aplikację zgodnie z metodologią i najlepszymi praktykami zalecanymi przez dostawcę platformy [low-code] w celu wykorzystania funkcji out-of-box, zespół programistów użył [platformy] tylko do orkiestracji przepływu pracy jako silnika back-end, ale napisał złożony kod dla wszystkich funkcjonalności. Niestandardowe kodowanie doprowadziło do trzykrotnego przekroczenia pierwotnych szacunków kosztów i czasu, a także do poważnych problemów z wydajnością i utrzymaniem, które ostatecznie doprowadziły do całkowitego przepisania aplikacji przy użyciu zespołu usług profesjonalnych dostawcy” - dodaje Mummigatti.

Brak dostaw oprogramowania kierowanego przez biznes

Platformy o niskim kodzie przede wszystkim umożliwiają obywatelskim programistom ze środowisk biznesowych szybkie dostarczanie aplikacji, mówi Mummigatti, a pozostawienie użytkowników biznesowych poza wczesnym procesem decyzyjnym nie jest dobrym pomysłem. „Jednym z kluczowych błędów, jakie widzieliśmy, jest to, że użytkownicy biznesowi nie są zaangażowani od początku projektu” - mówi Mummigatti. „W przypadku platformy typu low-code, 'model-driven development', zaangażowanie użytkowników biznesowych od samego początku jest kluczem do sukcesu. Brak zaangażowania biznesu od samego początku może prowadzić do poważnych zmian konstrukcyjnych oraz różnic w budżecie/planowanym harmonogramie”.

Projekty low-code powinny uwzględniać silne dopasowanie biznes-IT. Przykładem, który przytacza Mummigatti, jest platforma do obsługi klienta, która została zaprojektowana i stworzona przy minimalnym zaangażowaniu biznesu. Kiedy platforma została dostarczona, użytkownicy biznesowi odrzucili logikę procesu, reguły podejmowania decyzji, raportowanie i interfejsy użytkownika, ponieważ narzucały one skomplikowane zarządzanie zmianami operacyjnymi. „Gdy platforma jest dobrze wykonana, angażujemy biznes już od pierwszego sprintu. Użytkownicy biznesowi mogą zobaczyć, jak projektowane są modele procesów, definiowana logika biznesowa, tworzone formularze/interfejsy UI [interfejsu użytkownika] i przekształcane elementy danych na każdym kroku" w platformie low-code. W efekcie końcowym powstaje aplikacja, która jest "dokładnie taka, jaką wyobraził sobie biznes” - mówi.

Nieudana próba aktualizacji kultury i struktury

„Technologie niskokodowe i bezkodowe to doskonałe narzędzia wspierające przejście na aplikacje zarządzane przez biznes i rozwój obywatelski, o ile zostaną dobrze wykonane” - mówi Andrew Kum-Seun, starszy analityk w dziale aplikacji w firmie badawczej Info-Tech Research Group. „Wiele organizacji zapomina, że aby to nowe środowisko mogło się rozwijać, konieczne są znaczące zmiany w kulturze firmy, strukturach własności oprogramowania i ryzyka oraz modelach operacyjnych IT” - wyjaśnia. „Niestety, tradycyjne praktyki dostarczania oprogramowania, silosowe zespoły biznesowe i informatyczne oraz niska jakość systemów korporacyjnych ograniczają prawdziwy potencjał technologii niskokodowych i bezkodowych oraz zwiększają koszty wdrożenia i długoterminowego utrzymania”.

Dział IT musi zmienić się z operatora i wdrożeniowca rozwiązań „w zaufanego partnera, trenera i zwolennika platformy. Biznes musi być odpowiedzialny za swoje decyzje dotyczące wdrażania i rozwoju oprogramowania oraz musi być przejrzysty w kwestii zmian, jakie wprowadza w środowisku korporacyjnym. W końcu prawdziwa wartość technologii o niskim i zerowym kodzie ujawnia się, gdy jesteśmy gotowi zoptymalizować sposób pracy, aby w pełni wykorzystać ich funkcje” - mówi Kum-Suen.

Ustalanie zbyt ambitnej agendy, której narzędzia nie są w stanie obsłużyć

Platformy low-code mogą być cennymi narzędziami usprawniającymi rozwój. Nie są one jednak doskonałe. „Kluczowym błędem w przypadku platform low-code jest nieuwzględnienie pewnych ograniczeń technicznych” - mówi Mummigatti. W niektórych projektach LexisNexis Legal & Professional próbował rozszerzyć swoje platformy low-code, aby obsłużyć aplikacje o dużym natężeniu ruchu, skoncentrowane na transakcjach, z funkcjami odzyskiwania i przełączania awaryjnego lub przetwarzaniem wsadowym w dużych ilościach. „Stwierdziliśmy, że platformy o niskim kodzie nie skalują się i nie sprawdzają się w sytuacjach wymagających integracji danych lub orkiestracji usług w wielu systemach lub złożonych strukturach danych. Firma wykorzystała platformy o niskim kodzie w aplikacjach do przetwarzania kredytów hipotecznych i przeciwdziałania praniu brudnych pieniędzy, które wymagały przetwarzania wsadowego dokumentów i danych pochodzących z aplikacji do przetwarzania transakcji w dużych ilościach” - opowiada.

W obu scenariuszach firma odkryła, że platformy low-code nie były w stanie zapewnić wymaganej szybkości i jakości. Aplikacje zawodziły w środku procesu. „Nie mieliśmy możliwości zapewnienia 100% przetwarzania dużych ilości danych w trybie wsadowym” z platformami low-code - mówi Mummigatti. „Było to poważne wyzwanie operacyjne i regulacyjne o dużym wpływie na doświadczenia klientów”.

Wdrażanie zbyt wielu narzędzi

Zbyt wiele dobrych rzeczy nie zawsze jest dobrą rzeczą. Dotyczy to narzędzi typu low-code i no-code, szczególnie jeśli nie współpracują ze sobą dobrze.

Firma Nutanix, zajmująca się oprogramowaniem, napotkała na ten problem, który dyrektor ds. informatyki Wendy Pfeiffer porównuje do wieży Babel. Wdrażając wiele narzędzi, które nie mówią tym samym językiem, „Twój zespół nie będzie w stanie osiągnąć wysokiego poziomu automatyzacji” - mówi. „W przypadku mojego zespołu dopiero po przeszkoleniu wszystkich członków zespołu w zakresie korzystania z jednego narzędzia zaczęliśmy robić prawdziwe postępy w umożliwianiu autonomicznych operacji" - mówi Pfeiffer. „Trzy lata temu tylko około 15% naszych usług było wykonywanych autonomicznie. Dzisiaj ta liczba jest bliższa 85%, a wiele z pierwszych kroków na tej drodze zostało podjętych przez członków zespołu, którzy nigdy wcześniej nie pisali kodu automatyzacji, ale byli ekspertami w dziedzinie operacji IT”.

Ponadto, technologia low-code może nie być tak prosta do wdrożenia, jak reklamują ją sprzedawcy, mówi Kum-Seun. „Jej prawdziwe zalety polegają na możliwości wykorzystania i zintegrowania różnych usług i danych w aplikacjach korporacyjnych, hurtowniach danych i systemach. Jednak wiele organizacji jest ograniczonych architekturą swoich starszych systemów, brakuje im wspólnych definicji danych, a ich aplikacje są obciążone długiem technicznym”. Bramy interfejsu programowania aplikacji (API), jeziora danych, platformy chmurowe oraz inne narzędzia integracyjne i agregacyjne mogą pomóc w poprawie kompatybilności systemu z technologiami low-code, mówi Kum-Seun. Nie rozwiązują one jednak podstawowych wyzwań związanych z architekturą i zarządzaniem danymi.

Utrwalanie złych procesów

Pfeiffer twierdzi, że potencjał narzędzi o niskim kodzie jest ogromny. „Przy odrobinie szkolenia, każdy członek zespołu IT może zautomatyzować kluczowe elementy swoich wyspecjalizowanych przepływów pracy, umożliwiając zwiększenie dokładności i wydajności” - mówi. „Ale automatyzacja w rękach mas nie jest panaceum. Fatalny proces jest nadal fatalnym procesem, nawet jeśli jest wykonywany szybko i dokładnie przez maszynę”.

Nie ma specjalnej „magii maszyn”, która zmienia kiepski proces ręczny w genialny, mówi Pfeiffer. „Jako pierwszy krok, mój zespół jest zobowiązany do opisania procesów kandydatów w prostym języku”, mówi. Jest coś takiego w opisie pracy, która ma być wykonana, co uwypukla problemy i prowadzi do poprawy przepływu pracy.

Kiedy dokument ma już sens, proces jest gotowy do przetłumaczenia na kod przez narzędzie low-code.

Automatyzacja jest najlepiej realizowana stopniowo, mówi Pfeiffer. "Zespoły IT często uważają, że muszą zautomatyzować problematyczny, złożony proces od końca do końca, aby automatyzacja przyniosła efekty" - mówi. "Mój zespół i ja nauczyliśmy się, że skupienie naszych wysiłków na automatyzacji najbardziej podatnych na błędy etapów naszych procesów - etapów, które powodują najwięcej przeróbek - jest prawdziwym kluczem do doświadczenia korzyści płynących z tych narzędzi".

Źródło: CIO

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200