Aplikace low-code v analytických platformách

Vážení čtenáři, dobrý den!

Úkol vybudovat IT platformy pro sběr a analýzu dat dříve nebo později vyvstane pro každou společnost, jejíž podnikání je založeno na intelektuálně zatíženém modelu poskytování služeb nebo vytváření technicky složitých produktů. Budování analytických platforem je složitý a časově náročný úkol. Každý úkol lze však zjednodušit. V tomto článku se chci podělit o své zkušenosti s používáním nástrojů s nízkým kódem, které pomáhají vytvářet analytická řešení. Tyto zkušenosti byly získány při realizaci řady projektů ve směru Big Data Solutions společnosti Neoflex. Od roku 2005 se směr Big Data Solutions společnosti Neoflex zabývá problematikou budování datových skladů a jezer, řeší problémy optimalizace rychlosti zpracování informací a pracuje na metodice řízení kvality dat.

Nikdo se nebude moci vyhnout vědomému hromadění slabě a/nebo silně strukturovaných dat. Možná i když mluvíme o malých podnicích. Koneckonců, při škálování podnikání bude nadějný podnikatel postaven před otázky vývoje věrnostního programu, bude chtít analyzovat efektivitu prodejních míst, bude přemýšlet o cílené reklamě a bude zmaten poptávkou po doprovodných produktech. . Pro první přiblížení lze problém vyřešit „na koleni“. Ale jak podnikání roste, příchod na analytickou platformu je stále nevyhnutelný.

V jakém případě se však úlohy analýzy dat mohou rozvinout v problémy třídy „Rocket Science“? Snad ve chvíli, kdy se bavíme o opravdu velkých datech.
Pro usnadnění Rocket Science můžete slona sníst kousek po kousku.

Čím diskrétnější a autonomnější jsou vaše aplikace/služby/mikroslužby, tím snazší bude pro vás, vaše kolegy a celý podnik strávit slona.

Téměř všichni naši klienti přišli na tento postulát, když přestavěli krajinu na základě inženýrských postupů týmů DevOps.

Ale i při „oddělené, sloní“ stravě máme velkou šanci na „přesycení“ IT prostředí. V tuto chvíli stojí za to se zastavit, vydechnout a podívat se do strany nízkokódová inženýrská platforma.

Mnoho vývojářů se děsí vyhlídky na slepou uličku ve své kariéře, když se odkloní od přímého psaní kódu k „přetahování“ šipek v rozhraních uživatelského rozhraní systémů s nízkým kódem. Nástup obráběcích strojů ale nevedl ke zmizení inženýrů, ale přivedl jejich práci na novou úroveň!

Pojďme zjistit proč.

Analýza dat v oblasti logistiky, telekomunikací, mediálního výzkumu, finančního sektoru je vždy spojena s následujícími otázkami:

• Rychlost automatizované analýzy;
• Schopnost provádět experimenty bez ovlivnění hlavního toku produkce dat;
• Spolehlivost připravených dat;
• Sledování změn a verzování;
• Prověření dat, datová linie, CDC;
• Rychlé dodání nových funkcí do produkčního prostředí;
• A notoricky známé: náklady na vývoj a podporu.

To znamená, že inženýři mají obrovské množství úkolů na vysoké úrovni, které lze s dostatečnou efektivitou dokončit pouze tím, že se vyčistí od vývojových úkolů nízké úrovně.

Předpokladem pro posun vývojářů na novou úroveň byla evoluce a digitalizace podnikání. Mění se i hodnota vývojáře: je výrazný nedostatek vývojářů, kteří se mohou ponořit do konceptů automatizovaného podnikání.

