分析プラットフォームにおけるローコードの適用

読者の皆様、こんにちは！

データを収集して分析するための IT プラットフォームを構築するという課題は、知的負荷のサービス提供モデルや技術的に複雑な製品の開発に基づいてビジネスを行う企業には遅かれ早かれ発生します。 分析プラットフォームの構築は複雑で時間のかかる作業です。 ただし、どんなタスクも簡素化することができます。 この記事では、分析ソリューションの作成に役立つローコード ツールの使用に関する私の経験を共有したいと思います。 この経験は、Neoflex 社のビッグ データ ソリューションの方向での多数のプロジェクトの実施中に得られました。 2005 年以来、Neoflex のビッグ データ ソリューションの方向性は、データ ウェアハウスとレイクの構築の問題に取り組み、情報処理速度の最適化の問題を解決し、データ品質管理の方法論に取り組んできました。

構造が弱いデータや構造が強いデータの意識的な蓄積を避けることは誰にもできません。 おそらく中小企業の話であっても。 結局のところ、将来有望な起業家は、ビジネスを拡大する際、ロイヤルティ プログラムの開発という問題に直面し、POS の有効性を分析したいと考え、ターゲットを絞った広告について考え、付随する製品の需要に困惑することになるでしょう。 。 一次近似的に、この問題は「膝の上で」解決できます。 しかし、ビジネスが成長するにつれて、分析プラットフォームの利用は依然として避けられません。

しかし、どのような場合にデータ分析タスクが「ロケット サイエンス」クラスの問題に発展する可能性があるのでしょうか? おそらく、私たちが本当にビッグデータについて話している瞬間です。
ロケットサイエンスを簡単にするために、ゾウを少しずつ食べることができます。

アプリケーション/サービス/マイクロサービスがより離散的かつ自律的であればあるほど、あなた、あなたの同僚、そしてビジネス全体が象を理解するのが容易になります。

当社のクライアントのほとんどすべてが、DevOps チームのエンジニアリング プラクティスに基づいてランドスケープを再構築し、この仮説にたどり着きました。

しかし、たとえ「象のような分離」ダイエットを行ったとしても、IT 環境が「過飽和」になる可能性は十分にあります。 この瞬間、立ち止まり、息を吐き、横を見る価値があります ローコードエンジニアリングプラットフォーム.

多くの開発者は、コードを直接記述する作業からローコード システムの UI インターフェイスで矢印を「ドラッグ」する作業に移行すると、キャリアが行き詰まるのではないかと恐れています。 しかし、工作機械の出現によってエンジニアが消滅したわけではなく、彼らの仕事は新たなレベルに引き上げられました。

その理由を考えてみましょう。

物流、通信業界、メディア調査、金融分野のデータ分析には、常に次のような疑問が伴います。

• 自動分析の速度。
• 主要なデータ生成フローに影響を与えることなく実験を実施できる能力。
• 準備されたデータの信頼性。
• 変更の追跡とバージョン管理。
• データの出所、データ系統、CDC。
• 新機能を実稼働環境に迅速に提供します。
• そして悪名高いのは、開発とサポートのコストです。

つまり、エンジニアは高レベルのタスクを膨大に抱えており、低レベルの開発タスクの意識をクリアにするだけで十分な効率で完了することができます。

開発者が新たなレベルに移行するための前提条件は、ビジネスの進化とデジタル化でした。 開発者の価値も変化しており、自動化されるビジネスの概念に没頭できる開発者が大幅に不足しています。

低レベルプログラミング言語と高レベルプログラミング言語を例えてみましょう。 低レベル言語から高レベル言語への移行は、「ハードウェアの言語での直接命令」の作成から「人間の言語での命令」への移行です。 つまり、抽象化のレイヤーを追加します。 この場合、高級プログラミング言語からローコード プラットフォームへの移行は、「人々の言語での指示」から「ビジネス言語での指示」への移行です。 この事実を悲しんでいる開発者がいるとしたら、その人はおそらく、配列ソート関数を使用する Java Script が誕生した瞬間から悲しんでいるのでしょう。 そしてもちろん、これらの機能は、同じ高レベルのプログラミングによる他の手段によって、内部でソフトウェア実装されています。

したがって、ローコードは、抽象化の別のレベルの外観にすぎません。

ローコードを使用した応用経験

ローコードと一言で言っても非常に幅広いですが、ここでは私たちのプロジェクトを例に「ローコードの概念」の実践についてお話したいと思います。

