概要

  • Automic Automation が最も強力なのは、購入者がこの製品を、受け入れられたジョブチェーンのための運用コントロールプレーンとして扱う場合であって、すべてのスケジューラー、スクリプト、アプリケーションタスクを単一のコンソール下に置くことで安全にできるという、より広範な約束として扱う場合ではない。
  • 決定的な証拠は、コネクターやスケジュールされたジョブの数ではない。それは、カレンダー、依存関係、認証情報、ランタイムエンドポイント、ステータス解釈、ロールバック、ファイル転送検証、例外ルーティングが、新たな障害モードを隠すことなく、手動のランブック作業を削減できる十分な正確さを維持しているかどうかである。
  • SAP、メインフレーム、ファイル転送、クラウド、アプリケーション処理ウィンドウが複雑な企業にとって、このビジネスケースは信用に足る。しかし、それは規律ある移行、ジョブ定義の所有権、トレーニング、監視設計、そして Broadcom の下でのベンダーロックインに関する現実的な見方にかかっている。

ジョブチェーンこそが価値の単位である

Automic Software, Inc を最もよく理解するには、ひとつの具体的な問いかけが有効だ。企業は、ビジネスあるいは IT 運用ワークフローを、手動のランブック実行から、受け入れられた自動化ジョブチェーンへと移行できるか？ この表現は重要である。午前2時に開始するジョブだけでは不十分だ。先行ジョブの終了後に実行されるスクリプトだけでは不十分だ。緑色のアイコンを表示するダッシュボードだけでは不十分だ。受け入れられたジョブチェーンとは、一連のタスク、依存関係、承認、認証情報、転送、ステータスルール、リカバリーアクションが、通常の運用の一部となった状態を指す。それは把握され、名前が付けられ、監視され、所有され、復旧可能なものである。

これこそが Automic にとって有益な境界線である。なぜなら、エンタープライズ・ワークロード自動化には長い間、誇大宣伝の歴史があるからだ。ベンダーは幅広いプラットフォームサポート、ジョブテンプレート、ビジュアルデザイナー、自動化のスローガンを見せることができる。しかしオペレーターが重視するのは、それほど華やかではないテストである。月末に、適切な上流システムが適切なファイルを生成した後に、会計締めチェーンが確実に実行されるか？ SAP 移行中に、スケジュールされたアプリケーションジョブが、オペレーターをいくつものコンソールに戻すことなく、非 SAP ワークロードと同期できるか？ ファイル転送が「転送成功」のステータスで終了しても、ファイル内容が悪い場合、オペレーションプロセスはその差異を検出できるか？ 認証情報がローテーションされたとき、チェーンは部分的に実行を続けるのではなく、即座に明確に失敗するか？

現在 Broadcom の自動化ポートフォリオ内で販売されている Automic Automation は、このジョブチェーンテストにとって信頼できる材料を備えている。公開製品資料では、ビジネスアプリケーションおよび IT インフラストラクチャ処理のためのワークロード自動化が説明されている。Automic のドキュメントは、実行可能オブジェクト、ワークフロー、スケジュール、カレンダーイベント、ログインオブジェクト、接続オブジェクト、ファイル転送オブジェクト、サービスレベル監視、通知、ロールバック設定、実行レポートを中心に構築されたアーキテクチャを示している。Broadcom の現在のリリース資料も、24.4 リリースファミリーにおける Java、Tomcat、Jetty、z/OS の変更や、メジャーバージョンに対する5年間のサポートライフサイクルなど、製品ラインの継続的なメンテナンスを示している。

より難しい評価は、それらの要素が本番環境で何を意味するかである。コントロールプレーンは、運用上の真実の質も高めるときにのみ、トイルを減らすことができる。ジョブチェーンは単なる美しい依存関係グラフではなく、正しい依存関係をエンコードしなければならない。単なるスケジュールオブジェクトではなく、正しいカレンダールールを使用しなければならない。単なるパスワードフィールドではなく、管理可能な方法で認証情報を保持しなければならない。サイレントな部分実行を防ぐのに十分なコンテキストで、外部システムのリターンコードを解釈しなければならない。チェーンが単に実行されたのではなく、受け入れられたという証拠をオペレーターに提供しなければならない。

この区別が、Automic を一般的な自動化ストーリーから、より測定可能な運用上の賭けへと変える。購入者は魔法を買っているのではない。購入者は、手動ステップ、スクリプト、メール、アプリケーションコンソール、部族知識という脆弱な寄せ集めを、管理されたチェーンで置き換えているのである。チェーンが受け入れられれば、監督コストの低減、引継ぎ漏れの減少、監査可能性の向上、より予測可能なバッチウィンドウというリターンが得られる。チェーンが単に自動化されただけなら、組織は複雑さをツールの中に移動させたに過ぎず、そのツールのライセンス、パッチ適用、要員配置、防御をこれから行わなければならない。

製品の境界と系譜

