JP2017513138A - スケーラブルなビジネスプロセスインテリジェンスおよび分散アーキテクチャのための予測的分析 - Google Patents

Abstract

スケーラブルで効率的なビジネスインテリジェンスプラットフォームおよび分析プロセスのためのシステム、方法、およびコンピュータプログラムプロダクトが開示される。概して、発明の技術、システム、およびプロダクトは、ビジネスまたはビジネスプロセスに関連するデータを受信することと、メタデータモデルに従って受信データを処理することとを含み、処理することは、複数のデータ部分の各々に対応するメタデータを生成することを含み、方法はさらに、データ部分に対応するメタデータに少なくとも部分的に基づいて、受信データを複数のデータ部分に分割することと、複数のデータ部分の各々およびメタデータを分散アーキテクチャに配置された複数のリソース全体にわたって分散することとを含む。メタデータモデルは、データを記述する特徴を備え、特徴は、セマンティック特徴と、抜粋、変換、負荷（ＥＴＬ）特徴と、使用法の特徴とを含む。

Description

関連出願
本願は、"Scalable Business Process Intelligence and Predictive Analytics for Distributed Architectures"と題された２０１４年３月３１日付けの米国仮特許出願番号第６１／９７３，００６号の優先権を主張する２０１５年３月３１日付けの米国出願番号第１４／６７５，３９７号の優先権の利益を主張する。

発明の分野
本発明は、データ管理、特に分散システムアーキテクチャ全体にわたるデータ管理に関する。より一層具体的には、本発明の概念は、分散システムアーキテクチャ全体にわたってデータを管理するように構成されたシステム、技術、および／またはプロダクトに関連する。データは、それに関係して／関連してデータが収集され、生成され、もたらされ、取得されるビジネスプロセスに関連するビジネスインテリジェンスおよび／または予測的分析を決定し、提供するという特定の目的のために管理される。

背景
既知のビジネスインテリジェンスおよび分析では、データは、任意の数の従来の偏析スキームを用いて（たとえば、製造、品質管理、出荷、受取、会計、人的資源、顧客関係などについて別個のリソースを含むアーキテクチャのように、特定の目的または部門について特定のリソースを指定する）アーキテクチャ全体にわたって分散され得る。当該アーキテクチャの各別個のコンポーネントは、処理リソースおよび／または格納リソースを含み得る。典型的な処理リソースは、ハードウェアおよび／またはソフトウェアを含み得る。いくつかのインスタンスでは、処理リソースは、（任意に処理リソースに対してローカルにまたは遠隔に格納され得る）ビジネスデータに関連するビジネスインテリジェンスを分析し提供するように構成された分析ソフトウェアなどのコンテキスト固有のツールを含む。

従来のビジネスインテリジェンスは、あるとすれば、上記のような従来のアプローチに従って、データが分散される「ウェアハウス」規約に格納されたデータを活用する。

ウェアハウスに入れられたデータは、それによってユーザが標準的なクエリ（たとえば従来の関係データベース構造に関連して使用するのに好適なＳＱＬクエリまたは他のクエリ）を策定し、処理のために制御エンティティ（たとえばデータ記憶コントローラ）にクエリを投入するプロセスを用いて発見され、場所が特定される。制御エンティティは、エンティティが通信しているすべてのリソースにクエリを包括的に分散し、各リソースについての結果を示す回答を受信する。

許容できる性能を実現するために、従来のビジネスインテリジェンスアプローチは、含まれるデータを用いて任意の操作または計算を行なうために、全データセットをメモリにローディングすることを必要とする。

データ分散に対する従来の総当たりアプローチは任意の特定のリソースに課される格納負荷を効果的に減少させ、多数のプロセッサ全体にわたって作業負荷を分割することによってジョブ処理時間を同様に低減させる一方、格納および処理パラダイムの知的でない性質により、システム全体および関連付けられたプロセスに対して著しい非能率がもたらされる。

たとえば、格納されたデータを用いて典型的な処理動作を行なうために、従来のアプローチは、全データセットをメモリに格納し、十分にローディングされたデータセットに対して対応する処理動作を行なうことを必要とする。当然、この要件は、任意の所与のリソースを用いて処理することができるデータセットの最大サイズに制限をもたらす。ビジネスデータ統合および分析はより一層大きくより複雑なデータセットに依存することから、したがって従来のアプローチは、実現可能な性能にハード限界を与える。

また、従来のデータ格納は、データセットのための各アクセスポイント（たとえばデータへのアクセスまたは所有権を有している各ユーザ）がアクセスポイントとデータセットとの間の１組の関連付けを（通常はデータポインタまたはレファレンスの形態で）維持するパラダイムに従う。システムオーバヘッド要件は、したがってデータセットへのアクセスを必要とするユーザの数の関数として増大する。一般的な目安は、データセットに関連付けられたユーザ当たりおよそ１０％の追加リソースキャパシティ（たとえばメモリ）をシステムが必要とするということである。したがって、システムが一人のユーザに関連付けられたデータセットを処理するために１００ＧＢのメモリを必要とするならば、同システムは、１０人のユーザに関連付けられている場合に同じデータセットを同様に処理するには、２００ＧＢのメモリを必要とすることになる。

したがって、高度のフットプリント減少を実現することができる（たとえば特に優れたフットプリント減少は１０：１という圧縮比を実現し得る）としても、従来の圧縮技術は、ユーザアクセス要件がわずかに増大するだけでもすぐに無効となる。

従来のＢＩは、従来のクエリ構造およびプロセスを活用して、総当たりアプローチに従って複数のリソース全体にわたって格納されたデータを場所特定し、検索する。その結果、異なる場所に格納された特定のデータに関して冗長性および不整合性（たとえばバージョン履歴）が存在し得る。しかしながら、それにもかかわらずクエリは、そのような冗長性、不整合性、または従来のアプローチに固有の他の問題点に関係なく、その中に規定された条件に適合するすべてのデータを報告することになる。

さらに悪いことに、処理の目的で全データセットをメモリに保持する要件は、増大するデータ要件またはシステム自体と比例しない困難な性能限界をシステムに課す。換言すると、約１ＴＢのフットプリントを有するデータセットが０．７５ＴＢのメモリにのみアクセスする場合、プロセスは、中断するか、または現実世界の制約下では許容できない遅いペースで進行する。

これらの分析プラットフォームの多くは、したがって従来のデータ管理技術の能力の限界に達し、性能の問題を解決するためにインメモリ解決策に頼っている。ビジネスインテリジェンスプラットフォームと関連付けてインメモリを用いて、設備は、分析クエリが開始される時間の間の待ち時間を短縮し、組織を前進させるために結果を用いることができる。

第１世代のインメモリＢＩプロダクトは、単一サーバ上にあるメモリの使用に限定される。この問題は、各ユーザごとに追加的に１０％ものデータオーバーヘッドも必要とするという事実によって悪化し、適度のデータボリュームでも大部分のサーバ上ですぐに限度に達する。

処理パワーおよびメモリのアベイラビリティの増大により、多くのプラットフォーム（サーバ／デスクトップ／ラップトップ）は、プロセッサおよびメモリの利用可能なコンピュータリソースを十分に利用していない。インメモリアプローチは、従来の（つまり「スピニングディスク」）データ管理からメインメモリ空間データ管理にデータを移動させることによって、データ管理場所から処理実行までの「往復」時間量を減少させる。たとえば、ディスク上に格納されたファイル、またはディスク上に情報を格納するデータベース管理システム（ＤＢＭＳ））。

これらのインメモリ実装例は、従来のアプローチのいくつかの共通の特徴に基づく。たとえば、インメモリ実装例は、（単一のユーザ環境のためのサーバまたはデスクトップまたはラップトップなどの）単一プラットフォーム上で利用可能なメモリ空間の範囲内での処理に限定される。加えて、インメモリ設備は、汎用データ管理リソースとして利用されるのではなく、項目（たとえばベンダー実装例）に従って典型的に分散される。

その結果、これらの従来のアプローチおよび環境の多くは、プラットフォームの（サーバ／デスクトップ／ラップトップ）メモリ空間上の利用可能なメモリのおよそ半分を利用する。この限定されたメモリ割当て内では、（格納されているデータの種類に大きく依存する）ほぼ３〜５倍の圧縮因子を単一のユーザ環境について実現することができ、システム全体においてデータフットプリントを効果的に減少させる。たとえば、２４ＧＢのメモリがある標準的なコモディティサーバ上では、ビジネスインテリジェンスプラットフォームのための大部分のインメモリ施設は、およそ３６ＧＢと６０ＧＢとの間のデータを有するデータセットの処理をサポートする。

汎用のＤＢＭＳではなく専用のインメモリデータ管理解決策を用いて、多くのビジネスインテリジェンスプラットフォームは、特定のデータ構造内の情報を分離し、その情報へのアクセスを制限する。様々な分離されたコンポーネントは、汎用データベースの容量では構成されないかまたは作用することができないため、特定のベンダーの方法によって、または複雑なデータアクセスシステムを介してのみ情報にアクセスすることができる。

したがって、ビジネスインテリジェンスプラットフォームにおけるインメモリの実装に関連付けられるコストがある。これらの初期段階インメモリ設備の多くは、特定のベンダーの実装に固有の独占的構造に基づく。これは、メモリ管理およびデータ圧縮に関してなされるべき特定の作業負荷の検討を可能にする。これらのコンポーネントは、プラットフォームに関連付けられた利用可能なメモリと、解決策によって管理される情報の知識とをベンダーが十分に活用することを可能にする。しかしながら、それらはチューニングおよびリソース割当てに関する限り「ブラックボックス」であり得る。このように内部の作業が見えないことは、設計者および管理者が彼らの特定の環境に適切にリソースを分散するのを妨げる可能性がある。

次に、インメモリ設備によって利用されるメモリ空間は、既存のプラットフォーム（サーバ／デスクトップ／ラップトップ）の内部を「スケールアップする」だけである。ユーザの数が増えるにつれて、環境についての容量要件も上昇する。各追加ユーザは、分析要件をオーバーラップさせるためにおよそ１０％をさらに必要とする。これは、データセット論理積および個人ユーザ情報についてのオーバーヘッドの形で生じる。これは、分析されるべきコアデータのための利用可能な空間の量を減少させる。一人だけではなく１０人のユーザをサポートする上記と同様のサーバ環境は、これらの制約により縮小されたデータセットをサポートすることが可能であろう。３６〜６０ＧＢのデータの代わりに、増大したユーザ要求により１５〜２５ＧＢの情報のみが同じメモリ空間において役立つであろう。

最後に、これらのインメモリ設備の多くは汎用データベースではないため、他の用途と情報を共有するのは困難である。ＮｏＳＱＬデータ管理プラットフォームを例外として、標準的なデータアクセス方法は、データストア全体にわたって情報を統合する経路である。しかしこれらの独占的構造は、長年にわたる構造化クエリ言語（ＳＱＬ）と通信して分析プラットフォームの外部に統合をもたらさない。

