アーキテクチャ・ジャーナル SOAのためのエンタープライズ アーキテクチャ戦略 Hatay Tuna 2010/08/04

Page1 Page2 Page3

本コーナーは、マイクロソフトが季刊で発行する無料の技術論文誌『アーキテクチャジャーナル』の中から主要な記事をInsider.NET編集部が選び、マイクロソフトの許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『アーキテクチャ ジャーナル』の詳細は「目次情報ページ」もしくはマイクロソフトのサイトをご覧ください。 記事の著作権はマイクロソフトに帰属する。 ©2008-2010 Microsoft Corporation. All rights reserved.

ご注意：本記事は、雑誌の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

■概要

　この記事では、CIO、CTO、アーキテクト、および IT 部門のリーダーを対象に、サービス指向アーキテクチャ (SOA) によって組織の IT アーキテクチャやソリューションを発展させ、絶えず変化し続けるビジネスのニーズや需要に対応するために実践可能な主要な概念や手法について説明します。SOA は、既に成功を収めた実績のある手法や実践に基づいて構築された堅牢なアーキテクチャ基盤であり、効果的なサービス指向を漸進的、反復的に実装することができます。ビジネスの優先度や連携に重点を置くことによって、IT 資産の価値を最大限に活用しながら、予測や評価が可能なビジネス バリューを創出できます。

■はじめに

• SOA に着手する領域と方法
• ビジネスのニーズや優先順位にサービスを合わせる方法
• サービスを識別し、その適用範囲を設定する方法
• 敏捷性を実現し、サービスを通じて革新する方法
• SOA を実装する方法

　これらは、SOA を通じて、技術革新、成長、収益、運用コストなど、さまざまなビジネス バリューの実現を目指す組織が今日直面している基本的な課題です。

　取り決めに対する認識の食い違いや、同じ組織であっても実装へのアプローチが部門間で異なっている場合、また、製品やテクノロジに対して非現実的な期待を抱くことは、企業の要望を実現していく過程でさまざまな障害となります。

　この記事では、企業がこれらの課題を克服し、SOA を実装する過程でより良い結果を実現していくために必要な、アーキテクトが即座に実践できる主要な “概念”、“原則”、“手法” を紹介し、解説していきます。

　この記事で示す概念や手法は、テクノロジに依存しない、一般的に利用されている方法論と両立できるものです。また、オンプレミス、クラウド、またはその両方でサービス指向を実装するために、既存のケイパビリティを補完するよう設計されています。ここで取り上げる例は、こうした概念や手法の実装に成功した、世界的な就職斡旋コンサルタント企業の最近の導入事例から選んだものです。

■概念

　SOA は “目的地” ではありません。SOA は組織が購入/展開できる運用環境ではなく、また、それを購入/展開すれば、何かすばらしいテクノロジによって魔法のように変化に対応でき、予想だにしなかった価値が生まれるというものでもありません。

　SOA とは、組織が予測可能な “目的地” に到達するために “道順” と “手段” に従って実践する必要がある、漸進的で反復的な “旅” なのです。

　業界は “手段” の定義に関しては、問題なくこなしてきました。標準ベースの Web サービス、ミドルウェア製品の進歩、および統合パターンなどです。

　その一方で、主にソフトウェア ベンダーに多いボトムアップやテクノロジ中心の観点にとらわれるあまり、SOA を採用しようとする組織は、“道順”(SOA の実装において組織を導く手法や実践) が適切に定義されていないか、まったく存在しない暗闇に取り残されています。

　次に示すのは、組織が、直面している主な課題を克服し、SOA を成功に導く堅牢なエンタープライズ アーキテクチャ (EA) 戦略の構築を可能にする “道順” として取り入れることができる主な基本概念です。

1. “不安定要素” から “安定要素” への抽象化
2. “サービス” 内での “不安定要素” のカプセル化
3. “サービス” による “変更” の管理 (旅)

■不安定要素から安定要素への抽象化

　SOA に着手するのは簡単ではありません。人、IT システム、ビジネス プロセスが密接に結びついている Web という環境では、SOA の実装にどこからどのように着手すべきかを判断することは難しく、また、こうした密接な結びつきが、進化や発展を求める組織の変革を困難にする原因となっています。

　したがって、アーキテクトは、問題領域に対する新たな考え方や捉え方を身に付け、サービス指向によって解決できるよう、問題を安定的な処理が可能な小さな単位に切り分けられるようにする必要があります。

　ここでは、就職斡旋業界における次のシナリオを例に考えていきましょう。

“就職斡旋コンサルタントが、応募者に合格通知の電子メール メッセージを送信する。”

　このような要件の基本的な問題は、“何を行わなければならないか” と “どのように行わなければならないか” が区別されていないという点にあります。つまり、問題とソリューションが密接に結びついてしまっているのです。

　アーキテクトは、これまで何度となくこのような形で問題を提示され、低コストで迅速に変更可能なソリューションを開発することを求められてきました。

　ケイパビリティ指向の考え方を用いれば、この問題を解決できます。

●ケイパビリティは抽象的である

　“ケイパビリティ” とは、個々のビジネス機能が実行する内容を抽象的に示したものであり、機能の “何を” 行うかという部分を定義し、“どのように” という部分は考慮しません。ケイパビリティでは、混乱のもととなる次のような詳細情報が隠蔽されます。

• ケイパビリティを実行する “人”。
• ケイパビリティをサポートする “情報技術 (IT)”。
• ケイパビリティを実行するための“プロセス”。

　“抽象化” によって、組織やアーキテクトは問題に集中できるようになり、人、IT システム、ビジネス プロセス面のソリューションに重点を置くことができます。