エンティティの境界は重要である。Automic Software, Inc は Broadcom 全体ではなく、また顧客自身のジョブ資産でもない。関連する製品ラインは、Automic Automation とそのワークロード自動化の系譜である。Automic は独立した自動化専門企業として始まり、後に CA Technologies の一部となり、2018年に Broadcom が CA を買収した際に Broadcom の一部となった。この所有権の連鎖は商業的に重要である。なぜなら、大企業は単なるスケジューラーだけでなく、サポートモデル、リリースポリシー、ポートフォリオ戦略も購入するからである。

親会社の境界は諸刃の剣である。Broadcom は Automic に大規模なインフラストラクチャソフトウェアの流通およびサポート基盤へのアクセスを提供する。同時に、この製品を、独立系自動化スタートアップとしてではなく、広範なインフラストラクチャポートフォリオの一部としてソフトウェア事業が管理される企業の中に位置づける。Broadcom の公開財務報告では、インフラストラクチャソフトウェアが主要な収益セグメントであることが示されているが、そのセグメントは Automic よりもはるかに大きい。したがって、Automic の購入者は Broadcom レベルの収益から製品レベルの投資を推測すべきではない。より安全な解釈は、Automic がミッションクリティカルなインフラストラクチャソフトウェアポートフォリオの中に位置づけられており、そこではインストールベースの継続性、サポート条件、ポートフォリオ横断的なアカウント管理が商業的に中心である、ということである。

運用チームにとって、系譜は移行リスクも変える。Automic には数十年にわたるワークロード自動化のパターンが背後にあるが、多くの購入者は古いジョブ定義、以前の製品名、カスタムスクリプト、継承された命名規則、統合の慣習を抱えている。受け入れられたジョブチェーンは、その継承から切り離せない。Automic または UC4 スタイルの自動化を長年使用してきた企業は、既に所有しているものを標準化・モダナイズすることによって利益を得るかもしれない。別のエンタープライズスケジューラーを置き換える企業は異なる負担を負う。カレンダー、依存関係、認証情報、ジョブ命名、アラート、リターンコードロジック、アプリケーション所有者、リカバリー手順を、旧システムの運用上の意味を失うことなく移行しなければならない。

これが、本記事のベンチマークが「スケジューラーの幅広さ」ではない理由である。幅広さは複数のベンダーから購入できる。より難しい問題は、運用上の受け入れである。Automic は、人々が現在信頼している正確なランブックロジックを、機械が実行し人間が監督できるチェーンへと変換する手助けをしなければならない。それには、古いプロセスが何をしていたか、どこが曖昧だったか、どの例外が文書化されたルールではなく経験によって処理されていたか、というクリーンなモデルが必要である。

Automic がエンコードできるもの

公開ドキュメントは、オブジェクトから構築された製品モデルを示している。ジョブ、ワークフロー、スケジュール、イベント、ログイン、接続、ファイル転送、通知、カレンダー、タイムゾーン、サービスレベルオブジェクトは、単なる UI ラベルではない。それらは、手動のランブックを実行可能にするための語彙である。強固な実装は、その語彙を用いて持続的な運用記録を作成する。

中心となるのはワークフローである。Automic のワークフローオブジェクトは、複数のタスクを順番に挿入してリンクすることで自動化するように設計されている。ドキュメントには、このシーケンスが生成設定、カレンダー条件、時間依存関係、チェックポイント、ステータス依存関係、前提条件、ブレークポイントによって微調整できることが明記されている。ここが、Automic が cron の代替を超えられるポイントである。手動のランブックには「休日でなければ、フィードが到着した後に調整処理を実行し、遅延ウィンドウが破られた場合は財務に通知する」と書かれているかもしれない。ジョブチェーンシステムでは、その言葉が特定の依存関係と日付にならなければならない。この変換が精密であればあるほど、オペレーターが午前3時に覚えておくべきことは少なくなる。

スケジュールは繰り返しのトリガーを提供するが、スケジュールはひとつの層にすぎない。Automic のドキュメントは、定期的かつユーザー定義の間隔で実行を自動化し、ワークフローを含む実行可能オブジェクトの挿入を可能にするスケジュールオブジェクトについて説明している。実際の企業では、スケジュールがすべての真実として扱われると危険である。受け入れられたジョブチェーンには、営業日、休日、地域のタイミング、上流のバッチウィンドウ、メンテナンス凍結を理解するカレンダーも必要である。悪いカレンダーは古典的な失敗のひとつである。なぜなら、すべてが正しく自動化されているように見えても、間違った日に実行されたり、月末の例外を逃したり、国別の非稼働日と衝突したりするからである。

