サービスオーケストレーションはスケジューリングが解決できないことを解決します

ほとんどの組織はサービスオーケストレーションについて考えることから始めていません。彼らは症状から始まります：不完全なデータを示す朝のダッシュボード、上流プロセスが遅れたために期限違反となったSLA、または7 AMに何が壊れたのか、なぜ壊れたのかを解決しようとするクロスチームのSlackスレッドです。 「オーケストレーション」という言葉が会話に入るころには、通常、作業回避策が数ヶ月間存在しています。そして、それが問題なのです - それらの作業回避策は「プロセス」のように見えるため、目に見えません。 実際の違いは、機能しているシステムと壊れているシステムの間にあるのではありません。調整の欠如を補っている環境と、実際にエンドツーエンドの実行をサポートできる基盤の上に構築された環境の間にあります。それが、スケジューリングとオーケストレーションの違いが始まるところです - そして、それが重要な理由です。

ジョブスケジューリングが限界に達する場所

技術的には、現代のアプリケーションに付属するビルトインの自動化ツールに問題はありません。ERPシステム、CRM、データウェアハウス、大規模データベースプラットフォームはすべて、ネイティブなスケジューリング機能を持っています。特に複雑でない環境では、これらのツールは正確に期待される通りに動作します：それらを所有するアプリケーションの範囲内でジョブを自動化します。 問題は境界で始まります。 ビジネスの成果が複数のアプリケーションを超える作業を必要とする場合 - サプライチェーンの運用、財務締結、MLパイプラインの実行 - それを管理するための共通の調整層は存在しません。各アプリケーションスケジューラは自分の世界しか知りません。他の状態、進捗、または失敗の理解がない、個別に自動化されたワークフローのセットが結果として生じます。 これがサービスオーケストレーションが対処するコアのアーキテクチャギャップです。既存のスケジューラの上にあるコントロールプレーンは、ビジネス目的を組織の原則としてエンドツーエンドの実行を管理します。 

クロスシステム調整の実際の姿

顧客はウェブポータルを通じてアプリケーションを提出します。そこから、プロセスは非常に少ない共通点を持つシステムのスタックを横断して広がります：データ検証はKubernetesコンテナ内のAPIサービスを通じて実行され、アイデンティティ確認はサードパーティのSaaSプロバイダーに呼び出され、リスクスコアリングはクラウドにデプロイされたモデルで実行され、実際のアカウントはオンプレミスにあるコアバンキングシステムで作成され、CRMは顧客プロファイルを更新し、コンプライアンス文書が生成されてアーカイブされます。 それは6つの異なる環境 - クラウド、オンプレミス、コンテナ化インフラストラクチャ、SaaS - がすべて単一のビジネストランザクションに参加しています。そして、それが簡略化されたバージョンです。 今、これを実際に管理するのが非常に難しくするビジネス制約を追加します：顧客は、アプリケーションを提出してから1時間以内にプロセス全体が完了することを期待しています。明確にするために、それはビジネスのコミットメントです - そして、それは全体のチェーンに適用され、個々のステップには適用されません。 どのアプリケーションスケジューラも、その締切の下でそのトポロジーを調整するために作られてはいません。各スケジューラは、自分のジョブキューを管理するように設計されており、より大きなビジネスプロセスでどこに位置しているのか、またそれが遅れた場合に下流で何が起こるのかを理解するために設計されていません。

問題が運用上どのように明らかになるか

組織は通常、このギャップをアーキテクチャレビューを通じて発見することはありません。彼らは、徐々に正規化される運用の摩擦のパターンを通じてそれを発見します。 最も明白な初期信号は、時間バッファ契約と呼ばれるものです。データチームとアプリケーションチームが共通の調整層なしで運営していると、彼らは非公式なタイミング合意を交渉し始めます。アプリケーション層のデータは通常午後4時までに到着するため、ETLパイプラインは5時に開始されるように設定され、保険として1時間のバッファが組み込まれています。 そのバッファは責任ある計画のように見えますが、依存関係管理の欠如を隠しています。上流データが遅れた場合、下流パイプラインはそれでも開始され、そこにあるものを処理します。データが早く到着した場合、パイプラインは時計がチックするのを待って静止しています。 2つ目のパターンは、より破壊的です。データパイプラインは、CRMとERPからレコードを取り込み、完全なデータセット - 通常は100万レコード - を期待しています。上流ワークフローで問題が発生したため、データは不完全に到着します。パイプラインにはこれを知る手段がないため、完了に向けて実行され、部分的データでビジネスダッシュボードを更新します。ビジネスユーザーが何かが間違っているように見えることに気が付くまで、誰も気づきません。 その後に続くのは、クロスチームの再構築作業です：Slackメッセージ、電話会議、複数のツールでの実行ステップの手動追跡を行い、問題がどこで発生したのかを特定します。この種のインシデントレスポンス - 切り離されたシステムを横断して何が起こったのかを理解しようとするチームの奮闘 - は、組織が現在のワークフロー調整のアプローチには限界があることを示す最も明白な指標の1つです。 ビジネスアプリケーション層からデータ層に至るまでの全スタックにわたるプロセスの系譜の欠如が、これらのインシデントを解決するのを非常に難しくしています。BMC Softwareの製品マーケティングシニアディレクターであるBasil Faruqui氏が述べているように、「見えないものを管理することはできません。」そして、単一のツールが表示するように設計されていないものは見ることができません。 

現代の時代にオーケストレーションが必要とするもの 