初期段階インメモリ技術を実施するための前述の標準的なアプローチは限定要因を導入する。

第一に、スケールまたはスケーラビリティが主要な事柄である。これらのプラットフォームが、増大しかつ広範囲の分析要件に適合することができることは、手作業で駆動される分割技術なしにインメモリをどこにどのように適用することができるかを著しく限定する。

第２に、すべてのインメモリアプローチに移動することは、「スピニングディスク」がデータ管理のための有効なオプションとして利用される現在の世界共通の業界標準からこの技術が逸脱していることから、互換性の問題を生じさせる。インメモリは、分析について増大している要件に対処する優れた答えである。それでもなお従来のデータ管理は、動作上および経済上の理由の双方から良好な補足物を提供することができる。

第３に、初期段階のインメモリ設備は、メモリ割当ておよびデータ圧縮によって性能向上を駆動するために技術的なメタデータを活用することに主に注目する。この狭い注目は、汎用メタデータモデルおよび性能管理パラダイムを採用することによって提供される利益全体を実現しない。

これらの制限に留意して、分散コンピューティングと、データ管理アプローチ間の協調と、追加的なメタデータ層の利用とによる向上によってビジネスインテリジェンスプラットフォームのためのインメモリ施設を提供して、分析環境の性能および経済面の両方を最適化することが有益であろう。

発明の概要
本明細書で開示される発明概念は概して、スケーラブルなビジネスインテリジェンスおよび分析に関連し、シームレスで効率的な技術、システムおよびコンピュータプログラムプロダクトを提供する。

一実施形態において、方法は、ビジネスまたはビジネスプロセスに関連するデータを受信することと、メタデータモデルに従って受信データを処理することとを含み、処理することは、複数のデータ部分の各々に対応するメタデータを生成することを含み、方法はさらに、データ部分に対応するメタデータに少なくとも部分的に基づいて、受信データを複数のデータ部分に分割することと、複数のデータ部分の各々および各それぞれのデータ部分に対応するメタデータを分散アーキテクチャに配置された複数のリソース全体にわたって分散することとを含む。メタデータモデルは、データを記述する特徴を備え、特徴は、セマンティック特徴と、抜粋、変換、負荷（ＥＴＬ）特徴と、使用法の特徴とを含む。

別の実施形態では、方法は、ビジネスの現在の状況を表す１つ以上のシード値を受信することと、所定の期間にわたるビジネスの複数の過去の状況を表す過去のビジネス状況データを受信することと、少なくとも１つのプロセッサを用いて、１つ以上のシード値および過去のビジネス状況データに基づくモデルを利用する１つ以上のビジネスプロセスを連続的にシミュレーションすることと、シミュレーションにおいて所期の数列からの偏差を検出することとを含む。

さらに別の実施形態では、コンピュータプログラムプロダクトは、コンピュータ読取可能なプログラム命令が包含されたコンピュータ読取可能な記録媒体を含み、コンピュータ読取可能なプログラム命令は、実行されると少なくとも１つのプロセッサに、ビジネスまたはビジネスプロセスに関連するデータを受信させ、受信データをメタデータモデルに従って処理させ、処理は、複数のデータ部分の各々に対応するメタデータを生成することを含み、さらに、データ部分に対応するメタデータに少なくとも部分的に基づいて、受信データを複数のデータ部分に分割させ、複数のデータ部分の各々および各それぞれのデータ部分に対応するメタデータを、分散アーキテクチャに配置された複数のリソース全体にわたって分散させるように構成され、メタデータモデルは、データを記述する特徴を含み、特徴は、セマンティック特徴と、抜粋、変換、負荷（ＥＴＬ）特徴と、使用法の特徴とを含む。

当然、上記は単に例示的な実施形態であり、様々な発明の特徴は、詳細な説明および図に記載されるようにより十分に認識されるであろう。

一実施形態に係るアーキテクチャを表す図である。 一実施形態に従う、ユーザ装置および／またはサーバに関連付けられた代表的なハードウェア環境を示す図である。 発明の一実施形態の原理に概ね従って動作する分散アーキテクチャを表す図である。 一実施形態に係る方法のフローチャートである。 一実施形態に係る方法のフローチャートである。

詳細な説明
以下の説明は、本発明の一般的な原理を例示することを目的としてなされ、本明細書においてクレームされる発明の概念を限定することを意図しているのではない。さらに、本明細書に記載の特定の特徴は、可能なさまざまな組合せおよび置換え各々において、記載されている他の特徴と組合わせて使用することができる。

本明細書において特に指定しない限り、すべての用語は、明細書において示される意味および当業者によって理解されるおよび／または辞書、論文等において定義される意味を含む、可能な最も広い解釈が与えられるべきものである。

また、本明細書およびそれに続く請求項において使用される単数形「ａ」、「ａｎ」および「ｔｈｅ」は、特に指定しない限り複数のものを含むことに注意しなければならない。

本願は、データ管理に言及する。より具体的には、本明細書で開示される発明の概念は、データ管理に該当し、複数のシステム全体にわたるデータの共有を可能にする優れた技術、システムアーキテクチャ、プログラムプロダクトなどを開示する。

本明細書で言及されるシステム、技術、プロダクトなどは、管理および／またはその動作に追加的なオーバーヘッドをもたらすことなくユーザ、管理者、（物理的および／またはバーチャルな）機械、アクセスポイントなどが既存のアーキテクチャに追加され得、かつ／または既存のアーキテクチャから取除かれ得る場合は常に「高度にスケーラブルである」と考えられる。

概略的な一実施形態では、方法は、ビジネスまたはビジネスプロセスに関連するデータを受信することと、メタデータモデルに従って受信データを処理することとを含み、処理することは、複数のデータ部分の各々に対応するメタデータを生成することを含み、方法はさらに、データ部分に対応するメタデータに少なくとも部分的に基づいて、受信データを複数のデータ部分に分割することと、複数のデータ部分の各々および各それぞれのデータ部分に対応するメタデータを分散アーキテクチャに配置された複数のリソース全体にわたって分散することとを含む。メタデータモデルは、データを記述する特徴を備え、特徴は、セマンティック特徴と、抜粋、変換、負荷（ＥＴＬ）特徴と、使用法の特徴とを含む。

別の概略的な実施形態では、方法は、ビジネスの現在状況を表す１つ以上のシード値を受信することと、所定の期間にわたるビジネスの複数の過去の状況を表す過去のビジネス状況データを受信することと、少なくとも１つのプロセッサを用いて、１つ以上のシード値および過去のビジネス状況データに基づくモデルを利用する１つ以上のビジネスプロセスを連続的にシミュレーションすることと、シミュレーションにおいて所期の数列からの偏差を検出することとを含む。

さらに別の概略的な実施形態では、コンピュータプログラムプロダクトは、コンピュータ読取可能なプログラム命令が包含されたコンピュータ読取可能な記録媒体を含み、コンピュータ読取可能なプログラム命令は、実行されると、少なくとも１つのプロセッサに、ビジネスまたはビジネスプロセスに関連するデータを受信させ、受信データをメタデータモデルに従って処理させ、処理は、複数のデータ部分の各々に対応するメタデータを生成することを含み、さらに、データ部分に対応するメタデータに少なくとも部分的に基づいて、受信データを複数のデータ部分に分割させ、複数のデータ部分の各々および各それぞれのデータ部分に対応するメタデータを、分散アーキテクチャに配置された複数のリソース全体にわたって分散させるように構成され、メタデータモデルは、データを記述する特徴を含み、特徴は、セマンティック特徴と、抜粋、変換、負荷（ＥＴＬ）特徴と、使用法の特徴とを含む。

概略的なネットワーキングおよびコンピューティング概念
本明細書では、モバイル装置が、物理的な接続（たとえばワイヤ、コード、ケーブル等）を介した電力供給なしでデータを受信することが可能で、かつ、物理的なデータ接続（たとえばワイヤ、コード、ケーブル等）なしでデータを受信することが可能な任意の装置であることが理解される。本開示の範囲に含まれるモバイル装置は、携帯電話、スマートフォン、タブレット、携帯情報端末、ｉＰｏｄ（登録商標）、ｉＰａｄ（登録商標）、ＢＬＡＣＫＢＥＲＲＹ（登録商標）装置等の代表的な装置を含む。

当然、本明細書に記載のさまざまな実施形態は、ハードウェア、ソフトウェア、またはその所望の組合わせを用いて実現し得る。そのために、本明細書に記載のさまざまな機能を実現することが可能な何らかの種類のロジックを使用してもよい。

本明細書の記載は、当業者が本発明を実施し使用することを可能にするために示され、本発明の特定の用途およびその必要条件という文脈においてなされる。開示されている実施形態のさまざまな変形は、当業者には直ちに明らかになるであろう。また、本明細書において定義される一般的な原理は、本発明の精神および範囲から外れることなく他の実施形態および用途に応用し得る。このように、本発明は、示されている実施形態に限定されることを意図しているのではなく、本明細書に開示される原理および特徴に従う最も広い範囲に一致するものである。

特に、本明細書に記載の発明のさまざまな実施形態は、複数のコンピュータシステム間の通信手段としてインターネットを用いて実現される。本発明が通信媒体としてのインターネットの使用に限定されないこと、および、本発明の代替方法が、私用イントラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはそれ以外の通信手段の使用に適応し得ることを、当業者は理解するであろう。加えて、有線、無線（たとえば無線周波数）および光通信リンクをさまざまに組合わせたものを利用してもよい。

本発明のある実施形態を実行し得るプログラム環境は、例示として、汎用コンピュータ、またはハンドヘルドコンピュータ等の専用機器を、１つ以上含む。このような機器（たとえばプロセッサ、メモリ、データ記憶装置、入力および出力装置）の詳細は、周知であり、わかりやすくするために、ここでは示さない。

本発明の技術がさまざまな科学技術を用いて実現し得ることも理解されるはずである。たとえば、本明細書に記載の方法は、コンピュータシステムで実行されるソフトウェアにおいて実現してもよく、または、方法の動作を実行するための１つ以上のプロセッサおよびロジック（ハードウェアおよび／またはソフトウェア）、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等のプログラマブルロジックデバイス、および／またはこれらをさまざまに組み合わせたものを利用するハードウェアにおいて実現してもよい。