認証情報も実用的な境界である。公開ドキュメントには、ログインオブジェクトと接続オブジェクトが、実行可能オブジェクトがターゲットシステムと通信するために使用する、一元的に管理されるアイテムとして記述されている。また、特定の構成における CA PAM や CyberArk などの外部パスワードボールトのサポートについても述べられている。これは、Automic のケースにおける認証情報処理の部分に関する重要な証拠である。ランブックのステップがアプリケーションサーバー上の特権アカウントを必要とする場合、受け入れられたチェーンは、どのパスワードを貼り付けるかを人が覚えていることに依存すべきではない。しかし、ログインとボールト統合の存在が認証情報リスクを取り除くわけではない。それはリスクの形を変える。運用チームは、ボールト統合、アクセス権、ターゲットシステムマッピング、ローテーション動作、障害通知を維持しなければならない。

実行エンドポイント層も同様に重要である。Automic は、ターゲットシステム上のランタイムコンポーネントに依存して、作業を開始し、実行を監視し、レポートを可能にしている。これにより製品は異種混在環境全体にリーチできるが、メンテナンス作業も発生させる。エンドポイントのアップグレード、証明書、ホストの可用性、ネットワークパス、許可設定は、自動化資産の一部となる。小規模な実装では、そのコストは管理可能かもしれない。グローバルな SAP、メインフレーム、データベース、ファイル転送、クラウドの資産では、エンドポイント層はそれ自体で大規模な分散システムとなりうる。

ファイル転送は、そのようなモデルの強みと落とし穴を示している。Automic のドキュメントは、ソースと宛先の実行コンポーネント、ログインオブジェクト、文字変換、監視を通じて、システム間の転送を自動化するファイル転送オブジェクトを説明している。そこには重要な注意も含まれている。ファイル転送実行のステータスは、実行プロセスを反映するものであり、必ずしもファイル内容の正しさを反映するものではない。ファイルにエラーが含まれていても、実行が完了すればリターンコードは成功のままになる可能性がある。これは、受け入れられたジョブチェーンの教訓の縮図である。ファイルを移動することは、ビジネス記録を受け入れることと同じではない。成熟した Automic の実装では、ビジネスが必要とする場合に、検証、下流チェック、内容管理、調整ステップが追加される。

受け入れられたチェーンが難しい理由

受け入れられたジョブチェーンが難しいのは、エンタープライズの運用がクリーンなグラフではないからだ。それは、異なる速度で老朽化するシステム間の交渉である。SAP チームには独自のリリースカレンダーがある。メインフレームチームにはバッチの慣習がある。データチームはパイプラインを変更する。セキュリティは認証情報をローテーションする。財務は締め手順を変更する。クラウドチームはマネージドサービスを追加する。アプリケーション所有者は例外を追加する。自動化製品はその中間に位置するが、各システムの真実を所有しているわけではない。

Automic は実行と監視を中央集約できる。しかし、それ自体で、何が有効と見なされるべきかを決定することはできない。ワークフローは、あるタスクが別のタスクのステータスを待つことを要求できる。しかし、誰かがそのステータスが十分かどうかを判断しなければならない。スケジュールはカレンダーの日付を避けることができる。誰かがカレンダーを定義しなければならない。通知は例外をルーティングできる。誰かが誰が受け取るか、そして受け取った人が何を許可されているかを選択しなければならない。ロールバック設定はリカバリーアクションを提供できる。誰かが実際のシステム状態にとって安全なリカバリーを設計しなければならない。

ここで、監督コストが中心的な経済変数になる所以である。自動化はしばしば手動作業の削減として売り込まれる。それは真実でありうる。しかし、夜間の実行から取り除かれた作業は完全に消えるわけではなく、設計、メンテナンス、例外処理へと移行する。オペレーターはコンソールにログインする時間を減らし、チェーンの健全性チェック、失敗した実行の解釈、変更のレビュー、統合の維持、自動化プロセスがビジネス要件に合致していることの証明により多くの時間を費やすようになる。この新しい作業が古い作業よりも小さく、予測可能で、リスクが少ないときに、製品は費用対効果を発揮する。

受け入れのコストは移行中に最も高くなる。既存のランブックにはしばしば隠れた前提が含まれている。あるジョブは「通常」午前2時20分までに終了するが、月の最初の営業日には午前2時50分まで許容されることを人は知っている。ある転送警告は特定のパートナーでは無視できるが、別のパートナーでは無視できないことをチームは知っている。リカバリーステップは文書に記述されているが、熟練オペレーターの記憶に依存している。これらのパターンが Automic に移行される際、組織はそれらを保持するか、整理するか、プロセスを再設計するかを決定しなければならない。急いだ移行は古い脆弱性を新しいシステム内に再現し、その上にツールのロックインを追加する可能性がある。

受け入れには証拠も必要である。Automic はレポート、実行データ、モニター、サービスレベルメカニズムを公開しているが、証拠は組織が必要とする証明が何かを決定して初めて有用になる。給与計算チェーンにとって、受け入れられた証拠には、上流ファイルの完了、レコード数チェック、成功したアプリケーションジョブ、下流確認応答、文書化された例外パスが含まれるかもしれない。データウェアハウスチェーンにとって、受け入れられた証拠には、鮮度、依存関係の完了、行数、調整、遅延到着処理が含まれるかもしれない。インフラストラクチャメンテナンスにとっては、事前チェック、変更ウィンドウの調整、終了コードの解釈、ロールバック確認が含まれるかもしれない。同じ製品が各パターンをサポートできるが、受け入れられた状態はドメイン固有である。

