🥇 Приложение на нискокодиране в аналитичните платформи

Уважаеми читатели, добър ден!

Задачата за изграждане на ИТ платформи за натрупване и анализ на данни рано или късно възниква при всяка компания, чиято дейност е свързана с интелектуално натоварена бизнес модел на услуги или създаване на технически сложни продукти. Изграждането на аналитични платформи е сложна и трудоемка задача. Въпреки това, всяка задача може да бъде опростена. В тази статия искам да споделя опита си от използването на low-code инструменти, които помагат при създаването на аналитични решения. Този опит беше придобит при изпълнението на редица проекти в сектора Big Data Solutions на компанията "Неофлекс". Секторът Big Data Solutions на компанията "Неофлекс" от 2005 година се занимава с изграждането на хранилища и данни, решава проблеми с оптимизацията на скоростта на обработка на информация и работи върху методология за управление на качеството на данните.

Няма как да избегнете съзнателното натрупване на слабо или силно структурирани данни. Даже ако става въпрос за малък бизнес. При разширяване на бизнеса, перспективният предприемач ще се изправи пред въпросите за разработване на програма за лоялност, ще иска да анализира ефективността на търговските точки, ще помисли за таргетирана реклама и ще се замисли за търсенето на свързани продукти. В първоначален етап задачата може да бъде решена „на коляно“. Но с нарастването на бизнеса, преминаването към аналитична платформа става неизбежно.

Но при какви обстоятелства задачите по анализ на данни могат да преминат в категория "Rocket Science"? Може би в момента, когато става въпрос за наистина големи данни.
За да опростите задачата "Rocket Science", можете да ядете слона на парчета.

Колкото по-голяма е дискретността и автономността на вашите приложения/сервизи/микросервизи, толкова по-лесно ще бъде на вас, вашите колеги и целия бизнес да преработите слона.

До този постулат стигнаха почти всички наши клиенти, които промениха ландшафта, основавайки се на инженерните практики на DevOps екипите.

Но дори при "разделна, слонска" диета, имаме добри шансове за "пренасищане" на ИТ ландшафта. В този момент е добре да спрем, да издишаме и да погледнем в посока low-code engineering platform.

Много разработчици се притесняват от перспективата за застой в кариерата си, когато преминат от непосредствено писане на код към "плъзгане" на стрелки в UI интерфейсите на low-code системи. Но появата на машини не е довела до изчезването на инженерите, а е издигнала работата им на ново ниво!

Нека разгледаме защо.

Анализът на данни в сферата на логистиката, телекомуникационната индустрия, в областта на медийните изследвания и финансовия сектор винаги е съпроводен с следните въпроси:

Скорост на провеждане на автоматизиран анализ;
Възможност за провеждане на експерименти без въздействие върху основния поток производство на данни;
Достоверност на подготвените данни;
Проследяване на промените и версиониране;
Data provenance, Data lineage, CDC;
Бързина на доставка на нови функции в продукционната среда;
И вече познатата: цена на разработка и поддръжка.

Тоест, инжинерите имат огромно количество високоефективни задачи, които могат да изпълнят успешно само като освободят съзнанието си от задачи с ниско ниво на разработка.

Предпоследователствата за преминаване на разработчиците на ново ниво са еволюцията и цифровизацията на бизнеса. Ценността на разработчика също се променя: значително недостигат разработчици, способни да се потопят в същността на концепциите за автоматизиране на бизнеса.

Нека направим аналогия с нискоуровневите и високоуровневите езици за програмиране. Преходът от нискоуровневите езици към високоуровневите е преход от написването на "директиви на езика на желязото" към "директиви на езика на хората". Тоест добавяне на определен слой абстракция. В този случай, преходът от високоуровневите езици за програмиране към low-code платформи е преход от "директиви на езика на хората" към "директиви на езика на бизнеса". Ако се намерят разработчици, които ще се натъжат от този факт, тогава те, вероятно, са били натъжени още от момента, когато се е появил JavaScript, в който се използват функции за сортиране на масиви. И тези функции, разбира се, имат под капака софтуерна имплементация посредством други средства на същото високо ниво на програмиране.

Следователно, low-code е просто поява на още един ниво на абстракция.

Прикладен опит с low-code

Темата low-code е достатъчно широка, но в момента бих искал да говоря за приложното използване на 'малокодовите концепции' на примера на един от нашите проекти.

