(57)【要約】システム設計者が情報システムのモデルベースのアーキテクチャを設計するための自動システムおよび方法が提供される。提案されたシステムアーキテクチャの初期モデルから、性能メトリクス（ｍｅｔｒｉｃｓ：測定基準）がモデル化され、ユーザー定義されたビジネス要求セットと比較される。許容外のメトリクスに対しては、システムアーキテクチャの修正が決定され、システム設計者に提案される。容認されると、システムアーキテクチャのモデルは自動的に修正され、再度モデル化される。モデル化された性能メトリクスがビジネス要求を満たせば、そのモデルから得られるシステムアーキテクチャの詳細な記述を、別の開発ステージに出力する。【特許請求の範囲】
【請求項１】
モデルベースのシステムアーキテクチャを設計するプロセスであって、
複数のビジネスプロセスを記述し、かつ各ビジネスプロセスに対してビジネス要求セットを定義するビジネスプロセスデザインを提供するステップと、
前記ビジネスプロセスデザインをサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築するステップであって、該数学モデルの層がビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとからなる、ステップと、
前記システムアーキテクチャのマルチレイヤモデルの各レイヤに対して性能メトリクスをモデル化するステップと、
前記モデル化された性能メトリクスを各ビジネスプロセスの前記ビジネス要求セットと比較して、ビジネスプロセスに対して定義された前記ビジネス要求セットを満たさない１つまたは複数のビジネスプロセスの許容外の性能メトリクスの表示を生成するステップと、
前記システムアーキテクチャに対する修正を決定するステップと、を含むプロセス。
【請求項２】
請求項１において、さらに
前記システムアーキテクチャに対して修正を提案するステップと、
前記提案された修正で前記システムアーキテクチャのモデルの各レイヤに対して更新された性能メトリクスをモデル化するステップと、
前記更新された性能メトリクスを各ビジネスプロセスに対して定義された前記ビジネス要求セットと比較するステップと、
前記更新された性能メトリクスが前記ビジネス要求セットを満たす場合、前記システムアーキテクチャの記述を出力するステップと、を含むプロセス。
【請求項３】
請求項１において、システムアーキテクチャに対する修正を決定する前記ステップが、さらに、
許容外の性能メトリクスを有する前記１つまたは複数のビジネスプロセスをサポートする、前記アプリケーションレイヤおよびテクノロジーレイヤ内のコンポーネントモデルを識別するステップと、
許容外の性能メトリクスを有する１つまたは複数のサポートコンポーネントモデルを識別するのに、該サポートコンポーネントモデルの前記性能メトリクスを評価するステップと、
データ記憶装置を検索して修正を行うことにより、前記１つまたは複数のサポートコンポーネントモデルの許容外の性能メトリクスを改良するステップと、を含むプロセス。
【請求項４】
請求項３において、前記１つまたは複数のサポートコンポーネントモデルの許容外の性能メトリクスを改良する修正が、該１つまたは複数のサポートコンポーネントモデルを、前記データ記憶装置からの別のコンポーネントモデルと置き換えることを含むプロセス。
【請求項５】
請求項３において、さらに、前記アプリケーションレイヤまたはテクノロジーレイヤ内のサポートコンポーネントモデルが許容外の性能メトリクスを持たない場合、前記ビジネスプロセスデザインを修正するように提案することを含むプロセス。
【請求項６】
請求項１において、前記システムアーキテクチャのマルチレイヤ数学モデルを構築するステップが、さらに、
各ビジネスプロセスを前記アプリケーションレイヤ内のアプリケーションコンポーネントモデルにマッピングするステップを含み、各アプリケーションコンポーネントモデルが、前記アプリケーションコンポーネントモデルをサポートするアプリケーションレイヤおよびテクノロジーレイヤ内の１つまたは複数のコンポーネントモデルにリンクされているプロセス。
【請求項７】
請求項６において、前記アプリケーションレイヤはさらに、テクノロジーバスを備えており、このテクノロジーバスが、前記アプリケーションレイヤおよびテクノロジーレイヤにおいてモデル化されたコンポーネント間のデータアクセスまたはテクノロジーサービスに対して抽象インタフェースをモデル化するプロセス。
【請求項８】
請求項６において、前記アプリケーションレイヤはさらに、アプリケーションバスを備えており、このアプリケーションバスが、該アプリケーションレイヤ内のアプリケーションコンポーネントモデル間の通信、分散および管理インタフェースをモデル化するプロセス。
【請求項９】
請求項６において、前記アプリケーションレイヤ内のアプリケーションコンポーネントモデルは、ビジネスアプリケーションレイヤおよびアプリケーションエンジンレイヤに細分されており、前記ビジネスアプリケーションレイヤが、実時間または適時処理を提供するアプリケーションコンポーネントのモデルを備え、前記アプリケーションエンジンレイヤが、延期可能な処理を提供し、かつ該ビジネスアプリケーションレイヤ内の１つまたは複数のアプリケーションコンポーネントをサポートするアプリケーションコンポーネントのモデルを備えるプロセス。
【請求項１０】
請求項６において、ビジネスプロセスをサポートするコンポーネントモデルの任意の組み合わせを置き換えることにより、ビジネスプロセスの許容外の性能マトリックを改良するプロセス。
【請求項１１】
モデルベースのシステムアーキテクチャを設計するシステムであって、
複数のビジネスプロセスを記述し、かつ各ビジネスプロセスに対してビジネス要求セットを定義するビジネスプロセスデザインと、
前記ビジネスプロセスデザインに応答し、かつビジネスプロセスデザインをサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築するアーキテクチャ構築モジュールであって、マルチレイヤ数学モデルのレイヤが、ビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとを含むアーキテクチャ構築モジュールと、
前記アーキテクチャ構築モジュールに結合され、かつ前記システムアーキテクチャのマルチレイヤモデルの各レイヤに対して性能メトリクスをモデル化する性能モデル化モジュールと、
前記モデル化された性能メトリクスおよびビジネスプロセスデザインを受け取るように結合されており、該モデル化された性能メトリクスを各ビジネスプロセスのビジネス要求セットと比較し、ビジネス要求セットを満たさない１つまたは複数のビジネスプロセスの許容外の性能メトリクスを決定する比較モジュールと、
前記比較モジュールにより決定された許容外の性能メトリクスを改良するのに、前記システムアーキテクチャに対する修正を決定するルールベースの修正エンジンと、
前記ルールベースのエンジンとアーキテクチャ構築モジュールとの間に結合され、かつシステムアーキテクチャのモデルに対して決定された修正を提案する出力モジュールとを含むシステム。
【請求項１２】
請求項１１において、
前記性能モデル化モジュールはさらに、前記提案された修正により、システムアーキテクチャのモデルの各レイヤに対して、更新された性能メトリクスをモデル化し、
前記比較モジュールはさらに、前記更新された性能メトリクスを各ビジネスプロセスのビジネス要求セットと比較し、
前記出力モジュールはさらに、前記更新された性能メトリクスがビジネス要求セットを満たす場合、システムアーキテクチャの記述を出力するシステム。
【請求項１３】
請求項１１において、
前記アーキテクチャ構築モジュールはさらに、許容外の性能メトリクスを有する１つまたは複数のビジネスプロセスをサポートする前記アプリケーションレイヤおよびテクノロジーレイヤ内のサポートコンポーネントモデルを識別し、
前記比較モジュールはさらに、許容外の性能メトリクスを有する１つまたは複数のサポートコンポーネントモデルを識別するのに、サポートコンポーネントモデルの性能メトリクスを評価し、
前記ルールベースのエンジンはさらに、データ記憶装置を検索して修正を行うことにより、前記１つまたは複数のサポートコンポーネントモデルの許容外の性能メトリクスを改良するシステム。
【請求項１４】
請求項１３において、前記１つまたは複数のサポートコンポーネントモデルの前記許容外の性能メトリクスを改良する修正が、該１つまたは複数のサポートコンポーネントモデルを別のコンポーネントモデルと置き換えることを含むシステム。
【請求項１５】
請求項１３において、
前記出力モジュールはさらに、前記アプリケーションレイヤまたはテクノロジーレイヤ内のサポートコンポーネントモデルが許容外の性能メトリクスを持たない場合、前記ビジネスプロセスデザインを修正するように提案するシステム。
【請求項１６】
請求項１１において、前記アーキテクチャ構築モジュールは、各ビジネスプロセスを前記アプリケーションレイヤ内のアプリケーションコンポーネントモデルにマッピングし、各アプリケーションコンポーネントモデルが、該アプリケーションコンポーネントモデルをサポートするアプリケーションおよびテクノロジーレイヤ内の１つまたは複数のコンポーネントモデルにリンクされているシステム。
【請求項１７】
請求項１６において、前記アプリケーションレイヤはさらに、テクノロジーバスを含み、このテクノロジーバスが、前記アプリケーションおよびテクノロジーレイヤにおいてモデル化されたコンポーネント間のデータアクセスまたはテクノロジーサービスに対して抽象インタフェースをモデル化するシステム。
【請求項１８】
請求項１６において、前記アプリケーションレイヤはさらに、アプリケーションバスを含み、このアプリケーションバスが、該アプリケーションレイヤ内のアプリケーションコンポーネントモデル間の通信、分散および管理インタフェースをモデル化するシステム。
【請求項１９】
請求項１６において、前記アプリケーションレイヤにあるアプリケーションコンポーネントモデルは、ビジネスアプリケーションレイヤおよびアプリケーションエンジンレイヤに細分され、該ビジネスアプリケーションレイヤが、実時間または適時処理を提供するアプリケーションコンポーネントのモデルを含み、該アプリケーションエンジンレイヤが、延期可能な処理を提供し、かつビジネスアプリケーションレイヤ内の１つまたは複数のアプリケーションコンポーネントをサポートするアプリケーションコンポーネントのモデルを含むシステム。
【請求項２０】
請求項１６において、ビジネスプロセスをサポートするコンポーネントモデルの任意の組み合わせを置き換えることにより、ビジネスプロセスの許容外の性能マトリックを改良できるシステム。
【請求項２１】
システムアーキテクチャを設計するシステムであって、
複数のビジネスプロセスを記述し、かつ各ビジネスプロセスに対してビジネス要求セットを定義するビジネスプロセスデザインを受け取る手段と、
前記ビジネスプロセスデザインをサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築する手段であって、前記マルチレイヤ数学モデルがビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとからなる、手段と、
前記システムアーキテクチャのマルチレイヤモデルの各レイヤに対して性能メトリクスをモデル化する手段と、
前記モデル化された性能メトリクスを各ビジネスプロセスに対するビジネス要求セットと比較する手段と、
ビジネスプロセスに対して定義された前記ビジネス要求セットを満たさない１つまたは複数の許容外の性能メトリクスを改良するのに、前記システムアーキテクチャに対する修正を決定する手段と、
前記システムアーキテクチャのモデルに対する修正を提案する手段と、を含むシステム。
【請求項２２】
請求項１のプロセスにより形成されるシステムアーキテクチャ。
【請求項２３】
コンピュータ使用可能媒体と、
媒体に埋め込まれ、かつモデルベースのシステムアーキテクチャを設計する命令を含むコンピュータ動作命令のセットと、を備えた製品であって、
複数のビジネスプロセスを記述し、かつ各ビジネスプロセスに対してビジネス要求セットを定義するビジネスプロセスデザインを提供するステップと、
前記ビジネスプロセスデザインをサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築するステップであって、該マルチレイヤ数学モデルがビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとからなる、ステップと、
前記システムアーキテクチャのマルチレイヤモデルの各レイヤに対して性能メトリクスをモデル化するステップと、
前記モデル化された性能メトリクスを各ビジネスプロセスのビジネス要求セットと比較して、ビジネスプロセスに対して定義されたビジネス要求セットを満たさない１つまたは複数のビジネスプロセスの許容外の性能メトリクスの表示を生成するステップと、
前記システムアーキテクチャに対する修正を決定するステップと、に対する命令を含む製品。
【請求項２４】
モデルベースのシステムアーキテクチャを設計するコードセグメントを含む搬送波に埋め込まれたコンピュータデータ信号であって、このコードセグメントが、
複数のビジネスプロセスを記述し、かつ各ビジネスプロセスに対してビジネス要求セットを定義するビジネスプロセスデザインを提供するステップと、
前記ビジネスプロセスデザインをサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築するステップであって、該マルチレイヤ数学モデルがビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとからなる、ステップと、
前記システムアーキテクチャのマルチレイヤモデルの各レイヤに対して性能メトリクスをモデル化するステップと、
前記モデル化された性能メトリクスを各ビジネスプロセスのビジネス要求セットと比較して、ビジネスプロセスに対して定義されたビジネス要求セットを満たさない１つまたは複数のビジネスプロセスの許容外の性能メトリクスの表示を生成するステップと、
前記システムアーキテクチャに対する修正を決定するステップと、に対する命令を含むコンピュータデータ信号。
【発明の詳細な説明】
【０００１】
【発明の背景】
電子コンピューティングの到来により、金融機関などの企業組織は情報システムを利用して、ビジネスプロセスをサポートするコンピュータ化インフラを提供している。情報システムは、多数の相互接続されたハードウェアおよびソフトウェアコンポーネントを含み、１つまたは複数のビジネスソリューションを実現している。このようなシステムのアーキテクチャは一般に、課せられたビジネス制約下で、変動する作業負荷および優先順位を処理することを要求される。
【０００２】
このような要求および制約を有するシステムアーキテクチャを設計することは、極めて難しいことである。大部分の既存の方法、ツールおよびテクニックは、コンピュータ化ビジネスインフラの静的で部分的な記述に集中している。動的システムの挙動は一般に、情報システムが構築または作動状態になるまで未知であるため、改良の可能性が制限される。アーキテクチャによりサポートされなければならない新しいビジネスアプリケーションが追加されて、システムが進化するにつれ、許容できない、性能上の問題はさらに悪化する可能性がある。
【０００３】
さらに、問題の原因が開発プロセスの初期になされた決定にあるときは、システムアーキテクチャの特定レベルでの再設計が必要である場合に、改良コストが極めて高くなる可能性がある。したがって、許容外のシステムアーキテクチャの設計に起因する多額の投資損失が発生する場合がある。
【０００４】
【発明の概要】
本発明の実施形態によれば、情報システムのモデルベースのアーキテクチャを設計する自動システムおよび方法が提供される。自動システムおよび方法の実施形態は、システム設計者が利用するコンピュータ支援デザインツールで実現できる。このような実施形態は、多数のビジネスプロセスを記述し、各ビジネスプロセスに対するビジネス要求セットを定義するビジネスプロセスデザインを提供する。システムアーキテクチャのマルチレイヤ数学モデルがビジネスプロセスデザインから構築され、このモデルはビジネスレイヤ、アプリケーションレイヤおよびテクノロジーレイヤを有する。初期モデルが構築されると、性能メトリクス（ｍｅｔｒｉｃｓ：測定基準）が各レイヤでモデル化される。各ビジネスプロセスに対し、モデル化された性能メトリクスをビジネス要求セットと比較して、１つまたは複数のビジネスプロセスの許容外の性能メトリクスの表示をそれぞれ生成する。許容外の性能メトリクスを有するビジネスプロセスに対しては、システムアーキテクチャの修正が決定され、容認を得るためにシステム設計者に提案される。容認されると、システムアーキテクチャのモデルは、容認された修正形態で修正され、性能メトリクスが各レイヤで更新される。更新された性能メトリクスがビジネス要求を満たせば、その結果得られたシステムアーキテクチャの記述の出力が有効になる。
【０００５】
本発明の前述およびその他の目的、特徴、および利点は、添付図面に示す本発明の好ましい実施形態の以下の詳細な説明で明らかになるであろう。図面では、同一参照符号は異なる図面においても同一部品を指す。図面は必ずしも縮尺通りでなく、本発明の原理を示すことに重点が置かれている。
【０００６】
【好ましい実施形態の詳細な説明】
以下、本発明の好ましい実施形態について記述する。
【０００７】
本発明の実施形態は、システム設計者が情報システムのモデルベースのアーキテクチャを設計するための自動システムおよび方法を提供する。モデルベースのアーキテクチャとは、モジュール式ハードウェアおよびソフトウェアコンポーネントモデルから設計され、性能モデル化により実証されたシステムアーキテクチャである。性能モデル化による実証により、モデルベースのアーキテクチャは、システム設計者の経験だけに基づいて設計されたシステムアーキテクチャより堅牢かつ確実なものとなる。自動システムおよび方法の実施形態は、システム設計者により利用されるコンピュータ支援デザインツールで実現できる。
【０００８】
本発明を概略的に述べると、システム設計者に一連のグラフィカルユーザーインタフェースが提供され、これを介して、ビジネスプロセスデザインからシステムアーキテクチャの初期モデルが構築される。ビジネスプロセスデザインを提供している状態で、自動システムの実施形態は、予めモデル化されたビジネスアプリケーションの選択可能なリストを提供し、そのビジネスアプリケーションはデフォルトのハードウェアおよびソフトウェアコンポーネントモデルのセットに連結されている。初期モデルを構築するには、ビジネスプロセスデザインで定義された対応するビジネスプロセスに対して、利用可能なビジネスアプリケーションを単にマッピングするだけでよい。したがって、システム設計者は、サポートハードウェアおよびソフトウェアコンポーネントを定義することから解放される。初期モデルが構築された後、自動システムの実施形態は性能モデル化、比較およびアーキテクチャ修正ステージのシーケンスを反復し、この反復をモデル化されたメトリクスがビジネスプロセスデザインのビジネス要求を満たすまで続ける。ビジネス要求が満たされると、結果として得られたモデルから、システムアーキテクチャを記述した詳細な仕様書セットが導き出される。
【０００９】
図１は、本発明の１つの実施形態による、モデルベースのアーキテクチャを設計するための自動システムの機能モジュールを示す。自動システムの実施形態は、ビジネスデザインモジュール１０と、アーキテクチャ構築モジュール２０と、性能モデル化モジュール３０と、比較モジュール４０と、修正エンジン５０と、出力モジュール６０とを含む。
【００１０】
ビジネスデザインモジュール１０は、システム設計者がビジネスプロセスデザインを提供できるグラフィカルレイアウトインタフェースを提供する。ビジネスプロセスデザインは、企業組織内のビジネスプロセスと、これらビジネスプロセス間の通信および作業負荷の流れとを識別する。さらに、ビジネスプロセスデザインは、個々のビジネスプロセスに対してビジネス要求セットを定義する。
【００１１】
アーキテクチャ構築モジュール２０はグラフィカルユーザーインタフェースを提供しており、これを介してシステム設計者は、ビジネスデザインモジュール１０におけるビジネスプロセスデザイン入力をサポートするシステムアーキテクチャのマルチレイヤ数学モデルを構築する。モデルのレイヤは、ビジネスレイヤと、アプリケーションレイヤと、テクノロジーレイヤとを含む。ビジネスレイヤは、ビジネスプロセスデザインを含むのに対して、アプリケーションおよびテクノロジーレイヤは、ビジネスプロセスデザインをサポートするソフトウェアおよびハードウェアコンポーネントモデルをそれぞれ含む。マルチレイヤ数学モデルの構造に関する詳細な情報については、１９９８年７月３１日に出願された米国特許出願第０９／１２７，１９１号の、発明の名称「マルチレイヤ数学モデルを用いた情報システムの設計および解析の方法および装置（Ｍｅｔｈｏｄ　ａｎｄ　Ａｐｐａｒａｔｕｓ　ｆｏｒ　Ｄｅｓｉｇｎｉｎｇ　ａｎｄ　Ａｎａｌｙｚｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｙｓｔｅｍｓ　Ｕｓｉｎｇ　Ｍｕｌｔｉ−Ｌａｙｅｒ　Ｍａｔｈｅｍａｔｉｃａｌ　Ｍｏｄｅｌｓ）」を参照されたい。前記出願は、その全文を本願明細書の一部をなすものとしてここに引用している。
【００１２】
性能モデル化モジュール３０は、システムアーキテクチャのマルチレイヤ数学モデルの各レイヤで性能メトリクスをモデル化する。ビジネスフローおよび作業負荷の定義などのビジネス要求のいくつかが、性能メトリクスの計算に利用される。
【００１３】
各ビジネスプロセスに対して、比較モジュール４０は、性能モデル化モジュール３０から出力されたモデル化した性能メトリクスを、ビジネスデザインモジュール１０で提供される定義されたビジネス要求セットと比較する。比較モジュール４０は、１つまたは複数のビジネスプロセスが、入力ビジネス要求を満たさない許容外の性能メトリクスを表すかどうかの表示を生成する。
【００１４】
許容外のモデル化したビジネス性能メトリクスが識別されると、ルールベースの修正エンジン５０がシステムアーキテクチャのモデルに対して適切な修正を決定して、許容外のビジネス性能メトリクスを改良し、システム設計者に修正を提案して容認を求める。
【００１５】
容認されると、アーキテクチャ構築モジュール２０は、システム設計者からのそれ以上の支援を受けることなく、提案された修正をシステムアーキテクチャのモデルに自動的に組み込む。修正されたシステムアーキテクチャの性能メトリクスは、性能モデル化モジュール３０により更新され、比較モジュール４０により再度比較される。モデル化されたビジネス性能メトリクスがビジネス要求を満たせば、出力モジュール６０はシステム設計者にシステムアーキテクチャの詳細な記述を提供し、この記述は後続の実行ステージにおいて使用される。ビジネス要求を満たさない場合、自動システムの実施形態は、モジュール５０、２０、３０および４０の修正、モデル化および比較ステージを反復し続ける。このプロセスは、各ビジネスプロセスのモデル化された性能メトリクスがビジネス要求を満たすか、またはサポートハードウェアおよびソフトウェアコンポーネントモデルの性能メトリクスを、ビジネスプロセスデザインを変更することなくさらに改良することができなくなるまで続く。
【００１６】
図２Ａおよび図２Ｂは、図１の実施形態を用いたモデルベースのアーキテクチャを設計するための自動デザインプロセスのフローチャートを示す。
【００１７】
１１０において、ビジネスデザインモジュール１０はグラフィカルレイアウトインタフェースを提供し、図３に示されているように、そのインタフェースを介してシステム設計者がビジネスプロセスおよびプロセス相互作用の流れの記述を提供する。
【００１８】
図３は、１つの実施形態によるビジネスプロセスデザインのグラフィカルレイアウトを示す図である。この例では、ビジネスプロセスデザイン３００は、金融機関内の支払処理のビジネスプロセスおよび相互作用を記述する。システム設計者は、アイコン３１０およびリンク３２０をレイアウトに追加することにより、ビジネスプロセスデザインを作成する。各アイコン３１０はビジネスプロセスを識別し、一方、ビジネスプロセスアイコン３１０間のリンク３２０は処理の流れを表す。１つの実施形態によれば、グラフィカルレイアウトインタフェースは、ユニバーサルマークアップ言語（ＵＭＬ：Ｕｎｉｖｅｒｓａｌ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）などのグラフィカルスクリプト言語を用いて実現される。
【００１９】
図２Ａの１２０では、ビジネスデザインモジュール１０はグラフィカルレイアウトインタフェースを提供し、このインタフェースを介して、システム設計者が各ビジネスプロセスに対するビジネス要求を定義する。
【００２０】
１つの実施形態によれば、ビジネス要求とは、ビジネス制約およびビジネスドライバのことをいう。ビジネスドライバとは、一般に、ビジネスプロセスが受け取ると予測される作業負荷を表す。典型的なビジネスドライバは、ビジネスイベントの予測される数および種類とイベントを受け取る速度とを含む。
【００２１】
ビジネス制約とは、一般に、ビジネスニーズにより課せられる時間と量の制約を指す。例えば、ビジネス制約は時間制約と量制約とを含む。典型的な時間制約は、ビジネス応答時間を含むのに対して、典型的な量制約は、例えば一日当たりに処理されるイベントまたは１秒当たりに処理されるイベントを含む。ビジネス制約は、提案されたシステムアーキテクチャが、企業組織のニーズを満たすかどうかを決定する比較基準を提供する。
【００２２】
１３０において、アーキテクチャ構築モジュール２０はグラフィカルユーザーインタフェースを提供し、このインタフェースを介して、システム設計者が各ビジネスプロセスをビジネスアプリケーションにマッピングする。１つの実施形態によれば、システム設計者は、ビジネスプロセスデザイン３００のグラフィカルレイアウトにあるビジネスプロセスアイコン３１０を“ダブルクリック”することにより、アーキテクチャ構築モジュールに対してグラフィカルユーザーインタフェースを立ち上げる。
【００２３】
次に、システム設計者に、予めモデル化されたビジネスアプリケーションのリストが提供される。リストに示された各ビジネスアプリケーションは、サポートハードウェアおよびソフトウェアコンポーネントモデルのデフォルトセットに連結される。初期モデルを構築するには、利用可能なビジネスアプリケーションを、ビジネスプロセスデザインで定義された対応するビジネスプロセスに単にマッピングするだけでよい。したがって、システム設計者は、サポートハードウェアおよびソフトウェアコンポーネントのすべてを定義する作業から解放され、自動デザインプロセスがさらに単純化される。
【００２４】
ビジネスプロセスのすべてをマッピングした後、アーキテクチャ構築モジュール２０は、提案されたシステムアーキテクチャのマルチレイヤ数学モデルを生成する。モデルのレイヤは、ビジネスレイヤ、アプリケーションレイヤおよびテクノロジーレイヤを含む。マルチレイヤ数学モデルの構造に関する詳細な情報については、１９９８年７月３１日に出願された米国特許出願第０９／１２７，１９１号の発明「マルチレイヤ数学モデルを用いた情報システムの設計および分析方法および装置」を参照されたい。前記出願は、その全文を本願明細書の一部をなすものとしてここに引用している。
【００２５】
１４０において、性能モデル化モジュール３０は、アーキテクチャ構築モジュール２０において生成されたマルチレイヤ数学モデルの各レイヤに対する性能メトリクスをモデル化する。このようなメトリクスは、延長、応答時間、処理されるトランザクション量およびトランザクション処理速度を含む。１つの実施形態によれば、１２０において、ビジネスプロセスデザインで定義されたビジネスドライバは、性能メトリクスのモデル化に含まれる。性能メトリクスのマルチレイヤモデル化に関する詳細な情報については、１９９８年７月３１日に出願された米国特許出願第０９／１２７，１９１号の発明「マルチレイヤ数学モデルを用いた情報システムの設計および分析方法および装置」と、２０００年６月２９日に出願された米国特許出願第０９／６０６，８６９号の発明「情報システム構築に対し性能メトリクスを決定するシステムおよび方法（Ｓｙｓｔｅｍ　ａｎｄ　Ｍｅｔｈｏｄ　ｆｏｒ　Ｄｅｔｅｒｍｉｎｉｎｇ　Ｐｅｒｆｏｒｍａｎｃｅ　Ｍｅｔｒｉｃｓ　ｆｏｒ　Ｃｏｎｓｔｒｕｃｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｙｓｔｅｍｓ）」と、を参照されたい。前記の両出願は、その全文を本願明細書の一部をなすものとしてここに引用している。次に、モデル化された性能メトリクスは比較モジュール４０に送出される。
【００２６】
１５０において、比較モジュール４０は、ビジネスプロセスのモデル化された性能メトリクスが、ビジネスプロセスデザインで定義されたビジネス要求を満たすかどうかについて、初期決定を行う。１つの実施形態によれば、この比較は、モデル化された性能メトリクスの値と、応答時間のような対応するビジネス制約の値との差でなされる。ファジー論理を使用して、モデル化された性能メトリクスが定義されたビジネス制約を満たすかどうかを確認することもできる。
【００２７】
１６０において、モデル化されたビジネス性能メトリクスが各ビジネスプロセスのビジネス要求を満たせば、提案されたシステムアーキテクチャは、出力モジュール６０に送られ、１７０において、モデルベースのシステムアーキテクチャの仕様書の詳細な記述を出力する。出力モジュール６０は、システムアーキテクチャモデルを、システムアーキテクチャの構築および実施を記述した詳細な“青写真”セットにフォーマット（形式化）する。１つの実施形態によれば、出力フォーマットは、インターネットブラウザで容易に表示可能なユニバーサルマークアップ言語（ＵＭＬ）ドキュメントである。ＵＭＬで作成された表示は、ビジネス、アプリケーションおよびテクノロジーレイヤ内のコンポーネント間を結合するハイパーリンクを含むシステムアーキテクチャを表示できる。
【００２８】
１６０において、ビジネスプロセスの少なくとも１つが、許容外のビジネス性能メトリクスを示す場合、比較モジュール４０は、図２Ｂの１８０において、アプリケーションおよびテクノロジーレイヤ内にある、許容外のビジネス性能メトリクスの原因になる、サポートコンポーネントモデルを識別することを試みる。
【００２９】
図２Ｂの１８０では、比較モジュール４０は、許容外のビジネス性能メトリクスを示す１つまたは複数のビジネスプロセスにリンクした、サポートハードウェアおよびソフトウェアコンポーネントモデルの性能メトリクスを評価する。１つの実施形態によれば、サポートコンポーネントモデルのモデル化された性能メトリクスを、ベンダーが提供するか、またはモデル化されたベンチマークと比較して、このメトリクスの動作が非効率性であるかどうかを決定する。
【００３０】
１９０において、サポートコンポーネントモデルが、許容外のモデル化された性能メトリクスを示さなければ、システム設計者には、２００において、グラフィカルユーザーインタフェースを介して、許容外のビジネス性能メトリクスがビジネスプロセスデザインの欠陥により生じたことが通知される。これらの欠陥は、非効率的なビジネスプロセスの相互作用または非現実的なビジネス要求を含むことがある。プロセスは１１０に戻り、システム設計者にビジネスデザインモジュール１０のグラフィカルレイアウトインタフェースを提供し、それにより設計者はビジネスプロセスデザインを修正する。
【００３１】
１９０において、１つまたは複数のサポートコンポーネントモデルが許容外の性能メトリクスを示した場合、ステップ２１０は、サポートコンポーネントのアイデンティティ（識別情報）および許容外の性能メトリクスをルールベースの修正エンジン５０に送り、システムアーキテクチャの修正を決定して改良を行う。
【００３２】
２１０において、修正エンジン５０は、システムアーキテクチャの修正を決定して、サポートハードウェアおよびソフトウェアコンポーネントの、システムアーキテクチャにおいてモデル化された許容外の性能メトリクスに対処する。１つの実施形態によれば、ルールベースの修正エンジン５０は、データ記憶装置内に組み込まれた論理ツリーを検索する。サポートコンポーネントモデルのアイデンティティおよびそれらの許容外のメトリクスを使用して、業界標準、ベンダーベンチマークまたは前にモデル化された結果に従って、推奨された修正に対して論理ツリーを検索する。例えば、メモリサイズの増大が推奨された修正であれば、推奨されたサイズは、前のモデル化された結果、ベンダー提供のベンチマーク、または業界標準の仕様のいずれかから得られる値である。このような修正は、１つまたは複数のサポートコンポーネントモデルを別のコンポーネントモデルに置き換えることを含んでもよい。
【００３３】
２２０において、検索により、システムアーキテクチャに対する推奨された修正を見出した場合、２３０において、グラフィクルユーザーインタフェースを介してシステム設計者に修正が提案され、容認を求める。
【００３４】
２４０において、システム設計者が提案された修正をすべて拒絶すれば、２１０において、論理ツリーが再度検索され、システムアーキテクチャに対する別の修正を見出す。２２０において、検索により別の推奨される修正を見出すことができなければ、２００において、システム設計者には、グラフィカルユーザーインタフェースを介して、許容外のビジネス性能メトリクスがビジネスプロセスデザインの欠陥により生じたことが通知される。プロセスは１１０に戻り、システム設計者にビジネスデザインモジュール１０のグラフィカルレイアウトインタフェースを提供し、それにより設計者はビジネスプロセスデザインを修正する。
【００３５】
２４０において、設計者が１つまたは複数の提案修正を容認すれば、２５０において、システムアーキテクチャのモデルは、容認された修正でアーキテクチャ構築モジュール２０により自動的に修正される。
【００３６】
システムアーキテクチャモデルを修正後、別のモデル化を実行するために、プロセスは再度１４０に戻って、プロセスを繰り返し、これを各ビジネスプロセスのモデル化された性能メトリクスがビジネス要求を満たすか、または、サポートハードウェアおよびソフトウェアコンポーネントモデルの性能メトリクスを、ビジネスプロセスデザインを変更することなくさらに改良することができなくなるまで繰り返す。
【００３７】
モデル化されたビジネス性能メトリクスがビジネス要求を満たすと、システムアーキテクチャのモデルは、システムアーキテクチャの詳細な記述にフォーマットされ、これを、１７０において、出力モジュール６０から出力する。
【００３８】
図４は、図１〜２Ｂの前述の実施形態による自動デザインプロセスから得られた情報システムのモデルベースのアーキテクチャを示す。モデルベースのアーキテクチャ４００の実施形態は、アプリケーションレイヤ４０５およびテクノロジーレイヤ４５０を含み、アプリケーションレイヤ４０５は、ビジネスアプリケーションレイヤ４１０と、アプリケーションバスレイヤ４２０と、アプリケーションサービスレイヤ４３０と、テクノロジーバスレイヤ４４０からなるサブレイヤに分割される。アプリケーションサブレイヤは、多数の処理原則、制約およびガイドラインを実行して、複雑かつ多次元・多機能の適時な重大なビジネスソルーションをサポートする拡張可能なシステムアーキテクチャを設計する。
【００３９】
１つの実施形態によれば、ソフトウェアコンポーネントモデルは、ビジネスアプリケーションレイヤ４１０またはアプリケーションサービスレイヤ４３０のいずれかに分離される。ビジネスアプリケーションレイヤ４１０およびアプリケーションサービスレイヤ４３０は、フロントエンド・クライアント処理およびバックエンド・サーバ処理をそれぞれ実行するソフトウェアコンポーネントを区別する。フロントエンド・クライアント処理は一般に、実時間および適時の重大な処理を含むのに対して、バックエンド・サーバ処理は一般に、延期可能なバッチ処理を含む。
【００４０】
ビジネスアプリケーションレイヤ４１０は、システム設計者によりビジネスプロセスに最初にマッピングされるか、または、図２Ａおよび図２Ｂに記述されたように、自動デザインプロセス中にそのモデルに置き換えられたビジネスアプリケーションコンポーネントモデルに埋め込まれる。ビジネスアプリケーションレイヤ４１０は、プレゼンテーションレイヤおよび（例えば、グラフィカルユーザーインタフェース）およびビジネス論理レイヤに細分でき、さらにセグメント化できる。
【００４１】
アプリケーションサービスレイヤ４３０は、モジュラサービスエンジン、一般ルーチン、クライアント特定ソフトウェアコンポーネントおよび揮発性ソフトウェアコンポーネントの集合体を含み、この集合体は特定のサービスを１つまたは複数のビジネスアプリケーションに提供する。エンジンは個別の機能を実行する１つまたは複数のプログラムを含む。１つの実施形態によれば、アプリケーションサービスレイヤ４３０のコンポーネントが待ち行列ベースとしてモデル化され、サービス要求の並列処理を可能にして、処理時間を実質的に短縮する。このレイヤでのアーキテクチャデザイン方式は、例えば、分散型、パイプフィルタ方式、バッチシーケンシャルおよび黒板方式であってよい。
【００４２】
システム設計者が最初に、ビジネスプロセスをビジネスアプリケーションにマッピングすると、アプリケーションサービスレイヤ４３０に、選択されたビジネスアプリケーションをサポートするデフォルトアプリケーションサービスが自動的に追加される。デフォルトアプリケーションサービスは、図２Ａおよび図２Ｂに記述されているように、自動デザインプロセス中に置き換えることができる。新しいアプリケーションサービスが要求されると、アプリケーションサービスレイヤ４３０は拡張可能である。
【００４３】
アプリケーションバスレイヤ４２０は、複数の通信サービスを提供することにより、ビジネスアプリケーションレイヤ４１０とアプリケーションサービスレイヤ４３０の分離を容易にする。レイヤ４１０、４３０にあるソフトウェアコンポーネント間でのすべての通信は、アプリケーションバスレイヤ４２０を介して要求する必要がある。モデル化された通信サービスには、コードおよびネットワーク通信プロトコル変換サービス（例えば、Ｊａｖａからコボル、ＴＣＰ／ＩＰからＳＮＡ）、分散サービス（例えば作業負荷を分散して、サーバの過負荷を防ぐ）、イベント、システムおよびトランザクション管理サービス（例えば、各レベルでの複数のサービス要求の順序付けおよび完全性を与える）、セキュリティサービス（例えば認証）、スクリプトフロー、コンフリクト解決、ロック処理、サービス要求のスケジューリングおよびディスパッチング（タスクに対して処理装置上の時間を割り当てること）を含むことができる。このような通信サービスはディレイ（ｄｅｌａｙ）またはロック処理としてモデル化され、それにより情報システムの全体的な性能メトリクスに影響を与える。１つの実施形態によれば、アプリケーションバスレイヤ４２０は、メッセージ伝達およびＴＣＰ／ＩＰネットワーク通信プロトコルなどの通信ミドルウェアをモデル化する。
【００４４】
ソフトウェアコンポーネントをビジネスアプリケーション４１０とアプリケーションサービス４３０レイヤとに分離することにより、ソフトウェアコンポーネントの再利用および分散が行われる。再利用および適正な分散により、メンテナンスおよび開発コストが低減され、製品の配信速度が上がる。さらに、アプリケーションサービスレイヤ４３０内のサービスを混乱させることなく、ビジネスアプリケーションレイヤ４１０内でカスタマイズが可能である。
【００４５】
テクノロジーレイヤ４５０は、ビジネスアプリケーションおよびアプリケーションサービスが展開される物理ハードウェアのハードウェアコンポーネントモデルおよびオペレーティングシステムを提供する。このようなハードウェアの典型的な例には、データ記憶装置、処理ユニットおよびエンジン、ルーター、スイッチ、および他のネットワークデバイスを含む。特定のハードウェアコンポーネントは、自動デザインプロセスの予測モデル化、比較および修正ステージの間に決定される。
【００４６】
テクノロジーバスレイヤ４４０が、テクノロジーレイヤ４５０をアプリケーションレイヤ４１０、４３０から隔離して、テクノロジー特定のアーキテクチャを回避する。１つの実施形態によれば、テクノロジーバスレイヤ４４０は、データアクセスまたはテクノロジーサービスに対して抽象インタフェース（例えば、Ｊａｖａ（商標）仮想機械）をモデル化する。テクノロジーバスレイヤ４４０をモデルに組み込むことにより、その結果得られるシステムアーキテクチャは、ハードウェアコンポーネントの特定のセットに固有のものでなくなる。したがって、テクノロジーバスレイヤ４４０への移植性が最大になることにより、コードを新しいハードウェアプラットフォームに実質的に移植することなく、テクノロジーレイヤ４５０の物理ハードウェアを置き換えることができる。さらに、テクノロジーバスレイヤ４４０は、レベル補償、ネットワークプロトコル変換、暗号化および接続管理サービスを提供する。
【００４７】
当業者には、情報システムのモデルベースのアーキテクチャを設計する自動システムおよび方法に含まれるプロセスが、コンピュータ使用可能媒体を含む製品で具体化できることが認識されるであろう。例えば、このようなコンピュータ使用可能媒体には、ハードドライブデバイス、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、コンピュータディスケットまたは固体メモリコンポーネント（ＲＯＭ、ＲＡＭ）などのような、コンピュータ読取り可能なプログラムコードセグメントが格納された、読取り可能なメモリデバイスを含むことができる。コンピュータ読取り可能な媒体にはまた、例えば、ディジタルまたはアナログデータ信号のようなプログラムコードセグメントを伝送する光学、有線または無線のいずれかのバスまたは通信リンクのような通信または伝送媒体を含むことができる。
【００４８】
本発明を好ましい実施形態により図示し、説明してきたが、当業者には、添付の特許請求の範囲に定義された本発明の範囲から逸脱することなく、形態または細部に各種の変更を加えるのが可能であることは理解されるであろう。
【図面の簡単な説明】
【図１】
本発明の１つの実施形態にかかるモデルベースのアーキテクチャを設計する自動システムの機能モジュールを示す。
【図２Ａ】
図１の実施形態を用いて、モデルベースのアーキテクチャを設計するための自動デザインプロセスのフローチャートを示す。
【図２Ｂ】
図１の実施形態を用いて、モデルベースのアーキテクチャを設計するための自動デザインプロセスのフローチャートを示す。
【図３】
１つ実施形態によるビジネスプロセスデザインのグラフィカルレイアウトを示す図である。
【図４】
図１、図２Ａおよび図２Ｂの実施形態にかかる自動デザインプロセスから得られる情報システムのモデルベースのアーキテクチャを示す。
【図１】
2004507838.tif 000002
【図２Ａ】
2004507838.tif 000003
【図２Ｂ】
2004507838.tif 000004
【図３】
2004507838.tif 000005
【図４】
2004507838.tif 000006
【国際公開パンフレット】
2004507838.tif 000007
2004507838.tif 000008
2004507838.tif 000009
2004507838.tif 000010
2004507838.tif 000011
2004507838.tif 000012
2004507838.tif 000013
2004507838.tif 000014
2004507838.tif 000015
2004507838.tif 000016
2004507838.tif 000017
2004507838.tif 000018
2004507838.tif 000019
2004507838.tif 000020
2004507838.tif 000021
2004507838.tif 000022
2004507838.tif 000023
2004507838.tif 000024
2004507838.tif 000025
2004507838.tif 000026
2004507838.tif 000027
2004507838.tif 000028
2004507838.tif 000029
2004507838.tif 000030
2004507838.tif 000031
2004507838.tif 000032
2004507838.tif 000033
【国際公開パンフレット（コレクトバージョン）】
2004507838.tif 000034
2004507838.tif 000035
2004507838.tif 000036