SAP とハイブリッド環境の観点

Automic の関連性が最も明確なのは、スケジュールされた作業が SAP、非 SAP システム、データベース、ファイル転送、クラウドサービス、旧式プラットフォームにまたがるハイブリッド環境である。Broadcom の SAP S/4HANA アプリケーションジョブ資料では、Automic が SAP のスケジュールされたアプリケーションジョブをトリガー、監視、監督し、それらのプロセスを非クラウド運用と同期させる手段として説明されている。そこでは、接続オブジェクト、ジョブテンプレート、ステータス取得、レポート、より広範なワークフローへの組み込みが述べられている。これはまさに、単一の受け入れられたジョブチェーンが実際的な意味を持つユースケースである。

SAP の例は、すべての顧客が価値を得るという証拠ではない。それは、エンタープライズワークロード自動化が存続する理由の信頼できる例証である。SAP アプリケーションジョブは、単独の管理上の便宜ではない。それらはしばしば、請求、在庫、財務、調達、サプライチェーン、データフローの中に位置している。経済的な問題は、人々が SAP のジョブ画面をチェックするのを嫌うことだけではない。SAP の作業が、データベース抽出、ファイル転送、データ品質チェック、メインフレームフィード、レポートロード、サービスデスク通知、下流アプリケーションプロセスなどの非 SAP 作業と調整されなければならないことが多いということである。

これらのステップが手動で監督されている場合、コストは複数の場所に現れる。スタッフは複数のコンソールを監視しなければならない。チーム間の引き継ぎが遅れる可能性がある。ウィンドウを逃した根本原因が不明確になる可能性がある。ローカルジョブの成功が、失敗したチェーンを隠す可能性がある。人々はプロセスの周りにスプレッドシートやチャットメッセージを作り上げる。ひとつの休暇やシフト変更がランを弱体化させる可能性がある。Automic の主張は、チェーンがその負担を軽減するのに十分なほど中央でモデル化できるということである。

技術的なリスクは、中央集約化が脆弱な依存関係も生み出す可能性があることだ。中央の自動化層やそのターゲットエンドポイントが故障すれば、多くのジョブが影響を受ける。プラットフォームのアップグレードが不十分であれば、幅広いチェーンが混乱する可能性がある。あるオブジェクトが、クロスクライアントの使用を理解せずに名前変更または削除されると、下流の定義が壊れる可能性がある。公開ドキュメントでは、特定の一元管理オブジェクトがより広範な使用に影響を与えること、デフォルトフォルダーがアップグレード中に上書きされる可能性があることが警告されている。それらは製品を拒否する理由ではない。それらは、自動化インフラストラクチャが便利ツールとしてではなく、インフラストラクチャとして管理されなければならないことを思い出させるものである。

したがって、最善の Automic デプロイメントは、正しい意味で退屈である。それらは命名規則を使用する。可能な限りミステリースクリプトを避ける。所有権を文書化する。沈黙でも騒々しくもないサービスレベルアラートを設計する。可能な場合はロールバックをテストし、ロールバックが安全でない場合はそれを認める。ボールト統合をブラックボックスに変えることなく認証情報を保護する。カレンダーをレビュー下に置く。ジョブチェーン設計を一度限りのプロジェクトとしてではなく、プロダクションエンジニアリングとして扱う。

重要な障害モード

Automic で知られている障害モードは珍しいものではない。それらは、あらゆるエンタープライズ自動化層を危険にするのと同じ障害である。依存関係の見落とし、不適切なカレンダー、認証情報の失敗、ランタイムエンドポイントの停止、重複実行、サイレントな部分実行、ファイル転送エラー、ロールバックギャップ、アップグレードリグレッションである。違いは、実装が規律正しければ、Automic がそれらのリスクを可視化モデルに集中させることができる点だ。

依存関係の見落としは最も明快な例である。手動のランブックでは、正式にリストアップされていなかったファイル、データベースフラグ、アプリケーションステータスを待つことを人が知っているかもしれない。自動化されたチェーンでは、依存関係が表現されなければならない。表現されなければ、チェーンは迅速に、しかし誤って実行される可能性がある。狭い意味でツールは失敗しなかった。モデルが不完全だったのだ。移行前の依存関係発見が管理上のオーバーヘッドではなく、受け入れられたチェーンの基礎である理由がこれである。

