ガバナンスに関する記事は通常、企業がそのサービス指向アーキテクチャー (SOA) の実装において成熟する過程でガバナンスが果すさまざまな役割を説明しています。エンタープライズ・アーキテクチャー (EA) グループがガバナンスのポリシーと手順を開発し、最高情報責任者 (CIO) がガバナンスの執行委員会を編成するなか、アプリケーション開発グループは自分たちに及ぶ影響を懸念しはじめています。このガバナンスへの動きに対して、アプリケーション・グループが「エンタープライズ・アーキテクチャーの関係者は、我々の仕事や優先順位を理解していない。自分たちには、これに付き合っている時間も資金もない!」と反感を抱くことは珍しくありません。

この記事では、アプリケーション開発チームにとってのガバナンスの価値を明確にします。またアーキテクトにとっては、開発グループの見解を理解し、彼らの反感を和らげて支持を得るためには、どのようにメッセージを変えればいいかがわかるようになるはずです。

ガバナンスとは何か

ガバナンスの詳細については、最近の developerWorks の記事「Introduction to SOA governance」(「参考文献」にリンクを記載) で説明しています。この記事では、グループが合意して協力し合う方法を確立し、強化する手段としてガバナンスを定義しています。

ガバナンスは権限付与に関するものです。つまり、誰が、どのような IT の決定を下す権利を持つかを定義するためのポリシーおよびベスト・プラクティスのフレームワークとなります。また、これらの決定に責任を持つ人々の確保にも役立ちます。多くのアナリストがガバナンスと管理との明確な境界線を引いていますが、この違いを繰り返し表明することが重要です。

ガバナンスは特定の IT に関する決定を扱うことはなく、IT に関する決定能力を持つ人々の役割を決めるものです。一方、管理はガバナンスの指針によって強化され、特定の IT に関する決定を行います。

混乱してきましたか。それでは、SOA プロジェクトについて考えてみてください。SOA プロジェクトでのガバナンスは、従来のプロジェクトでの場合より複雑です。SOA プロジェクトでは、誰でも再使用したがる (そして、再使用が必要な) 小さな規模のサービスの数々を構築します。これらのサービスのライフ・サイクルを制御して最大限に再使用できるようにするため、ガバナンス・ポリシーが定義されます。誰がサービスを公開したか、サービスがどのように設計され構築されているか、誰が支払っているか、誰がセキュリティーを管理しているかなど、絶えずモニターしなければならないためです。

ガバナンスは、SOA プロジェクトの成功を握る鍵です。ガバナンスがなければ、SOA の価値を完全に理解することができないため、SOA を台無しにしてしまうことになるでしょう。

なぜガバナンスが必要なのか

ガバナンスの価値は、すぐには明らかにならないかもしれません。最初の SOA プロジェクトが完成するまでは、ガバナンス・ポリシーの重要性は実感しづらいものです。それでもなお、多数の SOA 実践者は、ガバナンス・ポリシーを前もって (極端に言えば、最初のプロジェクトでサービスを作成する以前に) 定義し始めておくことを強く推奨しています。

ガバナンスは、サービスの作成、サービスの検出、サービスの識別と再使用などに関わるルールおよびポリシーを決めることによって混乱をなくします。また、サービスの実行方法に関するサービス・レベルの合意 (SLA) が定義されるため、コンシューマーとプロバイダーの両方は何が制約され、何が期待できるかを認識できます。簡単に言うと、ガバナンスは、サービス品質に対する同じ見方をプロバイダーとコンシューマーに与えます。また、企業全体でのサービスを登録および検出するプロセスを定義して、冗長なサービスと重複した作業をなくしたり、あるいはその数を減らします。

ガバナンス・ポリシーは、標準プロセスに準拠し、そしてプロセスの各ステップで適切な文書が使用できることを確実にするものです。これにより、サーベインズ・オクスレイ法などの法規やその他の適合問題に対処することが可能になります。

ガバナンス構造を実装する際によくある誤りを防ぐ方法

アプリケーション開発チームと集権的 EA グループは、EA グループが独自にプロセス、手順、指針などを決めることについて衝突しがちです。多くの場合、EA グループはすべてのプロジェクト・チームと詳細を話し合わず、それぞれのチームに固有のプロジェクト要件、予定、そしてビジネス要因を理解しようとはしません。ここで鍵となる言葉は「すべて」です。EA グループは、以下のプロジェクト・グループと話し合えば、それで十分だと考えている場合があります。

• 最大規模のプロジェクトを扱っているグループ
• もっとも認知度の高いプロジェクトを扱っているグループ
• もっとも協力しやすいグループ

