Tillämpning av lågkod i analytiska plattformar

Kära läsare, god dag!

Uppgiften att bygga IT-plattformar för insamling och analys av data uppstår förr eller senare för alla företag vars verksamhet bygger på en intellektuellt laddad tjänsteleveransmodell eller skapandet av tekniskt komplexa produkter. Att bygga analytiska plattformar är en komplex och tidskrävande uppgift. Men vilken uppgift som helst kan förenklas. I den här artikeln vill jag dela med mig av min erfarenhet av att använda lågkodsverktyg för att skapa analytiska lösningar. Denna erfarenhet förvärvades under genomförandet av ett antal projekt inom Neoflex-företagets Big Data Solutions-riktning. Sedan 2005 har Neoflex Big Data Solutions-inriktningen tagit itu med frågorna om att bygga datalager och sjöar, lösa problem med att optimera informationsbehandlingshastigheten och arbeta med en metodik för datakvalitetshantering.

Ingen kommer att kunna undvika den medvetna ackumuleringen av svagt och/eller starkt strukturerad data. Kanske även om vi pratar om småföretag. När allt kommer omkring kommer en lovande entreprenör att ställas inför frågorna om att utveckla ett lojalitetsprogram, när allt kommer omkring, när allt kommer omkring, kommer att vilja analysera effektiviteten hos försäljningsställen, kommer att tänka på riktad reklam och kommer att bli förbryllad över efterfrågan på medföljande produkter . Till en första uppskattning kan problemet lösas "på knäet". Men när verksamheten växer är det fortfarande oundvikligt att komma till en analytisk plattform.

Men i vilket fall kan dataanalysuppgifter utvecklas till "Rocket Science" klassproblem? Kanske just nu när vi pratar om riktigt big data.
För att göra Rocket Science enklare kan du äta elefanten bit för bit.

Ju mer diskreta och autonoma dina applikationer/tjänster/mikrotjänster är, desto lättare blir det för dig, dina kollegor och hela verksamheten att smälta elefanten.

Nästan alla våra kunder kom till detta postulat, efter att ha byggt om landskapet baserat på ingenjörspraxis från DevOps-team.

Men även med en "separat, elefantisk" diet har vi en god chans att "övermättnad" av IT-landskapet. I detta ögonblick är det värt att stanna, andas ut och titta åt sidan ingenjörsplattform med låg kod.

Många utvecklare är rädda av utsikten till en återvändsgränd i sin karriär när de går bort från att direkt skriva kod mot att "dra" pilar i gränssnittet för lågkodssystem. Men tillkomsten av verktygsmaskiner ledde inte till ingenjörernas försvinnande, utan förde deras arbete till en ny nivå!

Låt oss ta reda på varför.

Dataanalys inom området logistik, telekomindustri, medieforskning, finanssektor är alltid förknippad med följande frågor:

• Hastighet för automatiserad analys;
• Förmåga att genomföra experiment utan att påverka det huvudsakliga dataproduktionsflödet;
• Tillförlitligheten hos de förberedda uppgifterna;
• Ändra spårning och versionshantering;
• Data härkomst, datalinje, CDC;
• Snabb leverans av nya funktioner till produktionsmiljön;
• Och det ökända: kostnaden för utveckling och support.

Det vill säga ingenjörer har ett stort antal uppgifter på hög nivå, som endast kan slutföras med tillräcklig effektivitet genom att rensa deras medvetenhet om utvecklingsuppgifter på låg nivå.

Förutsättningarna för att utvecklare skulle ta sig till en ny nivå var utvecklingen och digitaliseringen av verksamheten. Värdet på utvecklaren förändras också: det råder en betydande brist på utvecklare som kan fördjupa sig i konceptet med att verksamheten automatiseras.