不適切なカレンダーはより微妙だ。あるスケジュールは何ヶ月も機能し、四半期末、祝日、夏時間の変更、地域的なメンテナンス例外で突然失敗する可能性がある。Automic のカレンダーとタイムゾーン機能は必要だが、自己検証的ではない。カレンダーの所有権が割り当てられなければならない。ビジネスカレンダーは実際の運用コミットメントに対してチェックされなければならない。チェーンが地域をまたがる場合、またはグローバルチームがひとつの制御ポイントからローカルのバッチウィンドウを調整しようとする場合、タイムゾーン処理は重要になる。

認証情報の失敗は、セキュリティの問題であると同時に可用性の問題でもある。一元化されたログインオブジェクトとボールト統合は制御を改善できるが、ローテーションされたアカウント、期限切れの証明書、不足しているボールト権限、ターゲットシステムのポリシー変更がチェーンを停止させる可能性がある。受け入れられたチェーンの設計では、その場合に何が起こるかを決定しなければならない。ジョブは部分的な作業を行う前に失敗するか？ 通知は適切な所有者に届くか？ オペレーターは、その失敗が Automic、ボールト、ターゲットアプリケーション、ネットワークパスのどこにあるかを判断できるか？

エンドポイントの停止も同様である。ターゲットホスト上のランタイムコンポーネントがダウンしている場合、Automic は作業を開始または監視できない可能性がある。その場合、中央システムが不在のエンドポイントを露呈させることができるため、隠れたスクリプト失敗よりは良いかもしれない。しかし、それでも運用上の所有権が必要である。自動化資産は、それらのコンポーネントが実行するジョブだけでなく、自身のコンポーネントのヘルス監視も必要とする。

重複実行とサイレントな部分実行は、自動化の成功のように見えながらビジネス上の害を生み出す可能性があるため、特に危険である。請求の重複ステップ、ファイル配信の重複、決済タスクの繰り返し、データロードの繰り返しは、単純なロールバックでは元に戻せないかもしれない。部分実行は、システム間で不整合な状態を作り出す可能性がある。Automic はチェックポイント、ステータス依存関係、レポート、ロールバックメカニズムを通じて支援できるが、これらの制御は、タスク設計者が各ステップのビジネス副作用を理解している場合にのみ機能する。

ファイル転送エラーは、公開資料で最も文書化された注意事項である。転送成功ステータスはファイルの正しさを証明しない。これは Automic の主張を弱めるものではなく、それを明確にする。成熟した自動化は、転送証拠をビジネス検証から分離する。ファイルを転送するチェーンは、それらの事実が重要な場合、エンコーディング、ファイルサイズ、カウント、チェックサム、スキーマ、コントロール合計、またはアプリケーション確認応答も考慮すべきである。受け入れられたジョブチェーンが受け入れられるのは、各技術オブジェクトが完了したからではなく、正しいことを証明するからである。

アップグレードリグレッションは商業的かつ運用上の現実である。Broadcom のリリースポリシーは、メジャーバージョン、マイナーバージョン、サービスパック、ホットフィックス、定期的な更新を、サポートライフサイクルの期待とともに説明している。その継続性は価値があるが、すべての成熟した製品にはアップグレード作業が伴う。例えば、24.4 リリースアナウンスでは、Java 17 以上、更新された Tomcat および Jetty サポート、さらに TLS、UTF-8、セキュアメール、zIIP サポートを備えた Java ベースの z/OS コンポーネントが言及されている。これらはポジティブなメンテナンスシグナルだが、同時にプラットフォーム依存関係が移り変わることを顧客に思い出させる。購入者は、互換性テスト、エンドポイントアップグレード、トレーニング、変更ウィンドウのための予算を組まなければならない。

単体経済性：どこで投資が報われ、どこで失われるか

商業的な問いは、より少ない手動ランブックステップとより予測可能なバッチウィンドウが、ライセンス、移行、エンドポイントメンテナンス、監視、ベンダーロックインのコストを上回るかどうかである。これは製品機能だけでは答えられない。それは購入者のジョブチェーンの密度と重要性に依存する。

Automic が最も正当化しやすいのは、次の3つの条件が揃った場合である。第一に、組織がシステム境界を越える多くの反復的な運用を持っていること。第二に、それらの運用に失敗した場合のコストやリスクが測定可能であること。例えば、財務締めの遅延、注文処理の遅延、レポートウィンドウの未達、調整エラー、手動の残業、コンプライアンス証拠の欠落、顧客影響の遅延などである。第三に、組織がランブックを統制された自動化モデルに変換するのに十分なプロセス規律を持っていることである。

そのような環境では、経済的なアップサイドは現実的である。中央のワークロード自動化層は、夜間シフトのチェックを減らし、繰り返しの手動引き継ぎを排除し、共通レポートを作成し、監査証跡を改善し、障害調査を短縮し、複雑な依存関係を可視化できる。バッチウィンドウが一貫して短縮されるか、より予測可能になれば、価値は人件費削減を超えて拡がりうる。下流チームはより早く開始できる。ビジネスレポートはより新鮮になる。メンテナンスウィンドウはより自信を持って計画できる。本番コンソールへの特権アクセスを必要とする人が少なくなる。

