SOAを超えて: 動的な業務アプリケーションのための新しいエンタープライズアーキテクチャフレームワーク

作者 Vasile Buciuman-Coman, Michael Chervenic, 翻訳者 白石 俊平 投稿日 2008年6月16日 午前1時50分

コミュニティ

SOA,

Architecture

トピック

Business Process Management,

SOAプラットフォーム,

エンタープライズアーキテクチャ

タグ

ビジネスアーキテクチャ

Part I - すべての要求が出そろい、最適な設計があるにもかかわらず、あなたのアーキテクチャは失敗する可能性が高い。それは何故か...

現在の経営管理スクールにおける教育は、企業をどう運営していくか、についてのものだ。そこには、会社をどうデザインするかに関する注意はほとんどない... 計画的な成長と安定を達成するために組織をデザインすることには、ほとんどの人が注意を払っておらず、深く考えてもいない。
        -Jay W. Forrester, Designing the Future (1998)

Introduction

Forresterのシニアアナリスト John R. Rymerによる“ダイナミックビジネスアプリケーションに絶対必要なもの”という記事では、今日のアプリケーションが持つ基本的な欠点を指摘しています。

今日のアプリケーションは、人々に対して「孤立した情報と機能を、人々のタスクやプロセスといかにして結びつけるか」を考え出すことを強制します。そして ITのプロが市場や戦略、規制、ビジネスモデルを継続的に発展させるために、アプリケーションに対して費やさねばならない予算はあまりに多いと言えます。

今後5年間におけるITの主要なゴールは、ビジネスとその作業に貢献し、発展させるような、新世代のエンタープライズソフトウェアを発明することなのは間違いありません。

Forresterは、この新世代のアプリを「ダイナミックビジネスアプリケーション」と呼んでおり、ビジネスプロセスと作業（人に対する設計）に対する密接な連携、そしてビジネスの変化に対する順応性（変化に対する構築）を強化するものです。現在のところ、ダイナミックビジネスアプリケーションを作るのに必要な設計上のプラクティスよりも、それに対する要求の方が明確になっています。しかし（設計上のプラクティスを満たすような）ツールは既に我々の手元にあり、SOA、BPM、ビジネスルールのパイオニアたち - 独立系のソフトウェアベンダも含め -はその実現方法を我々に見せてくれています。まさに今こそ、ダイナミックビジネスアプリケーションを始めるときです。

全二回からなるこの記事では、こうしたダイナミックビジネスアプリケーション（Dynamic Business Applications:DBAs）の開発についての全体的な眺望を、アーキテクチャと方法論の観点から見ていくことになります。我々のゴールは、「ビジネスの変化や、その他に必要とされる変更に対して、いかにして容易に適応できるアプリケーションを構築していくか」を導きだすことです。21世紀におけるエンタープライズアプリケーションは柔軟性にフォーカスしています。DBAsは、今後10年間のビジネスとITを、成功に導くために必要な突破口となります。

図1. 柔軟性と効率性 - 21世紀のエンタープライズアプリケーションの両輪　

「ダイナミック」とは何を意味しているか？

ソフトウェア開発においては、多くのフレームワークや製品がその（変化に対する）適応能力を誇示しています。あるソリューションがどれほどうまく変化に適応できるかを把握しようとする前に、システムがどのように変化するか - それこそがダイナミック（動的）と言うことです - についてのしっかりした定義が必要とされます。

初期のオブジェクト指向による手法では[1]、システム分析は中立でなければならず、現実世界に置ける二種類の要求をベースにしていました。:

• 現実世界のエンティティ?現実世界のエンティティとその関連についての情報を収集することで、技術的・主観的な視点ではなく、オブジェクティブな視点でシステム構造の分析を開始することができる
• 現実世界のイベント?現実世界のエンティティが持つ状態を変化させるイベントの発生のみが、システムの振る舞いを決定する