Neoflex のビッグ データ ソリューション部門は、金融分野のビジネスに特化しており、データ ウェアハウスとレイクの構築とさまざまなレポートの自動化を行っています。 このニッチ分野では、ローコードの使用が長い間標準になっています。 ローコード ツールの中でも、ETL プロセスを整理するためのツールとして、Informatica Power Center、IBM Datastage、Pentaho Data Integration を挙げることができます。 または、Oracle Apex は、データにアクセスして編集するためのインターフェースを迅速に開発するための環境として機能します。 ただし、ローコード開発ツールの使用には、ベンダーに明確に依存する商用テクノロジ スタック上で、目的を絞ったアプリケーションを構築することが常に含まれるわけではありません。

ローコード プラットフォームを使用すると、データ フローのオーケストレーションを組織したり、データ サイエンス プラットフォームや、たとえばデータ品質をチェックするためのモジュールを作成したりすることもできます。

ローコード開発ツールの使用経験の応用例の XNUMX つは、Neoflex と、ロシアのメディア調査市場のリーダーの XNUMX つである Mediascope とのコラボレーションです。 この会社のビジネス目標の XNUMX つは、広告主、インターネット プラットフォーム、テレビ チャンネル、ラジオ局、広告代理店、ブランドが広告の購入に関する決定を下し、マーケティング コミュニケーションを計画するためのデータに基づいてデータを作成することです。

メディアリサーチはテクノロジーを多用したビジネス分野です。 ビデオ シーケンスの認識、視聴を分析するデバイスからのデータ収集、Web リソース上のアクティビティの測定 - これらすべては、同社が多数の IT スタッフと分析ソリューションの構築における膨大な経験を持っていることを意味します。 しかし、情報量、そのソースの数、種類が急激に増加することにより、IT データ業界は絶えず進歩する必要があります。 すでに機能している Mediascope 分析プラットフォームを拡張するための最も簡単な解決策は、IT スタッフを増員することです。 しかし、より効果的な解決策は、開発プロセスをスピードアップすることです。 この方向に導くステップの XNUMX つは、ローコード プラットフォームの使用かもしれません。

プロジェクトが開始された時点で、同社はすでに機能する製品ソリューションを持っていました。 ただし、MSSQL でのソリューションの実装では、許容可能な開発コストを維持しながら機能をスケーリングするという期待を完全に満たすことはできませんでした。

私たちの目の前の仕事は本当に野心的なものでした。Neoflex と Mediascope は、開始日の第 XNUMX 四半期以内に MVP をリリースすることを条件として、XNUMX 年以内に産業用ソリューションを作成する必要がありました。

Hadoop テクノロジー スタックは、ローコード コンピューティングに基づく新しいデータ プラットフォームを構築するための基盤として選択されました。 HDFS は、寄木細工のファイルを使用したデータ ストレージの標準になりました。 プラットフォーム内にあるデータにアクセスするために、Hive が使用されました。Hive では、利用可能なすべてのストアフロントが外部テーブルの形式で表示されます。 ストレージへのデータのロードは、Kafka と Apache NiFi を使用して実装されました。

このコンセプトにおける Lowe コード ツールは、分析プラットフォームの構築において最も労働集約的なタスクであるデータ計算タスクを最適化するために使用されました。

データ マッピングの主なメカニズムとして、ローコード データグラム ツールが選択されました。 Neoflex データグラム は、変換とデータ フローを開発するためのツールです。
このツールを使用すると、Scala コードを手動で記述しなくても済みます。 Scala コードは、モデル駆動アーキテクチャのアプローチを使用して自動的に生成されます。

このアプローチの明白な利点は、開発プロセスをスピードアップできることです。 ただし、速度に加えて、次の利点もあります。

• ソース/レシーバーのコンテンツと構造を表示します。
• データ フロー オブジェクトの起源を個々のフィールド (系統) まで追跡します。
• 中間結果を表示して変換を部分的に実行します。
• 実行前にソースコードをレビューして調整します。
• 変換の自動検証。
• 自動データダウンロード 1 in 1。

変換を生成するためのローコード ソリューションへの参入障壁は非常に低く、開発者は SQL の知識と ETL ツールの使用経験が必要です。 コード駆動型の変換ジェネレーターは、広い意味での ETL ツールではないことに注意してください。 ローコード ツールには、独自のコード実行環境がない場合があります。 つまり、生成されたコードは、ローコード ソリューションをインストールする前であっても、クラスター上に存在していた環境で実行されます。 そして、これはおそらく、ローコード カルマにとってもう XNUMX つの利点です。 ローコード チームと並行して、「クラシック」チームは、たとえば純粋な Scala コードで機能を実装する作業を行うことができるためです。 両方のチームによる改善を実稼働環境に反映することは、シンプルかつシームレスになります。