Отделът Big Data Solutions на компанията 'Неофлекс' се специализира основно в финансовия сектор на бизнеса, изграждайки хранилища и езера от данни и автоматизирайки различни отчети. В тази ниша приложението на low-code отдавна е стандарт. Сред другите инструменти за low-code можем да споменем средства за организиране на ETL-процеси: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Или Oracle Apex, който е среда за бързо разработване на интерфейси за достъп и редактиране на данни. Въпреки това, използването на малокодови средства за разработка не винаги е свързано с изграждането на тясно насочени приложения на търговски технологичен стек с ясно изразена зависимост от вендора.

С помощта на платформите low-code може също така да се организира оркестрация на потоците от данни, да се създадат data-science платформи или, например, модули за проверка на качеството на данните.

Един от приложните примери за опит в използването на малокодови средства за разработка е колаборацията на 'Неофлекс' с компанията Mediascope, един от лидерите на руския пазар на медийни изследвания. Една от бизнес задачите на тази компания е производството на данни, на базата на които рекламодателите, интернет платформи, телевизионни канали, радиостанции, рекламни агенции и марки вземат решения относно закупуването на реклама и планират своите маркетингови комуникации.

Медийните изследвания са технологично натоварена сфера на бизнеса. Разпознаването на видео материали, събирането на данни от устройства, които анализират гледанията, измерването на активността в уеб ресурсите – всичко това предполага наличието на голям IT екип и колосален опит в изграждането на аналитични решения. Но експоненциалният растеж на количеството информация, броя и разнообразието на източниците ѝ, принуждава IT индустрията на данните да прогресира непрекъснато. Най-простото решение за мащабиране на вече функциониращата аналитична платформа Mediascope би могло да бъде увеличаването на IT екипа. Но много по-ефективното решение е ускоряването на процеса на разработка. Един от стъпките, водещи към това, би могло да бъде използването на платформи low-code.

При старта на проекта компания вече имаше функциониращо продуктово решение. Обаче реализирането на решението върху MSSQL не можеше напълно да отговори на очакванията за мащабируемост на функционала с поддържане на приемлива цена за доработка.

Задачата, пред която стояхме, беше наистина амбициозна – «Неофлекс» и Mediascope трябваше да създадат индустриално решение за по-малко от година, при условие за излизане на MVP в рамките на първото тримесечие от началото на работата.

Като основа за изграждане на новата платформа за данни, основана на low-code изчисления, беше избран технологичният стек Hadoop. Стандартът за съхранение на данни стана HDFS с използване на файлове формат parquet. За достъп до данните, намиращи се в платформата, беше използван Hive, в който всички налични витрини са представени под формата на външни таблици. Зареждането на данни в хранилището се реализираше с помощта на Kafka и Apache NiFi.

Low-code инструментът в тази концепция беше приложен за оптимизиране на най-трудоемката задача в изграждането на аналитичната платформа – задачата за изчисление на данни.

Основният механизъм за маппиране на данни беше избран low-code инструмент Datagram. Neoflex Datagram е средство за разработка на трансформации и потоци данни.
Използвайки този инструмент, може да се мине без писане на код на Scala „на ръка“. Кодът на Scala се генерира автоматично с използването на подхода Model Driven Architecture.

Ясният плюс на такъв подход е ускорението на процеса на разработка. Но освен скоростта, има още следните предимства:

Преглед на съдържанието и структурата на източниците/приемниците;
Проследяване на произхода на обектите в потока данни до отделни полета (lineage);
Частично изпълнение на преобразованията с преглед на междинни резултати;
Преглед на изходния код и неговата корекция преди изпълнение;
Автоматична валидация на трансформациите;
Автоматично зареждане на данни 1 към 1.

Прагът за влизане в решенията с нисък код за генериране на трансформации е сравнително нисък: разработчикът трябва да знае SQL и да има опит с ETL инструменти. Важно е да се уточни, че генераторите на трансформации, управлявани от код, не са ETL инструменти в широкия смисъл на термина. Инструментите с нисък код може да нямат собствена среда за изпълнение на кода. Тоест генерираният код ще се изпълнява в средата, която е била налична в кластера преди инсталирането на решението с нисък код. И това е, може би, още едно предимство за ниския код. Тъй като в паралел с екипа с нисък код може да работи „класически“ екип, който реализира функционалността, например, с чист код на Scala. Интегрирането на подобрения от двата екипа в продуктивната среда ще бъде просто и „безшевно“.