Nakreslete analogii s nízkoúrovňovými a vysokoúrovňovými programovacími jazyky. Přechod od jazyků nízké úrovně k jazykům vysoké úrovně je přechodem od psaní „přímých směrnic v jazyce hardwaru“ k „směrnicím v jazyce lidí“. Tedy přidání nějaké vrstvy abstrakce. V tomto případě je přechod na platformy s nízkým kódem z programovacích jazyků na vysoké úrovni přechodem od „směrnic v jazyce lidí“ k „směrnicím v jazyce obchodu“. Pokud existují vývojáři, které tato skutečnost mrzí, pak jsou smutní snad od chvíle, kdy se zrodil Java Script, který využívá funkce řazení polí. A tyto funkce mají samozřejmě pod kapotou softwarovou implementaci jinými prostředky stejného programování na vysoké úrovni.

Proto je low-code jen zdání jiné úrovně abstrakce.

Aplikovaná zkušenost pomocí low-code

Téma low-code je poměrně široké, ale nyní bych rád hovořil o praktické aplikaci „low-code konceptů“ na příkladu jednoho z našich projektů.

Divize Big Data Solutions společnosti Neoflex se specializuje spíše na finanční sektor podnikání, budování datových skladů a jezer a automatizaci různých reportingů. V tomto výklenku se použití nízkého kódu již dlouho stalo standardem. Z dalších low-code nástrojů můžeme zmínit nástroje pro organizaci ETL procesů: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Nebo Oracle Apex, který funguje jako prostředí pro rychlý vývoj rozhraní pro přístup a úpravu dat. Použití vývojových nástrojů s nízkým obsahem kódu však vždy nezahrnuje vytváření vysoce cílených aplikací na zásobníku komerčních technologií s jasnou závislostí na prodejci.

Pomocí nízkokódových platforem můžete také organizovat orchestraci datových toků, vytvářet platformy data science nebo například moduly pro kontrolu kvality dat.

Jedním z aplikovaných příkladů zkušeností s používáním nízkokódových vývojových nástrojů je spolupráce mezi Neoflex a Mediascope, jedním z lídrů na ruském trhu mediálního výzkumu. Jedním z obchodních cílů této společnosti je produkce dat, na jejichž základě se inzerenti, internetové platformy, TV kanály, rozhlasové stanice, reklamní agentury a značky rozhodují o nákupu reklamy a plánují svou marketingovou komunikaci.

Mediální výzkum je technologicky nabitá oblast podnikání. Rozpoznávání videosekvencí, shromažďování dat ze zařízení, která analyzují sledování, měření aktivity na webových zdrojích – to vše naznačuje, že společnost má velký IT personál a obrovské zkušenosti s budováním analytických řešení. Ale exponenciální růst množství informací, počtu a rozmanitosti jejich zdrojů nutí IT datový průmysl neustále postupovat vpřed. Nejjednodušším řešením škálování již fungující analytické platformy Mediascope by mohlo být navýšení počtu IT pracovníků. Mnohem efektivnější řešení je ale urychlit proces vývoje. Jedním z kroků vedoucích tímto směrem může být využití low-code platforem.

V době zahájení projektu měla společnost již fungující produktové řešení. Implementace řešení v MSSQL však nemohla plně naplnit očekávání ohledně škálovací funkčnosti při zachování přijatelné ceny vývoje.

Úkol, který před námi stál, byl skutečně ambiciózní – společnosti Neoflex a Mediascope musely vytvořit průmyslové řešení za méně než rok, s výhradou vydání MVP během prvního čtvrtletí od data zahájení.

Technologický zásobník Hadoop byl vybrán jako základ pro vybudování nové datové platformy založené na výpočtech s nízkým obsahem kódu. HDFS se stalo standardem pro ukládání dat pomocí parketových souborů. Pro přístup k datům umístěným v platformě byl použit Hive, ve kterém jsou všechny dostupné výklady prezentovány formou externích tabulek. Načítání dat do úložiště bylo realizováno pomocí Kafka a Apache NiFi.

Nástroj Lowe-code v této koncepci byl použit k optimalizaci pracně nejnáročnějšího úkolu při budování analytické platformy – úkolu výpočtu dat.

