JP3891778B2

JP3891778B2 - 情報制御システム

Info

Publication number: JP3891778B2
Application number: JP2000365741A
Authority: JP
Inventors: 明男斉川; 真人森田
Original assignee: 株式会社大和証券グループ本社
Priority date: 2000-11-30
Filing date: 2000-11-30
Publication date: 2007-03-14
Anticipated expiration: 2020-11-30
Also published as: JP2002169714A

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の情報処理手段を用いて情報処理を行う情報制御システムに関する。
【０００２】
【従来の技術】
従来、複数の業務の手順を有するビジネスプロセスをコンピュータに実行させる場合、次のような論理規則を用いて実行されていた。まず、コンピュータに実行させるべき処理内容が記述されたシステム機能をビジネスプロセス毎に複数設定する。そして、各システム機能の処理手順を定め、その手順に従い各システム機能を実行する。その際、あるシステム機能を実行した後に他のシステム機能の実行に移行する場合には、あるシステム機能に対して処理手順が前後にあるシステム機能との関連性のみが実行に際して設定されており、処理手順が前後に位置づけられない他のシステム機能との間での関連性はなかった。
【０００４】
【発明が解決しようとする課題】
この場合、ビジネスプロセスの処理を所定の手順に従って実行するときには、命令部が予め処理手順を定め、その処理手順を実行させるための順序規則を各システム機能に関連付けておかなければならない。例えばシステム機能Ａ〜Ｄを順次実行する場合、まず命令部が最初に実行すべきシステム機能Ａに対して処理命令を出すと、今度はシステム機能Ａがシステム機能Ｂに対して予め関連付けられた順序規則に基づき処理命令を行い、同様にシステム機能Ｂが今度はシステム機能Ｃに対して予め関連付けられた順序規則に基づき処理命令を行う。
【０００７】
このように、処理手順を定める順序規則は各システム機能Ａ〜Ｄに関連付けられていた。しかしながら、このような処理手順の決定方法では、途中で処理不能なシステム機能が現れた場合等には処理が中断してしまう。しかし、中断したシステム機能がどのシステム機能かはビジネスプロセスの処理手順を定めた命令部にとっては分からないことが多い。
【０００８】
また、ビジネスプロセスを変更する場合には、各システム機能Ａ〜Ｄに対して順序規則の変更を行う必要が生じ、システム管理者としては変更に対応するために煩雑かつ時間のかかる手続が必要とされていた。新たなビジネスプロセスを実行させる場合には、各システム機能Ａ〜Ｄに対して新たな順序規則を関連付ける必要がある。
【０００９】
このように、複数のシステム機能によりビジネスプロセスを所定の処理手順に従って実行する場合には、煩雑な処理が必要となり、効率的なシステム管理が困難であった。
【００１０】
本発明は上記課題を解決するためになされたもので、その目的とするところは、簡便かつ効率的にビジネスプロセスを実現することができる情報制御システムを提供することにある。
【００１１】
【課題を解決するための手段】
本発明は、情報処理を行う複数の上位情報処理手段であって、それぞれが複数の下位情報処理手段を有する複数の上位情報処理手段と、前記複数の上位情報処理手段による情報処理を行うための処理手順であって、前記複数の上位情報処理手段における前記下位情報処理手段による情報処理の処理手順を記憶する処理手順記憶手段と、前記処理手順記憶手段に記憶された情報処理の処理手順に基づき、情報処理を行うべき下位情報処理手段を有する上位情報処理手段に対して当該下位情報処理手段に当該情報処理を行わせるための処理命令を出す処理命令手段とを具備し、前記上位情報処理手段は、当該上位情報処理手段が有する下位情報処理手段に情報処理を行わせるための処理命令を前記処理命令手段から受けて当該下位情報処理手段に情報処理を行わせ、当該下位情報処理手段の情報処理結果を前記処理命令手段に通知し、前記処理命令手段は、前記処理命令を行った下位情報処理手段からの情報処理結果を受けると、前記処理手順記憶手段に記憶された処理手順に基づき、次の情報処理を行うべき下位情報処理手段を有する上位情報処理手段に対して当該下位情報処理手段に当該情報処理を行わせるための処理命令を出す情報制御システムにおいて、前記複数の上位情報処理手段のうち第１の上位情報処理手段は第１の下位情報処理手段と第２の下位情報処理手段を有するとともに、前記複数の上位情報処理手段のうち第２の上位情報処理手段は第３の下位情報処理手段と第４の下位情報処理手段を有し、前記処理手順記憶手段に記憶された処理手順は、前記第１の下位情報処理手段による情報処理、前記第１の下位情報処理手段の情報処理結果に応じた前記第２の下位情報処理手段又は第３の下位情報処理手段による情報処理、前記第４の下位情報処理手段による情報処理の順に情報処理を行うための処理手順を含み、前記複数の上位情報処理手段の各々はビジネスプロセスの情報処理単位毎に設定されたものであり、前記上位情報処理手段が有する前記複数の下位情報処理手段の各々は当該上位情報処理手段でのビジネスプロセスの情報処理単位を分割した詳細ビジネスプロセスの情報処理単位毎に設定されたものであることを特徴とする。
【００２７】
また、本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラム、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２８】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態を説明する。
【００２９】
（第１実施形態）
図１は本発明の第１実施形態に係る情報制御システムの概念図である。図１に示すように、この情報制御システムは、単一のシステムクラスタ間ハブ１と３つのシステムクラスタ２〜４からなる。システムクラスタとは、情報制御システムを複数の情報処理単位に分割した場合の一情報処理単位であり、ビジネスプロセスの処理単位毎に設定される。また、ハブとは、複数の情報処理単位の管理を行う情報処理単位であり、各情報処理単位への処理手順の決定、処理命令、データ変換を実行する。例えばシステムクラスタ２は株式の売買に関する処理を行う情報処理単位、システムクラスタ３は営業成績を管理する情報処理単位、システムクラスタ４は経理処理を行う情報処理単位というように設定される。なお、ハブ１に対応づけられるシステムクラスタ数は３つに限定されず、複数であればいくつでもよい。また、システムクラスタ２〜４に対応づけられるハブ数は単一の場合に限られず、複数であってもよい。
【００３０】
各システムクラスタ２〜４はそれぞれ単一のハブと複数のサブシステムから構成される。サブシステムとは、システムクラスタをさらに複数の情報処理単位に分割した場合の一情報処理単位であり、システムクラスタよりも詳細なビジネスプロセスの処理単位毎に設定される。具体的には、システムクラスタ２はシステムクラスタ内ハブ２１と２つのサブシステム２２及び２３から構成される。システムクラスタ３はシステムクラスタ内ハブ３１と３つのサブシステム３２〜３４から構成される。システムクラスタ４はシステムクラスタ内ハブ４１と３つのサブシステム４２〜４４から構成される。なお、ハブ２１，３１及び４１に対応づけられたサブシステムの数は２つあるいは３つに限定されるものではなく、４つ以上であってもよい。また、複数のサブシステムに対応づけられるハブ数は単一に限られず、複数であってもよい。
【００３１】
図２はシステムクラスタ間ハブ１の詳細な構成を示す図である。図２に示すように、システムクラスタ間ハブ１は、ルーティング制御部１１と、データ記述形式変換部１２から構成される。
【００３２】
ルーティング制御部１１は、各システムクラスタ２〜４に対する処理命令の処理手順を複数格納するビジネスルールデータベース１１ｂと、このビジネスルールデータベース１１ｂに格納された処理手順のうちのいずれかに基づいて各システムクラスタ２〜４に処理命令を出すルーティングエンジン１１ａを有する。
【００３３】
データ記述形式変換部１２には、各システムクラスタ２〜４で使用されるデータ記述形式と標準のデータ記述形式との間のデータ記述形式変換を行うためのデータ記述形式変換ツール１２ａが設けられている。また、データ記述形式変換ルールデータベース１２ｂは、データ記述形式変換ツール１２ａにおけるデータ記述形式変換を行うデータ記述形式変換ルールを格納している。具体的には、システムクラスタ２，３及び４それぞれで使用されるデータ記述形式と標準データ記述形式の間のデータ記述形式変換ルールを格納している。従って、データ記述形式変換ルールデータベース１２ｂに格納されたデータ記述形式変換ルールはシステムクラスタの数だけ存在する。もちろん、不要な変換ルールは格納しておかなくてもよい。また、データ項目情報データベース１２ｃには、標準データのデータ記述形式及び副標準データ記述形式のフォーマットが記憶されている。
【００３４】
標準データ記述形式とは、各システムクラスタ２〜４で使用されるそれぞれのデータ記述形式と互換性を有するデータ記述形式であり、各システムクラスタ２〜４で使用されるそれぞれのデータ記述形式の間の変換の際には、この標準データ記述形式を経由することとなる。例えば、システムクラスタ２で使用されるデータ記述形式からシステムクラスタ３で使用されるデータ記述形式に変換される場合、システムクラスタ２で使用されるデータ記述形式から一旦標準データ記述形式に変換され、その後システムクラスタ３で使用されるデータ記述形式に変換される。
【００３５】
図３は株式の売買に関する処理を行うシステムクラスタ２の詳細な構成の一例を示す図である。図３に示すように、システムクラスタ内ハブ２１は、ルーティング制御部２１１とデータ記述形式変換部２１２を有する。
【００３６】
ルーティング制御部２１１は、ルーティングエンジン２１１ａと、このルーティングエンジン２１１ａに接続されたビジネスルールデータベース２１１ｂから構成される。データ記述形式変換部２１２は、データ記述形式変換ツール２１２ａと、このデータ記述形式変換ツール２１２ａに接続されたデータ記述形式変換ルールデータベース２１２ｂとデータ項目情報データベース２１２ｃから構成される。
【００３７】
サブシステム２２は、株式注文約定処理を実行する情報処理単位であり、株式注文約定処理の実行に必要な具体的な処理を行うためのシステム機能２２ａ及び２２ｂを有する。システム機能とは、サブシステムをさらに複数の情報処理単位に分割した場合の一情報処理単位であり、サブシステムよりも詳細なビジネスプロセスの処理単位毎に設定される。システム機能は、例えばデータの処理を行うプログラム、アプリケーション等の処理機能のみならず、例えばオブジェクト指向等により記述される場合の属性と操作を双方含む概念も含まれる。また、サブシステム２３は、株式決済処理を実行する情報処理単位であり、株式決済処理の実行に必要な具体的な処理を行うためのシステム機能２３ｃ及び２３ｄを有する。
【００３８】
ルーティングエンジン２１１ａは、ビジネスルールデータベース２１１ｂに格納されたビジネスルールに基づいて各サブシステム２２及び２３における情報処理の手順を決定するとともに、その手順に基づいて処理命令をサブシステム２２及び２３に出す。
【００３９】
データ項目情報データベース２１２ｃには、副標準データのデータ記述形式及び各地方データ記述形式のフォーマットが記憶されている。図４は副標準データ記述形式のフォーマットの構成の一例を示す図である。副標準データ記述形式の場合、ＩＳＩＮ（International Securities Identification Number：ＩＳＯ６１６６の推奨により規格化された有価証券等の識別コード）、約定年月日、株式約定数量、株式約定単価、名義区分という５つのデータ項目からデータが表現され、各データ項目には、各データ項目の属性として、説明、属性、データ長、小数点位置、不正値が対応づけられている。また、地方データ記述形式のフォーマットの構成の一例を示す図である。
【００４０】
図５はデータ記述形式変換ルールデータベース２１２ｂの詳細な構成の一例を示す図である。図５に示すように、副標準データ記述形式のデータ項目と地方データ記述形式のデータ項目が対応づけられている。さらに、地方データ記述形式のデータ項目には、副標準データを地方データに変換する変換手順が対応づけられている。
【００４１】
地方データ記述形式とは、サブシステム２２や２３における各種データ処理の際のデータを表現する形式であり、副標準データ記述形式とは、各サブシステムで使用されるそれぞれのデータ記述形式と互換性を有するデータ記述形式であり、各サブシステムで使用されるそれぞれのデータ記述形式の間の変換の際には、この副標準データ記述形式を経由することとなる。
【００４２】
ビジネスルールデータベース２１１ｂには、以上に示されるサブシステム２２やサブシステム２３、さらに詳細には各システム機能の処理手順が複数記憶されている。処理手順は、例えば各システム機能での処理を順序立てて行うための順序構造、各システム機能でのデータ処理結果等に応じて処理手順を選択する選択構造、各システム機能でのデータ処理結果が所定の条件を満たすまで所定のシステム機能での処理を繰り返し行う繰り返し構造、あるシステム機能でのデータ処理結果により与えられる複数の値のそれぞれに応じて処理を分岐させる多分岐構造、ある一つのシステム機能の処理終了後、複数のシステム機能に同時に処理を実行させる同時処理進行構造、各システム機能でのデータ処理結果等が少なくとも一つの条件を満たした場合に次のシステム機能での処理を開始する条件待ち構造や、これらの組み合わせ等により構成される。
【００４３】
このビジネスルールデータベース２１１ｂに格納された処理手順の具体例を図１３に示す。
【００４４】
例えば４つの処理手順ＩＤ（１〜４）を有する処理手順が図１３（ａ）〜（ｄ）に示されている。処理手順ＩＤが１の図１３（ａ）は、システム機能２２ａ，２２ｂ，２３ｃ，２３ｄの順に処理する処理手順を示す。処理手順ＩＤが２の図１３（ｂ）は、システム機能２２ａを処理後、システム機能２２ｂ及び２３ｃを同時処理し、各処理が終了した後システム機能２３ｄの処理を行う処理手順を示す。処理手順ＩＤが３の図１３（ｃ）は、システム機能２２ａ，２２ｂを順に処理し、その後システム機能２３ｃ及び２３ｄを同時処理する処理手順を示す。処理手順ＩＤが４の図１３（ｄ）は、システム機能２２ａ処理後、システム機能２２ａのデータ処理結果に示されるデータ項目のうち、約定単価の値が５００以上か５００未満かにより枝分かれする処理手順であり、約定単価≦５００の場合にはシステム機能２２ｂの処理を行い、約定単価＞５００の場合にはシステム機能２３ｃの処理を行い、いずれかの処理が終了した後システム機能２３ｄの処理を行う。
【００４５】
また、各処理手順における各システム機能での処理開始条件を例えば図１４に示すように設定してもよい。この処理開始条件は、図１３に示す処理手順に関連付けられてビジネスルールデータベース２１１ｂに格納される。図１４の例では、例えば処理手順ＩＤが１の場合、各システム機能の処理は前のシステム機能の処理が終了したことが処理の開始条件となっている。処理手順ＩＤが４の場合、システム機能２２ｂの処理は、システム機能２２ａのデータ処理結果のうち、約定単価≦５００が取得された後に開始され、システム機能２３ｃは約定単価＞５００のシステム機能２２ａのデータ処理結果を取得したことを条件に処理が開始され、システム機能２３ｄは、システム機能２２ｂ，２３ｃの処理が終了したことを条件に処理が開始されることを示している。
【００４６】
以上のように構成された情報制御システムの動作の一例を図６に示すフローチャートを用いて説明する。
【００４７】
まず、システムクラスタ間ハブ１のルーティングエンジン１１ａは、例えば本システム外部から処理命令を受けると、その処理命令に基づいてビジネスルールデータベース１１ｂを参照して処理手順を決定する（ｓ１）。例えばシステムクラスタ２での処理、システムクラスタ３での処理、システムクラスタ４での処理の順に処理手順が決定されると、ルーティングエンジン１１ａは、まずシステムクラスタ２に対して処理命令を出す（ｓ２）。この処理命令に基づき、システムクラスタ２による処理が開始される（ｓ３）。
【００４８】
システムクラスタ２による処理（ｓ３）の一例を図７に示すフローチャートに沿って詳細に説明する。
【００４９】
処理命令を受けたシステムクラスタ２のルーティング制御部２１１は、ビジネスルールデータベース２１１ｂを参照し、システムクラスタ間ハブ１の処理命令に基づいて処理手順を決定する（ｓ３１）。例えば前述した処理手順ＩＤが１の図１３（ａ）に示す処理手順、すなわちサブシステム２２でのシステム機能２２ａ、システム機能２２ｂ、サブシステム２３でのシステム機能２３ｃ、システム機能２３ｄでの処理の順に処理手順が決定されると、ルーティングエンジン２１１ａは、まず、サブシステム２２に対してシステム機能２２ａ、システム機能２２ｂの順に処理するように処理命令を出す（ｓ３２）。
【００５０】
処理命令を受けたサブシステム２２は、まずシステム機能２２ａによる処理を実行した後（ｓ３３）、システム機能２２ｂによる処理を実行する（ｓ３４）。これら処理の結果は、サブシステム２２に固有のデータ記述形式で得られる。サブシステム２２固有のデータ記述形式の一例を図８に示す。サブシステム２２は、システム機能２２ｂによる処理が終了すると、処理の終了をシステムクラスタ内ハブ２１に通知する（ｓ３５）。
【００５１】
システムクラスタ内ハブ２１のルーティングエンジン２１１ａは、処理の終了を受けて図８に示すデータ記述形式で得られたサブシステム２２固有の地方データを、次の処理手順を実行するサブシステム２３で用いられる地方データに変換するようデータ記述形式変換部２１２に命令を出す。データ記述形式変換部２１２のデータ記述形式変換ツール２１２ａは、データ記述形式変換ルールデータベース２１２ｂを参照してサブシステム２２固有の地方データを一旦システムクラスタ２固有の副標準データに変換する（ｓ３６）。さらに、得られた副標準データに対してデータ記述形式変換ルールデータベース２１２ｂを参照してサブシステム２３固有の地方データに変換する（ｓ３７）。
【００５２】
サブシステム２３用のデータ記述形式で得られる地方データの一例を図９に示す。図９に示すように、サブシステム２３用のデータ記述形式で得られる地方データのデータ項目は、サブシステム２２用のそれと一部が共通し、一部が異なる。
【００５３】
このサブシステム２２からサブシステム２３の地方データへの変換処理の一例を以下に示す。
【００５４】
例えば図８に示すように、サブシステム２２の銘柄コードというデータ項目のデータ長は５桁となっており、これを債券等に関する情報との識別情報も含むサブシステム２３の９桁の銘柄コードというデータ項目に変換する。これにより、図９に示すようなデータ記述形式の地方データが得られる。また、副標準データ記述形式では株式約定数量というデータ項目は１５桁のデータ長を有しており、これはサブシステム２２では、９桁のデータ長の約定済数量というデータ項目である。この約定済数量というデータ項目を一旦１５桁のデータ長の株式約定数量というデータ項目に変換する。さらに、この１５桁のデータ長の株式約定数量を約定数量に変換する。
【００５５】
また、サブシステム２２固有のデータ記述形式では約定済数量は不正値がnoneというように設定されており、この約定済数量に対応するサブシステム２３固有の約定数量というデータ項目では不正値は≦０（未約定状態）というように設定されている。データ記述形式変換部２１２はサブシステム２２固有の約定済数量というデータ項目を副標準データ記述形式の株式約定数量というデータ項目に変換する際に、不正値（≦０）か否かを判定する。
【００５６】
この不正値はデータ項目の妥当性検査に用いられる属性で、以下のような意義を有する。
【００５７】
不正値が０でない場合、すなわちnoneである場合には、次の処理手順に指定されたサブシステムに処理命令を出せるデータ記述形式に変換できるため、その処理手順下流のサブシステムへのデータ記述形式変換を実行する。不正値が≦０である場合、処理手順下流のサブシステムでは処理不可能なデータ記述形式であるとデータ記述形式変換部２１２は判定し、処理手順下流のサブシステムへのデータ変換処理を実行しない。これにより、処理手順上流のサブシステムで処理が確定していないのに次の処理手順のサブシステムの処理に進むという不都合を回避できる。
【００５８】
例えば図８に示すような地方データがデータ記述形式変換部２１２で判定される場合、不正値がnoneであるため、サブシステム２３に処理命令を出せるとデータ記述形式変換部２１２は判定し、サブシステム２３のデータ記述形式に変換する。なお、この判定は、サブシステム２３で使用される地方データのフォーマットをデータ項目情報データベース２１２ｃから参照し、この参照された不正値とサブシステム２２でのデータ処理結果に基づいて行われる。
【００５９】
次に、サブシステム２３でのデータ処理結果が図９に示すような場合、不正値が０、すなわち≦０であるため、次の処理プロセスに進めないデータ構造であるとデータ記述形式変換部２１２は判定し、副標準データへのデータ変換処理を実行しない。これにより、株式注文約定が確定したが株式決済のプロセスが確定していないのに次の処理プロセスに進むという不都合を回避できる。
【００６０】
なお、サブシステム２３へのデータ変換処理を実行しない場合には、サブシステム２２に対してデータ変換処理を実行できないデータ記述形式であることを通知してもよいし、ルーティングエンジン２１１ａに対してデータ変換処理を実行できないデータ記述形式をサブシステム２２から受けたことを通知してもよい。この場合、ルーティングエンジン２１１ａがサブシステム２２に対してデータ変換処理を実行できなかったデータの再処理命令を出してもよい。具体的には例えば、サブシステム２３によるデータ処理を実行しない場合には、サブシステム２２で処理されたデータ処理結果を一旦データ記述形式変換部２１２に設けられた図示しないデータベースに格納し、あるいはそのデータ処理結果をサブシステム２２ａに突き返し、あるいはそのデータ処理結果を消去する等の手法を取ることができる。
【００６１】
このように、各データ項目に不正値という属性を持たせ、データ変換可／不可の判定をシステムクラスタ内ハブ２１に実行させることにより、処理手順を進められない状況を容易に把握できるとともに、データの浄化機能が働く。
【００６２】
また、図８及び図９に示すデータ項目に対応してデータ属性“種類”が規定されている。この“種類”は、地方データと副標準データの種類を示すもので、このデータ項目が“local”に設定されている場合、そのデータ項目は地方データ固有のデータ項目、すなわちそのサブシステムに固有であって他のサブシステムにはその概念は存在しないデータ項目であることを示す。“dialect”に設定されている場合、その地方データのみならず副標準データと共通する、すなわち他のサブシステムとデータ記述形式は異なることがあるが、他のサブシステムにも存在するデータ項目であることを示す。“local”に設定されているデータ項目については、サブシステム内に隠蔽し、他のサブシステムから参照できないように設定するのが望ましい。これにより、サブシステムの独立性及び保守性を向上させることができる。従って、この“local”に設定されているデータ項目については本システムの管理対象外となり、本システムとは無関係に自由に設定することができる。
【００６３】
なお、上記サブシステム２２からサブシステム２３へのデータ変換処理の具体例はほんの一例にすぎない。
【００６４】
データ記述形式の変換が終了すると、データ記述形式変換部２１２はルーティングエンジン２１１ａに対して処理の終了を通知する。データ記述形式変換終了を受けて、ルーティングエンジン２１１ａは、サブシステム２３に対してシステム機能２３ｃ、システム機能２３ｄの順に処理するように処理命令を出す（ｓ３８）。処理命令を受けたサブシステム２３は、まずシステム機能２３ｃによる処理を実行（ｓ３９）した後、システム機能２３ｄによる処理を実行する（ｓ４０）。これら処理の結果は、図９に示されるようなサブシステム２３に固有のデータ記述形式で得られる。サブシステム２３は、システム機能２３ｄによる処理が終了すると、処理の終了をシステムクラスタ内ハブ２１に通知する（ｓ４１）。
【００６５】
サブシステム２３から処理の終了を受けたシステムクラスタ内ハブ２１は、サブシステム２３固有のデータ記述形式で取得されたデータをシステムクラスタ２固有の副標準データ記述形式に変換するようにデータ記述形式変換部２１２に命令を出す。データ記述形式変換部２１２のデータ記述形式変換ツール２１２ａは、データ記述形式変換ルールデータベース２１２ｂを参照してサブシステム２３固有の地方データをシステムクラスタ２固有の副標準データに変換する（ｓ４２）。データ記述形式の変換が終了すると、処理の終了をルーティング制御部２１１に通知する。
【００６６】
ルーティング制御部２１１は、このデータ記述形式変換処理の終了を受けると、そのシステムクラスタ２における処理が終了したと判定し、処理の終了をシステムクラスタ間ハブ１に通知する（ｓ４）。システムクラスタ間ハブ１のルーティング制御部１１は、このシステムクラスタ２からの処理の終了を受けて、システムクラスタ２固有の副標準データ記述形式で特定されるデータを標準データ記述形式に変換するようデータ記述形式変換部１２に命令を出す。データ記述形式変換部１２のデータ記述形式変換ツール１２ａは、データ記述形式変換ルールデータベース１２ｂを参照してシステムクラスタ２固有の副標準データを標準データに変換し（ｓ５）、標準データからシステムクラスタ３固有の副標準データにデータ記述形式を変換する（ｓ６）。データ記述形式の変換が終了すると、処理の終了をルーティング制御部１１に通知する。
【００６７】
標準データへの変換処理の終了を受け、ルーティングエンジン１１ａは、処理開始時に決定した処理手順に基づいて次の処理を行うべきシステムクラスタ３に処理命令を出す（ｓ７）。システムクラスタ３はこの処理命令を受けて上記システムクラスタ２と同様に副標準データ記述形式と地方データ記述形式との間のデータ変換を用いて処理を行い（ｓ８）、処理結果をシステムクラスタ３固有の副標準データ記述形式に変換して処理の終了をシステムクラスタ間ハブ１に通知する（ｓ９）。
【００６８】
ルーティングエンジン１１ａはこの処理終了の通知を受けてデータ記述形式変換部１２にシステムクラスタ３固有のデータ記述形式を標準データ記述形式に変換させ、さらに標準データ記述形式をシステムクラスタ４固有のデータ記述形式に変換させる（ｓ１０，１１）。変換が終了すると、ルーティングエンジン１１ａはシステムクラスタ４に処理命令を出す（ｓ１２）。システムクラスタ４はこの処理命令を受けて上記システムクラスタ２や３と同様の処理を行い（ｓ１３）、処理結果をシステムクラスタ４固有の副標準データ記述形式に変換して処理の終了をシステムクラスタ間ハブ１に通知する（ｓ１４）。
【００６９】
ルーティングエンジン１１ａはこの処理終了の通知を受けてデータ記述形式変換部１２にシステムクラスタ４固有のデータ記述形式を標準データ記述形式に変換させる（ｓ１５）。標準データ記述形式への変換が終了の通知をデータ記述形式変換部１２から受けたルーティングエンジン１１ａは、すべての処理が終了したと判定し、処理を終了する。
【００７０】
以上説明したように本実施形態によれば、それぞれが異なるデータ記述形式により処理される複数のサブシステムやシステムクラスタに対して単一のハブを設け、各サブシステムや各システムクラスタ間のデータ記述形式の変換をハブで行うことにより、複数存在するシステムの機能それぞれにデータ記述形式の変換手段を設ける必要がない。
【００７１】
具体的には例えば、ｎ個のサブシステムが設けられている場合、他のｎ−１個のサブシステムとの間のデータ記述形式の変換を行うデータ記述形式変換手段を設けることなく、ｎ個のサブシステムと副標準データ記述形式とのデータ記述形式の変換を行うデータ記述形式変換手段を設けるのみで、すべてのサブシステム間のデータ記述形式の変換を行うことができる。
【００７２】
また、これらデータ記述形式の変換をハブで一元的に行うことにより、各サブシステムの管理が容易となる。
【００７３】
具体的には例えば、新たにサブシステムを設ける場合には、そのサブシステムが対応づけられるハブのデータ記述形式変換ルールデータベース２１２ｂにそのサブシステムと副標準データ記述形式との変換ファイルを設けるのみで、そのハブに対応づけられた他のすべてのサブシステムとの間のデータ記述形式の変換が可能となる。また、サブシステムを変更する場合には、ハブの変換ファイルの当該サブシステムに該当する部分を変更するのみで対応可能である。また、サブシステムを削除する場合には、ハブの変換ファイルの当該サブシステムに該当する部分を削除するのみで対応可能である。
【００７４】
また、ハブにルーティングエンジンを設けることにより、各サブシステムには処理手順を判定する手段を設けることなく複数のサブシステムを用いた処理を所定の処理手順に基づいて実行できる。また、ルーティングエンジンで処理手順を一元管理することにより、各サブシステムに順序規則を関連付けて処理する必要がなく、システム管理が容易となる。
【００７５】
さらに、上記データ記述形式では、標準データ記述形式、副標準データ記述形式、地方データ記述形式という３階層のデータ記述形式により各データ処理を実行したが、このように複数の階層にデータ記述形式を分割し、かつ複数の下層のデータ記述形式と単一の上層のデータ記述形式で管理することにより、上層のデータ記述形式との間の一つのデータ変換手段を設けるのみで、データの互換性が確保されたサブシステムやシステムクラスタを追加することができる。また、ルーティングエンジンが参照するビジネスルールデータベースに、追加したサブシステムやシステムクラスタの処理を含む処理手順を組み込むのみで、追加したサブシステムやシステムクラスタを含む処理手順を簡便に実行可能である。
【００７６】
また、システム機能が増加してシステムが複雑化すると、システム全体の把握が困難となるが、本実施形態のように実際のビジネスプロセスの処理単位である株式注文約定や株式決済等をシステム機能に対応づけてシステムを構築することにより、実際のビジネスプロセスに沿ったシステムの把握が可能となる。従って、ビジネスプロセスに沿って実際のビジネスを遂行する者とシステムの設計開発者との間の情報伝達が円滑に行える。また、本実施形態では図１３（ｄ）のようにサブシステム２２のビジネスプロセスの処理後にサブシステム２３のビジネスプロセスの処理を行う場合に、サブシステム２２のシステム機能２２ａの処理結果に応じて、サブシステム２２のシステム機能２２ｂの処理を行うか、サブシステム２３のシステム機能２３ｃの処理を行うかを決めることができる。その結果、ビジネス変化に対する対応の迅速化が図れる。
【００７７】
また、各ハブにサブシステムやシステムクラスタとの間のデータ記述形式の互換性を有する共通規則を特定するデータ項目情報データベースが対応づけて設けられている。これにより、システムを追加する場合や新たに変更する場合等、システム管理者は対象とするサブシステムやシステムクラスタで用いられるデータ記述形式を定める場合の管理が容易となる。
【００７８】
本発明は上記実施形態に限定されるものではない。
【００７９】
上記実施形態ではデータが属する領域は特に言及していないが、各サブシステムやシステムクラスタ、ハブ等の情報処理機能毎にそれぞれ記憶手段を対応付け、データ処理の処理手順に従って処理すべきデータを処理手順に沿ってある情報処理機能の記憶手段から他の情報処理機能の記憶手段に出力してもよい。
【００８０】
また、各ハブには規則変換手段としてデータ記述形式変換部を備えた場合を示し、ハブでデータ記述形式を一元的に管理する場合を示したが、これに限定されるものではない。例えば、文字コード体系の変換や通信プロトコルの変換、データ項目の配列順序の変換（データの分解、選択、合成を含む）等、各システム機能で互いに相違するデータ記述形式以外の規則の変換をハブで一元的に行うこともできる。なお、データの分解、選択、合成とは、一つのレコードを２つのレコードにする、複数のレコードを一つのレコードにする、複数のレコードのうちの一部のみを残し、他のレコードを消去する等、種々の形態が考えられる。また、文字コードとは、例えばＪＩＳ（Japan Industrial Standards）、シフト−ＪＩＳ、ＥＵＣ（Extended UNIX Code）、ＥＢＣＤＩＣ（Extended Binary Coded Decimal Interchange Code）等、異なる規格により規定された文字コードを含む概念である。
【００８１】
文字コード体系の変換をハブで管理する場合には、ハブに各サブシステムや各システムクラスタで使用される文字コードと各文字コードとの間で互換性を有する共通文字コードとの文字コード体系変換手段を設けることにより本発明を適用可能である。
【００８２】
また、通信プロトコルをハブで一元的に管理する場合には、ハブに各サブシステムやシステムクラスタで使用される通信プロトコルと各通信プロトコルとの間で互換性を有する共通通信プロトコルとの通信プロトコル変換手段を設けることにより本発明を適用可能である。
【００８３】
さらに、各サブシステムやシステムクラスタで使用される文字コード体系や通信プロトコル以外のいかなる規則であっても、各サブシステムや各システムクラスタの規則との間で互換性を有する共通規則を定め、各規則と共通規則との間の変換をハブで行うようにすることにより本発明を適用することができる。
【００８４】
また、ハブ、システムクラスタ、サブシステム等、本システムを構成する情報処理機能と物理的なハードウェア構成の対応付けは種々考えられるが、例えば図１０に示すように、システムクラスタ間ハブ１をサーバ１００、各システムクラスタ２〜４を該サーバ１００にネットワーク５００を介して接続する対応付けでもよいし、ネットワークの介在しない単一の汎用コンピュータの記憶領域の各部にハブ、システムクラスタ、サブシステムを実現するためのプログラムを格納し、各記憶領域から各プログラムが読み出されることにより各システム機能の処理やルーティング、データ記述形式変換等が実行されるものであってもよい。より具体的には例えば、各クラスタをハードウェアとしてのコンピュータ１台に対応付けてもよい。コンピュータが異なると、データ保持形式、データ処理形式、通信方式等、規則が異なる可能性が高いためである。また、このように各クラスタをコンピュータ１台に対応づけた場合、クラスタの下位に位置づけられるサブシステムは例えばそのコンピュータ内にある複数の処理空間のそれぞれに対応づけてもよい。処理空間とは、具体的には例えば多重仮想記憶機構のアドレス空間や、階層的に体系化されたプロセス群の上位に位置するプロセスの個々を意味する。なお、さらに望ましくは、システムの処理内容をビジネス機能の観点から区分けし、サブシステムとして整理・管理する。サブシステム内のシステム機能は極めて密に結合され、各サブシステム同士の結合度は疎であることが望ましい。これにより、各サブシステムの保守性が向上する。なお、結合度の疎・密は、データの授受の疎・密に近い概念であり、例えば密結合の場合にはデータの授受を頻繁に行う必要がある形態であり、疎結合は、ごく少ない種類のインタフェース仕様や少量のデータ授受で成立する形態である。もちろん、クラスタ、サブシステムのハードウェアとの対応付けはここに示したものに限られない。
【００８５】
また、サブシステムのみにシステム機能を設ける場合を示したが、システムクラスタやハブにもシステム機能を設けてもよい。この場合、ビジネスルールデータベースにはシステムクラスタやハブのシステム機能における処理も含めた処理手順を格納しておくことにより、このようなシステム機能を含めた処理を実行することができる。
【００８６】
また、副標準データを介して異なるサブシステムへのデータ変換処理を行う場合を示したが、これに限定されるものではない。例えば、データ記述形式変換ルールデータベースには各サブシステムや各システムクラスタ同士を直接変換する変換規則を格納しておき、この変換規則に基づいて副標準データや標準データ等の共通規則を介さずにデータ変換処理を行ってもよい。
【００８７】
また、上記システムでは、使用するデータ記述形式として、地方データ、副標準データ、標準データの３階層のデータ記述形式を用いる場合で説明したが、これに限定されるものではない。例えば、地方データと標準データの２階層のシステムであれば、複数のサブシステムとこれらサブシステムを管理する一つのハブを有する構成でよい。また、地方データをさらに細分化し、４階層のデータ記述形式に本発明を適用してもよい。この場合、各階層にあるサブシステムを管理するハブをそれぞれ設けることにより本発明を適用可能である。
【００８８】
４階層のデータ記述形式に本発明を適用する場合のサブシステム２２の構成の一例を図１１に示す。図１１は図１〜図３におけるサブシステム２２に置換して適用される。図１１に示すように、サブシステム２２内にさらにハブ２２０とサブシステム２２０３，２２０４が設けられている。このようなサブシステム２２と同様にサブシステム２３を構成し、さらに他のシステムクラスタ３，４のサブシステムもこのようにハブ及びサブシステムから構成することにより、４階層のデータ記述形式が適用される。
【００８９】
もちろん、この図１１に示すサブシステム２２に設けられるサブシステム２２０３及び２２０４内にさらにハブ及びサブシステムからなるサブシステムを設けることにより、５階層のデータ記述形式が実現される。もちろん、同様の手法により６階層以上のデータ記述形式の階層化を実現することも可能である。
【００９０】
逆に、２階層のデータ記述形式を適用する場合、例えば図１２に示すように、複数のサブシステム複数のシステムクラスタ内ハブ２１，３１，４１がそれぞれ複数のサブシステム３２〜３４，２２〜２３，４２〜４４を管理し、かつ各システムクラスタ内ハブ２１，３１，４１がシステムクラスタ間ハブを介さずにデータ記述形式の変換を行う形態でもよい。このように、データ記述形式の階層を少なくすることにより、システムの管理が容易となる。すなわち、より少ない数のハブを管理することにより、すべてのシステムクラスタやサブシステムのデータ記述形式、ビジネスルールを管理することが可能となる。特に、ハブとシステムクラスタがサーバと端末というように物理的に別個のハードウェアに搭載される場合等には、単一のサーバ（ハードウェア）を参照することのみで他のすべての端末のデータ記述形式等の管理が可能となる。
【００９１】
また、上記実施形態ではシステムクラスタ、サブシステム及びシステム機能をビジネスプロセスの処理単位毎に設定する場合を示したが、他の処理単位毎に設定してもよいことはもちろんである。
【００９２】
【発明の効果】
以上詳述したように本発明によれば、簡便且つ効率的にビジネスプロセスを実現することができる情報制御システムを提供することができる。また、第１の上位情報処理手段に対応するビジネスプロセスの処理後に第２の上位情報処理手段に対応するビジネスプロセスの処理を行う場合に、第１の上位情報処理手段に対応するビジネスプロセスの処理のうち第１の下位情報処理手段に対応する詳細ビジネスプロセスの処理結果に応じて、当該第１の上位情報処理手段に対応するビジネスプロセスの処理のうち第２の下位情報処理手段に対応する詳細ビジネスプロセスの処理を行うか、第２の上位情報処理手段に対応するビジネスプロセスの処理のうち第３の下位情報処理手段に対応する詳細ビジネスプロセスの処理を行うかを決めることができ、ビジネスプロセスの状況変化に対する対応の迅速化を図ることができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態に係る情報制御システムの概念図。
【図２】同実施形態に係るシステムクラスタ間ハブの詳細な構成を示す図。
【図３】同実施形態に係るシステムクラスタの詳細な構成の一例を示す図。
【図４】同実施形態に係る副標準データ項目情報データベースの構成の一例を示す図。
【図５】同実施形態に係るデータ記述形式変換ルールデータベースの詳細な構成の一例を示す図。
【図６】同実施形態に係る情報制御システムの動作のフローチャートの一例を示す図。
【図７】同実施形態に係る情報制御システムのシステムクラスタの動作のフローチャートの一例を示す図。
【図８】同実施形態に係るサブシステム２２固有のデータ記述形式で得られる地方データの一例を示す図。
【図９】同実施形態に係るサブシステム２３固有のデータ記述形式で得られる地方データの一例を示す図。
【図１０】同実施形態に係る情報制御システムの変形例を示す図。
【図１１】同実施形態に係るサブシステムの変形例を示す図。
【図１２】同実施形態の変形例に係わる２階層のデータ記述形式による情報制御システムの概念図。
【図１３】同実施形態に係るビジネスルールデータベースに格納された処理手順の具体例を示す図。
【図１４】同実施形態に係るビジネスルールデータベースに格納された処理手順に関連付けられた処理開始条件の具体例を示す図。
【符号の説明】
１，１００…システムクラスタ間ハブ
２〜４…システムクラスタ
１１，２１１…ルーティング制御部
１１ａ，２１１ａ…ルーティングエンジン
１１ｂ，２１１ｂ…ビジネスルールデータベース
１２，２１２…データ記述形式変換部
１２ａ…データ記述形式変換ツール
１２ｂ…データ記述形式変換ルールデータベース
１２ｃ…データ項目情報データベース
２１，３１，４１…システムクラスタ内ハブ
２２，２３，３２〜３４，４２〜４４…サブシステム
２２ａ，２２ｂ，２３ｃ，２３ｄ…システム機能
２００，３００，４００…端末
２１２ａ…データ記述形式変換ツール
２１２ｂ…データ記述形式変換ルールデータベース
２１２ｃ…データ項目情報データベース
５００…ネットワーク