コスト面も現実的である。ライセンスは目に見える支出に過ぎない。移行は、特に大規模なレガシースケジューラーからの場合、相当なものになりうる。ジョブ定義は棚卸し、クレンジング、マッピング、テストされなければならない。ランタイムエンドポイントはデプロイされ、維持されなければならない。認証情報とボールトは統合されなければならない。アプリケーションチームは所有権について合意しなければならない。オペレーターは製品を学ばなければならない。監視はチューニングされなければならない。サービスデスクはどのアラートが重要かを知らなければならない。災害復旧手順には自動化層が含まれなければならない。変更管理は、不用意な編集が受け入れられたチェーンを壊すことを防がなければならない。

機会費用もある。一部のチームは既にクラウドネイティブスケジューラー、データオーケストレーター、CI/CD パイプライン、マネージドファイル転送ツール、SAP ネイティブスケジューリング、メインフレームスケジューラー、プラットフォーム固有の自動化を使用している。Automic は他のワークロード自動化スイートだけでなく、統合に対する購入者の意欲とも競合する。中央集約ツールはガバナンスを簡素化できるが、すべてのチームがジョブを変更するために中央自動化グループを待たなければならない場合、ボトルネックにもなりうる。ドメインチームがガードレール内で適切なチェーンを所有できるようにするプラットフォームであれば、商業的ケースは改善される。

ベンダーロックインは道徳的な異議ではなく、価格設定とレジリエンスの変数である。成熟した Automic 資産には、何年にもわたるジョブ定義、スクリプト、カレンダー、接続オブジェクト、命名規則、アラートルール、オペレーターの習慣が含まれている。そこから離れるのは難しい。そのロックインは、製品が信頼でき、サポートされ、重要な運用に組み込まれているなら受け入れ可能かもしれない。ライセンス条件、サポート品質、ロードマップ適合性、親会社のアカウント慣行が購入者のニーズと合わなくなれば、高くつく。慎重な顧客は、移植性を設計上の関心事として扱う。チェーンのビジネス上の意味を文書化し、不必要な独自複雑性を避け、後で必要になった場合に移行できるように、ツールの外側に十分なプロセス知識を保持する。

製品の主張と顧客の結果

公開証拠は、Automic が本格的なワークロード自動化プラットフォームであることを支持しているが、普遍的な顧客成果を証明するものではない。この留保は重要である。ドキュメントは機能が存在することを証明し、それらがどのように動作することを意図しているかを記述する。製品ページはポジショニングを説明する。ケーススタディとレビューは現場での使用を示しているが、それらは選択的である。コミュニティスレッドは現実世界の複雑さを示しているが、それは逸話的である。これらの情報源のいずれも、すべての購入者にわたって Automic が特定の割合でコストを確実に削減することを示すベンチマークとして読むべきではない。

Gartner Peer Insights は、関連する自動化市場において Automic Automation をリストし、限定的なセットの評価とユーザーコメントを表示している。これは市場シグナルとしては有用だが、統計的証明ではない。公開ページ自体が、ピアコンテンツは個々のエンドユーザーの意見を反映しており、Gartner 自身の事実陳述として扱うべきではないと警告している。一部のコメントは効率性や低メンテナンスコストに言及しているが、他の可視スニペットは管理や例外処理のフラストレーションを指摘している。バランスの取れた読み方は、Automic には認知された能力を持つインストール顧客基盤があるが、顧客価値は実装品質によって変動するということである。

古い Automic および Broadcom の顧客資料にも規律が必要である。公開事例証拠は、組織が Automic または関連する Broadcom 自動化製品を使用して、可視性を高めたり、監視を引き継いだり、複雑な運用を調整したりしていることを説明している。それらはもっともらしい成果である。しかし、ベンダーのケーススタディは成功を示すために書かれている。それらを用いて、同等のプロセス成熟度、人員配置、システム適合性なしに新規購入者が同じ結果を受け取ると推測すべきではない。

したがって、Automic を判断するための最も強力な事実基盤は、プロモーションではなくアーキテクチャにある。製品は受け入れられたチェーンをエンコードするために必要なオブジェクトを公開しているか？ はい、公開ドキュメントはその多くを示している。反復スケジュール、ワークフロー、カレンダー、認証情報、接続、ファイル転送、監視、通知、サービスレベル、ロールバックをカバーしているか？ はい、文書化された境界付きで。それは受け入れられた本番信頼性を証明するか？ いいえ。それはプラットフォームが機構を備えていることを証明する。信頼性は、その機構が購入者の実際の運用に対してどのように構成され、維持され、テストされるかから生まれる。

現実的な代替手段

Automic は空っぽの市場で事業を行っているわけではない。BMC Control-M、IBM Workload Automation、Redwood RunMyJobs、Stonebranch Universal Automation Center、Broadcom 自身の AutoSys、クラウドネイティブスケジューラー、データオーケストレーター、カスタムプラットフォーム自動化はすべて、代替または部分代替となる。正しい比較は、一般的な機能チェックリストではなく、受け入れられたジョブチェーンに依存する。