あらゆるシステム分析に対するこうしたコンテキストにおいては、私たちは常に、最も重要とされる一つもしくは少数のエンティティを識別することができます。各エンティティは、三つの関連した要素が組み合わされたものとなります: イベント、状態、ライフサイクルです。各イベントは状態の変化を表現し、ライフサイクルは全ての標準的なエンティティが持つ状態を順序づけたものによって表されます。しかし、通常フローの一部として状態変更を引き起こすイベントと、通常ではないフローの一部であるイベントの間には、明確な違いがあります。例えば、製品の注文が行われたときに発生しうるイベントの集合を考えてみましょう。このフローは支払い処理と注文配送を含みます。「顧客が注文を変更する」もしくは「業務上の理由で価格を変更する」と言ったとき、これらのアクションが通常フローの一部であるとは見なすことができず、これらがエンティティ（例えば注文）のライフサイクルと関連づけられないのです。中核となるエンティティのインスタンスライフサイクルは、通常のオペレーションによってシステムが最も行うであろう処理を単独で定義したものです。変更や中間的なステップなど、他のすべてのイベントタイプは（ライフサイクルとは）別個に処理されるのです。

このシナリオは、ほとんどの開発者に取っては親しみ深いものです。システムのモデルは、コアとなるエンティティ構造と、ライフサイクルを形作るイベントの集合とを持ちます。システムモデルは明確で、分析者とシステムの設計者の双方にとって理解し易いものです。有限状態機械やE-R図、エンティティの状態遷移図、データフローダイアグラムと言ったモデリングツールは、こうしたアプローチの手助けになるよう、およそ二十年の間磨きをかけられてきました。これが、数十億行のコードからなる複雑なシステム - 恐らく世界で最も先進的な戦闘機であるAirbus 380かF-22のような - を作る方法です。オブジェクトフロー図はイベントと状態遷移の両方をとらえるための基本的なモデルですが、同図を通じてエンティティのライフサイクルを視覚化することが、このモデルでは最も肝心です。このケースでは、いついかなるときでもシステム全体の状態を決定可能であることから、アーキテクチャは静的なものだと見なすことができます。

 

図2. イベントモデル、状態変化、そしてライフサイクルが、通常のオペレーションの中心をなす　

通常のイベント、状態、ライフサイクル、そして他の種類のイベントと通常のイベントの区別 - こうした要素間の関係が、ダイナミックなオペレーションに対して提案されたフレームワークを理解するための本質です。James MartinとJames Odellが、かなり昔に彼らの著作"Object-Oriented Analysis and Design"で述べたところによると、「アナリスト、設計者、そして実装者はすべて同じシステムモデルを使用すべきである」としています。アナリストはデータフロー図でものを考え、設計者は構造化されたチャートで、プログラマはJavaとSQLでものを考えます。データフローにおいては、アナリストはオブジェクトの種別とイベント、オブジェクトの状態変化を識別します。エンドユーザも同じように理解します。彼らはまた、オブジェクトの種別、イベント、オブジェクトの状態変化、ビジネスルール（イベントを引き起こし、それをコントロールする）についても考える必要があります。MartinとOdelll は、システム設計者にとってのオブジェクトフロー図の重要性を強調しました: "イベント・トリガ・条件・オペレーションと言う観点からプロセスを記述するためには、イベントのスキーマが用いられるのは適切です。しかし、巨大で複雑なプロセスをこの方法で表現するのは適切ではありません。システム化の領域は、イベントとトリガの関係で表すにはしばしば広大過ぎ、複雑過ぎます。これに加えて、恐らくもっと高いレベルでの理解が必要とされているのです。これは、計画の戦略的なレベルでは特に正しくなります。こうした状況下では、オブジェクトフロー図が便利です。オブジェクトフロー図（OFD）はデータフロー図（DFD）と同様です。なぜなら、オブジェクトフロー図は他のアクティビティに対しての、アクティビティのインターフェースを描くものだからです。DFDにおけるインターフェースは、データの受け渡しを行います。OO技術においては、データの受け渡しに限定されたくはありません。その代わりに、ダイアグラムはあるアクティビティから他のアクティビティに対して何らかの「もの」を渡す、と言うように表現する必要があります: それは注文、部品、最終生産物、デザイン、サービス、ハードウェア、ソフトウェア、もしくはデータかも知れません。簡潔に言うと、OFDはアクティビティと、アクティビティが生成してやり取りするオブジェクトを表すものなのです"