Låt oss dra en analogi med programmeringsspråk på låg och hög nivå. Övergången från lågnivåspråk till högnivåspråk är en övergång från att skriva "direkta direktiv på hårdvarans språk" till "direktiv på människors språk". Det vill säga att lägga till något lager av abstraktion. I det här fallet är övergången till lågkodsplattformar från högnivåprogrammeringsspråk en övergång från "direktiv på människors språk" till "direktiv på affärsspråk". Om det finns utvecklare som är ledsna över detta faktum, så har de kanske blivit ledsna sedan det ögonblick då Java Script föddes, som använder arraysorteringsfunktioner. Och dessa funktioner har naturligtvis mjukvaruimplementering under huven med andra medel av samma högnivåprogrammering.

Därför är lågkod bara utseendet på en annan abstraktionsnivå.

Tillämpad erfarenhet av lågkod

Ämnet lågkod är ganska brett, men nu skulle jag vilja prata om den praktiska tillämpningen av "lågkodskoncept" med exemplet från ett av våra projekt.

Big Data Solutions divisionen av Neoflex specialiserar sig mer på den finansiella sektorn av företag, bygga datalager och sjöar och automatisera olika rapportering. I denna nisch har användningen av lågkod sedan länge blivit en standard. Bland andra lågkodsverktyg kan vi nämna verktyg för att organisera ETL-processer: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Eller Oracle Apex, som fungerar som en miljö för snabb utveckling av gränssnitt för att komma åt och redigera data. Användningen av utvecklingsverktyg med låg kod innebär dock inte alltid att man bygger mycket riktade applikationer på en kommersiell teknologistack med ett tydligt beroende av leverantören.

Med hjälp av lågkodsplattformar kan du också organisera orkestreringen av dataströmmar, skapa datavetenskapliga plattformar eller till exempel moduler för att kontrollera datakvalitet.

Ett av de tillämpade exemplen på erfarenhet av att använda utvecklingsverktyg med låg kod är samarbetet mellan Neoflex och Mediascope, en av de ledande på den ryska medieforskningsmarknaden. Ett av affärsmålen för detta företag är produktion av data på grundval av vilken annonsörer, internetplattformar, TV-kanaler, radiostationer, reklambyråer och varumärken fattar beslut om att köpa reklam och planerar sin marknadskommunikation.

Medieforskning är ett tekniskt laddat affärsområde. Att känna igen videosekvenser, samla in data från enheter som analyserar visning, mäta aktivitet på webbresurser – allt detta innebär att företaget har en stor IT-stab och enorm erfarenhet av att bygga analytiska lösningar. Men den exponentiella tillväxten i mängden information, antalet och variationen av dess källor tvingar IT-dataindustrin att ständigt utvecklas. Den enklaste lösningen för att skala den redan fungerande Mediascope analytiska plattformen kan vara att utöka IT-personalen. Men en mycket effektivare lösning är att påskynda utvecklingsprocessen. Ett av stegen som leder i denna riktning kan vara användningen av lågkodsplattformar.

När projektet startade hade företaget redan en fungerande produktlösning. Implementeringen av lösningen i MSSQL kunde dock inte helt uppfylla förväntningarna på skalningsfunktionalitet samtidigt som en acceptabel utvecklingskostnad bibehölls.

Uppgiften framför oss var verkligen ambitiös - Neoflex och Mediascope var tvungna att skapa en industriell lösning på mindre än ett år, under förutsättning att MVP släpptes inom det första kvartalet efter startdatumet.

Hadoop-teknologistacken valdes som grunden för att bygga en ny dataplattform baserad på lågkodsberäkning. HDFS har blivit standarden för datalagring med parkettfiler. För att komma åt data som finns i plattformen användes Hive, där alla tillgängliga skyltfönster presenteras i form av externa tabeller. Att ladda data till lagringen implementerades med Kafka och Apache NiFi.

Lowe-code-verktyget i detta koncept användes för att optimera den mest arbetsintensiva uppgiften i att bygga en analytisk plattform - uppgiften att beräkna data.

