今週、フォーチュン500社のエンタープライズアーキテクトであるTodd Biske氏がITL とSOAの関係をめぐって議論を(再び)始めた(リンク)。この議論の開始点は、以下の見解である。
SOAとITIL Service Managementは、よく似た点がある。プロジェクトが動き始めるときに終了する従来のリニアライフサイクルから、サービスの特定で開始し、その閉鎖で終了するサーキュラーライフサイクルへSOAは考えをシフトすることができる。
Todd氏にとって、これは以下のようなことを意味する。
ITILサービスの提供について検討しているのと同様の方法で、アプリケーションや「Web」についても考えるべきです。多くの人はITILはIT操作や インフラのみに関することだと考えていますが、実際にはそうではありません。もしあなたがデベロッパであるなら、構築や提供しているアプリケーションに同 等に適用します。
Enterprise Integration ArchitectであるJack van Hoof氏(リンク)は、Todd氏と同意見である。昨年以下のように、書いている(リンク)。
- 数ある中でも、市場やサービスの市場価値が決定されるサービス戦略があある。サービスポートフォリオと所有権は管理される必要があり、サービスの提供やその維持のためのファイナンシャルモデルでなくてはならない。
- それからサービス設計があり、アーキテクチャの技術、人および処理の観点からソリューションが開発される。サービスカタログ管理、継続性、セキュリティレベルなどに関して、処理は開発される。
- サービスの遷移には、変更の管理、構成の管理、リリース、計画およびテストのような処理がある。
- 最後にサービスの操作はサービスの実行に焦点を絞って、統制される必要がある。これには、インスタンスの誤動作の管理、問題管理およびアクセス管理が含まれる。
上記のすべては、SOAガバナンスの側面である。そして、これがまさにITIL v3(リンク)のスコープである。
Jack氏は以下のように付け加えている。
SOAコンテンツにおいて、ITILをプルするにはさらに大きな利点がある。それはITIL指向のツールである。
実際これは口で言うほど簡単ではない。数年前、Jeff Kaplan氏がすでに以下の内容を記している(リンク)。
ITILおよびSOAの共通の目標および指針があるにもかかわらず、こうした取り組み間における多くの構造において、隔たりがある。
最大の障害は、IT操作およびソフトウェア開発チーム間の心理的距離および構造上の障壁である。(それには)別々に作業をしているという長い歴史があり、しばしば衝突することが、共通目標の達成に向けたお互いの相違点を棚上げにすることが困難になっている。過去において、ITILおよびSOAの導入に向けた取り組みを開始したにもかかわらず、多くの組織が適切に調整されたIT操作およびソフトウェア開発に立 ちはだかる同様の構造上の障壁を容認してきた。こうしたイニシアチブで組織上のサイロを打開するよりはむしろ、多くの企業が別々のITILおよびSOAの 取り組みを実行している。
フォローアップの記事内で、Todd氏はJames McGovern氏(リンク)に対し異議(リンク)を申し立てた。
James氏：自社のソフトウェア開発の側面に利益となる操作タイプへのフィードバックを概説することが非常に価値があるかもしれない。
Todd氏：オペレータがITIL cool-aidを飲むのであれば、サービスパフォーマンスを計測する必要があり、それに向けた目標はオペレーションチーム個々の目標に反映され、やがて 改善をもたらすものであるべきである。その測定が、時間通りに予算内で提供することのような、「一度きりの」測定カテゴリーに該当する場合、誤ったものを 測定していたかもしれないとかサービスベースのビューを取っていないという決定的証拠である。
シアトルにある財政組織のEnterprise ArchitectであるRichard Webb氏は、私信で、Todd氏の投稿にさらにコメントを寄せた。
計測は、使用され過ぎている。「実行状態」を知ることには、計測やメトリック(この場合、インスツルメンテーション)を含むが、根本原因やものごとの実体 は(組み込みとして)「どのような」ものであるか、実際にはものごとがどのように動作するのか(モデル)など、開発およびエンジニアリングの側面を知るこ とである。
Todd氏は、Service Oriented Architecturesの重要な(しかし、しばしば見過ごされる)基盤の1つを再び述べることで締めくくった。
単にスケジュールや予算を満たすことに焦点を当て、次のプロジェクトが割り当てられるのを待つよりはむしろ、持続的に改善をしていくという概念を導入することが重要である。