また、様々な実施形態に係るシステムは、プロセッサと、プロセッサに統合され、かつ／またはプロセッサによって実行可能なロジックとを含み得る。ロジックは、本明細書に記載される処理工程のうち１つ以上を行うように構成される。統合されるということによって意味されるのは、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などといったハードウェアロジックとして埋込まれたロジックをプロセッサが有するということである。プロセッサによって実行可能ということによって意味されるのは、ロジックがハードウェアロジック、ファームウェア、オペレーティングシステムの一部、アプリケーションプログラムの一部などといったソフトウェアロジック、または、プロセッサによってアクセス可能であり、プロセッサによって実行されると何らかの機能をプロセッサに行なわせるように構成されたハードウェアおよびソフトウェアロジックの何らかの組合せであるということである。ソフトウェアロジックは、当該分野において知られているように、任意のメモリタイプのローカルおよび／またはリモートメモリに格納され得る。ソフトウェアプロセッサモジュール、および／またはＡＳＩＣ、ＦＰＧＡ、中央処理装置（ＣＰＵ）、集積回路（ＩＣ）、グラフィック処理装置（ＧＰＵ）などといったハードウェアプロセッサといった当該分野において知られている任意のプロセッサが使用され得る。

例示としてのあるアプローチにおいて、本明細書に記載の方法は、物理的な（たとえば一時的でない）コンピュータ読取可能な媒体等の記録媒体にある、コンピュータによる実行が可能な一連の命令によって、実現してもよい。加えて、本発明の特定の実施形態は、オブジェクト指向ソフトウェアプログラミングコンセプトを採用し得るが、本発明はそのように限定される訳ではなく、コンピュータの動作の他の指示形態の採用に容易に適応する。

本発明は、計算装置（たとえばプロセッサ）および／またはシステムによって実行され得るコンピュータコードを有するコンピュータ読取可能な記録または信号媒体を含むコンピュータプログラムプロダクトの形態で提供することもできる。コンピュータ読取可能な記録媒体は、読取専用のおよび書込可能なＣＤおよびＤＶＤ等の光媒体、磁気メモリまたは媒体（たとえばハードディスクドライブ、テープ）、半導体メモリ（たとえばＦＬＡＳＨ（登録商標）メモリおよびその他のポータブルメモリカード等）、チップにおいて符号化されたファームウェア等を含む、計算装置またはシステムが使用する、コンピュータ符号を格納することが可能な任意の媒体を含み得る。

コンピュータ読取可能な信号媒体は、上記記録媒体の部類には入らないものである。たとえば、例示としてのコンピュータ読取可能な信号媒体は、システム内で、システム間で、たとえば物理または仮想ネットワーク等を介して一時的な信号を伝達するかそうでなければ転送する。

図１は、一実施形態に従うアーキテクチャ１００を例示する。図１に示されるように、第１の遠隔ネットワーク１０４および第２の遠隔ネットワーク１０６を含む複数の遠隔ネットワーク１０２が設けられる。ゲートウェイ１０１は、遠隔ネットワーク１０２と近接ネットワーク１０８との間に結合されていてもよい。このネットワークアーキテクチャ１００の文脈において、ネットワーク１０４、１０６は各々、インターネット、公衆電話交換網（ＰＳＴＮ）、内部電話網等のＬＡＮ、ＷＡＮを含むがこれに限定されない形態を取り得る。

使用時、ゲートウェイ１０１は、遠隔ネットワーク１０２から近接ネットワーク１０８への入口のポイントとして機能する。このため、ゲートウェイ１０１は、ゲートウェイ１０１に到達した所与のデータパケットを導くことができるルータとして、および、所与のパケットに対してゲートウェイ１０１に出入りする実際の経路を与えるスイッチとして機能し得る。

ゲートウェイ１０１を介して遠隔ネットワーク１０２からアクセスすることが可能な、近接ネットワーク１０８に結合された少なくとも１つのデータサーバ１１４がさらに含まれる。なお、データサーバ１１４は、いずれかの種類の計算装置／グループウェアを含み得る。各データサーバ１１４に結合されているのは複数のユーザ装置１１６である。このようなユーザ装置１１６は、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、プリンタ、または任意のその他の種類のロジックを含み得る。なお、一実施形態において、ユーザ装置１１１もネットワークのいずれかに直接結合されていてもよい。

１つの周辺装置１２０または一連の周辺装置１２０、たとえば、ファクシミリ機、プリンタ、ネットワークされた記憶ユニット等が、ネットワーク１０４、１０６、１０８のうちの１つ以上に結合されてもよい。なお、データベース、サーバ、および／またはその他構成要素が、ネットワーク１０４、１０６、１０８に結合された何らかの種類のネットワーク要素とともに使用されてもよく、またはこれに組込まれてもよい。本明細書の文脈において、ネットワーク要素は、ネットワークのいずれかの構成要素を意味し得る。

いくつかのアプローチに従うと、本明細書に記載の方法およびシステムは、仮想システム、および／または１つ以上の他のシステムをエミュレートするシステム、たとえばＭＡＣ ＯＳ環境をエミュレートするＵＮＩＸ（登録商標）システム、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）環境を事実上ホストするＵＮＩＸシステム、ＭＡＣ ＯＳ環境をエミュレートするＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳシステム等とともに実現されてもよく、および／またはそのシステム上で実現されてもよい。この仮想化および／またはエミュレートは、いくつかの実施形態ではＶＭＷＡＲＥ（登録商標）のソフトウェアの使用を通して向上させてもよい。

さらに他のアプローチにおいて、１つ以上のネットワーク１０４、１０６、１０８は、一般的に「クラウド」と呼ばれているシステムのクラスタを表わしていてもよい。クラウドコンピューティングでは、処理能力、周辺機器、ソフトウェア、データ処理および／または記憶、サーバ等の共有リソースが、クラウド内の任意のシステムに、好ましくはオンデマンドの関係で与えられることにより、多数の計算システム全体におけるアクセスおよびサービスの分配が行なえるようにしている。クラウドコンピューティングは、典型的にはクラウド内で動作するシステム間のインターネットまたはその他高速接続（たとえば４Ｇ ＬＴＥ（登録商標）、光ファイバー等）を必要とするが、システムの他の接続技術を使用してもよい。

図１は、一実施形態に従うアーキテクチャ１００を例示する。図１に示されるように、第１の遠隔ネットワーク１０４および第２の遠隔ネットワーク１０６を含む複数の遠隔ネットワーク１０２が設けられる。ゲートウェイ１０１は、遠隔ネットワーク１０２と近接ネットワーク１０８との間に結合されていてもよい。このアーキテクチャ１００の文脈において、ネットワーク１０４、１０６は各々、インターネット、公衆電話交換網（ＰＳＴＮ）、内部電話網等のＬＡＮ、ＷＡＮを含むがこれに限定されない形態を取り得る。

使用時、ゲートウェイ１０１は、遠隔ネットワーク１０２から近接ネットワーク１０８への入口のポイントとして機能する。このため、ゲートウェイ１０１は、ゲートウェイ１０１に到達した所与のデータパケットを導くことができるルータとして、および、所与のパケットに対してゲートウェイ１０１に出入りする実際の経路を与えるスイッチとして機能し得る。

ゲートウェイ１０１を介して遠隔ネットワーク１０２からアクセスすることが可能な、近接ネットワーク１０８に結合された少なくとも１つのデータサーバ１１４がさらに含まれる。なお、データサーバ１１４は、いずれかの種類の計算装置／グループウェアを含み得る。各データサーバ１１４に結合されているのは複数のユーザ装置１１６である。このようなユーザ装置１１６は、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、プリンタ、または任意のその他の種類のロジックを含み得る。なお、一実施形態において、ユーザ装置１１１もネットワークのいずれかに直接結合されていてもよい。

１つの周辺装置１２０または一連の周辺装置１２０、たとえば、ファクシミリ機、プリンタ、ネットワークされたおよび／またはローカル記憶ユニットまたはシステム等が、ネットワーク１０４、１０６、１０８のうちの１つ以上に結合されてもよい。なお、データベースおよび／またはその他構成要素が、ネットワーク１０４、１０６、１０８に結合された何らかの種類のネットワーク要素とともに使用されてもよく、またはこれに組込まれてもよい。本明細書の文脈において、ネットワーク要素は、ネットワークのいずれかの構成要素を意味し得る。

いくつかのアプローチに従うと、本明細書に記載の方法およびシステムは、仮想システム、および／または１つ以上の他のシステムをエミュレートするシステム、たとえばＭＡＣ ＯＳ環境をエミュレートするＵＮＩＸ（登録商標）システム、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）環境を事実上ホストするＵＮＩＸシステム、ＭＡＣ ＯＳ環境をエミュレートするＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳシステム等とともに実現されてもよく、および／またはそのシステム上で実現されてもよい。この仮想化および／またはエミュレートは、いくつかの実施形態ではＶＭＷＡＲＥのソフトウェアの使用を通して向上させてもよい。

さらに他のアプローチにおいて、１つ以上のネットワーク１０４、１０６、１０８は、一般的に「クラウド」と呼ばれているシステムのクラスタを表わしていてもよい。クラウドコンピューティングでは、処理能力、周辺機器、ソフトウェア、データ処理および／または記憶、サーバ等の共有リソースが、クラウド内の任意のシステムに、好ましくはオンデマンドの関係で与えられることにより、多数の計算システム全体におけるアクセスおよびサービスの分配が行なえるようにしている。クラウドコンピューティングは、典型的にはクラウド内で動作するシステム間のインターネットまたはその他高速接続（たとえば４Ｇ ＬＴＥ、光ファイバー等）を必要とするが、システムの他の接続技術を使用してもよい。

図２は、一実施形態に従う、図１のユーザ装置１１６および／またはサーバ１１４に関連付けられた代表的なハードウェア環境を示す。この図は、システムバス２１２を介して相互に接続されたマイクロプロセッサ等の中央処理装置２１０およびそれ以外の多数の装置を有するワークステーションの典型的なハードウェア構成を例示する。

図２に示されるワークステーションは、ランダムアクセスメモリ（ＲＡＭ）２１４と、読取専用メモリ（ＲＯＭ）２１６と、ディスク記憶ユニット２２０等の周辺装置をバス２１２に接続するためのＩ／Ｏアダプタ２１８と、キーボード２２４、マウス２２６、スピーカ２２８、マイク２３２、および／またはタッチスクリーンおよびデジタルカメラ（図示せず）等の他のユーザインターフェイス装置をバス２１２に接続するためのユーザインターフェイスアダプタ２２２と、ワークステーションを通信ネットワーク２３５（たとえばデータ処理ネットワーク）に接続するための通信アダプタ２３４と、バス２１２をディスプレイ装置２３８に接続するためのディスプレイアダプタ２３６とを含む。

ワークステーションには、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）のオペレーティングシステム（ＯＳ）、ＭＡＣ ＯＳ、ＵＮＩＸ ＯＳ等のオペレーティングシステムが常駐していてもよい。好ましい実施形態は、上記のもの以外のプラットフォームおよびオペレーティングシステム上でも実現し得ることが理解されるであろう。好ましい実施形態は、オブジェクト指向プログラミング技法とともに、ＪＡＶＡ（登録商標）、ＸＭＬ、Ｃ、および／またはＣ＋＋言語、またはその他のプログラミング言語を用いて記述されてもよい。複雑なアプリケーションの開発のために使用されることが増えているオブジェクト指向プログラミング（ＯＯＰ）を用いてもよい。

