SOA プロジェクト・プランを改善する

強力なガバナンス原則が成功を導く

SOA (Service-Oriented Architecture) は、IT の効率を劇的に改善する可能性を秘めています。しかし、組織において SOA を実装するためには、技術的なノウハウ以上のもの、つまり管理スキルも必要なのです。この記事では、Yvonne Balzer が、SOA プロジェクトを成功に導くガバナンス原則の概要を解説します。

Yvonne Balzer (yvonne.balzer@de.ibm.com), Senior IT Management Consultant, IBM Global Services ITMC

Yvonne Balzer はドイツの University of Mannheim にて、ビジネス管理のコンピューター・サイエンスで学位を取得しました。彼女は IBM Global Services の Senior IT Management Consultant であり、アーキテクチャー管理と SOA を中心とした IT ガバナンスと IT 戦略に思考リーダーシップを発揮しています。IT アーキテクトとして数年間働き、国内外の金融業界や公共組織、自動車業界などの顧客にコンサルティングを行ってきました。彼女はヨーロッパや中東、そしてアジアでの IT ガバナンスに関する市場活動の中心となっています。IBM Technical Expert Council のメンバーであり、またIBM Women in Technology に貢献しています。連絡先は yvonne.balzer@de.ibm.com です。



2004年 6月 16日

今日のビジネスと IT のバリュー・チェーンは、業界内で融合を始めています。今や私達は、エンタープライズ・アーキテクチャーと SOA (Service-Oriented Architecture) は IT 実装から独立したものとして語るようになっています。こうした変化のため、私達がビジネスや IT を構成し、また SOA のようなアーキテクチャーを定義、開発するための方法も、そして企業に焦点を絞った顧客のプロジェクトの実行も、それに合わせて変更しなければなりません。

こうした様々な理由から、今日の IT では、かつてないほどガバナンスが重要な役割を持つようになっています。この記事では、IBM の ITMC (IT Management Consulting) チームのベスト・プラクティスである、ベスト・ガバナンス方式を紹介します。この方式は、私達が何件かの顧客とのプロジェクトの中で開発し、実装してきたものです。実証済みの IT ガバナンス構造とプラクティスから始めることによって、私達のガバナンス・モデルを SOA の要求を満足するまでに高めることができたのです。

動機と目的

この業界の直面する課題と問題のために、最近の組織における IT の役割は劇的に変化しました。今日の IT は、ほとんどリアルタイムのビジネスを実現できるほど、迅速かつ柔軟に反応できなければなりません。ビジネス・コンポーネントと IT コンポーネントの境界は次第に曖昧になりつつある中で、IT は、高度に統合され複雑なエンタープライズ・アーキテクチャーの一部分を設計、管理できなければなりません。この記事では、こうしたゴールを実現し、SOA プロジェクトを成功に導くために鍵となるガバナンス機能を提案します。

ガバナンスは、全体的な構造を提供することで、戦略レベル、機能レベル、そしてオペレーション・レベルで顧客のビジネス目的をサポートします。またガバナンスは、SOA プロジェクトの効果的なプラニング、意志決定、方向付け、コントロールなどに必要なルールやプロセス、メトリックス、組織構造を定義し、顧客のビジネス要求や困難な目標を達成します。そして最後に、ガバナンス・モデルは下記を定義します。

  • 何を行うのか
  • どのように行うのか
  • 誰が行うべきなのか
  • どのように測定すべきなのか

このモデルもまた、SOA プロジェクトの効果的なプラニング、意志決定、方向付け、コントロールなどに必要なルールやプロセス、メトリックス、組織構造を定義し、顧客のビジネス要求や困難な目標を達成します。