Lågkodsverktyget Datagram valdes som huvudmekanism för datakartläggning. Neoflex Datagram är ett verktyg för att utveckla transformationer och dataflöden.
Med detta verktyg kan du göra utan att skriva Scala-kod manuellt. Scala-kod genereras automatiskt med modelldriven arkitektur.

En uppenbar fördel med detta tillvägagångssätt är att påskynda utvecklingsprocessen. Men förutom snabbhet finns det också följande fördelar:

• Visa innehållet och strukturen hos källor/mottagare;
• Spåra ursprunget för dataflödesobjekt till enskilda fält (härstamning);
• Partiell utförande av transformationer med visning av mellanresultat;
• Granska källkoden och justera den före körning;
• Automatisk validering av transformationer;
• Automatisk datanedladdning 1 i 1.

Barriären för att komma in i lågkodslösningar för att generera transformationer är ganska låg: utvecklaren behöver kunna SQL och ha erfarenhet av att arbeta med ETL-verktyg. Det är värt att nämna att koddrivna transformationsgeneratorer inte är ETL-verktyg i ordets vida bemärkelse. Lågkodsverktyg kanske inte har sin egen kodexekveringsmiljö. Det vill säga att den genererade koden kommer att exekveras i den miljö som fanns på klustret redan innan lågkodslösningen installerades. Och detta är kanske ytterligare ett plus för lågkodad karma. Eftersom det parallellt med ett lågkodsteam kan arbeta ett ”klassiskt” team som implementerar funktionalitet till exempel i ren Scala-kod. Att ta förbättringar från båda teamen i produktion kommer att vara enkelt och sömlöst.

Det är kanske värt att notera att förutom lågkod finns det även kodfria lösningar. Och i grunden är det olika saker. Låg kod gör att utvecklaren kan störa den genererade koden mer. När det gäller Datagram är det möjligt att se och redigera den genererade Scala-koden; no-code kanske inte ger en sådan möjlighet. Denna skillnad är mycket betydande inte bara när det gäller flexibiliteten i lösningen, utan också när det gäller komfort och motivation i dataingenjörernas arbete.

Lösningsarkitektur

Låt oss försöka ta reda på exakt hur ett lågkodsverktyg hjälper till att lösa problemet med att optimera hastigheten för att utveckla databeräkningsfunktioner. Låt oss först titta på systemets funktionella arkitektur. Ett exempel i detta fall är dataproduktionsmodellen för medieforskning.

Datakällor i vårt fall är mycket heterogena och olika:

• Personmätare (TV-mätare) är mjukvara och hårdvaruenheter som läser användarbeteende från tv-panelrespondenter - vem, när och vilken tv-kanal som sågs i hushållet som deltar i studien. Den tillhandahållna informationen är en ström av sändningsintervaller kopplade till mediepaketet och medieprodukten. Data vid laddningsstadiet i Data Lake kan berikas med demografiska attribut, referenser till geostratum, tidszon och annan information som behövs för att analysera tv-tittande av en viss medieprodukt. Mätningarna som tas kan användas för att analysera eller planera reklamkampanjer, bedöma publikens aktivitet och preferenser och sammanställa sändningsnätverket;
• Uppgifterna kan komma från övervakningssystem för strömmande tv-sändningar och mätning av visning av videoresursinnehåll på Internet;
• Mätverktyg i webbmiljön, inklusive både platscentrerade och användarcentrerade mätare. Dataleverantören för Data Lake kan vara ett webbläsartillägg för forskningsfält och en mobilapplikation med en inbyggd VPN.
• Data kan också komma från webbplatser som konsoliderar resultaten av att fylla i online-frågeformulär och resultaten av telefonintervjuer i företagsundersökningar;
• Ytterligare anrikning av datasjön kan ske genom att ladda ner information från loggar från partnerföretag.