アプリケーションは、モバイル装置にインストールされてもよく、たとえばモバイル装置の不揮発性メモリに格納されてもよい。あるアプローチにおいて、このアプリケーションは、モバイル装置上で画像処理を実行することを指示する命令を含む。別のアプローチにおいて、このアプリケーションは、ネットワークサーバ等の遠隔サーバに画像を送ることを指示する命令を含む。さらに他のアプローチにおいて、このアプリケーションは、モバイル装置上で一部またはすべての処理を実行するか否か、および／または画像を遠隔場所に送るか否かを判断することを指示する命令を含み得る。

様々な実施形態において、本明細書で開示される方法、システム、および／またはコンピュータプログラムプロダクトは、"SYSTEM AND METHOD FOR DISCOVERY OF BUSINESS PROCESSES"と題された２００５年１１月２日付けの関連する米国特許出願番号第１１／１６３，８６７号と、"STATE ENGINE FOR BUSINESS PROCESS EXECUTION"と題された２００５年１１月３０日付けの米国特許出願番号第１１／１６４，６１９号と、"METHOD AND SYSTEM FOR IMPROVING THE ACCURACY OF A BUSINESS FORECAST"と題された２００６年７月２１日付けの米国特許出願番号第１１／３０９，２８６号とに開示されている機能のうちのいずれかを利用し、かつ／または含み得る。

以下に述べるように、「データ」はデジタル（たとえばバイナリ）フォーマットによる情報のいずれかの表現を含むと理解されるべきである。同様に、「データセット」は、アレイ、ハッシュ、表、グラフ、ネットワーク、関係データベースなどを含む、現代のコンピューティングにおける従来から知られているデータ構造のうちのいずれかといった任意の既知のまたは好適なフォーマットで配置されたデータの集合を含むと理解され得るが、当業者はこのことを理解するであろう。

ビジネスインテリジェンス「データ」の共通の例は、受信されかつ／または消費されるリソースの任意の表現（たとえば発生した経費、受けた収益、在庫の目録など）、経過の尺度（たとえば経過時間、あらかじめ規定された目標への近さ、絶対量の蓄積など）、または、ビジネスプロセスを分析するコンテキストにおける任意の他の有益な情報を含むが、当業者はこれを本開示を読んで理解するであろう。

同様に、本明細書で言及される「メトリック」は、２つ以上のデータを組合せるかまたは評価することによって実現される任意の値、結論、結果、積などを含むと理解されるべきである。たとえば、上記の典型的なデータセットに続けて、ＥＸＰＥＮＳＥＳおよびＲＥＶＥＮＵＥを含むデータから算出され得る例示的なメトリックは、対応するＰＲＯＦＩＴ ＭＡＲＧＩＮを決定するためにＲＥＶＥＮＵＥからＥＸＰＥＮＳＥＳを減じることによって単純なシナリオで算出され得るＰＲＯＦＩＴ ＭＡＲＧＩＮとなる。当然、当業者が本明細書の記載を読んでビジネスプロセスにとって有用または有益であると認識するであろう任意の好適なやり方で任意の種類の他のデータを組合せてもよい。

ビジネスインテリジェンスプラットフォームのための初期段階のインメモリ施設の共通の要素への変更は、分散処理における発展を利用することである。多くの既存のビジネスインテリジェンスプラットフォームは、プラットフォームの（サーバ／デスクトップ／ラップトップ）ＣＰＵによる分散処理を利用することになる。マルチコアプロセッサにおける進歩がこの慣習を進めてきた。しかしながら、複数のメモリ空間全体にわたってデータを分配することができる点で、多くのビジネスインテリジェンスプラットフォームは、単一プラットフォームアプローチに注目している。単一プラットフォームアプローチは、アドレス指定可能なメモリ空間の量を限定するか、またはプラットフォームがサポートできるメモリの量に制約される。これは「スケーラビリティ」または単一のメモリ空間に「スケールアップする」能力と称されるシステムの属性である。

マルチＣＰＵコア全体にわたる並行処理だけでなく、複数のメモリ空間全体にわたる並行処理を利用するために複数のプラットフォーム全体にわたって分岐することは、拡大するデータ要件と一致する大きな機会をもたらす。この概念は、マルチメモリ空間全体にわたる「スケールアウト」と呼ばれる。スケールアウトすることができるプラットフォームは、さらなるハードウェアを追加することにより効果的に拡大して、概ねいずれのデータ要件も満たすことができる。調整された並列使用のためにマルチコモディティハードウェアコンポーネントを集約することは、単一の大きなサーバ環境よりも有効な解決策である。

技術獲得コストも有益に引き下げられる。アーキテクチャおよび実装の自由度が増大される。また、最も重要なことに、アドレス指定可能なメモリ空間の量が増大する。単一の環境上で利用可能なメモリの量を追加的なユーザがどのように低下させたかを示すために上の例を用いた。「スケールアウト」は、ユーザを増大させつつ同じ量のデータが使用されることを可能にする。この種の環境も、記載した増大するデータ要件をサポートする。

マルチプラットフォーム（サーバ／デスクトップ／ラップトップ）にまたがる容量の補足は、「スピニングディスク」ＤＢＭＳ設備と調和して、権利データ管理ツールをジョブに使用する能力である。インメモリオプションおよび在来型オプションの両方を使用することで、構造およびアーキテクチャの自由度がより大きくなる。これにより、ほぼリアルタイムの動作アクセスを必要とするデータをインメモリ設備内に位置決めすることが可能となる。応答要件がより低いデータは、「スピニングディスク」環境内に位置することができる。

この状況により、データ増大に関連付けられるリスクの緩和も可能となる。単一プラットフォーム「スケールアップ」状況またはマルチサーバ「スケールアウト」環境のいずれにおいても、メモリ空間は避けられない制限事項である。この状況では、ビジネスインテリジェンスプラットフォームが２つの状況の一方に陥るリスクがある。プラットフォームは、利用可能な空間の不足のために故障することになる。他のオプションは、オペレーティングシステムが「仮想メモリ」によってメモリ管理を引き継ぐか、またはメインメモリと「スピニングディスク」との間で情報交換を開始することである。

オペレーティングシステムは汎用のためにこのタスクを行なっているため、分析アプリケーションの性能が影響を受けることになる。この状況において、管理者は、故障または性能低下のリスクを緩和するために限定されたオプションを有する。補足的なコンポーネントとして従来のデータベースを利用することによって、「スピニングディスク」ＤＢＭＳのパワーを用いて特定レベルの性能を維持することができる。

最後に、ビジネスインテリジェンスプラットフォームは、管理する情報に関連付けられるメタデータのパワーを利用し始めたばかりである。技術的なメタデータは、長い間分析に関連付けられる情報管理の一部であった。ビジネスインテリジェンスプラットフォームにとって利用可能なセマンティックメタデータのレベルが増大するにつれて、より広範囲のメタデータを使用する価値が高まる。インメモリかまたは「スピニングディスク」であるかに関わらず、同様のデータセットおよび共通ドメインメトリックをデータ管理環境内に配列することができる。データを配列し調整することにより、分析の処理に関連付けられるさらなる価値が与えられる。顧客情報をともに配列することができる。その上、収益に関する詳細なデータを、微小粒子情報に関連付けられる集約またはロールアップメトリックによって位置決めすることができる。

ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）解決策
分析的な応答が向上したドライバにより、ビジネスインテリジェンスプラットフォームは、インメモリ技術の実現に向かって迅速に進んでいる。これらの実装例の多くは、あらかじめ規定されたデータ構造および組織スキームを必要とすること、マルチメモリ空間への「スケールアウト」能力不足、および調整されたメタデータ設備の不足などの限定要因を共有する。これらの境界を乗り越えることが従来のアプローチの制約を克服するために重要であり、それにより、分散システムアーキテクチャおよび技術がコンテキスト固有の「ワンオフ」解決策の寄せ集めから、性能に基づくデータ管理のためのユビキタスで効率的、かつ永続的な汎用の解決策へと移行することが可能となる。

１つのアプローチはいわゆる「ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）」データ管理機能であり、上記の従来のインメモリ技術に対するいくつかの解決策を可能にする。理解を容易にするために、本明細書に開示される「ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）」アプローチは、当該分野において知られている従来の「Ｍａｐ−Ｒｅｄｕｃｅ」アプローチ（たとえば「Ｍａｐ−Ｒｅｄｕｃｅ」、ウィキペディア、http://en.wikipedia.org/wiki/MapReduce参照（最新アクセスは２０１４年２月２１日））を参照して比較的に考察され得る。

ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は好ましくは、分散サーバベースのアプローチを用いる。これは、他のデスクトップサーバ実装例または単一サーバ実装例とは異なる。「スケールアウト」機能を用いることによって、ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、単一のメモリ空間に依存するのではなく、マルチメモリ空間全体にわたって組織が拡大することを可能にする。単一のメモリ空間は、上で述べたように、利用可能なメモリを使い果たし、かつ／または、仮想メモリの管理についてオペレーティングシステムに依存するという制限を有する。これらの問題は両方とも、ビジネスステークホルダによって必要とされる性能レベルを組織が満たすのを妨げる可能性がある。

ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）を含む本明細書で開示される技術は、ユーザ、設計者および管理者がマルチコモディティハードウェアベースの解決策によってビジネスステークホルダの要件を計画し満たすことを可能にする。必要に応じて追加的なコモディティハードウェアを実装することができることにより、管理者は、増大するデータ要件を満たすために経済的かつ動的に拡大することができる。

インメモリ性能について「スケールアウト」能力が付随することは、マルチデータ管理オプション全体にわたってデータ要件を管理する能力を与える発明のアプローチである。手短かに言って、すべてのデータが、インメモリ処理および格納設備の速度および性能を必要とするとは限らない。インメモリの性能を従来の「スピニングディスク」能力の均衡属性と一致させることは、正しいジョブに正しいツールを使用することができることを意味する。本明細書で述べられるパラダイムは、従来のデータ管理環境に及ぶインメモリ設備を提供する。これは、１つのプラットフォームでいくつかの課題に対応することができる。ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、プロセスおよびクエリ障害なしに「スピニングディスク」ＤＢＭＳの追加的な処理パワーおよびデータ格納装置をユーザが利用することを可能にする。

本技術は、両方の動作環境に関する管理者設計能力を容易にし、彼らの固有のビジネス状況の要件を査定する。インメモリおよび「スピニングディスク」オプションの両方にわたってデータがどのように割当てられるかについて決定を下すことができる。管理者は、既存の環境と長期的なデータセンターおよび予算源とに関連してそれらの要件を均衡させることができる。ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、本明細書で開示されるように、「スケールアウト」のための増大したサーバによるデータサイジングだけでなく、予算および動作上の検討事項も満たすようにプラットフォームを設計し構成する能力を提供する。