Claims

情報処理を行う複数の上位情報処理手段であって、それぞれが複数の下位情報処理手段を有する複数の上位情報処理手段と、
前記複数の上位情報処理手段による情報処理を行うための処理手順であって、前記複数の上位情報処理手段における前記下位情報処理手段による情報処理の処理手順を記憶する処理手順記憶手段と、
前記処理手順記憶手段に記憶された情報処理の処理手順に基づき、情報処理を行うべき下位情報処理手段を有する上位情報処理手段に対して当該下位情報処理手段に当該情報処理を行わせるための処理命令を出す処理命令手段と
を具備し、
前記上位情報処理手段は、当該上位情報処理手段が有する下位情報処理手段に情報処理を行わせるための処理命令を前記処理命令手段から受けて当該下位情報処理手段に情報処理を行わせ、当該下位情報処理手段の情報処理結果を前記処理命令手段に通知し、
前記処理命令手段は、前記処理命令を行った下位情報処理手段からの情報処理結果を受けると、前記処理手順記憶手段に記憶された処理手順に基づき、次の情報処理を行うべき下位情報処理手段を有する上位情報処理手段に対して当該下位情報処理手段に当該情報処理を行わせるための処理命令を出す情報制御システムにおいて、
前記複数の上位情報処理手段のうち第１の上位情報処理手段は第１の下位情報処理手段と第２の下位情報処理手段を有するとともに、前記複数の上位情報処理手段のうち第２の上位情報処理手段は第３の下位情報処理手段と第４の下位情報処理手段を有し、
前記処理手順記憶手段に記憶された処理手順は、前記第１の下位情報処理手段による情報処理、前記第１の下位情報処理手段の情報処理結果に応じた前記第２の下位情報処理手段又は第３の下位情報処理手段による情報処理、前記第４の下位情報処理手段による情報処理の順に情報処理を行うための処理手順を含み、
前記複数の上位情報処理手段の各々はビジネスプロセスの情報処理単位毎に設定されたものであり、前記上位情報処理手段が有する前記複数の下位情報処理手段の各々は当該上位情報処理手段でのビジネスプロセスの情報処理単位を分割した詳細ビジネスプロセスの情報処理単位毎に設定されたものである
ことを特徴とする情報制御システム。