Наистина, трябва да се отбележи, че освен ниския код съществуват и решения без код (no-code). По същество те представляват различни неща. Ниският код в значителна степен позволява на разработчика да се намеси в генерирания код. В случая с Datagram е възможно да се прегледа и редактира генерираният код на Scala, което може да не е възможно за решения без код. Тази разлика е значителна не само по отношение на гъвкавостта на решението, но и по отношение на комфорта и мотивацията на работещите с данни инженери.

Архитектура на решението

Нека се опитаме да разберем как точно инструментът с нисък код помага за разрешаването на задачата за оптимизиране на скоростта на разработка на функционалността за изчисление на данни. Първо, нека разгледаме функционалната архитектура на системата. В този случай пример представлява моделът на производството на данни за медийни изследвания.

Източниците на данни в нашия случай са доста хетерогенни и разнообразни:

Пипълметри (ТВ-метри) — програмно-апаратни устройства, които регистрират поведението на потребителите на респондентската телевизионна панелка – кой, кога и какъв телевизионен канал е гледал в домакинството, което участва в проучването. Предоставената информация е поток от интервали на гледане на ефир с привязване към медиапакета и медиапродукта. Данните на етапа на зареждане в Data Lake могат да бъдат обогатени с демографски атрибути, свързване с геострат, времеви зони и друга информация, необходима за провеждане на анализ на телегледането на определен медиен продукт. Извършените измервания могат да бъдат използвани за анализ или планиране на рекламни кампании, оценка на активността и предпочитанията на аудиторията, изготвяне на програмна схема;
Данните могат да постъпват от системи за мониторинг на потоково телевизионно предаване и измерване на гледаемостта на съдържанието на видеоресурси в интернет;
Измервателни инструменти в уеб-среда, сред които както site-centric, така и user-centric броячи. Доставчик на данни за Data Lake може да бъде разширение на браузъра research bar и мобилно приложение с вградена функционалност; VPN.
Данните също могат да постъпват от платформи, които консолидират резултатите от попълване на онлайн анкети и резултатите от провеждането на телефонни интервюта в проучванията на компанията;
Допълнителното обогатяване на данните в lake може да се извърши чрез зареждане на информация от логовете на партньорските компании.

Имплементацията на as is зареждане от системи-източници в първичен staging на сурови данни може да бъде организирана по различни начини. В случай, че за тези цели се използва low-code, е възможна автоматична генерация на скриптове за зареждане на базата на метаданни. При това не е необходимо да се спускаме на ниво разработка на mapping от source to target. За реализиране на автоматичното зареждане трябва да установим свързаност с източника, след което да определим в интерфейса за зареждане списъка с единици, подлежащи на зареждане. Създаването на структура за каталози в HDFS ще се извърши автоматично и ще отговаря на структурата на съхранение на данни в системата-източник.

Въпреки това, в контекста на този проект решихме да не използваме възможността на low-code платформите, тъй като компанията Mediascope вече е започнала работа по разработване на аналогична услуга в рамките на Nifi + Kafka.

Веднага трябва да подчертаем, че тези инструменти не са взаимозаменяеми, а по-скоро допълват един друг. Nifi и Kafka могат да работят както в пряка (Nifi -> Kafka), така и в обратна (Kafka -> Nifi) връзка. За платформата за медийни изследвания беше използвана първата опция за свързване.

В нашия случай на Nifi трябваше да обработва различни типове данни от системите-източници и да ги изпраща на брокера Kafka. В същото време, насочването на съобщенията в определена тема в Kafka се извършва чрез използването на Nifi-процесорите PublishKafka. Оркестрацията и обслужването на тези pipeline-ове се извършва в визуалния интерфейс. Инструментът Nifi и използването на комбинацията Nifi + Kafka също могат да се нарекат подход с нисък код за разработка, предоставящ нисък праг на влизане в технологиите Big Data и ускоряващ процеса на разработване на приложения.