ビジネスインテリジェンスプラットフォームがインメモリおよび「スピニングディスク」データ管理の両方を最大限に利用することを可能にするさらに別の属性は、包括的なメタデータ管理設備である。これは、分析の技術的なメタデータを判定するだけの能力以上のものであり、メタデータの意味的な属性、ならびにメトリックおよびクエリの使用情報に及ぶ。これらの属性をすべて識別し管理することができることにより、設計およびアーキテクチャの権限が、オペレーティングシステムやブラックボックス構造ではなくプラットフォーム管理者の手に委ねられる。

このレベルのメタデータ洞察は、本明細書で「メトリックマート」と称されるツールによってもたらされる。メトリックマートは、どの情報がインメモリに存在するべきであり、どのデータ要素が「スピニングディスク」データ管理によって最も良く作用されるかについての可視性をもたらす。決定は、技術的側面のみに基づくものではない。設計者は、ビジネス情報を共有メモリ空間に位置決めして、特定の分析作業負荷についての集約を容易にするように設計することができる。

本質的には、メトリックマートは、データ、メタデータおよびメトリックの認証状態を維持する単一の企業ライブラリである。これは、分散アーキテクチャの様々なリソース全体にわたるコードレス分析および向上したデータアクセスを可能にし、ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）が分散アーキテクチャ全体にわたるメモリおよび処理リソースの開発を可能にすることから、ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）と組合せると特に有力である。

インメモリ設備を最善利用するための権限をビジネスインテリジェンスプラットフォームに与え、"one size fits"を回避することに関連付けられる要素のすべてが、多くのビジネスインテリジェンスベンダーがインメモリの実装とともに取るあらゆるアプローチ。データ管理設備と利用可能なメタデータの高度な使用とのスケールアウト混合使用は、障壁を回避する機会をもたらす。ビジネスインテリジェンスおよび分析のためのインメモリへのＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）アプローチは、これら特定の要件を満たし、初期段階インメモリ実装例に関連付けられる落とし穴を回避するように組織を位置決めする。

一般に、ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、インメモリデータ管理アプローチを分散システムアーキテクチャおよび関係データベース概念と組合せて、結合力のあるエンジンによる包括的なデータ格納および処理解決策を提供する。エンジンは、３つの有効化規則（１）分散アーキテクチャのすべてのポイントの間で共有され、すべてのデータがエンジンによってまたはアーキテクチャ全体にわたって管理されるための単一のメタデータモデル、（２）（たとえば、上記し、かつ代替的に「メトリックマート」と称される単一のメタデータモデル内にあるメタデータに従って）前処理されたデータを体系化するように構成された（好ましくは関係）データベース管理システム（ＤＢＭＳ）、および（３）単一のメタデータモデルおよび管理システムを採用するための分散アーキテクチャ上で動作する。

より具体的には、単一のメタデータモデルは３つの主要な局面に関して理解され得る。一局面では、モデルは、セマンティックモデル-定義、時間内訳、利用可能な寸法、これらの寸法の性質（ディクショナリ、固有値）、ユーザアクセス制限、相互依存などに関するメトリックおよび記録（事実）の記述であり、当業者はこのことを本明細書の記載を読んで理解するであろう。第２の局面では、モデルは、抜粋、変形、負荷（ＥＴＬ）モデルである。換言すると、メタデータは、メトリックおよび記録のソース、リフレッシュ頻度およびボリューム、上書きロジックなどとして機能し得るが、当業者はこのことを本明細書の記載を読んで理解するであろう。第３の局面では、モデルは使用法のモデルであり、メタデータは、これらのメトリックおよび記録がダッシュボードおよびレポートのどこでどのように使用されるかを記述する。

以下で言及されるように、前処理データは、前述の局面のうちの１つ以上に従ってデータを前処理して、単一のメタデータモデルに従った前処理されたデータに関連してメタデータを生成し、操作し、関連付けることなどを含み得る。

たとえば図３に表されるような典型的なアーキテクチャ３００を参照して、本明細書で開示される発明概念を１つの例示的な実施形態に従って概略的に提示する。

一般に、ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は３ステップのプロセスに従って機能する。まず、データが分散アーキテクチャ３００全体にわたって分割される。第２に、データリクエストがデータサービスによって受信される。第３に、リクエストに対する応答が生成され、処理される。各ステップに関するさらなる詳細は以下に示される。

データ分割および分散に関し、一般に、データは、データ管理システム（好ましくはＤＢＭＳ、たとえば上記の「メトリックマート」）によって前処理され、すべての利用可能なサーバリソース全体にわたって結果が分割される。分割は、管理者によって任意に規定されるメタデータベースのヒューリスティックスおよびあらかじめ規定された格納規約、慣行などを含む要因の何らかの組合せに由来したモデルに従って行なわれる。単一サーバのメモリ内では、データは上記の前処理に従って規定されるメタデータに基づいて配置される。たとえば、データは、メタデータセマンティック特徴、ＥＴＬ特徴、使用特徴などの上に配置され得る。

データが分割された後のデータリクエストの受信に関して、一般にＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、分散アーキテクチャの広い区域全体にわたって採用されている同じ包括的な単一のメタデータモデルに基づいてデータ消費者（たとえば、ダッシュボード、レポートエンジン、警告エンジンなど）間の通信を容易にすることによって動作する。

たとえば、上記図３を参照して、一実施形態では、クライアントリクエストまたはリクエスト１がデータサービスによって受信される。リクエスト１は、クライアントによって、または分散アーキテクチャ内の、もしくは分散アーキテクチャと通信する別のコンポーネントによって、任意に生成され得る。

有利に、リクエスト１は単一のメタデータモデルに対応する（つまり、単一のメタデータモデルによって、または単一のメタデータモデル内で理解可能な）フォーマットで受信される。１つの例示的なシナリオでは、単一のメタデータモデルに伴うリクエストは、「過去１２か月を包含する期間についてのデータポイント：ＲＥＶＥＮＵＥ、ＥＸＰＥＮＳＥＳおよびＰＲＯＦＩＴ ＭＡＲＧＩＮを算出し、基準：ＤＥＰＡＲＴＭＥＮＴおよびＣＯＵＮＴＲＹに従ってそれらの結果を分類する」ことを実質的に示すフォーマットで表され得る。リクエストは単一のメタデータモデル用語で表されるため、それらは（たとえばデータサービス内の）ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）エンジンによって効率的に処理されることができ、処理されたリクエスト２は、それぞれのサーバ、たとえば一実施形態における適切なＲＥＶＥＮＵＥ、ＥＸＰＥＮＳＥおよびＰＲＯＦＩＴ ＭＡＲＧＩＮデータをホストするサーバにマッピングされる。

概ね先の例に伴う一実施形態では、どこでもホストされるのではなく、実際にホストされるＲｅｖｅｎｕｅおよびＥｘｐｅｎｓｅからオンザフライで算出されるため、メトリック「ＰＲＯＦＩＴ ＭＡＲＧＩＮ」を具体的に紹介した。

前処理に引き続き、マッピングされたリクエスト２は、単一のメタデータモデルを用いて、受信したクライアントリクエスト１に基づいてそれぞれのサーバに分散される。続いて、各サーバは、それによって受信されたマッピングされたリクエスト２を処理する。受信後、サーバは、マッピングされたリクエスト２を処理して、対応するリクエストされたデータがすでにメモリにローディングされている（またはそうでなければメモリ内に存在する）かを判定する。そうであれば、データはメモリに集められ得る。あるいは、データが部分的にのみメモリに、部分的にほかの場所（たとえばＤＢＭＳ内）または完全にほかの場所に存在する場合、サーバは（たとえばＤＢＭＳへの）適切なクエリ３を生成し、実行して、リクエストされたデータを場所特定する。

リクエストされたデータを場所特定した後、任意の必要な処理、たとえば単一サーバ上に別個に格納されたデータの集約、フィルタリング、フォーマット化などがサーバによって任意に行なわれてもよく、場所特定されたデータ４の結果として生じる（集約されたかまたは当初の）単一の「チャンク」は、応答５でデータサービスに返されてもよい。

データサービスは、応答５を受信し、当初のリクエスト１に関連するデータの部分を集約し、データのいずれかの必要な処理、算出、評価、操作、フォーマット化などを行なって、当初の（クライアント）リクエスト１に応じるのに必要な動作を行なう。

たとえば、上に記載した例示的なシナリオによれば、ＥＸＰＥＮＳＥＳおよびＲＥＶＥＮＵＥは様々なサーバ上に格納されたデータであり、ＰＲＯＦＩＴ ＭＡＲＧＩＮは、それらのデータを用いて算出され得るメトリックである。集約されたＥＸＰＥＮＳＥおよびＲＥＶＥＮＵＥデータを応答５の形態でそれぞれのサーバから受信すると、データサービスは、それらの集約データを利用して、対応するＰＲＯＦＩＴ ＭＡＲＧＩＮを対応する期間で算出し得る。

必要なメトリックをデータから算出しかつ／または集約した後、最終結果が集められ、当初のリクエスト１を投入したクライアントに、コンテキストが適切な応答６で返される。プロセスは、ユーザの想像と、分散アーキテクチャ全体にわたって分割されたデータにおいて表わされた属性の深さおよび幅とによってのみ限定される任意の数の基準に従って任意の回数繰り返されかつ／または変更され得る。

図４を参照し、分散アーキテクチャ全体にわたってデータを管理するための方法４００の典型的な実施形態が示される。方法４００は、データ管理のためのＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）解決策への１つの例示的なアプローチと捉えられ得る。方法４００は、図１〜図３に表されたものを含む任意の好適な環境、または本明細書の記載を読んで当業者が理解するであろう任意の他の好適な環境において行なわれ得る。

示されるように、方法４００は動作４０２を含み、ビジネスまたはビジネスプロセスに関連するデータが受信される。

動作４０４では、受信されたデータがメタデータモデルに従って処理される。メタデータモデルは、セマンティック特徴、ＥＴＬ特徴および使用法の特徴などのデータを記述した特徴を含む。処理は、データの複数の部分（データ部分の各々）に対応するメタデータを生成することを含む。

動作４０６において、受信データは、各それぞれのデータ部分に対応するメタデータの分析に少なくとも部分的に基づいて、複数のデータ部分に分割される。

動作４０８でにおいては、データ部分の各々が、対応するメタデータと共に、分散アーキテクチャに配置された複数のリソース全体にわたって分散される。

当然、様々なアプローチにおいて、本明細書の記載を読んで当業者が理解するであろう任意の組合せ、置換、合成、および／または変更において１つ以上の追加的なかつ／または代替的な特徴を含むことが有利であり得る。たとえば、いくつかの例示的な実施形態では、本明細書で開示される方法４００は、以下の特徴または動作のうちいずれか１つ以上を含み得る。