下記は、SOA プロジェクトの中で適切なガバナンス構造を定義する上で、鍵となる質問です。

  • このプロジェクトによって、顧客はどのような利益を得られるのか。顧客の目的と、期待するものは何か。
  • IT プラニング、方向付け、意志決定のための、どのような役割や責任、構造、手順が既にクライアントの側に存在するのか。
  • 必要なスキルやリーダーシップを、どのように開発するのか。
  • ビジネスと IT の整合を最適化するために、どのような原則や指針が必要なのか。
  • 新たな変化に十分迅速に対応できるよう、一貫性と柔軟性の両方を維持するためには、ビジネスと IT の相互作用をどのように構成すれば適切なのか。
  • サービスやサービスの定義、サービスの記述には、どのような標準化が適切なのか。
  • サービスとサービス・プロバイダーを、どのようにコントロールし、調べることができるのか。既存のサービスへの変更を、誰が監視し、定義し、許可するか。
  • サービスの配分戦略をどのように決定するのか。
  • どのような問題が存在し、そうした問題を解決する上でプロジェクトはどのように顧客をサポートできるのか。

私達は経験から、ビジネス目的を達成するためには、受け入れられ、正式化されたガバナンス・モデルが鍵だと考えています。従って私達は、SOA プロジェクトにガバナンス機能を設置することを提案します。このガバナンス・モデルは、各ステップで学んだ教訓を使って次のステップを定義、実行することに焦点を当て、徐々に適応していくための基本的な要求にも対応する必要があります。ガバナンス・モデルの中心的な要求として、SOA の適用と実装のためにガバナンス組織を作成することがあげられます。そうした組織が迅速、かつ十分に受け入れられるためには、顧客の既存組織を使用し、それらと協力しながら SOA プロジェクトに適用することが重要です。


ガバナンス・モデル: SOA プロジェクトのための正しい姿

IT ガバナンスには、さまざまな定義があります。IT Governance Institute (「参考文献」にリンクがあります) による定義は、IT ガバナンスを下記のように一般的にうまく概説しています。

IT ガバナンスは、取締役会や経営陣の責務です。IT ガバナンスはエンタープライズ・ガバナンスに必須のものであり、リーダーシップや、組織的な構造やプロセスから構成され、その組織の IT が戦略と目的を確実に、維持、拡張できるようにします。
IT ガバナンスの目的は、IT に関する努力を、IT のパフォーマンスがビジネス目的に合致するように導くことです。その結果、次のことが可能になります。
* IT と企業の業績との整合を図ることができ、約束された利益を実現することができます。
* IT によって企業の機会が十分に生かされ、利益が最大化されます。
* IT リソースを責任を持って利用することができます。
* IT に関連するリスクが適切に管理されます。

図 1 に示す私達のガバナンス・モデルは、組織的な構造、共同プロセス、そして戦略的な方向性と受け入れ済みの基本規則に基づく関係 (ガバナンス原則と呼ばれます) の組み合わせです。この方式は、大規模で複雑なプロジェクトでの私達の経験から開発されたものです。私達はこうしたプロジェクトの中で、これらの要素が、どのようなプロジェクトにとっても基本的なものだと認識したのです。

図 1. 中核となるガバナンス要素
中核となるガバナンス要素

戦略的な方向性と指針

顧客の戦略的な方向性を定義することは、適切な SOA 開発を成功させ、ビジネス上の要求にフォーカスし続ける上での鍵です。ビジネスの戦略と目的を共通で理解することは、ビジネス・ユニットにとっても IT にとっても基本的なことです。

ガバナンスの原則と指針は、あらゆる決定に対する基礎です。これによってソリューション領域が形成され、コラボレーションの方法が定義されます。従って経営幹部は、これをよく理解し、合意している必要があります。主な指針の 1 つが、ガバナンス方式です。この方式には、それぞれ異なる 2 つの主な方式があります。

  • 中央ガバナンス: 企業にとって最善の方式です。ガバナンス審議会は、各サービス・ドメイン (後ほど再度触れます) の代表者と、ソリューションの鍵となる技術コンポーネントの実装者に指示ができる専門家から構成されます。中央ガバナンス審議会は、変更の実装を許可する前に、既存サービスへの変更を含めたサービス・リストへの追加や削除を検討します。
  • 分散ガバナンス: 分散したチームにとって最善の方式です。各ビジネス・ユニットが、その組織内でのサービスの提供方法を自分でコントロールします。このためには機能サービス・ドメインの方式が必要です。中央の委員会は、様々なチームに対して指針や標準を提供することができます。