相談を受けないアプリケーション・チームは、疎外感を持ちます。そのようなグループはガバナンスの実装に対してもっとも強固に抵抗しがちで、その結果、SOA イニシアティブの全体的な成功が妨げられることになります。

EA グループにとってより効果的な戦術となるのは、小規模のプロジェクトから始めて、そのプロジェクトにおけるガバナンスの価値を実証することです。このようにすれば、ガバナンスの価値をまず短時間で示し、それからガバナンスのさまざまな利点を規模の大きいプロジェクトやその他すべてのグループに当てはめることができます。

1 つの推奨策としては、ポリシーの作成者と実践者を EA グループとは切り離し、EA グループをメンター (助言者) として機能させることです。EA グループはアプリケーション・グループに対し、より優れた設計指針を用いて標準的技法に従う方法を示し、ガバナンス・ポリシーについて説明します。EA グループは、アプリケーション・グループがすべてのガバナンス指針に適合していることを確認する「取締まり」機関になるべきではありません。ガバナンス・ポリシーの実施は、運営委員会、あるいはその役割を果す権限を明示的に付与されたガバナンス団体に任せるべきです。図 1 に、CIO のオフィスでそのような組織を構築する方法を大まかに示します。

SOA の成功と個々のプロジェクトの成功を確実にするには、図 1 に示したさまざまな役割が協力し合わなければなりません。ガバナンス審査委員会がポリシー定義グループとなり、エンタープライズ・アーキテクトがポリシー定義グループと業務別 IT グループと (アプリケーション・アーキテクトおよび開発者) の間の橋渡しとなります。これらのグループ間で絶え間なく主導権争いがあるようでは、SOA は成功しません。この記事の後半では、エンタープライズ・アーキテクト、アプリケーション・アーキテクト、そして開発者がプロジェクトで果すべき役割について説明します。

上に戻る

エンタープライズ・アーキテクトにとってのガバナンス

組織構造があるなしに関わらず、図 1 に示すようなガバナンスが組織に定義されているとします。エンタープライズ・アーキテクトは、ガバナンス・ポリシーの定義に関係している場合も、関係していない場合もあります。では、エンタープライズ・アーキテクトの役割とは何でしょう。

SOA ガバナンスは 1 つの社会変化です。エンタープライズ・アーキテクトには、取締り官としてではなく、教師や教育者としての役割があります。取締りは審査委員会の役目です。アプリケーション・チームに対するメンターとしての役割は、アプリケーション・チームにガバナンスの価値を示し、そして規定されたガバナンス・プロセス、ポリシー、ツールからどのような利益を享受できるか、ポリシーに従うために必要な追加作業がチームの生産性と事業価値の向上にどのように役立つかを示すことです。また、アプリケーション・チームが新しいポリシーに対して感じている苦痛を理解するように努め、彼らがガバナンスを自分たちのプロセスに組み込めるよう支援できる、そういった営業マンのようにならなければなりません。彼らの感情に同情すると同時に、やっかいな質問にも答えられるよう準備しなければなりません。それにはまず、ガバナンスの価値を十分に理解することが重要です。自分が納得していなければ、他人にその価値を認めさせることはできません。

エンタープライズ・アーキテクトのもう一つの仕事は、SOA ガバナンス・ポリシーを常に監視することです。どのポリシーが機能していて、どのポリシーが機能していないか、そして手を加える必要のあるポリシーを監視します。必要に応じてポリシーが改正または作成されるようにするには、審査委員会と連絡を取り合う必要があります。また、ポリシーが明確に文書化されていること、そしてアプリケーション・アーキテクトと開発者のコミュニティーが常に最新のポリシーに対応していることを確実にする必要もあります。

ガバナンス・プログラムの成功は、エンタープライズ・アーキテクトの肩にかかっています。アプリケーション・アーキテクト、そして開発者との対話がうまくいけば、プロジェクト全体が円滑に進むはずです。

上に戻る

アプリケーション・アーキテクトにとってのガバナンス

大抵のアプリケーション・アーキテクトがガバナンスに直面したときの最初の反応は、「独裁者に見張られている」というものです。これはもっともな反応ですが、アプリケーション・アーキテクトとして必要なのは、心を開いてガバナンスがもたらす価値を理解し、それを吸収することです。ガバナンスは、人とプロセスとの間のギャップを埋め、アプリケーションあるいはプロジェクトを超えた視点を持たせてくれます。アプリケーション・アーキテクトの役割は、すべてのガバナンス・ポリシーとプロセスに確実に準拠することだけではありません。これらのポリシーがどれくらい効果的あるいは効果的でないかを実証し、ポリシーが定着することによってもたらされる利益をチームが理解し、活用できるようにすることも、アプリケーション・アーキテクトの役割です。準備されたツールを使用して、より効果的な方法でアプリケーションまたはサービスを提供できるよう、確実にする必要があります。

