従来の IT と、より俊敏な DevOps 主導の IT との間の溝が深まり、本質的に 2 層のデータ センター アーキテクチャが出現しています。 注意を払っている人にとっては、これは驚くべきことではないはずです。 何年もの間、私は、より速く、より頻繁に行動したいが、コア ネットワークのハードウェアではなく、手動の承認と変更を実装するためのプロセスを必要とするプロセスの硬直性によって妨げられている運用担当者や開発者からの質問に圧倒されてきました。
データ センター内外のデータの安全かつ安定した高速転送を維持する役割を担う人々と、ビジネス成長のきっかけとなると考えられるapplicationsや機能を今すぐに市場に投入する役割を担う人々との間には、当然ながら摩擦が生じ、激しい非難や非難、悪感情が生まれます。
多くの人は「ボクセン」を責めたがります。 ネットワーク内に常駐する、老朽化したレガシー ハードウェアは、applicationsの拡張とセキュリティ維持に必要な重要なサービスを提供しているにもかかわらず、単に「邪魔」になっているだけです。 しかし現実には、それらのボックスンが自分自身を責める必要はありません。 今日のほぼすべてのアプリケーションには、 curlにアクセスでき、HTTP の実用的な知識を持つ人なら誰でも、あらゆるapplicationの展開に伴うサービスを構成、管理、操作できる API が備わっています。 これらの「ボックスン」の多くはそれ自体が仮想化されており、データセンターの奥深くにあるものと同じ種類の仮想エクスペリエンスを提供する役割を果たします。
これらは、継続的な展開という概念である高速道路上の障害物とはほとんど言えません。
むしろ、DevOps の支持者がよく言うように、組織や文化の硬直性がこの摩擦を引き起こし、applicationの展開を遅らせるのです。 アプリ開発という不安定な環境では必ずしも安定性とセキュリティを維持する必要はなく、本番環境では安定性とセキュリティを維持する必要があるため、ミスやミスが引き起こすビジネスへの不可避的な混乱に対する許容度が低くなります。
これは必ずしも悪いことではありません。 コア ネットワークは、データ センター内のapplicationsへのアクセスを確保するためだけでなく、パブリック SaaS ソリューションに依存して業務を遂行する内部ユーザーのためにも、高いレベルの可用性を維持する必要があります。
ただし、組織は、最新のデータ センターの両方のアーキテクチャ層のニーズをより適切にバランスさせるために、制約を緩和する必要があります。 アプリの展開はより迅速かつ頻繁に行う必要があります。 これを達成するには、組織は現在実施しているプロセスを真剣に検討する必要があります。これらのプロセスは、組織が管理する組織よりも確実に厳格で柔軟性がありません。 IT 運用プロセスは、今日のビジネスにとってビジネス プロセスと同じくらい重要であり、ビジネス リーダーは、効率性とビジネス パフォーマンスのメリットを生み出すために、IT 運用プロセスを調査、評価、文書化、自動化、改善する必要があることを理解しています。 さらに重要なのは、必要に応じて変更できるほど機敏である必要があることです。 しかし、そのためには、組織はそれらのプロセスを理解し、非効率性やボトルネックに対して批判的な目で評価する意欲を持つ必要があります。
2016 年の AIIM 業界ウォッチ レポート「情報管理 - 2016 年の業界の現状」では、回答者の 55% がビジネス プロセス管理 (BPM) が自社のビジネスにとって重要 (38%) または必須 (17%) であると回答しました。
プロセスを強化するためのテクノロジーの使用に関しては、企業は全般的に改善が見られました。
IT では「オーケストレーション」という用語を頻繁に使用しますが、それがプロセスとどのように関係するかについてはほとんど議論されません。 オーケストレーションを使用して、展開を管理する運用プロセスを自動化すると、実際の改善が見られます。 価値の流れにおける無駄やギャップを発見し、待ち時間や不必要な承認、冗長性を排除することで、組織はビジネスプロセス側で見られたのと同じ種類の速度と俊敏性の向上を実現できます。
これを DevOps と呼ぶことも、運用プロセス管理 (OPM) と呼ぶこともできますが、実際にはこの 2 つは密接に関連しています。 組織は、安定性とセキュリティを犠牲にすることなく、アプリの展開の俊敏性とスピードを向上させるために、ビジネス プロセスですでに行っていることを運用 IT プロセスでも実行する必要があります。
また、データセンターにボックスがあるかどうかとはほとんど関係ありません。