ローコードに加えて、ノーコード ソリューションもあることはおそらく注目に値します。 そして根本的には、これらは異なるものです。 ローコードを使用すると、開発者は生成されたコードにさらに干渉できます。 Datagram の場合、生成された Scala コードを表示および編集することができますが、ノーコードではそのような機会が提供されない可能性があります。 この違いは、ソリューションの柔軟性の点だけでなく、データ エンジニアの作業の快適さとモチベーションの点でも非常に重要です。

ソリューションアーキテクチャ

データ計算機能の開発速度を最適化するという問題の解決にローコード ツールがどのように役立つかを正確に理解してみましょう。 まず、システムの機能アーキテクチャを見てみましょう。 この場合の例は、メディア調査のためのデータ生成モデルです。

私たちの場合、データ ソースは非常に異質で多様です。

• ピープル メーター (TV メーター) は、テレビ パネルの回答者からユーザーの行動 (調査に参加している世帯で、誰が、いつ、どのテレビ チャンネルを視聴したか) を読み取るソフトウェアおよびハードウェア デバイスです。 提供される情報は、メディア パッケージおよびメディア 製品に関連付けられた放送視聴間隔のストリームです。 データ レイクにロードする段階のデータは、特定のメディア製品のテレビ視聴を分析するために必要な人口統計的属性、地理階層、タイムゾーン、その他の情報で強化できます。 取得された測定値は、広告キャンペーンの分析や計画、視聴者の活動や好みの評価、放送ネットワークの構築に使用できます。
• データは、ストリーミング テレビ放送の監視システムや、インターネット上のビデオ リソース コンテンツの視聴の測定から得られます。
• サイト中心のメーターとユーザー中心のメーターの両方を含む、Web 環境の測定ツール。 データ レイクのデータ プロバイダーには、リサーチ バー ブラウザー アドオンや、VPN が組み込まれたモバイル アプリケーションを使用できます。
• データは、オンライン アンケートへの記入結果と企業調査での電話インタビューの結果を統合するサイトから取得することもできます。
• パートナー企業のログから情報をダウンロードすることで、データ レイクをさらに強化できます。

ソース システムから生データのプライマリ ステージングへのそのままの読み込みの実装は、さまざまな方法で編成できます。 これらの目的にローコードを使用すると、メタデータに基づいたローディング スクリプトの自動生成が可能になります。 この場合、ソースからターゲットへのマッピングを開発するレベルまで下がる必要はありません。 自動ロードを実装するには、ソースへの接続を確立し、ロードするエンティティのリストをロード インターフェイスで定義する必要があります。 HDFS 内のディレクトリ構造は自動的に作成され、ソース システム上のデータ ストレージ構造に対応します。

ただし、このプロジェクトの文脈では、Mediascope 社がすでに Nifi + Kafka の組み合わせを使用して同様のサービスを独自に作成する作業を開始しているという事実により、ローコード プラットフォームのこの機能を使用しないことにしました。

これらのツールは互換性のあるものではなく、むしろ補完的なものであることをすぐに示す価値があります。 Nifi と Kafka は、直接接続 (Nifi -> Kafka) と逆接続 (Kafka -> Nifi) の両方で機能します。 メディア リサーチ プラットフォームには、バンドルの最初のバージョンが使用されました。

私たちの場合、NayFi はソース システムからのさまざまなタイプのデータを処理し、それらを Kafka ブローカーに送信する必要がありました。 この場合、メッセージは PublishKafka Nifi プロセッサを使用して特定の Kafka トピックに送信されました。 これらのパイプラインのオーケストレーションとメンテナンスは、ビジュアル インターフェイスで実行されます。 Nifi ツールと Nifi + Kafka の組み合わせの使用は、開発へのローコード アプローチとも言えます。これにより、ビッグ データ テクノロジへの参入障壁が低くなり、アプリケーション開発プロセスが高速化されます。