特に好ましいアプローチでは、方法は、データのいくつかまたはすべてに関連するリクエストを受信することと、複数のリソースのうちの１つ以上に対するリクエストを、リクエストにおけるメタデータに基づいて分散アーキテクチャにマッピングすることと、リクエストのマッピングに応じて、複数のリソースの各々から１つ以上の応答を受信することと、１つ以上の応答を処理してレポートを生成することと、リクエストが受信されたリソースにレポートを返すこととをさらに含む。

リクエストは、データに対応するメタデータを含み得る。たとえば、ＰＲＯＦＩＴ ＭＡＲＧＩＮのリクエストは、ＲＥＶＥＮＵＥおよびＥＸＰＥＮＳＥメタデータを含む。

データのシームレスで効率的な分散および分析を容易にするために、マッピングは、好ましくはリクエストに関連するデータサービスが存在する少なくとも１つのリソースにリクエストを導く。

方法は、１つ以上の応答を集約する前にリクエストされたデータの場所を判定することも含み得る。判定される場所は「インメモリ」または「アーカイブ」のいずれかであり、「インメモリ」は、処理タスクを行なうプロセッサ、Ｉ／Ｏのために搭載された記憶装置、データの格納または管理のためにローディングされたＤＢＭＳなどの、分散アーキテクチャによってアクティブユーズのために現在ローディングされているリソースを示す。一方、データロケーション「アーカイブ」は、現在「インメモリ」ではない分散アーキテクチャの（記憶装置などの）リソース、または現在「インメモリ」ではないデータベース管理システム（ＤＢＭＳ）における格納場所のいずれかに対応する。

リクエストされたデータの場所が「インメモリ」であると判定されると、分散アーキテクチャの全体にわたるデータの分散および処理を効率的にかつシームレスに可能にするために、この判定に直接応じて処理が優先的に行なわれる。

方法は、リクエストされたデータの少なくともいくつかの場所が「アーカイブ」であるとの判定に応じて１つ以上のリクエストを作成することと、クエリを実行して「アーカイブ」ロケーションからデータを検索することとをさらに含む。

方法は、「アーカイブ」ロケーションから検索したデータをメモリにローディングすることと、ローディングに応じてリクエストされたデータの場所が「インメモリ」であると判定することとをさらに含む。好ましくは、リクエストされたデータの場所が「インメモリ」であるとの判定に直接応じて集約することが行われる。

方法は、データに基づいて１つ以上のメトリックを算出することを含み得る。
レポートは、好ましくは、データ、メトリック、およびリクエストのうち１つ以上に少なくとも部分的に基づく。たとえば、レポートは、供給されたメトリックおよび／またはリクエスト自体を考慮したデータの文脈分析を含み得る。方法は、データに基づいて１つ以上のメトリックを算出することも含み得る。この場合、レポートは、データ、メトリック、およびリクエストのうち１つ以上に少なくとも部分的に基づく。

好ましくは、各データ部分は、受信されたデータのすべての他のデータ部分と重複しない少なくとも１つの特徴によって特徴付けられ、各データ部分は、少なくとも１つのメタデータラベルと関連付けられる。

連続シミュレーション
別の局面では、本明細書で開示される技術は、プロセスインテリジェンスをさらに拡張する有力な予測分析機能を活用し得る。連続シミュレーションと呼ばれる新しい機能は、本明細書に記載されるシステムおよび技術によってビジネスプロセスが監視されることに基づく、向上した動作予測のためのメカニズムを提供する。これらの予測は、収集されている実際の動作データに基づいて連続的に更新され改良され、より高い精度をもたらす。

連続シミュレーションは、従来の統計的および静的プロセスモデルベースの予報アプローチの制約を克服する。従来の統計的技術は、定常的な傾向の予測に適切であるものの、過去のパターンへの突然の変更の影響を検出し予測することができない。静的プロセスモデルは、モデル品質による問題と、シミュレーションされている状態に関係する不正確な想定とによる成績不良をもたらすことも多い。連続シミュレーションは、動作システムによって確認される動的プロセスモデルを用いることによって、これらの問題を排除し、最新の状態に基づいて連続的に調整する。

１つのアプローチでは、連続シミュレーションは以下の概略的な特徴を含む。まず、ビジネスの現在状況が判定され、受信され、規定されるなどされる。本質的には、ビジネスの状況は、当該分野において知られている任意の形態を取り得、任意の好適なデータ、モデルなどを用いて表され得る。好ましいアプローチでは、ビジネスの現在状況は、たとえばプロセスシュミレーションのための初期状態として使用するのに好適な１つ以上のシード値として、ビジネスインテリジェンスによって得られる。ビジネスの状況は、ユーザによって、所定のもしくはあらかじめ規定された「デフォルト」状況によって、ビジネスプロセスもしくはビジネスプロセスのグループからの出力として、または任意の他の好適なやり方もしくは技術の組合せに従って得られ得るが、当業者はこのことを本明細書の記載を読んで理解するであろう。

好ましくは、ビジネスの状況は、相応する過去のビジネス状況データ、たとえば、数営業日、週、月、「四半期」（たとえばおよそ３か月の期間）、年、会計期間、投資循環などといった拡張期間にわたって、観察され、規定され、測定され、算出されるなどしたビジネスの状況の記録を含むやり方、技術などに従って判定されるが、当業者はこのことを本明細書の記載を読んで理解するであろう。ビジネスの状況はしたがって、拡張期間にわたって収集されるか、観察されるか、または他の方法で取得され、「過去の」ビジネス状況データのリポジトリに任意にコンパイルされる。

過去のデータは、任意の既知または有益な規約に従って、体系化、細分化などされ得る。たとえば、過去のビジネス状況データは、月または会計期間によって年代順に体系化され、地理的な場所（たとえばビジネス領域、法域、国など）に従ってさらに体系化され得る。当然、過去のデータは、任意の数の基準、構造などに従って体系化されてもよく、当業者はこのことを本明細書の記載を読んで理解するであろう。

ビジネス状況データを利用して、いくつかのアプローチでは、本明細書で開示される技術は、たとえば（当業者はこのことを本明細書の記載を読んで理解するであろうが、あらかじめ規定されたビジネスおよび／または統計モデル、過去のビジネス状況データに基づくモデル、標準モデルなどといった）モデルを利用して連続シミュレーションを行ない得る。

より一層好ましいアプローチでは、連続シミュレーションは、過去のビジネス状況データおよび現在のビジネス状況データを利用して、ビジネスプロセスの連続シミュレーションを行ない、ビジネスプロセスシミュレーション中に過去のビジネス状況データを用いて、所期のまたは所望のシミュレーション進行からの偏差を検出する（たとえば、１つの典型的なシナリオで上述した所期のＰＲＯＦＩＴ ＭＡＲＧＩＮにおける偏差といった、１つ以上のデータポイント、メトリック、分析などに従ってビジネスモデルからの偏差を検出する）。シミュレーションに基づき、１つ以上の可能な現実世界のビジネスシナリオがシミュレーションされてもよく、様々な潜在的な応答（処置を全く講じないこと、たとえば無応答を含む）の影響が実験的にテストされ、観察され、かつ評価されて、意思決定主体がビジネスの方針を理解し、連続シミュレーションによってモデル化された様々な仮説のシナリオに誘導することを支援し得る。

所期のまたは所望のシミュレーション進行からの偏差は、任意の好適な技術に従って検出されかつ／または測定され得る。たとえば、あるアプローチでは、偏差が、しきい値で具体化され、過去のビジネス状況情報に基づいて所定のまたは動的に判定された量だけ離れる、ビジネスの状況を判定する間に測定される特定の値（たとえば収益）などにしきい値が合致するかまたはそれを上回ると検出され得る。一種のビジネス状況情報として収益を含む典型的なアプローチでは、対応するシミュレーションされたビジネス収益が、あるアプローチにおいて約１０％以上の大きさだけ過去のデータから離れる場合は常に、過去のビジネス状況データからの偏差がシミュレーションの間に検出され得る。

たとえば、収益は過去の収益の９０％以下に落下する（つまり、収益は過去に観察された収益より１０％以上低い）か、または過去の収益の１１０％に増加し得（つまり収益は過去に観察された収益よりも１０％高い）、シミュレーションはこの偏差の検出に応じて１つ以上の処置を講じ得る。一実施形態では、シミュレーションは、当業者がビジネス状況情報を再検討し、観察された偏差につながる１つ以上の貢献要因または原因となるプロセスをそこから判定することを可能にするのに十分なやり方で、ビジネス状況情報と、上記ビジネス状況情報（たとえば販売活動、購入または請求活動、投資活動、税金、罰金などといった法的活動）に能動的に影響を及ぼす任意のビジネスプロセスに関する情報とを含むログを生成し得る。

当然、シミュレーションは、いくつかの実施形態では人間の介入を伴わなくてもよく、シミュレーション数列が測定され得る複数のあらかじめ規定された基準またはしきい値を含んでもよい。自動システムは、満足されている、合格しているなどのあらかじめ規定された基準またはしきい値のうちの１つ以上の存在の検出に応じて所定の処置などを講ずるように構成され得る。このように、様々なビジネスプロセス開発戦略は過去のビジネス情報に経験的に基づいてテストされ得、知的な選択は、特定のコンテキストにおいて（つまり過去のビジネス状況情報によって反映される具体的な事実の下で）所与の手順の成功または失敗に基づいて実行され得る。

したがって、一実施形態では、連続シミュレーションは図５に示されるように方法５００に従って行なわれ得る。当該方法は、当業者が本明細書の記載を読んで理解するであろう任意の他の環境のうち、図１〜図３に表されたものを含む任意の好適な環境において行なわれ得る。

方法５００は、動作５０２〜５０８を含む。動作５０２において、ビジネスの現在状況を表す１つ以上のシード値が、たとえば本明細書に記載される分散アーキテクチャの１つ以上のリソースにおいて受信される。

動作５０４では、所定の期間にわたるビジネスの複数の過去の状況を表す過去のビジネス状況データが、再び好ましくは１つ以上の分散アーキテクチャリソースにおいて受信される。

動作５０６において、（たとえば分散アーキテクチャの）少なくとも１つのプロセッサを用いて、１つ以上のビジネスプロセスが、過去のビジネス状況データに基づく１つ以上のシード値およびモデルを利用して連続的にシミュレーションされる。

動作５０８では、シミュレーションにおける所期の数列からの偏差が検出される。一般に、偏差は、モデルおよび／または過去のビジネス状況データにおいて表わされる過去の挙動からの著しい相違に対応する。偏差はしきい値として具体化されてもよく、非標準的なイベント（たとえばシミュレーションされたシステムが経た状況またはプロセス）を表す。そのような非標準的なイベントは、リスク、責任、損失への露出を生じさせる場合があるか、または逆に重要なビジネスチャンスを表す場合があり、したがって、本明細書で開示される連続シミュレーションおよび偏差検出技術といった客観的基準を用いて認識するためは相当に有益である。