業務アナリストは、業務オペレーションに関連した情報の流れを捉えるため、「物と情報の流れ図」（Value Stream Mapping）を、OOの方法論につけ加えます。物と情報の流れ図を生み出したのはトヨタで、リーン生産方式と深く関係があります。アメリカ環境保護局は、物と情報の流れ図を"アクティビティと情報の流れの順序を理解するためのリーン・プロセスマッピング手法。製品の生産やサービスの提供のために用いられる"と定義しています。ここでのキーワードは"製品"と"サービス"です。それらは、大規模システム全体における正確な情報の流れを統合する役目を果たします。

オフジェクトフロー図と「物と情報の流れ図」が互いに一つとなれば、結果としてフレームワークの基盤となります。そのフレームワークは、エンタープライズシステムにおけるオペレーションのスコープ全体を表し、OOのコンセプトへと簡単に変換できます。    

しかし、多くのシステムは静的ではありません。なぜなら（エンティティの）関連とイベントの集合では、変化の最中にある振る舞いを捉えることはできないからです。実際には、システムが稼働するのは不可知の[2]未来においてであり、伝統的なツールではシステムのダイナミックスを捉えることができません。すべての業務アプリケーションと、現実世界のシステムのほとんどは、このカテゴリーに属します。こうしたシステムは、他の外部システムとの対話を基盤としていますが、三種類の変化を処理します:

• 通常のオペレーション - は、通常通りのイベントのシーケンスです。メインとなるエンティティや、エンティティのライフサイクルを形作ります。イベントが発生するごとにエンティティの状態は変化し、その処理を定義するのは通常簡単です。通常のオペレーションを構成する要素に、変化が生じることは考えられていません。例えば「顧客が製品を注文する」と言うプロセスを仮定します。すると、「注文を取る」「注文を受けて準備する」「注文された品を発送する」と言うプロセス全体において、価格や構成、発送タイプと言った属性は、変更されないことが期待されています。
• 内部的な変化 - 上で述べたように、コアとなるエンティティのライフサイクルの間は、変化が期待されない特定の要素が存在します。しかし実世界においては、これを常に満たすことはできません。経営上の意思決定によって、もしくは他の要因によって、コンテキストの構成要素を変更しなくてはならないかも知れません。私たちは、「内部的な変化」と呼んでいるのは、内部的なシステム属性の変化のことを指しています。
• 外部的、もしくは環境の変化 - 企業側がどれほど"彼ら自身の"顧客を信じていたくとも、顧客は常に心変わりする自由をいくらか残しています。これは、システムが外部のシステム - 顧客や供給者など - に対して常に"固定化された"規約を持つのとは大きく異なりいます。しかし、通常のオペレーションはほとんどが"固定化された"ルールの集合を中心に設計されます。私たちは、システムの外部で発生する変更のことを「外部的な変化」と呼びます。

現実世界のシステムをモデル化するのに成功すれば、これら三種類の変化は解決されるはずです。このモデルは、静的なアーキテクチャ向けのモデルに比べて桁外れに複雑です。通常のオペレーションの視点からは、内部のシステムと外部のシステムはどちらもメインの情報フローからは完全に独立して動いています。また内部のシステムと外部のシステムは、それぞれの情報フローによって表わされる独自のオペレーションを持ちます - 経営者は自身の意思決定サイクルを持ちますし、顧客は自由意志を持ちます。これら三つのシステムは、情報のフローと言う点から見ると、三つの並列宇宙の中で動いています。こうした三つの同期されていない情報フローを取り扱うための唯一の解決策は、各情報フローごとに分けられた完全なチェンジマネジメントを実装することです。この複雑な相互作用は、図3の動的オペレーション図で取り上げています。