それぞれの原則の定義は、その原則の目的と意味を説明できる理論的根拠により定義されている必要があります。ガイド原則は、SOA を開発、維持管理、そして使用するための基本規則を定義します。例えばアーキテクチャー設計やサービス定義のための特定原則は、こうしたガイド原則を元に、特定のテーマに焦点を絞って作られます。こうした原則は、設計スタイルに対する基本的な動作を決定する特性であり、プロジェクトの次のような側面をカバーしている必要があります。

  • 指針
    • 再利用性、粒度、モジュラー性、合成の容易さ、コンポーネント化
    • 標準への準拠 (一般的な標準と業界特有の標準の両方)
    • サービスの識別とカテゴリー化、プロビジョニングとデリバリー、モニタリングとトラッキング
  • アーキテクチャー面の特定原則
    • カプセル化
    • 基礎となる技術からのビジネス・ロジックの分離
    • コンポーネントの単一実装とエンタープライズ・ビュー
    • 可能な限りの既存資産活用
    • ライフ・サイクル管理
    • 効率的なシステム・リソース利用
    • サービスの成熟とパフォーマンス

SOA スタイルのアーキテクチャーや設計の原則と、そうした原則がビジネスや IT コミュニティーに与える利益を理解することによって、ソリューションの設計に際して SOA が適用可能かどうかを判断することができます。こうした原則は、サービスの設計にとって必須の、ある種の特性を後押ししてくれます。そうした特性のそれぞれをたどると、様々な原則や特性の完全性を実現する、1 つあるいは複数の SOA 原則を理解することができます。

ガバナンス・プロセス

ガバナンス・プロセスは戦略的な IT プラニングや方向付けに必要なプロセスであり、下記のようなものがあります。

  • 戦略開発
  • IT プラニング
  • ポートフォリオ管理
  • 配分
  • 革新管理
  • アーキテクチャー管理

SOA プロジェクトでは、一番最初に AMP (Architecture Management Process) を確立する必要があります。AMP の主な目的は、一貫性のある効率的な開発と、定義された SOA の有効性を確保することです。

私達は様々なプロジェクトでの経験から、顧客のプロジェクトで迅速かつ容易に使用、採用できる、標準的な AMP を開発しました。このプロセスは、図 2 に示す 4 つのサブプロセスから構成されます。これらのサブプロセスは的確に定義されており、資産として、IBM LOVEM 記法を使って利用することができます (LOVEM は line of visibility engineering methodology を表します。詳しくは「参考文献」を参照してください)。

図 2. アーキテクチャー管理プロセス
アーキテクチャー管理プロセス

この図の中のいくつかの要素を、少し詳しく見てみましょう。

  • アーキテクチャー・レビューと承認プロセス:
    • 構造を持ったレビュー方式を定義し、既存の SOA に対する変更を承認し、また SOA ロードマップに従って決定を行います。
    • 正式な設計とサービス評価レビューは重要なコントロール・ポイントです。
  • アーキテクチャー例外とエスカレーション・プロセス:
    • アーキテクチャー面での決定に訴える手段を提供します。
    • ユニークなビジネス要求を満足させるために、SOA アーキテクチャーに対する例外を許します。
  • アーキテクチャー・メンテナンス・プロセス:
    • SOA が維持管理されることを保証し、またアーキテクチャーに新しいサービスが追加された場合には、その変更が利害関係者に伝えられることを保証します。
    • アーキテクチャーとの相違点は文書化され、関係者に伝えられます。
  • アーキテクチャー・コミュニケーション・プロセス:
    • SOA を必要とする人が、誰でもSOA を利用できるようにします。
    • SOA の重要性を理解されるように促します。

組織構造

アーキテクチャー・ガバナンスを実現するためには、組織内に何らかの組織を設立する必要があり、その設立された組織が、必要なすべての役割や責任、また適切な意志決定構造を定義するようにします。これまでのフィールドでの経験から、特に大規模で複雑なプロジェクトでは、アーキテクチャー・オフィスを設立することが非常に有効なことが分かっています。アーキテクチャー・オフィスは、 SOA が戦略的、戦術的、そしてオペレーション的なレベルでビジネス要求と整合性を保つよう責任を持ちます。このオフィスには、アーキテクチャー管理プロセスの所有者である、アーキテクチャー設計の権威が含まれます。また、それぞれのレベルで、役割や責任が定義されます。