ガバナンスによって、アプリケーション・アーキテクトはチームのために上記のプロセスやコントロールを準備する必要がなくなります。その結果、ビジネスやアーキテクチャーの問題に一層重点を絞って、プロジェクトにより適切なビジネス・ソリューションとサービスを特定できるようになります。アプリケーション・アーキテクトにとって重要なのは、連携と意思の疎通です。

ガバナンスがアプリケーション・アーキテクトの仕事を奪うことはないということを覚えておくことも重要です。アプリケーションまたはサービスを設計するというアーキテクトの役割はそのまま変わりません。ガバナンスは単に、設計を支援するための指針とパラメーターを提供するだけのものです。ガバナンスは、スケーラビリティーや可用性などの要件に関わる質問に答えます。

上に戻る

開発者にとってのガバナンス

開発者へのガバナンスの影響はもっとも小さいものです。普段、ガバナンスが開発者に関係することはありません。ガバナンスは技術よりも政策に関係します。政策を扱うのはアーキテクトやプロジェクト・マネージャーです。開発者の視点からすると、ガバナンス・ポリシーは、プロジェクトへの取り組み、そしてソリューションやサービスの実現をより効果的にするために必要なツール、ベスト・プラクティス、指針を提供するものです。これらのポリシーは、サービスの作成および管理方法の一貫性を確実にすることによって、開発者の作業負担を軽減するように作成されています。

ガバナンス・ポリシーは、サービスの作成方法、他の人が作成した利用可能なサービスを見つける方法、そしてサービスが準拠しなければならない SLA を示します。また、これらのことすべてを行うのに必要なツールも提供します。ガバナンスは SOA の実装に伴う予測不可能な面と不明点を減らします。ガバナンスが規定されることによって一連の準拠対象の標準およびポリシーが明確になるため、責任の追及が少なくなるはずです。

上に戻る

まとめ

SOA は、サービス・ベースまたはサービス指向の EA です。ガバナンスにまつわる問題は目新しいものではありません。IT 組織におけるガバナンスの最初の徴候は、EA グループまたはプロジェクト管理室 (PMO) の設立でした。独自の利益と課題を理由として設立されたものでしたが、IT 組織の SOA が成熟するにつれ、ガバナンスの重要性が高まっています。アーキテクトも開発者も IT チームのメンバーとして、ガバナンスを恐れるのではなく、作業負担を軽減するのに役立つガバナンスを容認するべきです。いくつかの不明な点を取り除き、SOA に関する基本的な疑問に答えてくれるガバナンスにより、生産性は一層向上するはずです。また、サーベインズ・オクスレイ法の準拠など、法的な要件に対応できるようにもなります。

ガバナンスと SOA にはチームワークが必要です。結局のところ、SOA および個別のプロジェクトを成功させるには、さまざまな関係者全員が協力して取り組まなければなりません。

参考文献

学ぶために

• developerWorks の Archtecture ゾーンには、EA に関する記事が用意されています。
  
  
• developerWorks のSOA and web services ゾーン には、これらのトピックに関するその他の記事も用意されています。
  
  
• IBM の正式な SOA ガバメントの定義、そしてその必要性については、Bobby Woolf 著「Introduction to SOA governance」を読んでください。
  
  
• Tilak Mitra 著「A case for SOA governance」では、ガバナンスの実装方法についてのロードマップを説明しています。
  
  
• Paul Krill 著「Dueling SOA governance initiatives questioned」を読んで、2 つの SOA ガバナンス標準の詳細について学んでください。
  
  
• Safari Bookshelf で関連する本を検索してください。
  
  

製品や技術を入手するために

• 次期開発プロジェクトの構築に、developerWorks から直接ダウンロードできるIBM の試用版ソフトウェアをご利用ください。
  
  

議論するために

• developerWorks blogs から、developerWorks コミュニティーに加わってください。
  
  

著者について

Kunal MittalはJava技術やJ2EE、Webサービス技術などを専門とするコンサルタントであり、これらの話題に関する何冊かの本を共同執筆しています。彼はソニー・ピクチャーズ・エンターテインメントのDomestic TV ITグループのディレクターとして、部門のアプリケーションに関する技術的なアーキテクチャーや管理に責任を持っています。詳しくは彼のWebサイトをご覧ください。

この記事を評価する

コメント

上に戻る

目次

• ガバナンスとは何か
• エンタープライズ・アーキテクトにとってのガバナンス
• アプリケーション・アーキテクトにとってのガバナンス
• 開発者にとってのガバナンス
• まとめ
• 参考文献
• 著者について
• コメント