動的なオペレーションの例として、観光船のオペレータが顧客に対して提供しているサービスを取り上げましょう。顧客は申し込みの際に、参加しようとしている観光サービスに関する意思決定を行います。しかし、船旅の前や最中に顧客が心変りをするかも知れません。それだけではなく、新しいチャンスを活かしたり、思いがけないイベントに対応するため、船旅のオペレータによってそれらのサービスを変更する必要があるかもしれません。今日のアプローチを基にして設計されたシステムでは、ほとんどの変更が多大な運営上のコストを引き起こします。ダイナミックビジネスアプリケーションのアーキテクチャに基づいて設計されたシステムは、顧客による変更、もしくは内部的な経営上の決定による変更は、通常のオペレーションと完全に統合された、二つの変更管理サブシステムによって処理されます。このコストはより低いと言うわけではありませんが、サービスの品質を向上することを助け、オペレーションの最適化による利益の向上がもたらされます。全体的に見て汎用性が向上するため、標準的なコンポーネントの再利用も可能です。最終的には、関連するすべてのプレーヤ - ビジネス、IT、そして顧客 - にとってのwin-win-win関係をもたらす状況となります。      

 

図3. 動的オペレーションは３つの側面を持ちます - 通常のイベント、内部的なコントロール、外部からのフィードバック

ダイナミックビジネスアプリケーションのゴールの一つは、ソフトウェアの設計と実装を簡単にし、全てのビジネスに共通の動的なシステムをサポートすることです。私たちの経験では、DBAを構築するための技術的なアプローチは、フレームワーク・ファーストな開発と新しいアプローチを組み合わせたときに最も効率的になります。   

大規模システムの設計は、フレームワーク・ファーストなアプローチが必要

ダイナミック業務アプリケーションの構築は見た目よりも難しいものです。工学技術 - ソフトウェア工学も含む - は、1世紀も前のフレームワーク・ファーストなアプローチを採用しています。橋や航空機、もしくはソフトウェアアプリケーションを設計する際には、同じアプローチが使用されます: 設計チームが要件を収集してから、システムの設計と構築を行うために、よくできたフレームワークの集合を適用します。既存のフレームワークは、橋やその他のシステムを設計するときには非常に有効であることが証明されてきました。しかし、そうしたアプローチが業務システムのソフトウェアに適用されてみると、ぴたりと当てはまることもあれば、そうでないときもありました。こうした二つのカテゴリのシステム（橋や飛行機と、ソフトウェアシステム）の間には、根本的な違いが存在します。橋や飛行機の場合、最終的な結果は常に静的なアーキテクチャを持つシステムです: 橋の上の車線を増やしたり、飛行機のスピードを増加させると言った変更が行われるときには、システム全体はスクラッチから再設計されるようなものです。不幸なことに、ソフトウェアはあまりにも頻繁に静的なアーキテクチャによって設計されてきました: オペレーションに対して予期しない変更が加えられるときはいつでも、すべてが停止され、新しい機能を持った新しいシステムに丸ごと置き換えられるのに近いです。ビジネスは継続的に変化する環境の中で行われ、そうした環境への依存はITシステムへの依存よりも強いため、こうした「ストップ・アンド・ゴー」と言うソリューションは受け入れられるものではありません。継続的なアップグレードと、新しいシステムをエンタープライズインフラに統合することのコストは、もはや維持できないレベルに到達しています。  

一つ目の問題は、我々の要求全てが、ビジネス上のステークホルダーによるインプットに依存することです。そうした要求を考慮した場合の、動的なオペレーションを満たすようなソフトウェアを設計するための、真の"フレームワーク・ファースト"なアプローチは存在しません。カーネギーメロン大学ソフトウェア工学研究所でさえも、利害関係者のインプットに基づいて作成されたシナリオによって、アーキテクチャが動かされるとしています: "ソフトウェア中心のシステムにおいては、ビジネス上のゴールを導出するのが、標準的なアーキテクチャ設計と分析方法にとって重要な部分です。ビジネスゴールは分析を行うためのエンジンであり、シナリオとして現実化します....理想の設計方法やプロセスは、多くの利害関係者と多くの影響力を考慮しなくてはなりません。"