私達はこれまで様々な顧客と作業を行ってきた中から、アーキテクチャー・オフィスを設立、運営するために効果的な 2 つの方法を認識しています。

  • 顧客の組織が既にアーキテクチャー・オフィスと似たような機能の組織を持っている場合には、そうした既存の構造とのリンクを図るべきです。また、アーキテクチャーに関する決定をするために必要な、すべての機能と責任が用意されていることを確認する必要があります。SOA プロジェクトでは、取締役会のメンバーが SOA に関する決定に参加する必要があり、またプロジェクトの進行状況を把握している必要があります。
  • 顧客のサイトにガバナンス審議会がない場合には、SOA プロジェクトの中にアーキテクチャー・オフィスを設立し、プロジェクトからの重要な成果物に関しては、そのオフィスが決定を下すようにすることをお勧めします。アーキテクチャー・オフィスの一時的なメンバーとしては、顧客の中から選任された人員とプロジェクトに関係する人員があたるようにします。このメンバーは意志決定者であるべきであり、スポンサーとして CIO が含まれているべきです。プロジェクトが終わると、アーキテクチャー・オフィスは顧客の組織の中に統合することができます。

図3 は、アーキテクチャー・オフィスと、各レベルでこのオフィスが果たすべき役割と責任を示しています。戦略的なレベルでは、アーキテクチャー・ボードがあります。これは意志決定委員会であり、標準や原則を提出し、またサービスがビジネス戦略や IT 戦略と整合性を持つように優先度を付けます。戦術的なレベルでは、アーキテクチャー・グループはアーキテクチャー設計の権威として行動し、アーキテクチャー管理プロセスや、サービスの変更、削除、追加のための判断基準、ドメインの管理などに責任を持ちます。オペレーション・レベルでは、プロジェクト・チームがサービスを開発し、実装します。

図 3. アーキテクチャー・オフィス
アーキテクチャー・オフィス

各チームは、チームのタスクや責任、オペレーション・モードを定義する役割の記述を必要とします。

SOA ガバナンスでは、ドメイン・オーナーシップという概念が導入されています。ここで言うドメインは、ビジネスと何らかの共通の関係を持ち、管理対象となる一連の再利用可能なサービスです。多くの場合、これらはビジネス・サービスのサブセットです。つまり顧客情報やさまざまな事例、販売者との紛争履歴など、そして販売者のリスク格付けのような紛争関連資料や製品分析、プラニングなどのサービスなどです。各ドメインは自分のビジネス・オブジェクトの維持管理や、自分のサービス・インターフェースを他のドメインに公開することに責任を持ちます。ドメインは、そのドメインのオブジェクトやサービスに関連するビジネス・ロジックや位置、フォーマットをカプセル化し、ビジネス・オブジェクトのための取得サービスや維持管理サービスを提供します。ある 1 つの製品あるいは製品領域を担当する人達が、あるドメインからサービスを要求する場合、その人達はリクエストを行い、この 2 つのグループは両者の関係を決定し、サービスレベル・アグリーメントを作成します。こうした関係とアグリーメントは、ドメイン同士の間にも存在します。

ドメイン・オーナーシップという概念を使うことによって、SOA プロジェクトの開発ライフサイクルに提供すべき新たな役割や責任が、さらにいくつか生まれます。この概要を、下記の表 1 に示します。

