完全に分離された運用モデル

次の図では、縦軸にアプリケーションとインフラストラクチャが設定されています。アプリケーションとは、ビジネス成果を提供するワークロードを指し、カスタム開発または購入したソフトウェアであると考えます。インフラストラクチャとは、物理および仮想インフラストラクチャと、そのワークロードをサポートするその他のソフトウェアを指します。

横軸には、エンジニアリングと運用が設定されています。エンジニアリングとは、アプリケーションやインフラストラクチャの開発、構築、テストを指します。運用とは、アプリケーションとインフラストラクチャのデプロイ、更新、および継続的なサポートのことです。

多くの組織では、この「完全に分離された」モデルが存在します。各クアドラントのアクティビティは、個別のチームによって実行されます。 作業は、作業リクエスト、作業キュー、チケットなどのメカニズムを介して、または IT サービス管理 (ITSM) システムを使用してチーム間で渡されます。

チームへの、またはチーム間でのタスクを移行すると、複雑性が増し、ボトルネックや遅延が生じてしまいます。リクエストは、優先順位が高くなるまで遅延することがあります。遅れて特定された不具合は大幅な再処理が必要になる可能性があり、同じチームとその機能を再び通過する必要が生じます。エンジニアリングチームによるアクションを必要とするインシデントがある場合、引き渡しのアクティビティによって対応が遅れてしまいます。

業務チーム、開発チーム、運用チームが、実行されているアクティビティや機能を中心に編成されている場合には、調整不良のリスクが高くなります。これでは、チームはビジネス成果の達成に集中するのではなく、特定の責任に集中することになってしまいます。チームは専門的、物理的、あるいは論理的に細かく分けられて隔離されることがあり、コミュニケーションや共同作業の妨げになる場合があります。