当然、様々な実施形態において、本明細書に開示される連続シミュレーションの実施形態
方法は、追加的にかつ／または代替的に、シミュレーションにおける所期の数列からの偏差の検出に対するユーザ入力を受信することと、１つ以上のシード値、モデル、およびユーザ入力に基づいて、ビジネスの状況における変化をシミュレーションすることとをさらに含み得る。

好ましくは、偏差は、ビジネスのシミュレーションされた状況を表す特定の値が、しきい値偏差より大きな量だけビジネスの１つ以上の過去のビジネス状況を表す対応する値から離れているとの判定に応じて検出される。

特にシード値および偏差が利益率を表す場合であるが、任意の好適な実施形態では、しきい値偏差は約１０％である。いくつかのアプローチでは、シード値の少なくとも１つおよび偏差は各々、ビジネスの状況に対応する利益率を表す。

方法は、追加的にかつ／または代替的に、シミュレーションにおける所期の数列からの偏差の検出に対する入力を自動的に受信することと、１つ以上のシード値、モデル、および入力に基づいて、ビジネスの状況における変化をシミュレーションすることを含む。そのようなシナリオでは、入力は、偏差への有効な応答であると過去に判定された所定の応答を含む。

様々なアプローチでは、本明細書で開示される発明概念はサービスまたはサービスプラットフォームの形態で提供され得る。たとえば、一実施形態では、技術は、以下で「ＩＮＳＩＧＨＴ（登録商標）」または「Ａｌｔｏｓｏｆｔ ＩＮＳＩＧＨＴ（Ｒ）」と称されるビジネスインテリジェンスプラットフォームの形態を取り得る。下記の説明は、たとえば「ｉｓ」、「ａｒｅ」、「ｄｏｅｓ」、「ｗｉｌｌ」、「ｓｈａｌｌ」などの用語の使用によって、「ＩＮＳＩＧＨＴ（Ｒ）」の実施形態が明確に１つ以上の特徴または機能を含むものとして述べているが、各特徴の典型的な説明は例示として提示され、任意の好適な組合せ、置換、サブセットなどで組合せてもよいことが理解されるべきであり、当業者はこのことを本明細書の記載を読んで理解するであろう。

ＩＮＳＩＧＨＴ（Ｒ）は、他のＢＩツールの時間の数分の１で組織がブラウザベースの分析を導入することを可能にする企業クラスのビジネスインテリジェンス（ＢＩ）プラットフォームである。複数のソース全体にわたるデータの統合から、特徴に富んだダッシュボードのドラッグアンドドロップ作成への高度な変換および分析まで、ＩＮＳＩＧＨＴ（Ｒ）は以前は可能ではなかったスケーラビリティおよび性能を提供するプラットフォーム上のすべてにＢＩをアクセス可能にする。

使用しやすさおよび迅速な導入は妥協を意味しない。ＩＮＳＩＧＨＴ（Ｒ）は、ＢＩをプロセスインテリジェンスによって新しいレベル−関連するビジネスプロセスのコンテキストでデータを理解する能力に到達させる。結果は、動作有効性を容易に測定し、プロセスコンプライアンスを監視することができる点で、プロセス性能の明確なエンドツーエンドの可視性を与える。

異なるベンダーからの複数のツールを必要とするＢＩアプローチとは異なり、ＩＮＳＩＧＨＴ（Ｒ）は、ユーザがすべて単一プラットフォームからのビジネス活動に迅速にアクセスし、分析し、最適化することを可能にする。ＩＮＳＩＧＨＴ（Ｒ）上に構築された排他的なＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）分散インメモリアーキテクチャはほぼリアルタイムでソースシステムから情報を抽出し、無限のスケーラビリティによって高速計算を行ない、データのサイズまたはユーザの数にかかわらず最も最新かつ完全な情報をユーザが有することを確実にすることができる。

ＩＮＳＩＧＨＴ（Ｒ）は、動作性能向上およびデータ可視化のための高度な機能を与えつつ、従来のＢＩ解決策のコストおよび複雑さを排除する。ＩＮＳＩＧＨＴ（Ｒ）は、すべてのＢＩニーズのための包括的なプラットフォームである。

プロセスインテリジェンス
組織の成功は、それがどれくらい好都合にそのビジネスプロセスを管理するかに直接結び付けられる。そのプロセスを効果的に管理することは、それらがどのように行なわれるかという品質およびタイミングを理解することを必要とする。プロセスインテリジェンス、ビジネスプロセスのコンテキストにおけるデータ分析は、ＢＩのパワーを進歩させる際の次の進化のステップである。

データおよびメトリックをビジネスプロセス中のステップにつなげることにより、プロセスインテリジェンスは、プロセスとそれらが表す動作がどのように作用しているかを理解するのに必要な洞察をもたらし、組織の規定上のコンプライアンスを危険にさらし得るボトルネックおよびプロセス例外を発見することができる。サービスレベル合意（ＳＬＡ）または他の性能義務への遵守を監視することができる。ごく単純に、プロセスインテリジェンスは、他のＢＩツールでは可能ではないクエリに答えるのに必要な重要なコンテキストを与える。

プロセスインテリジェンスは、挑戦または機会を提示し得る将来の状態を予測するのに役立つこともできる。ＩＮＳＩＧＨＴ（Ｒ）の連続シミュレーション予測分析エンジンは、監視されているプロセスに基づいて動作予測を提供する。予測は、収集されている実際の動作データに基づいて連続的に更新され改良され、より高い精度をもたらす。ＩＮＳＩＧＨＴ（Ｒ）のアプローチは、過去のパターンへの突然の変更の影響を検出し予想することと、最新の状態に基づいてプロセスモデルおよび動作前提を動的に改良することとによって、従来の統計および静的プロセスモデルベースの予測の制約を克服する。

Ｎｏ Ｃｏｄｅ Ｅｖｅｒ
ＩＮＳＩＧＨＴ（Ｒ）の単一プラットフォームアプローチの重要な利点は、企業パワーを損なうことなくすべての符号化を排除することができる点である。ＳＱＬも、プログラミングも、任意の種類のスクリプト化も、まったく必要とされない。これにより、データにアクセスし分析する権限が、組織のニーズを理解する態勢が最も整っている人々の手に委ねられることが確実となる。ＩＮＳＩＧＨＴ（Ｒ）によれば、ＢＩ解決策の構築および導入は、直感的なポイントアンドクリックインターフェイスを用いた構成作業に単純化される。

強力かつ個人化されたＵＩ
ＩＮＳＩＧＨＴ（Ｒ）は、強力なＵＩを作成する能力をユーザに提供する。厳密なレポートまたはダッシュボードのためのこれ以上の解決はない。チャート種類を容易に変更し、表とチャートとを切り替え、直感的なピボットテーブル機能を用いてデータを操作し、詳細までドリルダウンする。すべてＩＴからの変更を要求する必要はない。ＩＮＳＩＧＨＴ（Ｒ）は、カスタムナビゲーションおよび他の豊富なインタラクションを含むブラウザベースのドラッグアンドドロップインターフェイスにより数分で豊富なダッシュボード展開を可能にして、データ発見プロセスを最適化する。

ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）マルチサーバ、インメモリ設計
ＩＮＳＩＧＨＴ（Ｒ）の ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）技術は、インメモリ処理の速度を、分散されるインメモリモデルのスケーラビリティおよび自由度と組合せることによって、迅速に拡大するデータボリュームと高速データ発見の要求とに対処するように設計される。第１世代のインメモリＢＩプロダクトは単一サーバ上のメモリに限定され、各ユーザについて最大で１０％の追加的なオーバーヘッドを必要とするが、ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、ＩＮＳＩＧＨＴ（Ｒ）がこれらの制約を克服することを可能にする。

ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）を用いると、組織は、任意の物理的または仮想的なサーバ上で利用可能なメモリおよびＣＰＵを知的に使用することによって単一サーバのリソース制約を越えて拡大することができる。ＭＡＰＡＧＧＲＥＧＡＴＥ（Ｒ）は、ユーザごとのオーバーヘッドも排除し、それにより、使用されるすべての利用可能なメモリがユーザの数に関係なく、より大きなデータボリュームを扱うことを可能にする。

支配データの発見
ＩＮＳＩＧＨＴ（Ｒ）は、データ発見によって約束されるエンドユーザの権限付与をサポートしつつＩＴ組織の支配要求を満たすように設計される。ＩＴ介入を必要とすることなく非ＩＴユーザがダッシュボードおよびレポートを設計し導入することを可能にしつつ、ＩＴリソースが共有サーバリソースを一元的に構成し、管理し、監視することを可能にするように設計される。

支配データ発見解決策としてのＩＮＳＩＧＨＴ（Ｒ）の導入を容易にするために、ＩＮＳＩＧＨＴ（Ｒ）プラットフォームは様々な導入プションをサポートする。これは、エンドユーザによって独立して作成され操作されることができる多くの個々のプロジェクトをサポートすることができる、ＩＴによって支配される単一の導入されたＩＮＳＩＧＨＴ（Ｒ）インスタンスを構成する能力を含む。

導入の自由度
単一プラットフォームは、はるかに高速の実装も意味する。ＩＮＳＩＧＨＴ（Ｒ）の顧客は、多くのＢＩイニシアチブよりもはるかに速い２〜４週間で典型的に動作可能である。また、机上ではビジネスは生じないため、ＩＮＳＩＧＨＴ（Ｒ）はブラウザにより任意の装置上のダッシュボードへのアクセスを提供する。データは必要な時に必要な場所で入手可能である。オフラインである場合、プラットフォームは、危険な状態について電子メールまたはメッセージングによってユーザに警告することもできる。

一実施形態では、方法は、ビジネスまたはビジネスプロセスに関連するデータを受信することと、メタデータモデルに従って受信データを処理することとを含み、処理することは、複数のデータ部分の各々に対応するメタデータを生成することを含み、方法はさらに、データ部分に対応するメタデータに少なくとも部分的に基づいて、受信データを複数のデータ部分に分割することと、複数のデータ部分の各々および各それぞれのデータ部分に対応するメタデータを分散アーキテクチャに配置された複数のリソース全体にわたって分散することとを含む。メタデータモデルは、データを記述する特徴、すなわちセマンティック特徴と、抜粋、変換、負荷（ＥＴＬ）特徴と、使用法の特徴とを含む。方法は、データのいくつかまたはすべてに関連するリクエストを受信することと、複数のリソースのうちの１つ以上に対するリクエストを、リクエストにおけるメタデータに基づいて分散アーキテクチャにマッピングすることと、リクエストのマッピングに応じて、複数のリソースの各々から１つ以上の応答を受信することと、１つ以上の応答を処理してレポートを生成することと、リクエストが受信されたリソースにレポートを返すこととをさらに含む。レポートは、好ましくはデータ、メトリック、およびリクエストのうち１つ以上に少なくとも部分的に基づく。その上、各データ部分は、受信データのすべての他のデータ部分と重複しない少なくとも１つの特徴によって特徴付けられ得る。各データ部分は、好ましくは少なくとも１つのメタデータラベルと関連付けられる。リクエストは、好ましくはリクエストが関連するデータに対応するメタデータを含む。有利に、マッピングは、リクエストに関連するデータサービスが存在する少なくとも１つのリソースにリクエストを伝える。方法は、１つ以上の応答を集約する前にデータの場所を判定することも含み得る。データロケーションは、「インメモリ」であるかまたは「アーカイブ」のいずれかである。データロケーション「アーカイブ」は、現在「インメモリ」ではない分散アーキテクチャの記憶装置か、または現在「インメモリ」ではないデータベース管理システム（ＤＢＭＳ）における格納場所のいずれかである。好ましくは、データロケーションが「インメモリ」であると判定された場合、処理は、データロケーションが「インメモリ」であるとの判定に応じて直接行なわれる。一方、データロケーションが「アーカイブ」であると判定された場合、処理は、データロケーションが「アーカイブ」であるとの判定に応じて１つ以上のクエリを生成することと、クエリを実行することとを含み、クエリは、「アーカイブ」データロケーションからデータを検索するように構成され、さらに方法は、データロケーション「アーカイブ」から検索したデータをメモリにローディングすることと、ローディングに応じてデータロケーションが「インメモリ」であると判定することと、データロケーションが「インメモリ」であるとの判定に直接応じて、「インメモリ」データを集約することとを含む。方法は、データに基づいて１つ以上のメトリックを算出することも含み得る。