開発者としては、正しいシナリオを持っているかどうか、システム要件を収集するときに正確な利害関係者がいるかどうかをどうやって知れば良いのでしょう？ビジネスの将来的な変更 - そうした変更は、どの利害関係者にとっても通常は知り得る物ではありません - をいかにして扱えば良いのでしょう？

" エンタープライズシステムの運用者と、設計者の間には根本的な違いがあります。これを説明するのに、飛行機の通常オペレーションにおいて最も重要な二人の人物を考えてみましょう。一人は飛行機の設計者で、一人はパイロットです。設計者は、普通のパイロットが操れるように飛行機を作成します。ここで「（飛行機の）マネージャ」と言えば、普通は設計者ではなく、パイロットの方を指すのではありませんか？そして、パイロットが飛行機を動かすのとちょうど同じように、経営者は組織を運営するのです。パイロットが成功するかどうかは、設計者がよくできた飛行機を作ったかどうかに依存しています。一方、経営者が運営する企業は、誰が設計したのでしょう？計画的な成長と安定を達成するために組織をデザインすることには、ほとんどの人が注意を払っておらず、深く考えてもいません。現在の経営管理スクールでは、企業のオペレータを教育しています。企業の設計については、ほとんど注意が払われていません。"

MITの教授で、システムダイナミックスの父であるJay Forresterによって数年前に作られたプレゼンテーション"Designing the Future"において、エンタープライズシステムの設計アプローチの基本的な限界として、この問題を指摘しました。:

Forrester の意見は、現在におけるエンタープライズアーキテクチャのアプローチを真っ向から否定するものです。私たちがエンタープライズシステムのアーキテクチャを設計するとき、認識の主な源として利害関係者と言うカテゴリを含めることは間違っています。彼らはエンタープライズシステムの"ユーザ"であり、"設計者"ではないのです。飛行機が設計されるとき、設計者はパイロットや乗客に対して、飛行機のアーキテクチャについて尋ねるようなことはしません。（これほど経営組織とシステムが密接である）にもかかわらず、エンタープライズシステムの設計をカリキュラムに含めているようなスクール、工学技術、MBAなどは存在していないのです。

では、エンタープライズアーキテクチャに話を戻すと、根本的な断絶が存在します。エンタープライズアーキテクチャの"ユーザ"は、ビジネス上の利害関係者であり、ビジネスのダイナミックスについてはよく知っていますが、工学的なアプローチについてはあまり知りません。エンタープライズシステムの設計者と開発者、つまりソフトウェアエンジニアは、静的なフレームワークには精通していますが、動的なフレームワークについてはよく知りません。実際には、ビジネスのダイナミックスを取り扱うようなフレームワークは存在していません。これはエンタープライズアーキテクチャフレームワークの観点から見ると、埋めるべき穴だと言えるでしょう。そうしたフレームワークは、いかにしてエンタープライズシステムが"設計される"かを記述するだけの物かも知れません。もしくは、開発ロードマップを定義したり、エンタープライズをサポートするためのシステム構築に用いられる、メインのコンポーネントを定義したりもするかもしれません。

図4. エンタープライズアーキテクチャにおけるビジネス vs 工学的アプローチ

私たちは情報システムのアーキテクチャを作成し、設計する方法を根本的に変える提案を行います。この方法では、ビジネスの利害関係者が主なインプットである必要はありません。私たちは、業務エンティティのライフサイクルを中心に据えたフレームワークを利用し、アーキテクチャへのインプットは、イベントモデルを主たる源泉とすることをおすすめします。業務シナリオは主要なドライバではなく、アーキテクチャをよくチューニングするためのエクササイズとして利用するのみです。

このフレームワーク・ファーストアプローチは、最初からビジネスのダイナミックスを考慮しており、後づけではありません。そのことが暗に意味しているのは、このアプローチに基づいて設計されたエンタープライズアプリケーションは、今日の方法論によって実装された静的な適応能力ではなく、動的な適応能力を持つと言うことです。これにより、ソフトウェアの開発と保守のコストを桁違いに低減し、既存システムの変更・保守と直接関連する、IT関連費用を70%以上削減します。