Implementeringen av as is laddning från källsystem till den primära iscensättningen av rådata kan organiseras på olika sätt. Om lågkod används för dessa ändamål är automatisk generering av laddningsskript baserade på metadata möjlig. I det här fallet finns det inget behov av att gå ner till nivån för att utveckla källan för att rikta in kartor. För att implementera automatisk laddning måste vi upprätta en anslutning till källan och sedan definiera i laddningsgränssnittet listan över enheter som ska laddas. Katalogstrukturen i HDFS skapas automatiskt och kommer att motsvara datalagringsstrukturen på källsystemet.

Men inom ramen för detta projekt beslutade vi oss för att inte använda den här funktionen hos lågkodsplattformen på grund av det faktum att Mediascope-företaget redan självständigt har påbörjat arbetet med att producera en liknande tjänst med Nifi + Kafka-kombinationen.

Det är värt att omedelbart indikera att dessa verktyg inte är utbytbara, utan snarare komplementära. Nifi och Kafka kan arbeta både i direkt (Nifi -> Kafka) och i omvänd (Kafka -> Nifi) anslutning. För medieforskningsplattformen användes den första versionen av paketet.

I vårt fall behövde NayFi bearbeta olika typer av data från källsystem och skicka dem till Kafka-mäklaren. I det här fallet skickades meddelanden till ett specifikt Kafka-ämne med hjälp av PublishKafka Nifi-processorer. Orkestreringen och underhållet av dessa pipelines utförs i ett visuellt gränssnitt. Nifi-verktyget och användningen av kombinationen Nifi + Kafka kan också kallas en lågkodsmetod för utveckling, som har en låg barriär för inträde i Big Data-teknologier och påskyndar applikationsutvecklingsprocessen.

Nästa steg i projektimplementeringen var att få detaljerad data till ett enda semantiskt lagerformat. Om en enhet har historiska attribut utförs beräkningen i samband med den aktuella uppdelningen. Om enheten inte är historisk är det valfritt möjligt att antingen räkna om hela innehållet i objektet eller helt vägra att räkna om detta objekt (på grund av bristen på ändringar). I detta skede genereras nycklar för alla enheter. Nycklarna lagras i de Hbase-kataloger som motsvarar masterobjekten, som innehåller en överensstämmelse mellan nycklarna i den analytiska plattformen och nycklarna från källsystemen. Konsolidering av atomära enheter åtföljs av berikning med resultaten av preliminär beräkning av analytiska data. Ramverket för databeräkning var Spark. Den beskrivna funktionen för att föra data till en enda semantik implementerades också baserat på mappningar från verktyget Datagram med låg kod.

Målarkitekturen krävde SQL-åtkomst till data för företagsanvändare. Hive användes för detta alternativ. Objekt registreras i Hive automatiskt när du aktiverar alternativet "Registrera Hive-tabell" i lågkodsverktyget.

Beräkningsflödeskontroll

Datagram har ett gränssnitt för att skapa arbetsflödesdesigner. Mappningar kan startas med Oozie-schemaläggaren. I strömutvecklargränssnittet är det möjligt att skapa scheman för parallella, sekventiella eller exekveringsberoende datatransformationer. Det finns stöd för skalskript och java-program. Det är också möjligt att använda Apache Livy-servern. Apache Livy används för att köra applikationer direkt från utvecklingsmiljön.

Om företaget redan har en egen processorchestrator är det möjligt att använda REST API för att bädda in mappningar i ett befintligt flöde. Till exempel hade vi ganska framgångsrik erfarenhet av att bädda in kartor i Scala i orkestratorer skrivna i PLSQL och Kotlin. Lågkodsverktygets REST API inkluderar operationer som att generera ett körbart år baserat på mappningsdesignen, anropa en mappning, anropa en sekvens av mappningar och, naturligtvis, skicka parametrar till URL:en för att köra mappningar.

Tillsammans med Oozie är det möjligt att organisera ett beräkningsflöde med Airflow. Jag kanske inte kommer att dröja länge vid jämförelsen mellan Oozie och Airflow, utan kommer helt enkelt att säga att i samband med arbetet med ett medieforskningsprojekt föll valet till Airflows fördel. Huvudargumenten denna gång var en mer aktiv community som utvecklade produkten och ett mer utvecklat gränssnitt + API.

