IT自動化は戦略的である
「メインフレームは Google よりも多くのトランザクションを毎日処理しており（CICS では 130 万 / 秒、Google では 68,542 / 秒）、その中には全エンタープライズ トランザクションの 55 パーセントが含まれています」（ Forbes ）と言ったらどう思いますか。
ショックを受けるでしょうか？ そんなことはすべきじゃない。 デジタルトランスフォーメーションやアプリ経済について語るとき、Facebook、Netflix、Google などのハイパースケール企業が主役を務めることが多いですが、現実には、アプリ経済は、誰も見たことも聞いたこともない何千、何万ものアプリケーションに、同じくらい（あるいはそれ以上に）依存しています。 注目されないのはメインフレームだけではありません。 また、最新のアプリやデバイスの光沢のあるインターフェースの下に巧妙に隠されているアプリケーション サービス、インフラストラクチャ、ミドルウェア、データ ソースもあります。
デジタル変革とは、テクノロジー自体の目覚ましい変革というよりも、テクノロジーと私たちがどのように関わり合うかということなのです。 API やセンサー、デバイスについては何も新しいことはありません。 タッチスクリーンや音声制御には特に驚くべき点はありません。 こうしたテクノロジーは、何らかの形でかなり長い間存在してきました。 そして場合によっては、それはまさに豚に口紅を塗ったようなものなのです。
負荷分散サービスなしではスケーリングできません。 セキュリティ アプリケーション サービスがなければアプリを保護することはできません。 ミドルウェアと API がなければアプリを接続することはできません。 そして、管理するデータがなければ、それらのどれもあまり興味深いものではありません。
アプリ経済は、私たちが目にするものよりも目にしないものに依存しています。 そのため、IT 部門がデジタルの場で発言権を持つことが不可欠になります。 アプリがパブリック クラウドに展開されているか、オンプレミスのプライベート クラウドに展開されているかに関係なく、そのシートは重要です。 アプリがまだモノリシックであるか、コンテナ化されたマイクロサービスであるかに関係なく、そのシートは重要です。 その席は重要です。 期間。
この議席は、IT をサポート的な役割から戦略的な役割へと変革するために必要なコラボレーションと文化的変化を象徴しています。
IT自動化の戦略的性質
今日、CIO が行うことができるより戦略的な決定の 1 つは、自動化に重点を置いています。 デジタル変革の結果として 55% の組織が自動化を導入しており、その戦略的影響は見逃せません。 アプリ開発のためのプログラミング言語とプラットフォームの選択が戦略的であるのと同様に、自動化の取り組みを支えるために選択されるツールセット、言語、プラットフォームも戦略的です。
これらの決定を重要でないとして無視するのは愚かなことだ。 技術的負債とアーキテクチャ的負債は急速に増大し、感謝祭で増えた体重と同じくらい予算から削減するのが困難です。 アーキテクチャ負債は、ソフトウェア開発における「技術的負債」の原則に基づいています。 それは比喩です: 複雑さとアーキテクチャの選択により、既存のシステム (故障/修理、メンテナンスなど) に対処することにすべての時間を費やすため、新しい作業を完了できなくなります。多額の負債がある場合、そのお金をすべて利息に費やしてしまうため、他のことにお金を使うことができなくなります。 この負債により、新しいサービスのコストが上昇し、生産性や利益のいずれで測定しても、収益を向上させる機会を活用するために必要なサービス速度が低下します。
これが、IT 自動化を戦略的な投資にする理由です。 企業では、自動化の実装に関して今行う選択は、何年も前にアプリ開発で行った選択と同じくらい大きな反響をもたらすでしょう。
たとえば、昨年の当社の調査では、 DevOps の 65% が、セルフサービス イネーブルメントが IT を回避してクラウドまたはオープン ソース ソリューションを探すという決定に影響を与えていると回答しました。 IT を避けるということはセキュリティを回避することを意味し、ビジネスやその他のシステムが危険にさらされます。
間違った言語を選択すると、適切な人材がいなければシステムを維持できなくなるため、時間の経過とともに負債が生じる可能性があります。 言語を選択しないと混乱が生じ、自動化スクリプトとシステムが常に注意と配慮を必要とするペットのようになってしまいます。 これにより、予算はイノベーションではなく、故障/修理とメンテナンスに振り向けられます。
IT 自動化は、エンタープライズ アプリケーション アーキテクチャと同様の要素を慎重に考慮して取り組む必要がある戦略的な取り組みです。
- ツールチェーン全体にわたるサポート
今日では、ほぼすべての IT ベンダーが、生産パイプラインにおける自動化と他のプレーヤーとの統合をサポートしています。 今日のネットワークの複雑さとパイプラインを構成するベンダーの多様性を考えると、従来型またはコミュニティベースのサポートは必須です。 ドキュメント、コード サンプル、アクティブなコミュニティは大いに役立ちます。 - 人材および/またはトレーニングの可用性
進めたいプラットフォーム、システム、言語で作業できるスタッフをトレーニングしたり、優秀な人材を雇用したりできない場合は、ステップ 1 に戻って選択プロセスを再度開始します。 構築しようとしているシステムを維持できない場合は、維持できるようになるまで手動で作業を続ける方がよいでしょう。 - マルチクラウド対応
マルチクラウド ビジネスのサポートは比較的新しい要件ですが、必須要件です。 自動化はオンプレミスのデータセンターに限定されません。 自動化の取り組みには、少なくとも 1 つのパブリック クラウド、そしてほぼ確実に複数のパブリック クラウドを含める必要があります。 つまり、自動化イニシアチブの一環として、プラットフォームの互換性と環境間でのポリシーの移植性を慎重に考慮する必要があります。 - 命令形または宣言形
おそらくこのことについては聞き飽きていると思いますが、この選択は非常に重要です。 命令型（純粋な API ベース）の方法は開発が速く、IT による適応も少なくて済みますが、自動化を特定のデバイスやベンダーに結び付けることによって大きな技術的負債が発生します。 宣言型（成果物ベース）の方法は、最初に多くの時間とアーキテクチャを必要とする可能性がありますが、プロセスと製品の密結合を緩和し、技術的負債を削減します。
IT 自動化は、CIO が行うことができる最も戦略的なテクノロジー上の決定の 1 つです。 また、アプリ経済のほとんどが IT 管轄下のシステムに依存していることを考えると、これは CIO が今日行うことができる最も戦略的なビジネス上の決定の 1 つでもあります。
賢明に選択してください。