レベル: 中級 Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM
Gregory Hodgkinson (ghodgkinson@hotmail.com), IT Architect, 7irene (IBM Tier 1 Business Partner)
2007年 10月 23日 このシリーズ第 2 回目の今回は、アーキテクチャーを、ビジネス・レベルで詳細に調べます。そして SOA (Service-Oriented Architecture) ソリューションを構築する際に活用される、モデル駆動開発 (MDD: model-driven development) と、再利用可能なアセットのフレームワークとタイプについて学びます
なぜビジネス・アーキテクチャーが重要なのか
このシリーズの第 1 回では、ソフトウェア・アーキテクチャーの基本を学びました。今回は、特別なタイプのアーキテクチャー、つまりビジネス・アーキテクチャーについて見ていきます。まず IT レベルのアーキテクチャーに加えてビジネス・レベルのアーキテクチャーを持つことがなぜ重要なのかを説明し、さらに IBM® による、ビジネス・アーキテクチャーに関連する CBM (component business modeling) と呼ばれる手法を紹介します。
ビジネス・アーキテクチャーを定義する
ビジネス・アーキテクチャーは、TOGAF (The Open Group Architecture Framework) ではエンタープライズ・アーキテクチャーの半分を構成すると考えられており、残りの半分がソフトウェア・アーキテクチャーとして定義されています (後者は IT アーキテクチャーと呼ばれることもあり、データや、アプリケーション、技術要素などで構成されます。「参考文献」には、ウィキペディアの「ソフトウェア・アーキテクチャー」の項目へのリンクを挙げてあります)。
ビジネス・アーキテクチャーのコア・コンポーネントには下記が含まれます。
- 製品戦略
- ガバナンス
- 人間の組織
- ビジネス情報
- 重要なビジネス・プロセス
ソフトウェア・アーキテクチャーと同様、ビジネス・アーキテクチャーは定義されたアーキテクチャー原則に従い、そしてリファレンス・アーキテクチャーとアーキテクチャー・フレームワークを使用します (これを詳細に記述したカーネギー・メロン大学の論文を「参考文献」に挙げましたので、それを読んでください)。
注意: 次のセクションで説明するアクティビティーは、ビジネス戦略やビジネス・モデリングなど、他の領域で行うアクティビティーの一部と考えることもできます。
ビジネス・アーキテクチャーの重要性
ビジネス・アーキテクチャーが重要な理由として、下記を挙げることができます。
ビジネス・アーキテクチャーは、汎用的なビジネスのロードマップを提供します。ビジネス・アーキテクチャーは、ビジネスの原則や戦略、そしてゴールを入力とし、そしてビジネスのプロセスやビジネスを行う人々、あるいはビジネスの情報といった要素を定義するための仕組みです。ビジネス・アーキテクチャーによって、企業は自分たちの現在の位置を知ることができ、どこに進みたいのかを定義することができ、そしてもっと重要なこととして、そこに到達するためのロードマップを定義することができます。このように、IT に対するビジネス・アーキテクチャーの利点を考える以前でさえ、ビジネスにとってビジネス・アーキテクチャーは非常に重要なのです。
図 1. ビジネス・プロセスの変化のシーケンス
ビジネス・アーキテクチャーは、IT の応答性を改善します。ビジネスは変化を認識できる必要があり、変化に対して迅速に反応できる必要があります。通常、ビジネスの変化が認識されてから、それに伴って必要な IT の変更が、認識、評価され、実装されるまでには、受け入れがたいほどのタイムラグがあります。ビジネス・アーキテクチャーは、ビジネスと IT とを連関させることで、このタイムラグを減らす方法を提供しようとします。その結果、IBM On Demand Business で説明されているように、ビジネスの要求に対する企業の IT の応答性を高めることができます (詳細は「参考文献」を参照してください)。
ビジネス・アーキテクチャーは、ビジネスと IT システムとの連携を確実なものにします。最初にビジネス・アーキテクチャーを検討し、ソフトウェア・アーキテクチャーとの関連を記述することによって、両者の間のギャップをなくすことができます。言い換えれば、ソフトウェア・アーキテクチャーがビジネス要件を (戦略面、および戦術面の両面で) どのように扱うかを記述することによって、IT システムのすべての機能を逆にたどればビジネス要件に行き着くこと、そして IT システムによる自動化に対するビジネス要件がすべて満たされること、という 2 つを保証することができます。ビジネス・アーキテクチャーの重要な目的は、ソフトウェア・アーキテクチャーのビジネス価値を示すことです。
ビジネス・アーキテクチャーは、IT の柔軟性を改善します。ビジネス・アーキテクチャーの最も重要な要素として、ソフトウェア・アーキテクチャー (IT ビュー) の基礎をビジネス・アーキテクチャー (ビジネス・ビュー) に置くことにより、ビジネスの変化を抑制するのではなく、ビジネスの変化に適応しやすい IT システムを作成できることが挙げられるでしょう。そのため、どのソフトウェア・コンポーネントがビジネスの変化の影響を受けるのかを見やすくなるだけではなく、ビジネスの変更の結果による変化がソフトウェア・アーキテクチャー全体に与える影響を小さくすることができると考えられます (図 2)。
図 2. ビジネスと IT の間のマッピングによって柔軟性を向上させる
コンポーネント・ビジネス・モデリング
IBM の CBM (Component Business Model) は、組織がビジネスのコア・コンピテンシー (競合相手と差別化をするビジネス部分) に集中し、リソースの使用状況を監視し、そしてビジネスと IT との連携を強化するための戦略的な方法です。
SOA (Service-Oriented Architecture: サービス指向アーキテクチャー) にとって必須のものであるコンポーネント・ビジネス・モデリングは、ビジネスに連携したサービスに中心を置きます。コンポーネント・ビジネス・モデリングによって、企業を、さまざまなアカウンタビリティー・レベル (責任レベル) に属しているビジネス・コンポーネント (つまり機能領域) とビジネス・コンピテンシー (ビジネス・ドメイン) のマップとして分解することができます。各ビジネス・コンポーネントは、他のビジネス・コンポーネントにビジネス・サービスを提供したり、逆に他のビジネス・コンポーネントのビジネス・サービスを利用したりします (振る舞いの定義)。CBM は、ゴールや KPI (key performance indicator)、ビジネス・プロセスなどの戦略的なビジネス・アーキテクチャー要素に注目します。(CBM の詳細については「参考文献」を参照してください。) 図 3 は、これを視覚的に表現した例です。この図は DVD をレンタルする会社の CBM を示しています。
図 3. DVD をレンタルする会社の CBM マップ
すべてのモデルの利点を活用する: MDD の導入
MDD (model-driven development: モデル駆動開発) はモデル駆動工学 (MDE: model-driven engineering) としても知られており、モデルと変換をベースとするソフトウェア工学の方法です。
MDD は、メタデータやメタモデル、抽象化レベル、自動化、ビューポイント、パースペクティブ、UML (Unified Modeling Language) などのモデリング言語、そして EMF (Eclipse Modeling Framework) などのモデリング・フレームワークを利用することで、ソフトウェア開発プロセスへの自動化の適用を促進します。(これらの用語に関して詳しくは、「参考文献」に挙げた SOA 用語へのガイドを参照してください)。基本的な考え方として、MDD では、ソフトウェア開発ライフサイクル全体を通じて MDE の主要な成果物として、さまざまな抽象化レベルで一連のモデルの使い方を規定し、またこれらのモデルの正確さを利用して、上位レベルのモデルから下位レベルのモデルを生成する自動変換プロセスを実現しようとします。図 4 はこの変換を示しています。
Rational® Unified Process (RUP) はモデルを「ある特定のパースペクティブ (観点) から見たシステムの完全な記述を提供する、システムの抽象表現またはシミュレーション」と記述しています。
また Object Management Group による MDA (Model-Driven Architecture: モデル駆動アーキテクチャー) では、変換を「システムの 1 つのモデルから同じシステムの別のモデルに変えること」と定義しています。
図 4. MDD 変換の例
MDD の利点
ソフトウェア・アーキテクチャーとビジネス・アーキテクチャーがなぜ重要かを理解できたので、これらのアーキテクチャーに MDD を適用することによる他の利点を調べることにしましょう。
-
パースペクティブ。ソフトウェア・アーキテクトはさまざまなドメインやモデルを理解するために必要な見識の広さを持ち合わせているべきですが、他の大部分のロールはもっと特化されています。例えば、ビジネス・アナリストはビジネス・プロセスやユース・ケースを理解していますが、設計モデルは理解していません。モデルは、そのモデルを理解する一群のユーザーを対象にしており、またさまざまな人が理解できるように、同じシステムを明確に異なるモデルで表現することもできます。モデルは正確で完全でなければならず、またモデルによって抽象化を行える必要もあります。これが、グラフィカル・モデリングが推奨される理由です。グラフィカル・モデリングはソフトウェア・アーキテクチャーを設計するためのモデルで特に重要です。この場合には、UML と、特別な SOA UML プロファイルを使うことが推奨されます。
-
自動化と変換。MDD を使うことで、品質と生産性を高めることができます。これは、下位レベルの抽象化のモデルは上位レベルの抽象化のモデルから生成され、最終的にはコード生成まで行われるためです。例えば SOA のサービス・モデルは、UML の形式から WSDL (Web Services Definition Language) と XML Schema 定義に、そして Java™ などのコードへと変換することができます。下位レベルの抽象化から上位レベルの抽象化への逆変換もあります。例えば設計者は、コードから設計へと逆変換をすることによって、開発者のコードが設計者による設計をどの程度まで順守しているかを検証することができます。そうした変換機能を Rational Software Architect などの CAD (Computer-Assisted Design) ツールに含める必要があることに注意してください。ツールがこれをサポートできるのは、OMG の UML や MDA など、ツールが実装できるモデリング標準があるためです。
-
追跡可能性。追跡可能性は、下位レベルの抽象化から上位レベルの抽象化をたどり、上位レベルのモデルでの「要件」(必要事項) が下位レベルのモデルで対応されていることを確認します。例えば SOA では、概念的なサービスを、そのサービスが識別された要素 (ビジネス・アクティビティーなど) に至るまで「追跡する」こと、または設計に関する決定を、その決定の元となった要件に至るまで追跡ことが重要です。そうすることによって、要件 (つまり上位レベルの抽象化モデル) の変更が下位レベルの抽象化モデルすべてに与える影響を分析することもできます
既存のアセットを活用する
再利用は、ソフトウェア・アーキテクチャーにとっても SOA にとっても重要です。再利用にはさまざまな形式があります。例えばソフトウェア開発の成果物の (あらゆる抽象化レベルでの) 再利用や、ランタイム・サービスの再利用、またエクスペリエンスやベスト・プラクティスの再利用などがあります。
パターン
ここからはアーキテクチャーのスタイルと原則について詳細に説明します。もっと具体的には、まずアーキテクチャー・スタイルとしての SOA について説明し、このシリーズの今後の記事で、SOA の中心にあるアーキテクチャーの原則について説明します。それではまず、パターンを使った、エクスペリエンスとベスト・プラクティスの再利用について見ていきましょう。
パターンは、コンテキストでの特定の問題に対する実証されたソリューションであり、通常は、名前とコンテキスト、問題、そしてソリューションの記述によって指定されます。もっと重要なこととして、特定のプラットフォーム上でパターン仕様を実現するパターン実装を使ってパターンを自動化することができます。このため、パターンを使うことは非常に魅力的で強力なことです。Rational Software Architect は、自動化されたパターンと PBE (pattern-based engineering: パターンに基づく工学) を完全にサポートするツールの一例です。(「参考文献」に挙げた、IBM developerWorks へのリンクを見てください。developerWorks にはパターン・ソリューションに焦点を当てたエリアがあります。)
パターンはアーキテクチャーにとって重要であり、またさまざまな抽象化レベルすべてにわたって存在します。これはつまり、ビジネス・アーキテクチャーのパターンや上位レベルの設計パターン、下位レベルの設計パターン、実装パターンなどがあるということです。
こうしたあらゆるタイプのパターンを再利用することによって、高品質のソフトウェアの作成や、リスクの削減、生産性の向上、一貫性、そして企業全体にわたる相互運用性の向上などが実現されます。
上に挙げたパターンのタイプの中で、おそらくデザイン・パターンが最もよく知られているでしょう。例えば皆さんには GoF (Gang of Four) パターンがおなじみかもしれません。SOA に関しては、このシリーズの次回の記事で特別な一連のソフトウェア・アーキテクチャー・パターンについて説明する予定です。また CBM (先ほど触れました) は、一連の一般的な業界をカバーする独自のビジネス・アーキテクチャー・パターンのセットを持っています。
リファレンス・アーキテクチャー
リファレンス・アーキテクチャーは、特定のドメインに対して実証されたアーキテクチャーです (例えばデータ・センターやコール・センター用のリファレンス・アーキテクチャーや、テレコミュニケーション業界用のリファレンス・アーキテクチャーなど)。リファレンス・アーキテクチャーは、既に作成された完全なアーキテクチャーです。リファレンス・アーキテクチャーは、1 つあるいは複数のアーキテクチャー・スタイルを活用しており、通常はアーキテクチャー・パターンで構成されています。例えば、階層化アーキテクチャーや MVC (model view controller)、クライアント・サーバー、さらには SOA を考えてみてください。リファレンス・アーキテクチャーは、あるドメインの機能要件と非機能要件の両方に対応することでアーキテクチャー全体をカバーします。例えばテレコミュニケーション用のリファレンス・アーキテクチャーは、特にメッセージのペイロードに注目します。リファレンス・アーキテクチャーを使うことでアーキテクチャーに関する実証ずみのプラクティスを再利用できるため、アーキテクチャーの品質を改善することができます。リファレンス・アーキテクチャーの欠点は、完成されたものであるためサイズが非常に大きく、小規模のプロジェクトやシステムには適用できないかもしれないことです。
第 1 回では、SOA のリファレンス・アーキテクチャーである SOA Solution Stack を紹介しました。このスタックは、サービス指向のソリューションを正確に構築するために必要な階層やビルディング・ブロックを定義しています。
既存のソフトウェア・アセット
SOA が成功するための重要な要因として、アーキテクチャーの中にある既存のアセットを再利用できるかどうかを挙げることができます。ここで言う既存のアセットは、実動環境で実行している、サービス指向とは無縁の既存のソフトウェア (レガシー・アプリケーション) を指します (次のセクションでは既存のソフトウェア開発成果物について説明します)。SOA への変換プロジェクトによって会社は SOA への旅に出発することができ、そして次第に、サービスが中心的な役割を担う企業へと変化を遂げることができます。通常、こうしたプロジェクトでは、その企業の中核にある重要なソフトウェア・アセット (レガシー・アプリケーション) をサービス指向にするための作業を伴います。SOA への変換プロジェクトでは、変換を行う前に、そのアーキテクチャーの中で役割を果たす可能性のあるアセットを特定する必要があり、それが EAA (Existing Asset Analysis: 既存アセット分析) の間に行われます。既存のアセットには、IBM CICS® または IMS® のトランザクション、あるいは COBOL のプログラムが含まれるかもしれません。これらのアセットは長年にわたって実行されており、企業を差別化するための重要な一部分でもあります。こうしたアセットを SOA の中で使用し、活用する必要があります。例えば、こうしたアセットをアーキテクチャーの中にサービスとして公開する (ラップする) ことができます。ある特定の SOA プロジェクトにとって意味を持つアセットを表面化させる、ボトムアップとも呼ばれる分析レベルの手法もあります。例えば SOA プロジェクトが保険請求のビジネス・プロセスに関するものだとすると、請求データに関係するプログラムやトランザクションがおそらく存在し、それを活用できるはずです。IBM WebSphere® Studio Asset Analyzer などの分析ツールが、まさにこうした領域で、膨大な実動環境の中から必要な情報を表面化させるために重要な役割を果たせることに注意してください。また、既存のアセットを盲目的にサービスとして公開してはならないこと、そしてサービスを特定する際には RUP の SOMA (Service-Oriented Modeling and Architecture) など、実証ずみのプロセスに従う必要があることにも注意してください。
ソフトウェア・アセットの管理とアセット・ベースの開発
ABD (asset-based development: アセット・ベースの開発) は大きな概念であり、ABD のみを取り上げた記事をシリーズで書けるほどです。しかしこのセクションでは、ABD の背景にある概念を紹介するだけにとどめます。
ABD は、ソフトウェア・アセットを使ってソリューションを構築するソフトウェア工学の方法です。ここで言うアセットは上記で定義した既存のアセットではなく、任意のレベルの抽象化における任意のタイプのソフトウェア開発アセットであり、設計モデルやパターン、そしてコード実装などが含まれます。ABD に関しては長年にわたって議論されており、またコンサルティング会社は労働ベースのモデルではなくアセット・ベースのモデルを採用して成功することを夢見ていますが、ABD を採用して成功している組織はごくわずかしかありません。これは単に文化によるものではなく、他の人の成果を再利用するよりもゼロから作成することを好む人が多いためでもありません。むしろ、ガバナンスとプラットフォームに対するサポートがないためなのです。幸い IBM のような会社は、IBM Rational Asset Manager や、IBM Rational の Asset Governance プロセスおよび Asset-Based Development プロセスといった新しい製品やプロセスによって、この問題に取り組んでいます。アセットによって、本当に開発が必要なものだけを開発し、他は実証ずみの要素を可能な限り再利用することができます。
ABD によって、組織全体にわたる一貫性を実現することができます (同じアセットを使用するため、同じ要件であれば同じ設計判断がなされます)。ABD と MDD は相互に排他的なものではありません。実際はまったくその逆です。他の人が再利用できるように、モデルをアセットとしてパッケージ化することは非常に強力なのです。(Rational Asset Manager 製品に関する詳しい情報は「参考文献」を参照してください。)
サービス・レジストリーとサービス・リポジトリー
SOA 環境での 2 つの重要コンポーネントである、サービス・レジストリーとサービス・リポジトリーは、サービスのライフサイクル全体をとおしてサービスをサポートすることにより、導入済みのガバナンスを実行します。
この両コンポーネントの重要な特徴のひとつに、これらのコンポーネントによってサービスの再利用が可能になることが挙げられます。ほとんどの会社では、まだ SOA プロジェクトを数多く経験しているわけではありませんが、SOA の見所は、以前に開発されたサービスが将来のプロジェクトで再利用された時に初めて実現されます。アプリケーションに将来を見越したアーキテクチャー・スタイルを適用すると、これらのサービスを確実に再利用するために多くの努力が注がれることになるでしょう。
ソフトウェアのアーキテクトや設計者、そして実装者は、SOA のソリューションを構築、または設計、実装する際には (開発時に) サービス・レジストリーを調べることを検討する必要があります。サービス・レジストリーは、サービスの仕様や説明、使用ポリシー、依存関係、相互作用などの情報を提供します。もし (まだ存在していないために) サービスを開発する必要があるなら、ソフトウェア・アーキテクトは、その企業のサービス・レジストリーにそのサービスを提出 (公開) することを検討する必要があります。またサービス指向のアーキテクチャーでは、実行時にサービス・レジストリーとサービス・リポジトリーを利用します。これは、サービス・レジストリーとサービス・リポジトリーによって、例えばエンドポイントの選択や可用性管理、そしてポリシーの実施などに関して効率的で動的なサービスのやり取りをサポートできるためです。またリポジトリーはサービスのバージョン管理を補助する管理コンポーネントも提供しているため、サービスが最適状態で使用され、サービス・レベル・アグリーメントを満たすことが保証されます。(IBM WebSphere Service Registry and Repository に関する詳細の情報は「参考文献」を参照してください。)
まとめ
この記事では、ビジネス・アーキテクチャーとモデル駆動開発、そして再利用可能なアセットについて学びました。そしてビジネス・アーキテクチャーがロードマップを提供し、IT の応答性と柔軟性を改善すること、そして IT システムをビジネスに連携させる上で役立つことを理解しました。また、IBM のコンポーネント・ビジネス・モデリング (CBM) の手法と、モデル駆動開発とその利点について、パースペクティブや自動化、追跡可能性の観点から学びました。そして最後に、SOA とアーキテクチャーの意味合いにおける再利用可能なアセットについて、パターンやリファレンス・アーキテクチャー、既存のソフトウェア・アセット、そしてアセットとサービス・レジストリーを含めて学びました。
参考文献 学ぶために
製品や技術を入手するために
-
RUP SOMA Plug-In をダウンロードしてください。
- Rational には他にも試用版のダウンロードがありますのでご利用ください。
-
IBM 製品の試用版をダウンロードし、DB2® や Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。
議論するために
著者について  | 
| | Bertrand Portier は IBM Software Group のSOA Advanced Technologies の IT アーキテクトです。彼は戦略的な SOA 変換プロジェクトの分野での経験を生かしながら IBM Software Group の開発チームと協力して業務を行っています。彼は J2EE や Web サービスに携わってきており、現在は ABD や MDD に深く関わっています。 |
| 
| | Gregory Hodgkinson は、イギリスにおける IBM の Tier 1 ビジネス・パートナーである 7irene 社 (www.7irene.com) の設立者であり、取締役であり、そして SOA のリーダーです。彼はソフトウェア・アーキテクチャーに 10 年の経験があり、最初は CBD (component-based development) を専門にしていましたが、やがてシームレスに SOA (service-oriented architecture) に移行しました。その他の専門領域はソフトウェア開発プロセスであり、彼は 7irene や IBM の顧客がRUP フレームワーク・ベースのアジャイル開発プロセスと SOA の方法を採用する上での協力を行っています。彼は精力的に実務を行う技術者であり、FTSE 100 (ロンドン証券取引所株価指数に算入の 100 社) の何社かのサービス・アーキテクチャーを担当しています。彼はアジャイル SOA のプロセスや方法について、IBM (Rational と WebSphere) やその他のイベントで講演を行っています。また SOA ソリューションに関する Redbook も共同執筆しています。 |
記事の評価
| 