表 1. SOA プロジェクトにおける役割と責任
役割説明
ドメイン・オーナードメインの方向性を管理します。ドメインは、1 つ以上のサービスと、さまざまなビジネス・ユニットのプロセス・オーナーがビジネスの展望を理解するよう補助するためのビジネス関係の集合から構成されます。データとプロセスのオーナーと協力しながら、基幹業務によるビジネス分析を使ってビジネス・ゴールや要求を明確にします。ROI を計算するためにサービスの使用状況を追跡します。
ドメイン・サービス指向のビジネス・アナリスト特定のユーザー・インターフェースを想定せず、サービスの機能に注目してユース・ケースを開発します。的確に抽象化、正規化されたビジネス・サービスを識別し、規定します。厳格かつ変化の早い、サービス定義と開発ライフサイクルに対応する必要があります。
基幹業務の代表ドメインに対するビジネス・サービスを識別し、分析します。
ドメイン開発者と維持管理者サービス指向の開発ライフ・サイクルに沿ったサービスを構築し、維持管理します。開発ルール (例えばサービスの設計に関する考慮や、Web サービス実装の指針など) や SOA、参照アーキテクチャーなどに沿ったサービスを構築し、実装します。
サービス・テスターあるサービスが、そのサービスに関して合意済みの判断テストに準拠していることを認証し、適切なビジネス価値が得られるようにします。機能インターフェースと、その実装の独立性を調べるためのテストケースを構築します。

あるサービス・ドメインで作業する人達の責任は、ビジネスと技術を統合してビジネス・サービスを生み出すこと、そして、そうしたサービスが様々な基幹業務全体に渡って共有されるようにし、そのメンバーや領域に利益を与えることです。これによって、機能の開発はアプリケーション内からサービス・ドメインへと移行するため、アプリケーション開発のための組織構造 (役割と責任) に変化が生まれます。


ガバナンス・モデルを開始する

ガバナンス・モデルの開発に使用するプロセスは、下記の 3 つのフェーズから構成されます。この方式は、時間に制約のある様々な顧客プロジェクトの中から開発されたものです。成功するための鍵は、プロジェクトの第 1 日目からガバナンス機能を確立することです。

  • ステップ 1: オペレーション化
    • 中核となるガバナンス機能を適切に設立し、顧客のビジネス・オペレーションをサポートします。
    • 実行しながら学習することが最善です。
    • 経験豊富な実務者を選任し、最上位の管理レベルで行動させます。
  • ステップ 2: プロフェッショナル化
    • 必要な構造やプロセス、方法、ツールなどを構築します。
    • ステップ 1 の経験を生かします。
    • アーキテクトやその方法の実務者に経験豊富な人を選任します。
  • ステップ 3: 安定化
    • 顧客の人員がオペレーションを行えるように教育訓練します。
    • オペレーション・モードからコーチング・モードに変更します。
    • コーチングの経験豊富なコンサルタントやスペシャリストを選任します。

図 4 は、こうしたステップを、さらに詳細に示したものです。

図 4. ガバナンス・モデルを開始する
ガバナンス・モデルを開始する

ヒントと助言

以下は、実際のプロジェクトから私達が学んだ現実的な教訓です。

  • SOA を利用しようとする全員と、定期的にコミュニケーションを図る (プロジェクト・ニュースレターや、あるいはミーティングなどによって)。SOA によって、文化的にも技術的にも変化が生まれるため、障壁が生じる可能性があり、コミュニケーションは必須である。
  • 決定や制約、仮定をそれぞれ文書化することによってバイイン (buy-in) を可能にし、また意志決定の透明性を確保する。
  • 鍵となる成果物と、必要なツール・セットやテンプレートを定義する。
  • ライフ・サイクル管理とバージョニングのために、実用的なツールをセットアップする。
  • 理論的根拠を持って決定事項を定義し、こうした決定事項を文書化し、関係者に徹底する。
  • すべての利害関係者、そして意志決定者からの支援を確保する。

まとめ

この記事では、なぜガバナンスが重要なのか、また SOA プロジェクトで何が必要かを示しました。そして私達の SOA ガバナンス・モデルの鍵となる要素について概要を説明しました。最初に、方向性を明確にするものとして SOA の原則を説明し、次に、SOA に対する一貫性と SOA 準拠を維持するための 1 つの鍵となるプロセスとして、アーキテクチャー管理プロセスを説明しました。そして、適切な意志決定と開発に必要な役割と責任を持つ組織構造の設立が必要なことを述べました。最後に、どのようにガバナンス・モデルを開始するかを説明し、私達がこれまでフィールドから学んだ教訓を元に、ヒントと助言を提供しました。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=242129
ArticleTitle=SOA プロジェクト・プランを改善する
publish-date=06162004