前述の典型的な方法と共に有利に使用され得る別の実施形態は、ビジネスの現在状況を表す１つ以上のシード値を受信することと、所定の期間にわたるビジネスの複数の過去の状況を表す過去のビジネス状況データを受信することと、少なくとも１つのプロセッサを用いて、過去のビジネス状況データに基づく１つ以上のシード値およびモデルを利用する１つ以上のビジネスプロセスを連続的にシミュレーションすることと、シミュレーションにおいて所期の数列からの偏差を検出することとを含む。方法は、シミュレーションにおける所期の数列からの偏差の検出に対するユーザ入力を受信することと、１つ以上のシード値、モデル、およびユーザ入力に基づいて、ビジネスの状況における変化をシミュレーションすることとをさらに含み得る。追加的にかつ／または代替的に、方法は、シミュレーションにおける所期の数列からの偏差の検出に対する入力を自動的に受信することを含み、入力は、偏差に対する有効な応答であると過去に判定された所定の応答を含み、方法はさらに、１つ以上のシード値、モデル、および入力に基づいて、ビジネスの状況における変化をシミュレーションすることを含み得る。好ましくは、シミュレーションされたビジネスの状況を表す特定の値がしきい値偏差より大きな量だけ１つ以上の過去のビジネスの状況を表す対応する値から離れているとの判定に応じて偏差が検出される。特に好ましくは、しきい値偏差が約１０％であり、シード値の少なくとも１つおよび偏差が各々ビジネスの状況に対応する利益率を表す実施形態を含む。

以上さまざまな実施形態が説明されているが、これら実施形態は限定ではなく専ら例示のために示されていることが理解されるべきである。各個々の発明概念と、本明細書に開示されているかまたは本明細書の記載を読んで本明細書で説明した概念の均等物であると当業者が理解するであろう任意の変形例を、任意の好適なやり方で組合せてもよい。したがって、これらの発明の開示を読んで当業者が理解するであろう任意の並べ替え、組合せ、置換、合成、変更、または他の変形例は発明の範囲内にあるものと理解されるべきである。

よって、本発明の実施形態の広さおよび範囲は、上記代表的な実施形態のいずれによっても限定されてはならず、以下の請求項およびこれらの均等物に従ってのみ定義されるべきものである。

発明の概要
本明細書で開示される発明概念は概して、分散システムアーキテクチャ全体にわたるデータの管理のための、スケーラブルなビジネスインテリジェンスおよび分析に関連し、シームレスで効率的な技術、システムおよびコンピュータプログラムプロダクトを提供する。データは、それに関係して／関連してデータが収集され、生成され、もたらされ、取得されるビジネスプロセスに関連するビジネスインテリジェンスおよび／または予測的分析を決定し、提供するという特定の目的のために管理される。

当然、様々な実施形態において、本明細書に開示される連続シミュレーションの実施形態は、本明細書に開示された追加的なおよび／または代替的な特徴のいかなる組み合わせもも含み得る。
方法は、追加的にかつ／または代替的に、シミュレーションにおける所期の数列からの偏差の検出に対するユーザ入力を受信することと、１つ以上のシード値、モデル、およびユーザ入力に基づいて、ビジネスの状況における変化をシミュレーションすることとをさらに含み得る。

Claims (20)

1. ビジネスまたはビジネスプロセスに関連するデータを受信することと、
   メタデータモデルに従って受信データを処理することとを含み、前記処理することは、複数のデータ部分の各々に対応するメタデータを生成することを含み、前記方法はさらに、
   前記データ部分に対応する前記メタデータに少なくとも部分的に基づいて、前記受信データを前記複数のデータ部分に分割することと、
   前記複数のデータ部分の各々および各それぞれのデータ部分に対応する前記メタデータを分散アーキテクチャに配置された複数のリソース全体にわたって分散することとを含み、
   前記メタデータモデルは、前記データを記述する特徴を備え、前記特徴は、
   セマンティック特徴と、
   抜粋、変換、負荷（ＥＴＬ）特徴と、
   使用法の特徴とを含む、方法。
2. データのいくつかまたはすべてに関連するリクエストを受信することと、
   前記複数のリソースのうちの１つ以上に対するリクエストを、前記リクエストにおけるメタデータに基づいて前記分散アーキテクチャにマッピングすることと、
   前記リクエストのマッピングに応じて、前記複数のリソースの各々から１つ以上の応答を受信することと、
   前記１つ以上の応答を処理してレポートを生成することと、
   前記リクエストが受信されたリソースに前記レポートを返すこととをさらに含む、請求項１に記載の方法。
3. 前記リクエストは、前記リクエストが関連する前記データに対応するメタデータを含む、請求項２に記載の方法。
4. 前記マッピングは、前記リクエストに関連するデータサービスが存在する少なくとも１つのリソースに前記リクエストを伝える、請求項２に記載の方法。
5. 前記１つ以上の応答を集約する前に前記データの場所を判定することをさらに含み、前記データロケーションは、「インメモリ」であるかまたは「アーカイブ」のいずれかである、請求項２に記載の方法。
6. 前記データロケーション「アーカイブ」は、現在「インメモリ」ではない前記分散アーキテクチャの記憶装置か、または現在「インメモリ」ではないデータベース管理システム（ＤＢＭＳ）における格納場所のいずれかである、請求項５に記載の方法。
7. 前記データロケーションは「インメモリ」であると判定され、
   前記処理は、前記データロケーションが「インメモリ」であるとの判定に応じて直接行なわれる、請求項６に記載の方法。
8. 前記データロケーションが「アーカイブ」であるとの判定に応じて１つ以上のクエリを生成することと、
   前記クエリを実行することとをさらに含み、前記クエリは、前記「アーカイブ」データロケーションから前記データを検索するように構成される、請求項６に記載の方法。
9. 前記データロケーション「アーカイブ」から検索された前記データをメモリにローディングすることと、
   前記ローディングに応じて前記データロケーションが「インメモリ」であると判定することと、
   前記データロケーションが「インメモリ」であるとの判定に直接応じて、前記「インメモリ」データを集約することとをさらに含む、請求項８に記載の方法。
10. 前記データに基づいて１つ以上のメトリックを算出することをさらに含む、請求項９に記載の方法。
11. 前記レポートは、前記データ、前記メトリック、および前記リクエストのうち１つ以上に少なくとも部分的に基づく、請求項１０に記載の方法。
12. 前記データに基づいて１つ以上のメトリックを算出することをさらに含み、前記レポートは、前記データ、前記メトリック、および前記リクエストのうち１つ以上に少なくとも部分的に基づく、請求項２に記載の方法。
13. 各データ部分は、前記受信データのすべての他のデータ部分と重複しない少なくとも１つの特徴によって特徴付けられ、
    各データ部分は、少なくとも１つのメタデータラベルと関連付けられる、請求項１に記載の方法。
14. ビジネスの現在状況を表す１つ以上のシード値を受信することと、
    所定の期間にわたるビジネスの複数の過去の状況を表す過去のビジネス状況データを受信することと、
    少なくとも１つのプロセッサを用いて、前記過去のビジネス状況データに基づく前記１つ以上のシード値およびモデルを利用する１つ以上のビジネスプロセスを連続的にシミュレーションすることと、
    前記シミュレーションにおいて所期の数列からの偏差を検出することとを含む、方法。
15. 前記シミュレーションにおける前記所期の数列からの前記偏差の検出に対するユーザ入力を受信することと、
    前記１つ以上のシード値、前記モデル、および前記ユーザ入力に基づいて、前記ビジネスの状況における変化をシミュレーションすることとをさらに含む、請求項１４に記載の方法。
16. 前記偏差は、前記ビジネスのシミュレーションされた状況を表す特定の値が、しきい値偏差より大きな量だけ前記ビジネスの１つ以上の過去のビジネス状況を表す対応する値から離れているとの判定に応じて検出される、請求項１４に記載の方法。
17. 前記しきい値偏差は約１０％である、請求項１６に記載の方法。
18. 前記シード値のうちの少なくとも１つおよび前記偏差は各々、前記ビジネスの状況に対応する利益率を表す、請求項１４に記載の方法。
19. 前記シミュレーションにおける前記所期の数列からの前記偏差の検出に対する入力を自動的に受信することを含み、前記入力は、前記偏差に対する有効な応答であると過去に判定された所定の応答を含み、前記方法はさらに、
    前記１つ以上のシード値、前記モデル、および前記入力に基づいて、前記ビジネスの状況における変化をシミュレーションすることを含む、請求項１４に記載の方法。
20. コンピュータ読取可能なプログラム命令が包含されたコンピュータ読取可能な記録媒体を含むコンピュータプログラムプロダクトであって、前記コンピュータ読取可能なプログラム命令は、実行されると少なくとも１つのプロセッサに、
    ビジネスまたはビジネスプロセスに関連するデータを受信させ、
    前記受信データをメタデータモデルに従って処理させ、前記処理は、複数のデータ部分の各々に対応するメタデータを生成することを含み、さらに、
    前記データ部分に対応する前記メタデータに少なくとも部分的に基づいて、前記受信データを前記複数のデータ部分に分割させ、
    前記複数のデータ部分の各々および各それぞれのデータ部分に対応する前記メタデータを、分散アーキテクチャに配置された複数のリソース全体にわたって分散させ、
    前記メタデータモデルは、前記データを記述する特徴を含み、前記特徴は、
    セマンティック特徴と、
    抜粋、変換、負荷（ＥＴＬ）特徴と、
    使用法の特徴とを含む、コンピュータプログラムプロダクト。