Следващата стъпка в реализирането на проекта беше приведението към формата на единен семантичен слой на детайлните данни. В случай че съществото има исторически атрибути, изчислението се извършва в контекста на разглежданата партиция. Ако обаче съществото не е историческо, то опционално е възможен либо повторен обход на всичкото съдържание на обекта, либо изцяло отказ от повторния обход на този обект (поради липса на изменения). На този етап се генерират ключове за всички съществителни. Ключовете се запазват в съответните справочници на мастер-обектите Hbase, съдържащи съответствието между ключовете в аналитичната платформа и ключовете от системите-източници. Консолидацията на атомарните съществителни се придружава с обогатяване на резултатите от предварителното изчисление на аналитичните данни. Framework-ът за изчисление на данните беше Spark. Описаната функционалност за приведението на данните към единна семантика беше реализирана също на базата на маппинги на инструмента с нисък код Datagram.

В целевата архитектура беше необходимо да се осигури SQL-достъп до данните за бизнес потребителите. За тази опция беше използван Hive. Регистрацията на обектите в Hive става автоматично при включване на опцията «Registr Hive Table» в инструмента с нисък код.

Управление на потока на изчисление

Datagram предлагая интерфейс за проектиране на workflow потоци. Мапингите могат да се стартират с помощта на Oozie планировчик. В интерфейса за разработка на потоци е възможно създаването на паралелни, последователни или зависещи от условията изпълнения на трансформации на данни. Подкрепят се shell скриптове и java програми. Също така е възможно използването на сървър Apache Livy. Apache Livy се използва за стартиране на приложения директно от средата за разработка.

Ако компанията вече разполага с собствен оркестратор на процеси, е възможно използването на REST API за интегриране на мапингите в съществуващия поток. Например, имали сме доста успешен опит с интегрирането на мапинги на Scala в оркестратори, написани на PLSQL и Kotlin. REST API на инструмента с малко код предполага наличие на операции като генериране на изпълняем код на базата на дизайна на мапинга, извикване на мапинга, извикване на последователност от мапинги и, разбира се, предаване на параметри в URL за стартиране на мапингите.

Заедно с Oozie, е възможно организиране на поток на изчисление с помощта на Airflow. Няма да се спирам дълго на сравнение между Oozie и Airflow, а просто ще кажа, че в контекста на проектите за медийни изследвания изборът падна върху Airflow. Основните аргументи бяха по-активната общност, развиваща продукта, и по-развитият интерфейс + API.

Airflow също е добър, защото за описване на изчислителните процеси се използва обичаният от мнозина Python. И като цяло, платформите за управление на работни потоци с отворен код не са толкова много. Стартирането и мониторингът на изпълнението на процесите (включително с диаграма на Ганта) само добавят точки в кармата на Airflow.

Форматът на конфигурационния файл за стартиране на мапингите на решения с малко код стана spark-submit. Това се случи по две причини. Първо, spark-submit позволява директно стартиране на jar файл от конзолата. Второ, той може да съдържа цялата необходима информация за конфигуриране на работния поток (което улеснява писането на скриптове, генериращи Dag).
Най-често срещаният елемент от работния поток на Airflow в нашия случай стана SparkSubmitOperator.

SparkSubmitOperator позволява стартирането на jar-ове — опаковани мапинги на Datagram с предварително формулирани входни параметри.

Важно отметить, че всяка задача в Airflow се изпълнява в отделен поток и не знае нищо за другите задачи. В тази връзка взаимодействието между задачите се осъществява чрез оператори за управление, като DummyOperator или BranchPythonOperator.

Комбинацията от използването на low-code решение Datagram в съчетание с унификацията на конфигурационните файлове (формиращи Dag) доведе до съществено ускорение и опростяване на процеса на разработка на потоци за зареждане на данни.

Изчисляване на витрини

Вероятно, най-интелектуално натовареният етап в производството на аналитични данни е стъпката по изграждане на витрини. В контекста на един от потоките за изчисляване на данни на изследователска компания, на този етап се извършва приведението към еталонната транслация с отчитане на поправките за часови зони, свързани със системата за излъчване. Също така е възможно коригиране на местната ефирна мрежа (местни новини и реклама). Сред другото, на тази стъпка се извършва разбивка на интервалите на непрекъснато гледане на медиапродукти на база анализ на интервалите на гледане. Тук също се извършва „взвешаване“ на стойностите на гледането на база информация за тяхната значимост (изчисляване на поправъчния коефициент).

Отделен етап за подготовка на витрини е валидизацията на данни. Алгоритмът за валидизация е свързан с прилагането на редица математически science-модели. Въпреки това, използването на low-code платформа позволява сложният алгоритъм да бъде разделен на редица отделни визуално четими мапинги. Всеки от мапингите изпълнява конкретна задача. В резултат на което е възможен междинен дебъг, логване и визуализация на етапите на подготовка на данните.