Jako hlavní mechanismus pro mapování dat byl zvolen nízkokódový nástroj Datagram. Datagram Neoflex je nástroj pro vývoj transformací a datových toků.
Pomocí tohoto nástroje se obejdete bez ručního psaní kódu Scala. Scala kód je generován automaticky pomocí přístupu Model Driven Architecture.

Zjevnou výhodou tohoto přístupu je urychlení procesu vývoje. Kromě rychlosti však existují také následující výhody:

• Zobrazení obsahu a struktury zdrojů/přijímačů;
• Sledování původu objektů toku dat k jednotlivým polím (lineage);
• Částečné provádění transformací s prohlížením mezivýsledků;
• Kontrola zdrojového kódu a jeho úprava před spuštěním;
• Automatické ověřování transformací;
• Automatické stahování dat 1 v 1.

Bariéra vstupu do řešení s nízkým kódem pro generování transformací je poměrně nízká: vývojář potřebuje znát SQL a mít zkušenosti s prací s nástroji ETL. Stojí za zmínku, že kódem řízené transformační generátory nejsou ETL nástroji v širokém slova smyslu. Nástroje s nízkým kódem nemusí mít vlastní prostředí pro provádění kódu. To znamená, že vygenerovaný kód bude spuštěn v prostředí, které existovalo v clusteru ještě před instalací řešení s nízkým kódem. A to je možná další plus pro nízkokódovou karmu. Protože paralelně s týmem s nízkým kódem může pracovat „klasický“ tým, který implementuje funkčnost například v čistém kódu Scala. Zavedení vylepšení od obou týmů do výroby bude jednoduché a bezproblémové.

Možná stojí za zmínku, že kromě nízkého kódu existují také řešení bez kódu. A v jádru jsou to různé věci. Nízký kód umožňuje vývojáři více zasahovat do generovaného kódu. V případě Datagramu je možné prohlížet a upravovat vygenerovaný Scala kód, žádný kód nemusí takovou možnost poskytovat. Tento rozdíl je velmi výrazný nejen z hlediska flexibility řešení, ale také z hlediska komfortu a motivace při práci datových inženýrů.

Architektura řešení

Zkusme přesně přijít na to, jak nástroj s nízkým kódem pomáhá vyřešit problém s optimalizací rychlosti vývoje funkce výpočtu dat. Nejprve se podívejme na funkční architekturu systému. Příkladem je v tomto případě model produkce dat pro výzkum médií.

Zdroje dat jsou v našem případě velmi heterogenní a různorodé:

• Peoplemetry (TV metry) jsou softwarová a hardwarová zařízení, která odečítají chování uživatelů od respondentů televizního panelu – kdo, kdy a jaký televizní kanál byl sledován v domácnosti, která se studie účastní. Poskytované informace jsou proudem intervalů sledování vysílání spojených s mediálním balíčkem a mediálním produktem. Data ve fázi načítání do Data Lake mohou být obohacena o demografické atributy, geostratifikaci, časové pásmo a další informace potřebné pro analýzu televizního sledování konkrétního mediálního produktu. Provedená měření lze použít k analýze nebo plánování reklamních kampaní, posouzení aktivity a preferencí publika a sestavení vysílací sítě;
• Data mohou pocházet z monitorovacích systémů pro streamování televizního vysílání a měření sledování obsahu video zdrojů na internetu;
• Měřící nástroje ve webovém prostředí, včetně měřičů zaměřených na web i uživatele. Poskytovatelem dat pro Data Lake může být doplněk prohlížeče Research Bar a mobilní aplikace s vestavěnou VPN.
• Data mohou pocházet i z webů, které konsolidují výsledky vyplňování online dotazníků a výsledky telefonických rozhovorů ve firemních průzkumech;
• K dalšímu obohacení datového jezera může dojít stahováním informací z protokolů partnerských společností.