Luftflödet är också bra eftersom det använder den älskade Python för att beskriva beräkningsprocesser. Och i allmänhet finns det inte så många plattformar för hantering av arbetsflöden med öppen källkod. Att starta och övervaka exekveringen av processer (inklusive ett Gantt-diagram) lägger bara till poäng till Airflows karma.

Konfigurationsfilformatet för lansering av lågkodslösningsmappningar har blivit spark-submit. Detta hände av två anledningar. För det första låter spark-submit dig köra en jar-fil direkt från konsolen. För det andra kan den innehålla all nödvändig information för att konfigurera arbetsflödet (vilket gör det lättare att skriva skript som genererar Dag).
Det vanligaste inslaget i Airflow-arbetsflödet i vårt fall var SparkSubmitOperator.

SparkSubmitOperator låter dig köra jars - paketerade Datagram-mappningar med förgenererade indataparametrar för dem.

Det är värt att nämna att varje Airflow-uppgift körs i en separat tråd och inte vet något om andra uppgifter. Därför utförs interaktion mellan uppgifter med hjälp av kontrolloperatorer, såsom DummyOperator eller BranchPythonOperator.

Sammantaget ledde användningen av Datagrams lågkodslösning i samband med universaliseringen av konfigurationsfiler (som bildar Dag) till en betydande acceleration och förenkling av processen att utveckla dataladdningsflöden.

Showcase beräkning

Det kanske mest intellektuellt laddade steget i produktionen av analytisk data är steget att bygga skyltfönster. Inom ramen för ett av forskningsföretagens databeräkningsflöden reduceras i detta skede data till en referenssändning, med hänsyn tagen till korrigeringar för tidszoner och kopplade till sändningsnätet. Det är också möjligt att anpassa för det lokala sändningsnätet (lokala nyheter och reklam). Detta steg bryter bland annat ner intervallen för kontinuerlig visning av medieprodukter baserat på analys av visningsintervall. Omedelbart "viktas" visningsvärdena baserat på information om deras betydelse (beräkning av en korrektionsfaktor).

Ett separat steg i att förbereda skyltfönster är datavalidering. Valideringsalgoritmen innebär användning av ett antal matematiska vetenskapsmodeller. Användningen av en lågkodsplattform låter dig dock bryta en komplex algoritm i ett antal separata visuellt läsbara mappningar. Var och en av mappningarna utför en smal uppgift. Som ett resultat är mellanliggande felsökning, loggning och visualisering av dataförberedande stadier möjlig.

Det beslutades att diskretisera valideringsalgoritmen i följande delsteg:

• Bygga regressioner av tv-nätverksberoende i en region med visning av alla nätverk i regionen under 60 dagar.
• Beräkning av studentiserade residualer (avvikelser av faktiska värden från de som förutspås av regressionsmodellen) för alla regressionspunkter och för den beräknade dagen.
• Ett urval av onormala region-nätverkspar, där det studentiserade saldot för avvecklingsdagen överstiger normen (specificeras av operationsinställningarna).
• Omräkning av den korrigerade studentiserade residual för onormala region-TV-nätverkspar för varje respondent som tittade på nätverket i regionen, vilket bestämmer bidraget från denna respondent (mängden förändring i den studerade resterande) när den här respondentens tittande exkluderas från urvalet .
• Sök efter kandidater vars uteslutning gör att det studentiserade saldot på lönedagen återgår till det normala.

Exemplet ovan bekräftar hypotesen att en dataingenjör redan har för mycket på hjärtat... Och om det här verkligen är en "ingenjör" och inte en "kodare", så är rädslan för professionell degradering när han använder lågkodsverktyg. måste äntligen dra sig tillbaka.

Vad mer kan lågkod göra?

Tillämpningsområdet för ett lågkodsverktyg för batch- och strömdatabehandling utan att behöva skriva kod manuellt i Scala slutar inte där.

