ポイント: BMCのControl-Mは、データプロジェクトの運用を合理化し、可視性と効率を向上させるワークフローオーケストレーションプラットフォームです。Control-Mは、パイプラインを自動化し、多様な技術を統合することで、データイニシアチブの運用化における課題を克服するのに役立ちます。
- Control-Mは、DevとOpsの間の協力のためのAutomation APIを提供します。
- クラウドリソースとファイル転送管理のための組み込みサポートを提供します。
データプロジェクトを運用化するためには、組織はデータパイプラインのすべてのステージにわたって自動化された、オーケストレーションされたエンドツーエンドの可視性を必要とします。構造化された運用化フレームワークがなければ、最も洗練されたデータイニシアチブでさえ、本番に到達する前に立ち往生します。異なるデータツールの複雑さを抽象化する統一されたワークフローオーケストレーションプラットフォームが、動作するプロトタイプと企業規模のデプロイメントの間の重要な架け橋です。
データは豊富で、指数関数的に増加しています。しかし、単にデータを持っているだけでは不十分です。企業は一貫してデータプロジェクトを開発から生産に移行することに苦労し、そのギャップのコストは重要です。2018年、ガートナーは「2019年の予測: 人工知能コア技術」という報告書の中で、最先端のデータプロジェクトのうちわずか15％しか2022年までに生産に移行できないと予測しました。つまり、85％は結果を出せないということです。また、データとアナリティクスのトップトレンド、2022年の報告書では、持続可能なデータとアナリティクスの運用化フレームワークを持たない組織は、イニシアチブが最大で2年遅れるリスクがあると警告しています。
なぜデータプロジェクトは生産に到達するのが難しいのか？
根本的な課題はスケールです。プロジェクトは一つの場所でプロトタイプとしてうまく機能することができますが、全国的または世界的にスケールできなければ、実質的に失敗しています。
企業は計画に運用化を組み込む必要性を認識するにつれて、業界はIT運用（ITOps）に焦点を再調整し、データ用のDataOps、機械学習用のMLOps、人工知能用のAIOps、アナリティクスモデリング用のModelOpsというさまざまな専門的Opsフレームワークを生成しています。この増加は、業界の一部で言われるように「次に何が来るかわからないが、何らかの形でOpsが関与する」という意味での総称XOpsを生み出しました。問題は野心ではなく、複雑さです。
データパイプラインの4つの段階は何か？
すべてのデータプロジェクトは、データパイプラインの基本的な4つの段階を共有し、それがデータパイプラインの構成要素となります。
1. データ取り込み
企業資源計画（ERP）や顧客関係管理（CRM）システム、金融プラットフォーム、その他の記録システムからのデータをオーケストレーションし、デバイス、センサー、ソーシャルメディア、ウェブログ、IoTセンサーおよびデバイスからのデータと組み合わせます。
2. データストレージ
データがどこでどのように保存されるかは、持続性、データセットの相対的価値、アナリティクスモデルの更新頻度、データが処理に移動できる速度によって大きく異なります。
3. データ処理
処理要件は大きく異なります: どのくらいのコンピュートが必要ですか？それは一定ですか、それとも変動しますか？ワークロードはスケジュールが設定されていますか、イベント駆動ですか、それともアドホックですか？コストはどのように最小化されますか？
4. インサイト提供
最後のマイル - データ出力をアナリティクスシステムに移動します。インサイト層は複雑で、常に変化しています。生産でスケールされていない新しいデータアナリティクスサービスは、行動可能なインサイトやビジネス価値を提供しません。これは、収益生成や運用効率で測定されます。
なぜエンドツーエンドのオーケストレーションがデータパイプラインにとって重要なのか？
運用の目標は、最小限の人的介入でデータパイプラインを高度に自動化された方法で実行し、すべてのコンポーネントにわたって完全な可視性を持つことです。しかし、データパイプライン内のほぼすべての技術には、独自の組み込み自動化ユーティリティやツールが付属しており、それらはしばしば互いに連携するようには設計されていません。これらをエンドツーエンドの自動化とオーケストレーションのために一緒に縫い合わせることが、チームが壁にぶつかる場所です。
この課題は、アプリケーションおよびデータワークフローオーケストレーションプラットフォームの台頭を促しました。これらのソリューションは、生産においてスピードとスケールで機能し、基盤となる自動化ユーティリティを抽象化して、チームがインフラストラクチャではなく成果に焦点を合わせることを可能にします。
Control-Mはどのようにデータプロジェクトの運用化を支援しますか？
BMCのControl-Mは、複雑なデータパイプラインを簡素化するための抽象化レイヤーとして機能するアプリケーションおよびデータワークフローオーケストレーションおよび自動化プラットフォームです。Control-Mは、任意のデータ技術やインフラストラクチャ全体でエンドツーエンドの可視性と予測可能なサービスレベル契約（SLA）を提供し、生産でデータ駆動のインサイトを提供し、最も複雑なデータパイプラインに新技術革新を統合します。
Control-Mプラットフォームは、アプリケーションとデータのワークフローを自動化し、オーケストレーションするためのさまざまな機能を提供します:
- Control-M Automation APIは、開発者がアプリケーションが開発されている間に本番準備が整ったワークフロー自動化を組み込むことを可能にすることで、DevとOpsの間のコラボレーションを促進します。
- Amazon Web Services (AWS) LambdaやAzure Logic Apps、Functions、Batchなどのクラウドリソースのための組み込みサポートを提供し、クラウドエコシステムの柔軟性とスケーラビリティを活用できるようにします。
- すべてのアプリケーションとの統合ファイル転送を提供し、内部および外部ファイル転送を中央インターフェースに移動して可視性とコントロールを改善します。
- セルフサービス機能を提供し、ビジネス内の従業員が関連するジョブデータにアクセスできるようにします。
- アプリケーションインテグレーターは、カスタムジョブタイプの作成をサポートし、Control-M環境に迅速かつ容易に展開します。
- 変換ツールは、第三者のスケジューラーからの変換を簡素化します。
データプロジェクトは戦略的重要性が高まり続けます。プロジェクト計画と実行の核心としてデータワークフローを成功裏に運用化することは、ビジネス成果にとって不可欠です。アプリケーションおよびデータワークフローオーケストレーションプラットフォームは、すべてのDataOpsの旅における基礎的なステップであるべきです。
Control-MがどのようにDataOpsの成功を支援できるかについて詳しくは、私たちのウェブサイトを訪れてください。
よくある質問
データプロジェクトを運用化するとはどういう意味ですか？
データプロジェクトを運用化するとは、それをプロトタイプや開発から信頼性が高く、繰り返し可能な生産に移行することを意味します。運用化には、データプロジェクトが手動介入なしに一貫して行動可能な結果を生み出すために、コアパイプラインステージ（取り込み、ストレージ、処理、およびインサイト提供）を自動化することが必要です。
なぜほとんどのデータプロジェクトは生産に到達できないのか？
ほとんどのデータプロジェクトが生産に到達できない理由は、スケールにおける複雑さです。それぞれのパイプラインステージは、ネイティブに統合されていない異なるツールや技術に依存しており、エンドツーエンドの自動化を実現することが難しいです。これらのコンポーネントを統一するオーケストレーション層がなければ、チームは生産でパイプラインを信頼性高く運営するために必要な可視性とコントロールを維持できません。
データ自動化とデータオーケストレーションの違いは何ですか？
データ自動化は、人的介入なしに個々のタスクやプロセスを実行することを指します。データオーケストレーションは、ツール、システム、環境全体で複数の自動化されたタスクを調整し、単一の管理されたワークフローとして完全なデータパイプラインを実行します。オーケストレーションは、エンタープライズ規模で自動化が機能することを可能にします。
DataOpsはデータプロジェクトの運用化にどのような役割を果たしますか？
DataOpsは、データパイプラインの開発と運用においてDevOpsの原則（継続的インテグレーション、自動化、コラボレーション）を適用します。DataOpsフレームワークは、組織が最初からデータプロジェクトに運用化を組み込むのを支援し、プロトタイプから生産への時間を短縮し、データ駆動の成果の信頼性を向上させます。
ワークフローオーケストレーションプラットフォームに求めるべきものは何ですか？
データプロジェクトのためのワークフローオーケストレーションプラットフォームは、エンドツーエンドのパイプライン可視性、異種データ技術およびクラウド環境のサポート、イベント駆動およびスケジュールされたワークロード機能、統合ファイル転送管理、ビジネスユーザーのためのセルフサービスアクセス、開発中のDevとOpsのコラボレーションを可能にするAPIを提供するべきです。
GARTNERは、米国および国際的にGartner, Inc.およびその関連会社の登録商標およびサービスマークであり、ここに許可を得て使用されています。全ての権利は保護されています。
この投稿において表明された見解や意見は著者のものであり、必ずしもBMCの公式な立場を反映するものではありません。
これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。