図5. ソフトウェアソリューションの開発におけるフレームワークベースのアプローチ

私たちが提案するアプローチにおいては、業務シナリオはメインのドライバではなく、アーキテクチャをよくチューニングするためのエクササイズとして利用するのみです。私たちが設計プロセスに直感や経験、スキルを注ぎ込んだ後に、コストのかかるエラーが発生するのを抑えられます。利害関係者のインプットによる要求の変更は、既存のソリューションフレームワークを用いて処理することができ、リスクと遅延を減らすことができます。

Standish の報告書によると、1000万ドル以上のプロジェクトが成功する確率はわずか3%であると言われています。業務コンサルタントであり、ハーバードビジネススクール教授であるAndrew MacAfeeは、コストのかかるテクノロジー - ERP、CRM、サプライチェーンマネジメント、Eコマース、その他のエンタープライズアプリケーションなど - をデプロイしている組織は、25%から70%の成功率を達成していることを示しました。McAfeeは、"直面した問題は個別に分かれた物ではなく、全ては同じ物事に対する例に過ぎません。これは基本的に、ITを使用している業務プロセスを変更するための努力なのです。"と結論づけています。最近こうしたパーセンテージは向上しましたが、ITは依然として、複雑なプロジェクトに対する明確なパスを欠いています。ビジネスの変化をITのインプリメンテーションに統合でき、ビジネスをテクノロジーへと明確に変換することのできるフレームワーク・ファーストアプローチは、プロジェクトが成功する確率を100%に近づけます。複雑なシステムのアーキテクチャを作成することが、数ヶ月や数年ではなく、数日で行えるようになるのです。

ダイナミックオペレーションのサーバアーキテクチャ - SOAを忘れてください。ようこそ、情報の組み立てラインへ

90 年代初頭、オブジェクト指向方法論に関するほとんどすべての書籍において、イベントが中心的な役割を果たしていました。WindowsのようなGUIベースのオペレーティングシステムの到来により、GUI開発のためのプラットフォームは、スタンドアローンアプリケーションを設計、構築するための複雑なイベントモデルに依存していました。しかしクライアント-サーバ環境においては、サーバサイドでのイベント処理は、いつもよりシンプルなモデルをベースとしていました。

J2EEや.NETによって、伝統的なクライアント-サーバアプリケーションがWebベースの技術で置き換えられ始めたとき、クライアントとサーバは根本的な変化を体験しました。クライアントサイドにおけるリッチなOSイベントモデルは、Webブラウザとプリミティブなスクリプト言語に置き換えられました。サーバサイドにおけるイベント処理は、WebページがWebブラウザに配布されるのと非常に良く似たアーキテクチャ - ステートレスで単調、そして静的 - に置き換えられました。

ステートフル、階層型、動的、そして分散されたアーキテクチャが要求される、現実世界の要件をエミュレートするには、データベースに強く依存した設計にならざるを得ません。データベースには、様々な種類の動的な情報が保存されることになります。しかし、本質的にリレーショナルデータベースが力を発揮するのは、変更が期待されていない、データ間の関連を保持するときです。動的で、分散され、階層構造を持ち、ステートフルな情報を保存するには、リレーショナルデータベース中心ではないインフラが要求されます。

Web ベースのテクノロジーは、現実世界のシステムをサポートするために、他の困難も生み出しています。J2EEアプリケーションサーバを分散環境で使用するとき、プログラミング言語としてJavaを利点が全くなくなってしまいます。Java仮想マシン向けのガベージコレクションは、複数のサーバインスタンス間でやり取りされているメモリ上のオブジェクトを、自動的に除去するようには設計されていません。この場合、アーキテクトと設計者はプログラミング言語の能力とは関係なく、オブジェクトのライフサイクル全体を管理しなければなりません。情報がデータベースに保存されているときも、同様の問題により、データの消去が非常に難しいタスクとなります。 