BMC Control-M は、幅広いワークフローオーケストレーション、アプリケーションおよびデータワークフロー管理、SAP 統合、確立されたエンタープライズスケジューリングモデルを望む組織にとって、直接的なエンタープライズワークロード自動化の代替である。IBM Workload Automation は、IBM およびメインフレームの比重が大きい環境で特に関連性が高い。Redwood RunMyJobs は、しばしばクラウドワークロード自動化と SAP 指向のビジネスプロセス自動化を中心に位置づけられている。Stonebranch はハイブリッド IT 自動化、イベント駆動オーケストレーション、中央制御を強調する。AWS Step Functions、Azure Data Factory、Google Cloud Workflows、Kubernetes コントローラー、Airflow のようなデータツールなどのクラウドネイティブツールは、自身のプラットフォーム境界内では強力でありうる。

Automic の優位性は、購入者が既に Automic スキル、既存チェーン、Broadcom アカウントアラインメント、または中央オーケストレーションから利益を得る異種ワークロード資産を持っている場合に最も可能性が高い。その不利は、組織が高度にプラットフォーム固有の自動化に移行している場合、より軽量なセルフサービスモデルを望んでいる場合、またはヘビーウェイトなエンタープライズスケジューラーを運用するスタッフが不足している場合に現れる。少数のクラウドデータパイプラインを実行するだけのチームは、幅広いスイートが存在するからといって、幅広いワークロード自動化スイートを購入すべきではない。何十年にもわたるクロスプラットフォームのバッチおよびアプリケーション依存関係を持つ銀行、公益事業、小売、製造業は、非常に異なる答えを持つかもしれない。

代替の問いは障害モードによっても変わる。主な問題がファイル配信と検証である場合、マネージドファイル転送と調整がより良い最初の投資かもしれない。主な問題がデータパイプラインのリネージである場合、データオーケストレーターがより自然かもしれない。主な問題がより大きなハイブリッド資産にわたる SAP ジョブ調整である場合、Automic、Control-M、Redwood、Stonebranch のすべてが評価に値するかもしれない。主な問題がメインフレームバッチである場合、メインフレームネイティブスケジューラーが依然として中心的でありうる。受け入れられたチェーンがツールを決定するのであり、その逆ではない。

Automic が要求する運用規律

Automic の約束は、運用規律があって初めて信頼できるものになる。第一の規律は棚卸しである。移行や拡張の前に、チームはチェーンの現実のマップを必要とする。所有者、タスク、依存関係、カレンダー、認証情報、ファイル、入力検証、出力検証、アラート、リカバリーアクション、ビジネスデッドラインである。そのマップがなければ、自動化は未知のリスクに対するより良いインターフェースに過ぎなくなる。

第二の規律は命名と構造である。オブジェクトは、オペレーターが素早く意味を推測できるように命名・グループ化されるべきである。ジョブチェーンは、そのビジネス目的、環境、所有者、重要度を明らかにすべきである。かつては一人のチームに意味をなした巧妙な略語は、チェーンが失敗し、新しいオペレーターがシフトに入ったときに高くつく。

第三の規律は例外設計である。すべてのチェーンは、よくある例外に対する答えを必要とする。上流不在、ファイル遅延、認証情報失敗、エンドポイント利用不可、部分成功、重複試行、下流拒否、ロールバック不可、ビジネスカレンダー競合などである。答えは、あるケースでは「停止して所有者を呼び出す」かもしれない。別のケースでは「3回再試行する」かもしれない。ビジネス上の結果が理解されている場合に限り、「警告付きで続行する」かもしれない。Automic は通知をルーティングし、サービスレベル反応をサポートできるが、ポリシーは購入者の責任である。

第四の規律は検証である。チェーンは、ビジネスプロセスが受け入れられたことを証明する事実を証明すべきである。ファイル転送では、それは転送ステータスを超えた内容チェックを意味するかもしれない。SAP ジョブでは、非 SAP 作業とのステータス取得と調整を意味するかもしれない。データロードでは、行数と鮮度を意味するかもしれない。インフラストラクチャタスクでは、事前チェックと事後チェックを意味するかもしれない。製品はこれらのチェックを運ぶことができるが、チームはどのチェックが必要かを決定しなければならない。

第五の規律は変更管理である。今日機能するジョブチェーンは、カレンダー編集、認証情報変更、エンドポイントアップグレード、アプリケーションリリース、オブジェクトの名前変更、または新しい依存関係によって壊される可能性がある。変更管理は、自動化層自体とそれが触れるシステムをカバーすべきである。自動化チームはアプリケーション変更の事前通知を必要とし、アプリケーションチームは自動化変更への可視性を必要とする。