Implementace as is načítání ze zdrojových systémů do primárního stagingu nezpracovaných dat může být organizována různými způsoby. Pokud se pro tyto účely použije low-code, je možné automatické generování načítacích skriptů na základě metadat. V tomto případě není potřeba sestupovat až na úroveň mapování mezi zdrojovými a cílovými zdroji. Abychom mohli implementovat automatické načítání, musíme vytvořit připojení ke zdroji a poté v načítacím rozhraní definovat seznam entit, které se mají načíst. Adresářová struktura v HDFS bude vytvořena automaticky a bude odpovídat struktuře datového úložiště na zdrojovém systému.

V rámci tohoto projektu jsme se však rozhodli tuto funkci low-code platformy nevyužít, a to z toho důvodu, že společnost Mediascope již samostatně začala pracovat na výrobě podobné služby s využitím kombinace Nifi + Kafka.

Stojí za to okamžitě uvést, že tyto nástroje nejsou zaměnitelné, ale spíše se doplňují. Nifi a Kafka jsou schopni pracovat jak v přímém (Nifi -> Kafka), tak v reverzním (Kafka -> Nifi) spojení. Pro platformu pro výzkum médií byla použita první verze balíčku.

V našem případě NayFi potřebovala zpracovat různé typy dat ze zdrojových systémů a odeslat je brokerovi Kafka. V tomto případě byly zprávy odeslány na konkrétní téma Kafka pomocí procesorů PublishKafka Nifi. Orchestrování a údržba těchto potrubí se provádí ve vizuálním rozhraní. Nástroj Nifi a využití kombinace Nifi + Kafka lze nazvat také low-code přístupem k vývoji, který má nízkou bariéru pro vstup do Big Data technologií a urychluje proces vývoje aplikací.

Další fází implementace projektu bylo převedení podrobných dat do formátu jediné sémantické vrstvy. Pokud má entita historické atributy, výpočet se provede v kontextu příslušného oddílu. Pokud entita není historická, pak je volitelně možné buď přepočítat celý obsah objektu, nebo zcela odmítnout přepočet tohoto objektu (kvůli chybějícím změnám). V této fázi se vygenerují klíče pro všechny entity. Klíče jsou uloženy v adresářích Hbase odpovídajících hlavním objektům, které obsahují shodu mezi klíči v analytické platformě a klíči ze zdrojových systémů. Konsolidaci atomových entit doprovází obohacení o výsledky předběžného výpočtu analytických dat. Rámcem pro výpočet dat byl Spark. Popsaná funkcionalita pro přivedení dat do jediné sémantiky byla také implementována na základě mapování z nízkokódového nástroje Datagram.

Cílová architektura vyžadovala přístup SQL k datům pro podnikové uživatele. Pro tuto možnost byl použit Hive. Objekty jsou registrovány v Hive automaticky, když povolíte možnost „Registrovat tabulku Hive“ v nástroji s nízkým kódem.

Řízení toku výpočtu

Datagram má rozhraní pro vytváření návrhů workflow flow. Mapování lze spustit pomocí plánovače Oozie. V rozhraní pro vývojáře streamů je možné vytvářet schémata pro paralelní, sekvenční nebo na provedení závislé transformace dat. K dispozici je podpora pro shell skripty a java programy. Je také možné použít server Apache Livy. Apache Livy slouží ke spouštění aplikací přímo z vývojového prostředí.

Pokud již společnost má vlastní orchestrátor procesů, je možné použít REST API k vložení mapování do existujícího toku. Například jsme měli docela úspěšnou zkušenost s vkládáním mapování ve Scale do orchestrátorů napsaných v PLSQL a Kotlin. REST API nástroje s nízkým kódem zahrnuje operace, jako je generování spustitelného roku na základě návrhu mapování, volání mapování, volání sekvence mapování a samozřejmě předávání parametrů URL pro spuštění mapování.

Spolu s Oozie je možné organizovat výpočetní tok pomocí Airflow. Možná se nebudu dlouho zdržovat srovnáním Oozie a Airflow, ale jednoduše řeknu, že v kontextu práce na projektu mediálního výzkumu padla volba ve prospěch Airflow. Hlavními argumenty byla tentokrát aktivnější komunita vyvíjející produkt a propracovanější rozhraní + API.

