IBMの顧問アーキテクトPrabhakar Mynampati氏(リンク)は先週、SOAガバナンスのビジネスプロセス６つを詳述した論文(リンク)を発表した。この論文では、以下に関してBPMNのプロセス定義をしている。
- サービスの識別
- サービスの作成
- サービスの検査
- サービスのバージョニングおよび変更の管理
- サービスの管理
- サービスのセキュリティ
SOAガバナンスをしていないSOA開発ライフサイクルにおいて、遭遇の可能性が高い難題に対応する形で、次のようなシナリオが定義された。
- 新サービスの識別と優先順位付けをする上での奮闘。
- 余剰で非効率的なサービスの作成といった、サービスの作成と再利用に関する重要問題。
- 導入検査の戦略と基準が場当たり的。
- 変更のガバナンスとサービスのバージョンが大まかで、洗練されていない。
- サービスの管理、サービスの品質（QoS）、サービスのセキュリティを守らせる組織的な方法が欠如している。
サービスの識別が必要な理由をMynampati氏は以下のように主張している。
ビジネスサービスとITサービスにおける一貫性のない識別アプローチが原因で、様々なプロジェクトリスクが発生しています。サービスには相互運用性がない可能性があり、サービス識別後にはサービスの多くが不要になるかもしれません。サービスの識別やサービスのデリバリに責任を負う所有者が存在しない、という事態もあるかもしれません。最終的には、こうしたリスクのすべてが原因でプロジェクト費用が増大し、納期に間に合わなくなる可能性があるのです。
Mynampati氏は次のようなサービス識別プロセスの利用を提案する。
同様に、サービス作成プロセスが必要な理由は以下のとおりである。
組織は現在、水平および垂直ドメインの異なるラインをまたぎ、他のリポジトリを考えることなく構築した余剰かつ非効率的なサービスの開発とデプロイメントに苦しんでいます。サービスの中には、システム機能の認識が矛盾するような方法で具体化されているものもあります。類似もしくは同一のサービスが複数維持されているため、維持費が増加し、そうしたサービスに対する制御が働いていないため、そこで開発が停止してしまいます。
サービス検査の場合、Mynampati氏は次のように考えている。
様々なグループがサービスの検査に異なるツールと検査戦略を使用している状態です。組織内には、サービス実現に向けたツールやプラグイン、検査戦略の使用に対して、統一されたアプローチがありません。統一アプローチの欠如は、縦割りの部署でサービスのコンプライアンス検査が展開されたという事実に起因するものであり、実現されたITサービスではビジネス要件を的確に満たせないという問題が発生しました。厳しいプロジェクトスケジュールでは、統合とシステム検査の期限に間に合わない部署もあります。また、ITサービスの組織的な実現に向けて、ビジネス要件の変更を処理できないプロジェクトチームもあります。こうした問題のすべてが、検査シナリオにおけるガバナンスに難題をもたらしているのです。
サービスのバージョニングと変更管理プロセスが必要なのは、次のような場合であるとMynampati氏は主張する。
ビジネスプロセスに必要とされる変更をITに実施する必要があるか否か、また、その変更を既存サービスに実施すべきなのか、あるいは次期バージョンのリリース時に実施すべきなのかを決定する権限が組織にない場合です。こうした変更が他のサービス消費者に及ぼす影響を調査し、理解する共通の組織が存在しないのです。そして、サービスのバージョニング向けのランタイムポリシーを決定する権限がありません。サービスのバージョン変更時には、プロダクション中断のせいでシステムが利用できない、と顧客から苦情が発生します。
サービスの管理プロセス分野にも重大なSOAガバナンス活動がある、とMynampati氏は考える。
このサービス管理のシナリオでは、様々なサービス消費者に公開されているサービスの監視と管理において困難に直面している組織に注目します。…サービス内容合意書（SLA）に基づいて監視の必要があるサービスとリソースについて、アーキテクチャ・開発チームは認識していないのです。ビジネスアプリケーションの端から端までを見通す管理ツールを導入するための統一されたアプローチがなく、そして、個々のリソースのパフォーマンスと可用性の測定に関する詳細な情報を提供するための統一されたアプローチがないのです。
最後になるが、Mynampati氏は次のような場合にも問題があるとしている。
セキュリティの脅威に取り組むための、また外部からのアクセスからサービスを守るための共通した戦略が組織に無い場合です。サービスに多数の認証と認可を要すると、オペレーターの苛立ちが募ります。ポリシーを導入するための、そして、そうしたポリシーの開始から実施までを追跡するためのセキュリティポリシーを管理するフレームワークがなく、企業の境界にある組織と相互作用し、連絡をとりあって、共通したセキュリティ基準セットを維持管理する責任を負う組織体が存在しません。他のサービスやデータとの相互作用に備えた合意済みのセキュリティ基準がなく、ポリシー管理のための明確な役割や責任もありません。
サービスの識別あるいは実装、保護、管理には高度に系統的なSOAガバナンスが必要である。みなさんの組織では似たようなプロセスをお使いだろうか。使っていない場合は、筆者が今回紹介したような問題を経験しただろうか。みなさんはこうしたプロセスの実施を検討されるだろうか。
原文はこちらです：http://www.infoq.com/news/2008/10/bp-soa-governance