第六の規律は定期的なレビューである。自動化は陳腐化しうる。ビジネスカレンダーは変わる。所有者は去る。ジョブは時代遅れになる。チェーンはビジネス目的が変わった後もずっと実行され続ける可能性がある。成熟した Automic 資産は、重要なチェーンをレビューし、死んだ作業を取り除き、所有権を更新し、リカバリーパスをテストする。そのレビュー作業は自動化が失敗した兆候ではない。それは自動化を信頼できるものにするためのメンテナンスコストである。

Automic がおそらく価値ある場面

Automic が真剣な検討に値する可能性が高いのは、企業が複数のシステムにわたるミッションクリティカルなジョブチェーンを持ち、それらのチェーンが既に人間の監督を消費している場合である。最も強い例には、財務業務、SAP 中心プロセス、メインフレームから分散への引き継ぎ、夜間のデータ移動、複雑なアプリケーションメンテナンス、小売や物流のバッチウィンドウ、実行証拠を必要とする規制業務が含まれる。そうした環境では、手動で監督されるランブックはしばしば高コストでリスクが高い。よく設計された Automic チェーンは、より良い運用記録を作成できる。

また、購入者が制御された可視性を委譲する必要がある場合にも Automic は魅力的である。一部の組織は、ビジネスやアプリケーションチームが広範なシステムアクセスを与えられることなく、自身のジョブを見られるようにしたいと考える。公開事例資料や製品ドキュメントは、価値提案の一部として、安全な監視、レポート、ロール認識のインタラクションを指摘している。これは、許可と所有権がうまく設計されていれば、中央運用チームの負担を軽減できる。

購入者が受け入れたいチェーンを記述できない場合、この製品はあまり説得力がない。「自動化が欲しい」は強い要件ではない。「月末の売掛金チェーンが、これらの上流フィードの後に、これらの検証、これらの例外ルート、この証拠をもって、現地時間の午前5時30分までに実行される必要がある」は強い要件である。Automic は具体性に報いる。

また、組織がプロセス政治をツールに修正させることを期待する場合も、あまり説得力がない。SAP、財務、セキュリティ、インフラストラクチャチームが所有権、検証、リカバリーについて合意できない場合、Automic が魔法のように合意を生み出すことはない。それは不一致をより早く露呈させるかもしれない。それは有用だが、ソフトウェアだけの勝利ではない。

評決

Automic Software, Inc の現在の関連性は、狭いが価値ある提案に基づいている。すなわち、エンタープライズ運用は依然として、受け入れられた自動化ジョブチェーンを必要としている。ワークロード自動化が最初にエンタープライズカテゴリになった頃と比べて、世界にはより多くのクラウドスケジューラー、より多くのデータオーケストレーター、より多くの CI/CD システム、より多くのマネージドアプリケーションサービスが存在する。しかし、実際の運用の多くは依然としてそれらの境界を越えている。それらは依然としてカレンダー、認証情報、ファイル移動、レガシープラットフォーム、SAP 作業、メインフレーム作業、アプリケーションジョブ、例外ルーティング、人的証拠に依存している。

Automic Automation はその問題に対処するための製品語彙を持っている。その公開ドキュメントは、ワークフロー、スケジュール、カレンダー、認証情報、ランタイム実行、ファイル転送、監視、サービスレベルオブジェクト、通知、ロールバックメカニズムを備えた本格的なワークロード自動化モデルを示している。Broadcom のライフサイクルとリリース資料は、アクティブに維持されている製品ラインを示している。買収の歴史は、なぜこの製品が現在、独立企業としてではなく、より大きなインフラストラクチャソフトウェアポートフォリオの中に位置しているかを説明している。

この主張を誇張すべきではない。Automic は多くのものをスケジュールできるから価値があるのではない。脆弱なランブックを、オペレーターとビジネス所有者が受け入れるジョブチェーンに変換できるときに価値がある。その受け入れには、依存関係の真実、認証情報の規律、カレンダーの正確さ、エンドポイントメンテナンス、転送成功を超えた検証、明確な例外ルーティング、テストされたリカバリー、そしてビジネスプロセスが本来あるべき状態に達したという証拠が必要である。

複雑なクロスプラットフォーム運用を持つ企業にとって、これは真剣な提案である。狭いクラウドネイティブワークフローを持つチームには、より軽量な代替手段がより良いかもしれない。プロセス所有権が貧弱な組織にとって、Automic は混乱を保管する高価な場所になりうる。したがって、この製品はデモチェーンによってでも、コネクター数によってでも、一般的な自動化スローガンによってでもなく、ひとつの運用トライアルによって評価されるべきである。実際の手動ランブックを取り、それを統制されたチェーンとしてエンコードし、正常時と失敗時の条件で実行し、その結果がビジネス成果を所有する人々によって受け入れられるかどうかを問うこと。答えがイエスなら、Automic はその場所を獲得した。答えがノーなら、スケジュールは走ったが、ジョブチェーンは信頼できるものにはならなかった。