Решено е алгоритъмът за валидизация да бъде дискретизиран на следните подетапи:

Изграждане на регресии на зависимостите между гледането на телевизионната мрежа в региона и гледането на всички мрежи в региона за 60 дни.
Изчисляване на стюдентизирани остатъци (отклонения на действителните стойности от предсказаните от регресионния модел) за всички точки на регресия и за изчисления ден.
Избор на аномални двойки регион-телевизионна мрежа, където стюдентизираният остатък за изчисления ден надвишава нормата (задана от настройката на операцията).
Преброяване на коригирания стюдентализиран остатък по аномални двойки регион-телесет за всеки респондент, гледал мрежата в региона с определяне на вноската на този респондент (размер на промяната на стюдентализирания остатък) при изключване на гледането на този респондент от извадката.
Търсене на кандидати, чийто изключения водят стюдентализирания остатък на отчетния ден в норма.

Приведеният по-горе пример е потвърждение на хипотезата, че дата-инженерът вече трябва да има твърде много в главата си… И, ако това наистина е "инженер", а не "кодер", страхът от професионалната деградация при използване на low-code инструменти трябва напълно да отстъпи.

Какво друго може low-code?

Областта на приложение на low-code инструмент за пакетна и потокова обработка на данни без необходимост от ръчно написване на код на Scala не свършва.

Приложението на low-code в разработката на datalake'ове вече стана стандарт за нас. Може би може да се каже, че решенията на стека Hadoop следват пътя на развитие на класически DWH, основани на РСУБД. Малокодовите инструменти на стека Hadoop могат да решават както задачи за обработка на данни, така и задачи за изграждане на крайни BI интерфейси. И трябва да се отбележи, че под BI може да се разбира не само представянето на данни, но и тяхното редактиране от бизнес потребители. Тази функционалност често я използваме при изграждането на аналитични платформи за финансовия сектор.

Сред различия, с помощта на low-code и, в частност, Datagram е възможно да се реши задачата за проследяване на произхода на обектите в потока от данни с атомарност до отделни полета (lineage). За това в low-code инструмента е имплементирано свързване с Apache Atlas и Cloudera Navigator. По същество, на разработчика е необходимо да регистрира набор от обекти в речниците на Atlas и да се позовава на регистрираните обекти при изграждането на мапинги. Механизмът за проследяване на произхода на данни или анализ на зависимостите на обектите спестява значително количество време при необходимост от внесе доработки в алгоритмите за изчисление. Например, при изграждането на финансов отчет, тази функция позволява по-комфортно да преживеем периода на промени в законодателството. Все пак, колкото по-добре осъзнаваме междупластовата зависимост в контекста на обектите от детайлния слой, толкова по-малко ще се сблъскаме с "внезапни" дефекти и ще намалим броя на реворковете.

Качество на данни & low-code

Още една задача, реализирана от low-code инструмента в проекта на компанията Mediascope, стана задача от клас Data Quality. Особеност на реализирането на конвейера за проверка на данни за проекта на изследователската компания бе отсъствието на влияние върху работоспособността и скоростта на основния поток на изчисление на данни. За възможността за оркестрация на независими потоци за проверка на данни се използва вече познатият Apache Airflow. При подготовката на всяка стъпка на производството на данни паралелно се стартираше отделната част на DQ-конвейера.

Добра практика е да се наблюдава качеството на данните от момента на тяхното създаване в аналитичната платформа. Имайки информация за метаданните, можем вече от момента на попадане на информацията в първичния слой да проверяваме спазването на базовите условия — not null, constraints, foreign keys. Тази функционалност е реализирана на база на автоматично генерирани мапинги от семейството на data quality в Datagram. Кодогенерацията в този случай също се основава на метаданните на модела. В проекта на компанията Mediascope взаимодействието е станало с метаданните на продукта Enterprise Architect.

Благодарение на свързването на low-code инструмента и Enterprise Architect автоматично бяха генерирани следните проверки:

Проверка за наличие на стойности «null» в полета с модификатор «not null»;
Проверка за наличие на дубли на първичния ключ;
Проверка на външен ключ на съществото;
Проверка за уникалност на реда по набор от полета.

За по-сложни проверки на достъпност и валидност на данни е създадено мапиране с Scala Expression, което приема за вход външен Spark SQL код за проверка, подготвен от анализаторите в Zeppelin.