先に述べたように、通常のオペレーションを変化から一度分離すると、アーキテクチャは設計と実装においてイベントとライフサイクルにのみ依存するようにすることができます。ライフサイクル周りのシステム設計は、一世紀以上も行われてきました - それは組み立てラインと呼ばれるものです。

組み立てラインが20世紀はじめに作り出される前は、製造業は今日のサービス指向アーキテクチャ（SOA）が情報を処理していたのと多かれ少なかれ似たような方法をとっていました。SOAサービスに対する各呼び出しは、通常ステートレスな呼び出しとして扱われます。以前の呼び出し履歴を扱うには、システムの内部的な状態を処理する方法を、各サービスが完全に実装しなくてはなりません。要求が変化すると、ほとんど全てのサービスが個々の実装を変更するのです - それも、多大なコストを払い、かなりのコードを書き直すことによって。

図6. サーバアーキテクチャはイベントモデルに基づいている　      

我々が提案する情報アーキテクチャはイベントモデルとライフサイクルを中心としており、業務要件とシステムアーキテクチャを二種類の方法で変換するためのプラットフォームとして使用することができます。イベントモデルは、四つの基本的なモデルによって次のレベルに拡張されます: ステートフル、分散、階層型、そして動的です。基本的な要求やアーキテクチャ上のコンポーネントにおいては、これら五つのモデルを解釈するのは、ビジネスにとっても技術者にとっても簡単です。

• イベントモデル/ライフサイクル – これは、他のモデルが全て構築された後のモデルであり、ビジネスユーザにとっては価値の流れです。プロセスの順序は、製品/サービスのライフサイクルを反映しており、顧客にとっての価値を創造します。技術者にとっては、メインの業務エンティティの状態変更を反映しているのは、連続したイベントです。結果として、イベントモデルは粗結合な要素として働き、設計と実装をより簡単なタスクにします。イベントモデルは他にも重要な役割を演じます。なぜなら、他の四つのモデルはイベントモデルの周りに構築されるので、統合プラットフォームとしても動作するのです。実際のところ、イベントモデルは変化をインプリメントし、階層型で分散されたコンポーネントを作成するための唯一の方法です。
• ステートフルモデル – ビジネスユーザに取っては、このモデルはエンタープライズダッシュボードを表現しており、現在のオペレーションの全ての状態を捉えた物です。技術者にとって、それはシステム全体の状態を表しており、全てのライフサイクルインスタンスの現在の状態 - その変化も含め - をまとめた物です。
• 分散モデル – ビジネスユーザにとってのこのモデルは、メインの製品/サービスをそのライフサイクルの間コントロールしている、様々な組織を捉えたものです。技術者にとっては、メインとなるエンティティが分散モデル上でのみコントロールされると言うことになります。
• 階層型モデル – 全てのビジネスは、経営のレイヤを表現する階層構造を持ちます。全てのシステム設計は、コントロールの階層がアーキテクチャ上で反映されている必要があります。営業のバイスプレジデントがCEOに対して命令を行えないのと同様、低いランクのコンポーネントは、それより高いレベルのコンポーネントに対して" 命令（コマンド）"を送信することはできません。
• ダイナミックモデル – イベントモデルの次に重要なモデルです。ビジネスユーザはこのモデルを用いて、彼らのオペレーションが日々扱う必要のある全ての変化を捉えることができます。前述したように、二つの種類の変化が存在します。顧客からのインプットのように外部的なもの、経営上の決定のように内部的なものです。技術者に取っては、動的モデルは様々なイベント、ライフサイクル、変化の種類にマッチする、プラグインアーキテクチャへと変換されます。

これら五つのモデルは、設計の初期に利用されるだけではなく、システムのライフサイクル全てを通じ、要求が変化したときにも用いることができます。同時に、それらは適応力のあるビジネスシステム設計のための（これまで存在していなかった）フレームワークを形成します。五つのモデルは、エンタープライズアーキテクチャの主要なインプットとして、ユースケースが用いられる必要をなくします。橋や飛行機の設計で使用されていたのと同様の方法で、これらのモデルは工学的な問題の明確で包括的な集合へと変換することができるのです。     