プロジェクト実装の次の段階は、詳細データを単一のセマンティック レイヤー形式に変換することでした。 エンティティに履歴属性がある場合、計算は問題のパーティションのコンテキストで実行されます。 エンティティが履歴的なものではない場合、オプションでオブジェクトの内容全体を再計算することも、(変更がないため) このオブジェクトの再計算を完全に拒否することもできます。 この段階で、すべてのエンティティのキ​​ーが生成されます。 キーは、マスター オブジェクトに対応する Hbase ディレクトリに保存されます。このディレクトリには、分析プラットフォームのキーとソース システムのキー間の対応関係が含まれています。 原子実体の統合には、分析データの予備計算の結果による強化が伴います。 データ計算のフレームワークは Spark でした。 データを単一のセマンティクスに統合するための説明された機能も、ローコード データグラム ツールからのマッピングに基づいて実装されました。

ターゲット アーキテクチャでは、ビジネス ユーザーのデータへの SQL アクセスが必要でした。 このオプションには Hive が使用されました。 ローコード ツールの [Registr Hive Table] オプションを有効にすると、オブジェクトが Hive に自動的に登録されます。

計算フロー制御

Datagram には、ワークフローのフロー設計を作成するためのインターフェイスがあります。 マッピングは、Oozie スケジューラーを使用して起動できます。 ストリーム開発者インターフェイスでは、並列、順次、または実行依存のデータ変換のスキームを作成できます。 シェル スクリプトと Java プログラムがサポートされています。 Apache Livy サーバーを使用することもできます。 Apache Livy は、開発環境からアプリケーションを直接実行するために使用されます。

企業がすでに独自のプロセス オーケストレーターを持っている場合は、REST API を使用して既存のフローにマッピングを埋め込むことができます。 たとえば、私たちは、PLSQL と Kotlin で書かれたオーケストレーターに Scala のマッピングを埋め込むという非常に成功した経験があります。 ローコード ツールの REST API には、マッピング設計に基づいて実行可能な年の生成、マッピングの呼び出し、一連のマッピングの呼び出し、そしてもちろん、マッピングを実行するための URL へのパラメーターの受け渡しなどの操作が含まれています。

Oozie と合わせて、Airflow を使用して計算フローを整理することができます。 おそらく、Oozie と Airflow の比較については長くは述べませんが、メディア研究プロジェクトの作業の文脈において、選択は Airflow に有利になったとだけ述べておきます。 今回の主な議論は、製品を開発するより活発なコミュニティと、より開発されたインターフェイスと API でした。

Airflow は計算プロセスの記述に人気の Python を使用しているため、優れています。 そして一般に、オープンソースのワークフロー管理プラットフォームはそれほど多くありません。 プロセスの実行 (ガント チャートを含む) の起動と監視は、Airflow のカルマにポイントを追加するだけです。

ローコード ソリューション マッピングを起動するための構成ファイル形式は、spark-submit になりました。 これには XNUMX つの理由があります。 まず、spark-submit を使用すると、コンソールから jar ファイルを直接実行できます。 次に、ワークフローを構成するために必要な情報をすべて含めることができます (これにより、Dag を生成するスクリプトの記述が容易になります)。
この場合の Airflow ワークフローの最も一般的な要素は SparkSubmitOperator でした。

SparkSubmitOperator を使用すると、jar (事前に生成された入力パラメーターを使用してパッケージ化されたデータグラム マッピング) を実行できます。

各 Airflow タスクは別のスレッドで実行され、他のタスクについては何も認識しないことに注意してください。 したがって、タスク間の対話は、DummyOperator や BranchPythonOperator などの制御演算子を使用して実行されます。

まとめると、構成ファイルの汎用化 (Dag の形成) と組み合わせた Datagram ローコード ソリューションの使用により、データ ロード フローの開発プロセスが大幅に高速化され、簡素化されました。

ショーケースの計算

おそらく、分析データの作成において最も知的負荷がかかる段階は、ショーケースを構築するステップです。 調査会社のデータ計算フローの XNUMX つでは、この段階で、データはタイム ゾーンの補正を考慮して基準放送に変換され、放送グリッドにリンクされます。 ローカル放送ネットワーク (ローカル ニュースや広告) に合わせて調整することもできます。 とりわけ、このステップでは、視聴間隔の分析に基づいてメディア製品の連続視聴間隔を細分化します。 すぐに、視聴値はその重要性に関する情報に基づいて「重み付け」されます（補正係数の計算）。

ショーケースを準備する別のステップはデータ検証です。 検証アルゴリズムには、多数の数理科学モデルの使用が含まれます。 ただし、ローコード プラットフォームを使用すると、複雑なアルゴリズムを視覚的に読み取り可能な多数の個別のマッピングに分割できます。 各マッピングは狭いタスクを実行します。 その結果、データ準備段階の中間的なデバッグ、ログ記録、視覚化が可能になります。