Proud vzduchu je také dobrý, protože používá milovaný Python k popisu procesů výpočtu. A obecně není tolik open source platforem pro správu workflow. Spouštění a sledování provádění procesů (včetně Ganttova diagramu) pouze přidává body do karmy Airflow.

Formát konfiguračního souboru pro spouštění mapování řešení s nízkým kódem se stal spark-submit. Stalo se tak ze dvou důvodů. Za prvé, spark-submit vám umožňuje přímo spustit soubor jar z konzoly. Za druhé, může obsahovat všechny potřebné informace pro konfiguraci pracovního postupu (což usnadňuje psaní skriptů, které generují Dag).
Nejčastějším prvkem workflow Airflow byl v našem případě SparkSubmitOperator.

SparkSubmitOperator vám umožňuje spouštět jary - zabalené mapování Datagramu s předem vygenerovanými vstupními parametry.

Za zmínku stojí, že každá úloha Airflow běží v samostatném vlákně a neví nic o jiných úlohách. Interakce mezi úkoly se proto provádí pomocí řídicích operátorů, jako je DummyOperator nebo BranchPythonOperator.

Dohromady vedlo použití nízkokódového řešení Datagram ve spojení s univerzalizací konfiguračních souborů (vytváření Dag) k výraznému zrychlení a zjednodušení procesu vývoje toků načítání dat.

Ukázka výpočtu

Snad nejvíce intelektuálně zatíženou fází při produkci analytických dat je krok budování vitrín. V kontextu jednoho z toků výpočtu dat výzkumné společnosti jsou v této fázi data redukována na referenční vysílání, přičemž se berou v úvahu korekce pro časová pásma a jsou propojeny s vysílací mřížkou. Je také možné upravit pro místní vysílací síť (místní zprávy a reklama). Tento krok mimo jiné rozděluje intervaly nepřetržitého sledování mediálních produktů na základě analýzy intervalů sledování. Okamžitě jsou hodnoty zobrazení „váženy“ na základě informace o jejich významnosti (výpočet korekčního faktoru).

Samostatným krokem při přípravě vitrín je validace dat. Validační algoritmus zahrnuje použití řady matematických vědeckých modelů. Použití platformy s nízkým kódem vám však umožňuje rozdělit složitý algoritmus na řadu samostatných vizuálně čitelných mapování. Každé z mapování plní úzký úkol. V důsledku toho je možné přechodné ladění, protokolování a vizualizace fází přípravy dat.

Bylo rozhodnuto diskretizovat ověřovací algoritmus do následujících dílčích fází:

• Budování regresí závislostí sledování televizní sítě v regionu se sledováním všech sítí v regionu po dobu 60 dnů.
• Výpočet studentizovaných reziduí (odchylky skutečných hodnot od hodnot předpovězených regresním modelem) pro všechny regresní body a pro vypočítaný den.
• Výběr anomálních párů region-síť, kde studentizovaná bilance zúčtovacího dne překračuje normu (určenou nastavením provozu).
• Přepočet korigovaného studentizovaného rezidua pro anomální páry region-TV síť pro každého respondenta, který sledoval síť v regionu, stanovení příspěvku tohoto respondenta (výše změny studentizovaného rezidua) při vyloučení sledovanosti tohoto respondenta ze vzorku .
• Hledejte kandidáty, jejichž vyloučení vrátí studentský zůstatek výplaty zpět do normálu.

Výše uvedený příklad potvrzuje hypotézu, že datový inženýr už toho má na srdci příliš... A pokud je to skutečně „inženýr“ a ne „kodér“, pak strach z profesionální degradace při používání nástrojů s nízkým kódem musí konečně ustoupit.

Co jiného umí low-code?