Användningen av lågkod i utvecklingen av datalake har redan blivit en standard för oss. Vi kan nog säga att lösningar baserade på Hadoop-stacken följer utvecklingsvägen för klassiska DWH:er baserade på RDBMS. Lågkodsverktyg på Hadoop-stacken kan lösa både databearbetningsuppgifter och uppgiften att bygga slutliga BI-gränssnitt. Dessutom bör det noteras att BI inte bara kan betyda representation av data, utan även deras redigering av företagsanvändare. Vi använder ofta denna funktion när vi bygger analytiska plattformar för finanssektorn.

Bland annat med hjälp av lågkod och i synnerhet Datagram är det möjligt att lösa problemet med att spåra ursprunget för dataströmsobjekt med atomicitet ner till enskilda fält (lineage). För att göra detta implementerar lågkodsverktyget gränssnitt med Apache Atlas och Cloudera Navigator. I grund och botten måste utvecklaren registrera en uppsättning objekt i Atlas-ordböcker och referera till de registrerade objekten när man bygger mappningar. Mekanismen för att spåra ursprunget för data eller analysera objektberoenden sparar mycket tid när det är nödvändigt att göra förbättringar av beräkningsalgoritmerna. Till exempel, när du förbereder finansiella rapporter, låter den här funktionen dig mer bekvämt överleva perioden med lagändringar. När allt kommer omkring, ju bättre vi förstår beroendet mellan formerna i samband med objekt i ett detaljerat lager, desto mindre kommer vi att stöta på "plötsliga" defekter och minska antalet omarbetningar.

Datakvalitet och lågkod

En annan uppgift som implementerades av lågkodsverktyget i Mediascope-projektet var klassuppgiften Data Quality. En speciell egenskap för implementeringen av dataverifieringspipelinen för forskningsföretagsprojektet var bristen på inverkan på prestandan och hastigheten hos huvuddataberäkningsflödet. För att kunna orkestrera oberoende dataverifieringsflöden användes det redan välbekanta Apache Airflow. Eftersom varje steg i dataproduktionen var klart lanserades en separat del av DQ-pipelinen parallellt.

Det anses vara god praxis att övervaka kvaliteten på data från det ögonblick de inleds i den analytiska plattformen. Med information om metadata kan vi kontrollera efterlevnaden av grundläggande villkor från det ögonblick då informationen kommer in i det primära lagret - inte null, begränsningar, främmande nycklar. Denna funktionalitet implementeras baserat på automatiskt genererade mappningar av datakvalitetsfamiljen i Datagram. Kodgenerering i detta fall baseras också på modellmetadata. På Mediascope-projektet utfördes gränssnittet med metadata för Enterprise Architect-produkten.

Genom att para ihop lågkodsverktyget med Enterprise Architect genererades följande kontroller automatiskt:

• Kontrollera om det finns "null"-värden i fält med modifieraren "inte null";
• Kontrollera förekomsten av dubbletter av primärnyckeln;
• Kontrollera den främmande nyckeln för en enhet;
• Kontrollera unikheten hos en sträng baserat på en uppsättning fält.

För mer komplexa kontroller av datatillgänglighet och tillförlitlighet skapades en mappning med Scala Expression, som tar som indata en extern Spark SQL-kontrollkod som utarbetats av analytiker på Zeppelin.

Självklart måste automatisk generering av kontroller uppnås gradvis. Inom ramen för det beskrivna projektet föregicks detta av följande steg:

• DQ implementerat i Zeppelin-anteckningsböcker;
• DQ inbyggd i kartläggning;
• DQ i form av separata massiva mappningar som innehåller en hel uppsättning kontroller för en separat enhet;
• Universella parameteriserade DQ-mappningar som accepterar information om metadata och affärskontroller som input.