Разбира се, автогенерацията на проверки трябва да настъпи постепенно. В рамките на описваното проекта предшестваха следните стъпки:

DQ, реализирани в бележниците на Zeppelin;
DQ, интегрирани в мапирането;
DQ под формата на отделни обемисти мапинг, съдържащи цял набор от проверки за отделна същност;
Универсални параметризирани DQ-мапинги, приемащи за вход информация за метаданни и бизнес проверки.

Основното предимство на създаването на услуга за параметризирани проверки е съкращаването на времето за доставяне на функционалността в продукционната среда. Новите проверки за качество могат да заобиколят класическия шаблон за доставка на код чрез разработки и тестови среди:

Всички проверки на метаданни се генерират автоматично при промяна на модела в EA;
Проверки за достъпност на данни (определяне на наличието на някакви данни в конкретен момент) могат да бъдат генерирани на основа на справочник, който съхранява очакваното време за поява на поредната партида данни по отношение на обектите;
Бизнес проверки на валидността на данни се създават от анализаторите в бележниците на Zeppelin. От там те директно се изпращат към конфигурационните таблици на модула DQ в продукционната среда.

Рисковете от директно извършване на скриптове на продукцията не съществуват. Дори при синтактична грешка, максималното, което ни заплашва, е неизпълнението на една проверка, тъй като потокът на изчисление на данни и потокът на стартиране на проверки за качество са разделени.

Същността е, че услугата DQ е постоянно активирана в продукционната среда и е готова да започне работа при появата на поредната партида данни.

Вместо заключение

Предимството на използването на low-code е очевидно. Разработчиците не трябва да създават приложение "от нулата". Освободеният от допълнителни задачи програмист дава резултати по-бързо. Скоростта, от своя страна, освобождава допълнителни ресурси от време за решаване на оптимизационни въпроси. Следователно, в този случай може да се разчита на наличието на по-качествено и бързо решение.

Разбира се, low-code не е панацея, а магията сама по себе си няма да се случи:

Индустрията на low-code преминава през етап на "засилване" и все още няма еднообразни индустриални стандарти;
Много low-code решения не са безплатни и тяхното придобиване трябва да бъде осъзната стъпка, която трябва да се направи при пълна увереност в финансовата полза от тяхното използване;
Много малкокодови решения не винаги работят добре с GIT / SVN. Или са неудобни за използване в случай на скриване на генерирания код;
При разширяване на архитектурата може да се наложи доработка на малкокодовото решение – което, от своя страна, провокира ефект на "принадлежност и зависимост" от доставчика на low-code решение.
Нужният ниво на осигуряване на сигурността е възможно, но е доста трудоемко и сложно за реализиране в low-code системи. Малкокодовите платформи трябва да се избират не само по принципа на търсене на полза от тяхното използване. При избора е хубаво да се зададете въпроса за наличието на функционалност за управление на достъпа и делегиране/ескалация на идентификационни данни на ниво в целия IT ландшафт на организацията.

Въпреки това, ако всички недостатъци на избраната система са ви известни и ползите от нейното използване, въпреки това, са в доминиращо мнозинство, можете да преминете към малкия код без страх. Тем повече, че преходът към него е неизбежен – както е неизбежна всяка еволюция.

Ако един разработчик на платформата за нискокодиране извършва работата си по-бързо от двама разработчици без нискокодиране, то това предоставя на компанията предимство във всяко отношение. Прагът за влизане в решения за нискокодиране е по-нисък от този на "традиционните" технологии и това оказва положително влияние върху въпроса за недостига на кадри. При използването на инструменти с нисък код е възможно да се ускори взаимодействието между функционалните екипи и по-бързо вземане на решения относно правилността на избрания път на изследванията в data science. Нискокодовите платформи могат да станат причина за цифрова трансформация на организацията, тъй като произведените решения могат да бъдат достъпни за разбиране от нетехническите специалисти (в частност, бизнес потребителите).

Ако имате стегнати срокове, натоварена бизнес логика, недостиг на технологична експертиза, и ви е необходимо да ускорите времето за навлизане на пазара, то нискокодиране е един от начините да задоволите вашите нужди.

Не бива да се отрича значението на традиционните инструменти за разработка, обаче в много случаи използването на решения с нисък код е най-добрият начин за повишаване на ефективността на решаването на задачите.

Източник: habr.com