オーケストレーション機能を機能セットとしてリストすることは、実際に必要とされるものを過小評価しています。アーキテクチャは、サイロ化されたスケジューリングが生み出す失敗モードへの直接の応答である必要があります。 最初の要件は広範な環境サポートです。クラウド環境のみで機能するコントロールプレーンや、特定のアプリケーションタイプにのみ接続するものは、より良いUIを持つ別のサイロに過ぎません。 ビジネス成果をエンドツーエンドでオーケストレーションすることは複雑であり、SaaSアプリケーション、マルチクラウドインフラストラクチャ、オンプレミスデータセンター、場合によってはメインフレームシステムを跨ぐ必要があります。銀行業界、金融サービス、保険業界などの多くの業界では、メインフレームのサポートはオプションではありません。 2つ目の要件はプロセスの系譜を持ったエンドツーエンドの可視性です。ジョブが完了したことを知ることは、そのビジネスサービスが順調であるかどうかを知ることとは異なります。効果的な可視性は、ワークフローの状態をそれが触れるすべてのシステムを横断してリアルタイムで追跡できることを意味します。 3つ目の要件は、ビジネスコンテキストを持つSLA管理です。プロセスが遅れているという通知は、供給チェーンのワークフローが遅れており、次の20分以内に回復しないと5つの下流ビジネスサービスに影響を与えるという通知よりも有用ではありません。前者は何かが間違っていることを教えてくれます。後者は何をすべきかを教えてくれます。 自己修復は4つ目の要件であり、組織の知識が運用ポリシーになる場所です。ワークフローステップが一時的なネットワークの問題で失敗した場合、誰かが調査し、そのステップを再実行することを決定します。その解決策はポリシーとしてキャプチャ可能であるべきです - そして、ますますAI対応の機能が、同じ失敗パターンが以前に発生したことを特定し、履歴の修正を表面化し、人間の承認が必要な場合には自動的に応答を行うことができます。目標は、インシデントが発生したときにシフトにいた人々の頭の中だけで生きるのではなく、プラットフォームに組織的な知識を組み込むことです。 最後に、CI/CD統合はしばしば与えられている評価よりも重要です。オーケストレーションは、その本質において、チームスポーツです。ビジネスユーザー、アプリケーションチーム、運用チームはすべて、ワークフローがどのように定義され、テストされ、デプロイされるかに利害関係を持っています。オーケストレーションワークフローをコードとして扱うこと - バージョン管理、自動化テスト、現代のDevOpsプラクティスに一致したデプロイメントパイプラインを持つこと - は、あってはならないものではありません。それは、プラットフォームをあらゆるスケールで管理可能にするものです。

AIワークロードがパイプラインモデルを破る 

この分野での一般的な誤解の1つは、AIおよびMLワークロードが既存のデータパイプラインツールを拡張することで処理できるということです。モデルのトレーニングは単に計算集約的なバッチジョブであり、推論は単なる別のAPI呼び出しであるという仮定は、どちらも不十分です。 顧客の解約検出モデルを考えてみてください。トレーニングデータは、データシステムではないシステムから調達する必要があります - ERP、CRM、カスタムアプリケーション、潜在的にはソーシャルメディアフィード。データをステージング環境に取り込むことはすでにアプリケーション層全体での調整を必要とします。次に、モデルトレーニングパイプラインが実行される必要があります。ここまでで、推論が発生する前に2層の調整が必要です。 モデルが生産に投入され、リスクのある顧客を特定すると、ビジネスの応答 - 例えば、プロモーションオファーを送信すること - は、モデルの内部では発生しません。それは、顧客プロファイルやプロモーションワークフローが存在するCRMおよびERP層で発生します。モデルは、アプリケーションから始まり、ビジネスアクションで終わるビジネスプロセスの中での一ステップです。  AIワークロードをデータパイプラインツールに制限すると、プラットフォームはそのチェーンの中央を管理できますが、端は管理できません。データの調達と下流のビジネス応答の両方がその範囲外です。AIワークロードを単一のツールにサイロ化すると、プロセスをソースからビジネスアクションにマッピングまたは制御できないシステムが残ります。 これは、エージェントベースのアーキテクチャが一般的になりつつあるため、さらに重要です。組織は、すでに大きなプロセス内の個別のタスクを引き受けるエージェントを展開しています。注文から現金へのワークフローは、すぐにはエージェントに完全に引き渡されることはありませんが、エージェントはその特定のコンポーネントを処理することが増えています。これは、オーケストレーションプラットフォームがエージェントを呼び出し、適切なコンテキストを渡し、ガードレールを強制し、他のワークフローを管理するのと同じSLAに従って実行を管理できる必要があることを意味します。アクティブなエージェント展開を持つ組織にとって、エージェントオーケストレーションはすでに現在の考慮事項です。 

問題を再考する

組織がワークフロー調整の問題に直面すると、本能的により良い自動化が必要かどうかを尋ねます。より多くの場合、実際に必要なのはオーケストレーションです。 より良い自動化は個々のジョブを改善します。オーケストレーションは、それらの間の関係を管理します。単一のアプリケーションの境界内にとどまるワークフローの場合、より良い自動化が正しい答えである可能性があります。システム、チーム、環境を横断して、定義された締切でビジネス成果を提供するワークフローの場合、自動化だけでは必要なものを提供できません。 症状は特定可能です。プロセスの規律として仮面をかぶった時間バッファ。追跡が必要な部分的データインシデント。特定の障害ポイントに起因できないSLA違反。これらのいずれも、自動化が調整を必要とする兆候ではありません。これらは、欠落しているコントロールプレーンを示しています。 この区別は重要です。調整のギャップの上にさらに自動化を構築することは、ギャップを埋めることにはなりません。それは調整するべきものをさらに増やします。

これらの投稿は私自身の見解であり、BMCの立場、戦略、または意見を必ずしも代表するものではありません。