検証アルゴリズムを次のサブステージに離散化することが決定されました。

• 60 日間、地域内のすべてのネットワークを視聴して、地域内の TV ネットワーク視聴依存関係の回帰を構築します。
• すべての回帰ポイントおよび計算された日のスチューデント化残差 (回帰モデルによって予測された値からの実際の値の偏差) の計算。
• 決済日のスチューデント化された残高が標準 (操作設定で指定された) を超える、異常な地域とネットワークのペアの選択。
• 地域内のネットワークを視聴した各回答者について、異常な地域と TV ネットワークのペアの修正済みスチューデント化残差を再計算し、サンプルからこの回答者の視聴を除外した場合のこの回答者の寄与 (スチューデント化残差の変化量) を決定します。 。
• 除外された学生の給与残高が通常に戻る候補者を検索します。

上の例は、データ エンジニアがすでに多くのことを考えているという仮説を裏付けています...そして、これが本当に「エンジニア」であり「コーダー」ではない場合、ローコード ツールを使用する際の専門性の低下を懸念することになります。ついに撤退しなければならない。

ローコードで他に何ができるでしょうか?

Scala でコードを手動で記述する必要がなく、バッチおよびストリーム データを処理するためのローコード ツールの適用範囲はそれだけではありません。

Datalake の開発におけるローコードの使用は、すでに私たちにとって標準となっています。 おそらく、Hadoop スタックに基づくソリューションは、RDBMS に基づく従来の DWH の開発パスをたどっていると言えるでしょう。 Hadoop スタック上のローコード ツールは、データ処理タスクと最終的な BI インターフェイスの構築タスクの両方を解決できます。 さらに、BI はデータの表現だけでなく、ビジネス ユーザーによるデータの編集も意味する場合があることに注意してください。 金融部門向けの分析プラットフォームを構築する際には、この機能をよく使用します。

とりわけ、ローコード、特にデータグラムを使用すると、データ ストリーム オブジェクトの起源を個々のフィールド (系統) に至るまで原子性を持って追跡する問題を解決できます。 これを行うために、ローコード ツールは Apache Atlas および Cloudera Navigator とのインターフェイスを実装します。 基本的に、開発者はオブジェクトのセットを Atlas ディクショナリに登録し、マッピングを構築するときに登録されたオブジェクトを参照する必要があります。 データの出所を追跡したり、オブジェクトの依存関係を分析したりするメカニズムにより、計算アルゴリズムを改善する必要がある場合に時間を大幅に節約できます。 たとえば、財務諸表を作成する場合、この機能を使用すると、法改正の時期をより快適に乗り切ることができます。 結局のところ、詳細なレイヤーのオブジェクトのコンテキストにおけるフォーム間の依存関係を理解すればするほど、「突然の」欠陥に遭遇することが減り、やり直しの回数が減ります。

データ品質とローコード

Mediascope プロジェクトのローコード ツールによって実装されたもう XNUMX つのタスクは、Data Quality クラスのタスクでした。 調査会社のプロジェクトにおけるデータ検証パイプラインの実装の特徴は、主要なデータ計算フローのパフォーマンスと速度に影響が及ばなかったことです。 独立したデータ検証フローを調整できるようにするために、すでに使い慣れた Apache Airflow が使用されました。 データ生成の各ステップの準備が整うと、DQ パイプラインの別の部分が並行して起動されました。

分析プラットフォームでデータが開始された瞬間からデータの品質を監視することは、良い方法であると考えられています。 メタデータに関する情報があれば、情報がプライマリ層に入った瞬間から、null、制約、外部キーなどの基本条件への準拠をチェックできます。 この機能は、Datagram のデータ品質ファミリーの自動生成されたマッピングに基づいて実装されます。 この場合のコード生成もモデルのメタデータに基づいています。 Mediascope プロジェクトでは、Enterprise Architect 製品のメタデータを使用してインターフェイスが実行されました。

ローコード ツールを Enterprise Architect と組み合わせることで、次のチェックが自動的に生成されました。

• 「not null」修飾子を使用してフィールドに「null」値が存在するかどうかを確認します。
• 主キーの重複の存在を確認します。
• エンティティの外部キーを確認します。
• 一連のフィールドに基づいて文字列の一意性をチェックします。

データの可用性と信頼性のより複雑なチェックのために、Scala Expression を使用してマッピングが作成されました。これは、Zeppelin のアナリストによって準備された外部 Spark SQL チェック コードを入力として受け取ります。