図7. 適応力のあるアーキテクチャは、5つのモデルをベースとした情報アーキテクチャの結果として生まれる

5 つのモデルは、ダイナミックビジネスアプリケーション - 変化と情報の組み立てモデルを中心としています - の汎用アーキテクチャを定義するために使用されます。最も重要なサブシステムは: 静的モデル、チェンジマネジメント、組み立てのための仮想オブジェクト、そしてイベント処理です。さらに詳細なレベルにおいては、私たちはさらに二つのサブシステムを持ちます: システムコマンド＆コントロール、そして永続化です。

このアーキテクチャはまた、「トランザクショナルなワークフローのメタファに対する包括的なソリューション」と言う長きにわたって問題とされてきた事柄も解決します。この問題はJim Gray[3]によって数十年来提起されてきたものです。単一のイベント実行を中心として全ての設計が行われるため、"組み立てラインにおける次のステップに移動する"という処理を実装できるだけではなく、"前のステップに移動する"という実装も可能です。実装が必要とするのは、ユーザのインプットを基に"どの方向に進むか"を決めることであり、トランザクショナルなワークフローにおける「アンドゥ」は、同じアーキテクチャを使って実装することができます。

ダイナミックビジネスアプリケーションの鍵となる要素の一つはイベント処理です。適応力のあるシステムのための、新しい情報のセオリーを使えば、各イベントは一つの汎用的なコンポーネント構造を用いて"実行される"ようにできます。コンポーネントは宣言的なプログラミングモデルを用いてビジネスロジックを埋め込んだり、ワークフローエンジンやスケジューラ、ビジネスルールエンジンを呼び出します。こうした実装は適応力のあるシステムの開発を劇的にスピードアップさせるだけではなく、後に起こる変更の処理を非常に容易にし、複雑に統合されたシステムを保守する必要性を減らすことができます。

私たちはコントロール、オペレーション、イベント（オペレーション）を取り巻く環境、そしてイベントのライフサイクルを提供する、物理的なモデルの作成を提案します。ライフサイクルコントローラは、イベントのために情報の組み立てを管理します。チェンジマネジメントの機能は、内部的な変化や外部的な変化を、標準的なイベントモデルと個々のイベントへと変えます。

まとめ

私たちは、単調でステートレス、さらに静的なWebベースのクライアント-サーバソリューションが、どのようにしてITアーキテクチャと現実世界のビジネス（階層的でステートフル、動的、分散）の間を分断してきたかについて議論しました。また、伝統的な工学的アプローチではビジネスのダイナミックスをサポートできるような、適応力のあるシステムの開発の助けにならないことについても論じてきました。私たちがお見せしてきたのは、こうした問題の両方を解決するソリューションは、新しいモデル-ドリブンアーキテクチャアプローチにあると言うことです。

この記事の第二部では、ダイナミックビジネスアプリケーションを可能にするアーキテクチャについて述べるとともに、私たちのコンセプトを実際に実装するケーススタディについても述べたいと思います。

参考文献

Yourdon Systems Method – Model Driven Systems Development – Yourdon Press、1993年

Eric D. Beinhocker - "The Origin of Wealth", HBS Press Book、2006年 - マッキンゼー・アンド・カンパニーのシニアアドバイザーであるEric D. Beinhockerは、彼の新しい書籍「The Origin of Wealth（富の起源）」において、経済学の伝統的な視点は静的で均衡が保たれたシステムであったとし、多数の研究分野を巻き込んでそうした視点が根本的に見直されつつある、と論じています。この新しい見解は"複雑性の経済学"と呼ばれ、経済は高度に動的で、常に進化するシステムであり、全てを予測するのは不可能である、としています。ここでは彼の書籍を引用して、未来が不可知であるとき、企業はどのように戦略をたてられるのか、について扱います。

The Register社のMark WhitehornによるJim Grayへのインタビュー　- http://www.regdeveloper.co.uk/2006/05/30/jim_gray/

原文はこちらです：http://www.infoq.com/articles/dynamic-business-applications
（このArticleは2008年3月28日に原文が掲載されました）

• 次へ >