Rozsah použití nízkokódového nástroje pro dávkové a streamové zpracování dat bez nutnosti ručního psaní kódu ve Scale nekončí.

Používání low-code při vývoji datalaku se pro nás již stalo standardem. Pravděpodobně můžeme říci, že řešení založená na Hadoop stacku jdou cestou vývoje klasických DWH založených na RDBMS. Nízkokódové nástroje na Hadoop stacku dokážou vyřešit jak úlohy zpracování dat, tak úlohu budování finálních BI rozhraní. Navíc je třeba poznamenat, že BI může znamenat nejen reprezentaci dat, ale také jejich editaci firemními uživateli. Tuto funkcionalitu často využíváme při budování analytických platforem pro finanční sektor.

Mimo jiné pomocí low-code a zejména Datagramu je možné řešit problém sledování původu objektů datového toku s atomicitou až k jednotlivým polím (lineage). K tomu nástroj s nízkým kódem implementuje rozhraní s Apache Atlas a Cloudera Navigator. Vývojář v zásadě potřebuje zaregistrovat sadu objektů ve slovnících Atlas a odkazovat na registrované objekty při vytváření mapování. Mechanismus pro sledování původu dat nebo analýzu závislostí objektů ušetří spoustu času, když je potřeba vylepšit výpočetní algoritmy. Například při sestavování účetní závěrky vám tato funkce umožňuje pohodlněji přežít období legislativních změn. Ostatně, čím lépe porozumíme mezitvarové závislosti v kontextu objektů detailní vrstvy, tím méně se budeme setkávat s „náhlými“ defekty a snížíme počet předělávek.

Kvalita dat a nízký kód

Dalším úkolem implementovaným nízkokódovým nástrojem na projektu Mediascope byla úloha Data Quality class. Zvláštností implementace kanálu ověřování dat pro projekt výzkumné společnosti byl nedostatečný dopad na výkon a rychlost hlavního toku výpočtu dat. Aby bylo možné zorganizovat nezávislé toky ověřování dat, byl použit již známý Apache Airflow. Protože každý krok produkce dat byl připraven, byla paralelně spuštěna samostatná část DQ pipeline.

Za dobrou praxi se považuje sledování kvality dat od okamžiku jejich vzniku v analytické platformě. Díky informacím o metadatech můžeme kontrolovat dodržování základních podmínek od okamžiku, kdy informace vstoupí do primární vrstvy - ne null, omezení, cizí klíče. Tato funkcionalita je implementována na základě automaticky generovaných mapování rodiny datové kvality v Datagramu. Generování kódu je v tomto případě také založeno na metadatech modelu. Na projektu Mediascope bylo provedeno rozhraní s metadaty produktu Enterprise Architect.

Spárováním nízkokódového nástroje s Enterprise Architect byly automaticky vygenerovány následující kontroly:

• Kontrola přítomnosti hodnot „null“ v polích s modifikátorem „not null“;
• Kontrola přítomnosti duplikátů primárního klíče;
• Kontrola cizího klíče entity;
• Kontrola jedinečnosti řetězce na základě sady polí.

Pro komplexnější kontroly dostupnosti a spolehlivosti dat bylo vytvořeno mapování pomocí Scala Expression, které bere jako vstup externí kontrolní kód Spark SQL připravený analytiky společnosti Zeppelin.

Automatického generování kontrol musí být samozřejmě dosaženo postupně. V rámci popsaného projektu tomu předcházely následující kroky:

• DQ implementované v noteboocích Zeppelin;
• DQ zabudované do mapování;
• DQ ve formě samostatných masivních mapování obsahujících celou sadu kontrol pro samostatnou entitu;
• Univerzální parametrizovaná mapování DQ, která přijímají jako vstup informace o metadatech a obchodních kontrolách.

Snad hlavní výhodou vytvoření parametrizované kontrolní služby je zkrácení doby potřebné k dodání funkčnosti do produkčního prostředí. Nové kontroly kvality mohou obejít klasický vzor doručování kódu nepřímo prostřednictvím vývojových a testovacích prostředí:

• Všechny kontroly metadat jsou generovány automaticky při úpravě modelu v EA;
• Kontroly dostupnosti dat (určující přítomnost jakýchkoli dat v určitém okamžiku) lze generovat na základě adresáře, který ukládá očekávané načasování výskytu další části dat v kontextu objektů;
• Kontroly ověření obchodních dat vytvářejí analytici v noteboocích Zeppelin. Odtud jsou odesílány přímo do tabulek nastavení modulu DQ v produkčním prostředí.

Neexistují žádná rizika přímého odesílání skriptů do výroby. I při syntaktické chybě nám maximum hrozí neprovedení jedné kontroly, protože tok výpočtu dat a tok spuštění kontroly kvality jsou od sebe odděleny.

Služba DQ je v podstatě trvale spuštěna v produkčním prostředí a je připravena začít pracovat v okamžiku, kdy se objeví další část dat.

Místo závěru

Výhoda použití low-code je zřejmá. Vývojáři nemusí vyvíjet aplikaci od začátku. A programátor osvobozený od dalších úkolů produkuje výsledky rychleji. Rychlost zase uvolňuje další čas na řešení problémů s optimalizací. Proto se v tomto případě můžete spolehnout na lepší a rychlejší řešení.

Samozřejmě, low-code není všelék a magie se nestane sama od sebe:

• Průmysl s nízkým kódem prochází fází „posilování“ a dosud neexistují jednotné průmyslové standardy;
• Mnoho řešení s nízkým kódem není zdarma a jejich nákup by měl být vědomým krokem, který by měl být učiněn s plnou důvěrou ve finanční výhody jejich používání;
• Mnoho řešení s nízkým kódem nefunguje vždy dobře s GIT/SVN. Nebo je jejich použití nepohodlné, pokud je vygenerovaný kód skrytý;
• Při rozšiřování architektury může být nutné zdokonalit řešení s nízkým kódem – což zase vyvolává efekt „připoutanosti a závislosti“ na dodavateli řešení s nízkým kódem.
• Přiměřená úroveň zabezpečení je možná, ale je velmi pracná a obtížně implementovatelná v systémech s nízkým kódem. Nízkokódové platformy by měly být voleny nejen na principu hledání výhod z jejich používání. Při výběru se vyplatí položit si otázky ohledně dostupnosti funkcionality pro řízení přístupu a delegování/eskalaci identifikačních údajů na úroveň celého IT prostředí organizace.

Pokud jsou vám však známy všechny nedostatky zvoleného systému a výhody z jeho používání jsou přesto v dominantní většině, přejděte bez obav na malý kód. Navíc přechod k němu je nevyhnutelný – stejně jako je nevyhnutelná jakákoli evoluce.

Pokud jeden vývojář na platformě s nízkým kódem dělá svou práci rychleji než dva vývojáři bez nízkého kódu, pak to dává společnosti náskok ve všech ohledech. Hranice pro vstup do nízkokódových řešení je nižší než do „tradičních“ technologií, což má pozitivní vliv na problematiku personálního nedostatku. Při použití low-code nástrojů je možné zrychlit interakci mezi funkčními týmy a rychleji se rozhodovat o správnosti zvolené cesty výzkumu datové vědy. Nízkoúrovňové platformy mohou řídit digitální transformaci organizace, protože vytvořená řešení mohou pochopit i netechnickí specialisté (zejména obchodní uživatelé).

Pokud máte napjaté termíny, nabitou obchodní logiku, nedostatek technologických znalostí a potřebujete urychlit dobu uvedení na trh, pak je nízký kód jedním ze způsobů, jak vyhovět vašim potřebám.

Nelze popřít důležitost tradičních vývojových nástrojů, ale v mnoha případech je použití nízkokódových řešení tím nejlepším způsobem, jak zvýšit efektivitu řešených úloh.

Zdroj: www.habr.com