もちろん、小切手の自動生成は段階的に実現する必要があります。 説明したプロジェクトの枠組み内で、この前に次の手順を実行しました。

• Zeppelin ノートブックに DQ が実装されました。
• DQ はマッピングに組み込まれています。
• 別個のエンティティに対するチェックのセット全体を含む別個の大規模マッピングの形式の DQ。
• メタデータおよびビジネス チェックに関する情報を入力として受け入れる、ユニバーサルなパラメーター化された DQ マッピング。

おそらく、パラメーター化されたチェック サービスを作成する主な利点は、機能を運用環境に提供するのにかかる時間が短縮されることです。 新しい品質チェックでは、開発環境やテスト環境を通じて間接的にコードを配信するという従来のパターンを回避できます。

• EA でモデルが変更されると、すべてのメタデータ チェックが自動的に生成されます。
• データ可用性チェック (ある時点でのデータの存在の判定) は、オブジェクトのコンテキストで次のデータが出現する予想されるタイミングを格納するディレクトリに基づいて生成できます。
• ビジネス データの検証チェックは、アナリストによって Zeppelin ノートブックで作成されます。 そこから、実稼働環境の DQ モジュール セットアップ テーブルに直接送信されます。

スクリプトを運用環境に直接送信するリスクはありません。 たとえ構文エラーがあったとしても、データ計算フローと品質チェック起動フローが分離されているため、最大の脅威は XNUMX つのチェックを実行できないことです。

基本的に、DQ サービスは運用環境で永続的に実行されており、次のデータが表示された瞬間に作業を開始する準備が整っています。

代わりに、結論の

ローコードを使用する利点は明らかです。 開発者はアプリケーションを最初から開発する必要はありません。 また、プログラマーは追加のタスクから解放され、より速く結果を生み出すことができます。 速度が向上すると、最適化の問題を解決するための時間がさらに確保されます。 したがって、この場合は、より優れた、より高速なソリューションを期待できます。

もちろん、ローコードは万能薬ではなく、魔法が単独で起こるわけではありません。

• ローコード業界は「強化」段階を迎えていますが、統一された業界標準はまだありません。
• 多くのローコード ソリューションは無料ではないため、それらを購入することは意識的なステップである必要があり、それらを使用することによる経済的メリットを十分に確信して行う必要があります。
• ローコード ソリューションの多くは、GIT/SVN では必ずしもうまく機能するとは限りません。 あるいは、生成されたコードが非表示になっている場合は使用が不便です。
• アーキテクチャを拡張する場合、ローコード ソリューションを改良する必要がある場合があります。これにより、ローコード ソリューションのサプライヤーに対する「愛着と依存」の影響が引き起こされます。
• 適切なレベルのセキュリティは可能ですが、非常に労力がかかり、ローコード システム エンジンに実装するのは困難です。 ローコード プラットフォームは、その使用によるメリットを追求するという原則だけで選択されるべきではありません。 選択するときは、アクセス制御機能の可用性と、組織の IT ランドスケープ全体のレベルへの識別データの委任/エスカレーションについて質問する価値があります。

ただし、選択したシステムの欠点がすべてわかっていて、それにもかかわらず、そのシステムを使用することによるメリットが圧倒的多数を占めている場合は、恐れることなく小さなコードに移行してください。 さらに、あらゆる進化が避けられないのと同じように、そこへの移行も避けられません。

ローコード プラットフォームを使用する XNUMX 人の開発者が、ローコードを使用しない XNUMX 人の開発者よりも早く仕事を遂行できれば、企業はあらゆる点で有利なスタートを切ることができます。 ローコード ソリューションへの参入の敷居は「従来の」テクノロジに比べて低く、これが人材不足の問題にプラスの影響を与えています。 ローコード ツールを使用すると、機能チーム間の対話を高速化し、データ サイエンス研究の選択されたパスの正しさについてより迅速な意思決定を行うことができます。 低レベルのプラットフォームは、作成されたソリューションが技術専門家以外 (特にビジネス ユーザー) にも理解できるため、組織のデジタル変革を推進できます。

納期が厳しく、ビジネス ロジックが満載で、技術的な専門知識が不足しており、市場投入までの時間を短縮する必要がある場合、ローコードはニーズを満たす XNUMX つの方法です。

従来の開発ツールの重要性は否定できませんが、多くの場合、ローコード ソリューションを使用することが、解決されるタスクの効率を高める最善の方法です。

出所： habr.com