用語として、ビジネスサービス管理(BSM)は、2007年版の情報技術インフラストラクチャライブラリ(ITIL)に最初に含まれ、その定義は「ビジネス顧客に提供されるビジネスサービスの管理」でした。
2017年2月に早送りすると、BSMは可能な限り最も劇的な方法で休息するようになりました。ガートナーのアナリスト、ゲイリー・スピバクとヴィヴェック・バラは次のように書いています。BSMは死んでいます。他のITOMツールを使用して、価値を伝え、運用を管理します。」彼らは続けてこう言います:
「ビジネスサービス管理は、ビジネスに不可欠な機能に[インフラストラクチャと運用]リソースを優先し、伝達し、集中させるという約束を果たしていません。」
控えめに言っても、それは少し厳しいものでした。
BSMの非常に短い歴史
当時、ITチームは管理に非常に集中していました 要素 ITの。 HRはITに電話し、Webサイトがダウンしていると不平を言いました。インフラストラクチャと運用(I&O)チームは、サーバーが稼働していて、ネットワークが稼働していて、何も赤く点滅していないと応答しました。それでは、HRの問題は何でしたか?もちろん、問題は、これら2つの部門が異なる言語を話していることでした。 ITはテクノロジーについて話し、HRはビジネスサービスについて話していました。そして、ビジネス目標は翻訳で失われました。
ITとビジネスの間のインタプリタとして機能するソリューションを構築するというアイデアは、BSMが生まれた経緯です。 ITの焦点を要素からサービスに移すために新しいツールが構築され、それらはBSMスイートとしてパッケージ化されました。最も一般的なのは、IBM(Tivoli、Netcool、Omnibus)、HP(Operations Bridge、Operations Manager i)、CA(UnicenterおよびSpectrum)です。 )およびBMC(Patrol、Remedy)。これらの各ツールは、ネットワーク、ストレージ、ログ、仮想化、サーバー、オペレーティングシステムなどのサービス要素に重点を置いていました。理想的には、顧客はBSMビジョンとモノリシックスイートを購入してから、要素中心の管理フレームワークからサービス中心の管理フレームワークに切り替えます。しかし、それはそれほど簡単ではありませんでした。
理論は実践されなかった
前提自体は良好でしたが、実行ははるかに複雑であることが判明しました。コンサルタントのチームが集まり、カスタムアーキテクチャ、運用モデル、および必要なツールの目標とパラメータを定義します。スイート自体はオンプレミスでホストされていたため、データセンターにアクセスしてインストールするのに数か月から数か月かかりました。インストールすると、スペシャリストのチームが正しく実行および管理する必要がありました。これらはすべて、専門的なサービスに数十万ドルの費用がかかります。実装は通常、契約上のガードレールをはるかに超えて拡張されるため、恐ろしい「スコープクリープ」もこれらのコストを押し上げました。そして、特定のチームがカスタム機能を必要としたのはいつですか?その要求は、18〜24か月のリリースサイクルで失われました。その間、メンテナンス、ライセンス、サポートの料金は高騰し続けました。 IT予算は持続不可能なレベルにまで膨れ上がりました。したがって、BSMは決して定着しませんでした。そして、ガートナーは最終的にその厳しい賛辞を書きました。
ガートナーの布告からわずか18か月ですが、BSMの約束はこれまで以上に重要であるように思われます。切断された「最善の」ツールが多すぎると、IT運用管理の問題のごく一部に対処し、防止します。 現代のデジタルオペレーションよりサービス中心の方法で提供されることから。さらに、クラウドの台頭とパブリッククラウドインフラストラクチャの可用性は、ITの役割が「構築と運用」から「コンサルティング」にシフトしていることを意味します。モニタリング と 管理します」。 BSMの概念が必要であることは明らかですが、完全に再考されています。
次の論理的な質問は、なぜ今回は状況が異なるのかということです。私が呼ぶものへの新しいアプローチの必要性を加速する5つの根本的な変化があると私は信じています サービス中心のデジタルオペレーション:
- クラウドネイティブアーキテクチャの台頭:サーバーレスコンピューティング、コンテナー、マイクロサービスにより、IT要素の世界は徐々に構外に統合され、完全に一時的なものになりつつあります。 IT部門は、ベアメタルが常に希少になっているため、以前ほど要素を管理していません。
- SaaSの台頭: あらゆる場所のベンダーが、柔軟性とスケーラビリティを目的として構築されたSaaSプラットフォームを開発していますが、そのフレームワークは適切に管理されています。つまり、SaaSプラットフォームは、さらに別の監視ツールや管理ツールを追加することなく、ビジネスの複雑さに応じて拡張することがこれまでになく簡単になります。
- サービスの台頭: サービス指向はもはや例外ではありません。ガートナーは、ITサービスの共通の見方を備えた「IT運用モデルにエンタープライズレベルのサービスポートフォリオが含まれる」サービスバリューチェーンを提唱しています。サービスマッピング、サービストポロジ、およびサービス可用性ダッシュボードはどこにでもあります。さらに、ITがビジネスのサービスプロバイダーになり、指揮統制ではなく柔軟性とガバナンスを提供するようになった大企業の多くには、文化的な変化があります。
- T彼はDevOpsの台頭: チームは彼らの働き方を変えています、そしてそれはビジネスが彼らと共に進化していることを意味します。構築したものを実行する必要がある開発チームは、ネットワークがダウンしている午前2時にポケットベルに応答することには関心がありません。彼らはビジネスサービスの維持に関心があり、それらをサポートするプロセスとソリューションを必要としています。
- AIOpsの台頭:自動化と人工知能は、最新のIT運用とサービス管理に伴う指数関数的なデータ過負荷に対処するためのキラーテクノロジーです。これらは、IT運用チームがサービスの健全性を予測的かつ積極的に維持する上で大きな役割を果たす方法のエンジンです。
アジャイルデジタル運用のためのインテリジェントサービス
この新しい形式のサービス指向は、変化するビジネスニーズに対応するための弾力性と、コンプライアンスを維持するための管理された機能の両方を備えています。俊敏性と新しいテクノロジーへの適応性が必要ですが、合併や買収を通じて一貫性があります。モノリシックではなく、消耗性が高い必要があります。そして最も重要なことは、導入と保守がより簡単で安価でなければならないということです。
私たちは、次世代のビジネスサービス管理戦略、ソリューション、テクノロジーのターニングポイントにいます。たぶんそれは時代を先取りした素晴らしいアイデアでした。しかし、最新のクラウドネイティブでWebスケールのAIを活用したエンタープライズIT組織は、社内外の顧客にとって重要なことに焦点を当てる必要があります。彼らは、顧客へのより良いサービスがすべてであることを知っています。そして、サーバーの調査をやめ、サービスの調査を開始することを拒否するITチームは、次の厳しい賛辞の受け手になるかもしれません。