　図 1 は、問題に対するケイパビリティ指向の考え方を示しています。

図 1: ケイパビリティの視点

●ケイパビリティは安定している

　ビジネス プロセス、組織構造、IT システムと比較して、ケイパビリティは変化という点で非常に安定しています。人、IT、プロセスは通常、非常に不安定であり、時間と共に変化します。一方、ケイパビリティは抽象的な視点を表すものなので、何世紀もの間変化しません。

　先ほどのシナリオに戻りましょう。

“就職斡旋コンサルタントが、応募者に合格通知の電子メール メッセージを送信する。”

　電子メール メッセージを送信することは、このシナリオを実行するための 1 つの方法に過ぎません。このシナリオを “どのように” 行うかという部分は、組織によって異なります。しかし、“何を” 行うかは何世紀もの間変化していません。これまでも、100 年後も、応募者に対して求職の結果を通知するということは変わりません。しかし、それをどのように行うかは変化する可能性があり、その可能性は非常に高いと言えます。

　たとえば、図 2 に示すように、コンサルタントは、録音された自動音声メッセージを応募者の電話に残す方法や、SMS メッセージを送信する方法を選択できます。

図 2: 変化や発展は必ず起こる

　こうした発展という性質を考慮すると、ケイパビリティ指向の考え方は、変化に対応するサービス指向の理想的な基盤となります。

　SOA では、変化への対応が約束されます。

●ケイパビリティには明確な境界がある

　抽象的で安定しているという性質の結果として、ケイパビリティは境界が明確であり、アーキテクトはソリューションの実装のスコープを定義しやすくなります。このような境界があることによって、ケイパビリティと依存関係との関連性や、実装間の関連性を理解することが容易になります。

　“ケイパビリティ アーキテクチャ” は、“ビジネス ケイパビリティ アーキテクチャ” または “ビジネス アーキテクチャ” とも呼ばれ、ビジネス モデルを分解して提示したものであり、“ケイパビリティ” で構成される “ケイパビリティ マップ” として表されます。ケイパビリティ マップは、詳細を異なる粒度で表し、“レベル” とも呼ばれます。

　ケイパビリティ マップの例として、次のような就職斡旋企業の場合を見てみましょう。

• 製品/サービスを開発する
• 需要を創出する
• 営業
• 新しい仕事を創出する
• ...
• マーケティング
• ...
• 製品/サービスを提供する
• 採用
• 新しい応募者を募集する
• 応募を管理する
• 応募書類を提出する
• 応募書類を処理する
• 履歴書および経歴書を分析する
• 応募者に通知する
• 応募者に応募の受付を通知する
• 応募者に応募の却下を通知する
• 応募者を評価する
• 選抜応募者リストを管理する
• ...
• 事業を計画および管理する
• 財務管理
• 請求処理をする
• ...
• 共同作業を管理する

　ケイパビリティ アーキテクチャには、アーキテクトにとって興味深い次の 3 つの属性があります。

• 変更が予想されるソリューションの問題点をソリューションから抽象化する。
• 明確な境界を持つ複数の粒度レベルに問題を分解する。
• ビジネス チームと IT チームで共有される共通の言語や語彙を確立する。

●ケイパビリティ マップの構築

　アーキテクトにとっての最初の仕事は、この考え方を受け入れ、ビジネス部門の代表者との協議 (ワークショップや面接など) を主導、促進して、ビジネスの “方法” ではなく “内容” を表すマップを作成することです。

　ケイパビリティ マップの各レベルでは、同じ粒度レベルのケイパビリティを表示し、組織が特定のケイパビリティの詳細をドリルダウンしたり収集できるようにすることが重要です。たとえば、組織で自動化の機会を模索している場合や、特定のケイパビリティが適切に機能していない理由を調査している場合などに重要になります。つまり、組織の期待どおりになっていない理由が、人、IT、プロセスのいずれにあるかを把握できるようにするということです。

●優先順位付けとコンテキスト化

　ケイパビリティ マップによって、組織はビジネスに対する重要性に基づいて、ケイパビリティに対して目的に沿った分析と評価を事前に行い、注意が必要なケイパビリティとそうでないケイパビリティを識別し、優先順位を付けることができます。

　サンプルを見てみましょう。組織で最初に解決する必要がある、パフォーマンスの低いケイパビリティはどちらでしょうか。

　答えは、多くの場合 “応募者と仕事の対応付け” と考えられます。実際、このケイパビリティは、“従業員への支払い” と比較した場合、ビジネスに対する価値は高く、市場では競争力のある差別化要因となります。

　組織では、このようにして、ビジネスのニーズや優先順位に合わせて、SOA 構想を実現すべき領域を把握することができます。

　ケイパビリティの属性を分析的に評価することによって、即座に次のようなメリットを得られます。

• より正確、合理的で正当な意思決定が可能になり、問題の優先順位付けに役立てることができる。
• 発生している問題を的確に理解できるコンテキスト情報 (ビジネスにとって何が重要か、パフォーマンスが低いのは何か、それはなぜかなど) をアーキテクトに提供できる。

　何を行うかという “内容” は非常に “安定” しており、どのように行うかという “方法” は “不安定” であるという基本原則を思い出してください。次に行うのは、“方法” を “サービス” で隠蔽することです。

INDEX
	［アーキテクチャ・ジャーナル］
	SOAのためのエンタープライズ アーキテクチャ戦略
	1．不安定要素から安定要素への抽象化
	2．サービス内での不安定要素のカプセル化
	3．サービスを通じた変更の管理

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）