Den kanske främsta fördelen med att skapa en parametrerad checktjänst är minskningen av tiden det tar att leverera funktionalitet till produktionsmiljön. Nya kvalitetskontroller kan kringgå det klassiska mönstret att leverera kod indirekt genom utvecklings- och testmiljöer:

• Alla metadatakontroller genereras automatiskt när modellen modifieras i EA;
• Datatillgänglighetskontroller (som bestämmer närvaron av data vid en tidpunkt) kan genereras baserat på en katalog som lagrar den förväntade tidpunkten för uppkomsten av nästa datastycke i objektsammanhang;
• Verifieringskontroller av affärsdata skapas av analytiker i Zeppelins anteckningsböcker. Därifrån skickas de direkt till DQ-modulens inställningstabeller i produktionsmiljön.

Det finns inga risker med att skicka manus direkt till produktion. Även med ett syntaxfel är det maximala som hotar oss underlåtenhet att utföra en kontroll, eftersom databeräkningsflödet och kvalitetskontrollens lanseringsflöde är separerade från varandra.

I grund och botten körs DQ-tjänsten permanent i produktionsmiljön och är redo att börja sitt arbete i samma ögonblick som nästa del av data visas.

I stället för en slutsats

Fördelen med att använda lågkod är uppenbar. Utvecklare behöver inte utveckla applikationen från grunden. Och en programmerare befriad från ytterligare uppgifter ger resultat snabbare. Hastigheten frigör i sin tur ytterligare tid för att lösa optimeringsproblem. Därför kan du i det här fallet räkna med en bättre och snabbare lösning.

Naturligtvis är lågkod inte ett universalmedel, och magi kommer inte att hända av sig själv:

• Lågkodsindustrin går igenom ett "bli starkare" stadium, och det finns inga enhetliga industriella standarder ännu;
• Många lågkodslösningar är inte gratis, och att köpa dem bör vara ett medvetet steg, som bör göras med fullt förtroende för de ekonomiska fördelarna med att använda dem;
• Många lågkodslösningar fungerar inte alltid bra med GIT/SVN. Eller så är de obekväma att använda om den genererade koden är dold;
• Vid utbyggnad av arkitekturen kan det bli nödvändigt att förfina lågkodslösningen - vilket i sin tur framkallar effekten av "anknytning och beroende" hos leverantören av lågkodslösningen.
• En adekvat säkerhetsnivå är möjlig, men den är mycket arbetskrävande och svår att implementera i systemmotorer med låg kod. Lågkodsplattformar bör väljas inte bara utifrån principen att söka fördelar av deras användning. Vid val är det värt att ställa frågor om tillgängligheten av funktionalitet för åtkomstkontroll och delegering/eskalering av identifieringsdata till nivån för hela organisationens IT-landskap.

Men om alla brister i det valda systemet är kända för dig och fördelarna med användningen ändå är i den dominerande majoriteten, gå vidare till liten kod utan rädsla. Dessutom är övergången till det oundviklig - precis som varje evolution är oundviklig.

Om en utvecklare på en lågkodsplattform gör sitt jobb snabbare än två utvecklare utan lågkod så ger detta företaget ett försprång i alla avseenden. Tröskeln för att komma in i lågkodslösningar är lägre än för "traditionella" teknologier, och detta har en positiv effekt på frågan om personalbrist. När du använder lågkodsverktyg är det möjligt att påskynda interaktionen mellan funktionella team och fatta snabbare beslut om riktigheten av den valda vägen för datavetenskaplig forskning. Lågnivåplattformar kan driva den digitala transformationen av en organisation eftersom de lösningar som produceras kan förstås av icke-tekniska specialister (särskilt företagsanvändare).

Om du har snäva deadlines, laddad affärslogik, brist på teknisk expertis och du behöver snabba upp din tid till marknaden, så är låg kod ett sätt att möta dina behov.

Det går inte att förneka vikten av traditionella utvecklingsverktyg, men i många fall är det att använda lågkodslösningar det bästa sättet att öka effektiviteten i de uppgifter som löses.

Källa: will.com