相互運用可能な情報システムのアーキテクチャ

相互運用可能な情報システムのアーキテクチャ (AIOS)は、相互運用可能な企業情報システムの開発のための参照アーキテクチャです。企業や行政機関が他の組織と自動化されたビジネス プロセスに関与する場合、IT システムが連携して動作できる必要があり、つまり相互運用可能である必要があります。AIOS は、これらの組織が内部情報システムを体系的に調整および拡張することによって相互運用可能な情報システムを開発するための一般的な構築計画を表しています。AIOS は博士論文で説明されており、相互運用性に関するさまざまな研究プロジェクトの結果に基づいています。^{[ 1 ]}特定の製品やベンダーとは独立していますが、相互運用可能な情報システムを効率的に構築するために必要なさまざまなレイヤー、ビュー、関係、および技術的手段を一般的に説明しています。この目的のために、サービス指向アーキテクチャ、協調ビジネス、およびビジネス プロセス モデリングの概念を組み合わせています。これは、内部情報システムおよびビジネス プロセスのよく知られたアーキテクチャであるARISを補完するものと見なすことができます。

組織内部のプロセス自動化と同様に、組織横断的なビジネスプロセスの自動化も重要なトレンドです。この取り組みにおいて、連携する組織は、情報システムの緊密な統合ではなく、むしろ疎結合を目指します。つまり、連携する情報システムは互いに連携しながらも、可能な限り独立性を維持する必要があります。この特性は相互運用性、あるいは連携する組織の文脈ではビジネス相互運用性、すなわち自律的な組織が相互に連携したビジネスプロセスを実行できる能力とも呼ばれます。

情報システムとは、情報を処理するシステム、つまり情報を収集、転送、変換、保存、提供するシステムのことです。情報システム研究で主流となっている概念によれば、情報システムは企業のハードウェアとソフトウェアだけでなく、関連する人間の行為者、ビジネス機能とプロセス、組織構造も含みます。 ^{[ 2 ]}この広範な理解は、例えばザックマンフレームワークにも体現されています。

アーキテクチャは、「システムの基本的な組織であり、その構成要素、それらの相互関係および環境との関係、そしてその設計と進化を規定する原則に具現化される」と定義される。 ^{[ 3 ]} Sinzは、情報システムアーキテクチャを、情報システムの構成要素とその関係をすべての関連する視点から記述し、構築計画を作成するための構築ルールも含むという意味で、情報システムの構築計画と定義している。 ^{[ 4 ]}

したがって、相互運用可能な情報システムのアーキテクチャとは、組織間で協調的なビジネスプロセスを実行できるようにする、組織横断的な情報システムの構築計画と定義できる。

^{2010年に欧州研究プロジェクト[ 5 ]}で実施された相互運用可能な情報システムに関する研究を受けて、相互運用可能な情報システムのアーキテクチャ（AIOS）が、疎結合で相互運用可能な情報システムの構築と、協調的なビジネスプロセスの体系的かつモデルベースの実行のための参照として公開されました。

AIOSは、主に相互運用性を求める大規模組織を対象としています。この目的のために、AIOSは内部情報システム要素を協力パートナーの情報システムと体系的に接続する方法を説明しています。AIOSの主な要素は以下のとおりです。

1. 相互運用可能な情報システムを構成するさまざまなデータタイプとその関係性について説明します。これは静的部分、またはアーキテクチャの構造とも呼ばれます。組織がコラボレーションパートナーに提供する必要のある情報要素（メッセージの説明、交換シーケンス、役割、サービスなど）と、それらを内部要素と最適に関連付ける方法を示します。
2. 相互運用可能な情報システムを実装または調整するための、さまざまな構築パスの説明。これはアーキテクチャの動的部分とも呼ばれます。組織に対し、上述の要素を反復的に開発する方法を示します。
3. アーキテクチャを実装するために必要な技術コンポーネントのコンセプト。例えば、設計ツール、内部および外部からアクセス可能なリポジトリなど。

第3のカテゴリに含まれる要素の1つは「BIIリポジトリ」であり、各組織はそこで自社のビジネス相互運用性インターフェース（BII）の内容をコラボレーションパートナーに公開します。情報システム要素の外部ビューが含まれているため、サービス指向アーキテクチャで必要とされる公開機能と検索機能を提供します。BIIでは、外部に関連するプロセス、サービス、組織構造などがさまざまな技術的粒度で記述されているため、他の組織は技術的な成果物だけでなく、ビジネスレベルの要素も検索できます。ここでは、従来のSOAアプローチとは異なり、中央のサービスディレクトリの代わりに、さまざまなパートナー固有のリポジ​​トリが実装されています。

アーキテクチャの静的な部分は、企業規模、技術的粒度レベル、およびコラボレーションビューという3つの直交軸に基づいて構築されています。

企業規模

ビジネスプロセスを包括的に記述するために、この軸はプロセス、機能、データ、組織要素に関する明確な視点を提供する。

1. 組織的側面では、コラボレーションに関連する役割、部門、その他の組織要素が記述され、内部要素と関連付けられます。これにより、例えば、コラボレーションのパートナー間で相互の役割について共通理解が確保されます。
2. データ次元では、コラボレーションで使用される文書タイプが定義され、内部で使用される文書タイプに関連付けられます。
3. 機能面では、コラボレーションにおいて提供されるビジネス機能とサービスについて説明します。
4. プロセス面では、各組織が提供するプロセス、およびこれらの公開プロセスが提携組織の関連プロセスとどのように関連しているかが記述されます。

このように、「協調的な視点」という軸と組み合わせることで、 プロセス、機能、データ、組織上の役割に関する、プライベート、パブリック、グローバルな視点が提供される。

技術的な詳細度

さまざまな技術的粒度レベルでのシステム要素の説明は、ビジネス要件の定義からコードレベルに至るまで、協調型情報システムの体系的な開発をサポートします。構築面だけでなく、多次元的な相互運用性の説明も提供され、各レベルでの協調システムの同期が容易になります。例えば、ARISやOMGのMDAと同様に、 3つのレベルが使用されます。

1. ビジネスレベル：ここでは、自動化対象となるプロセスが、技術に依存しないレベルで記述されます。MDAでは、このレベルはCIMレベルと呼ばれます。
2. 技術レベル：ここではITコンセプトが記述されます。そのため、第1レベルのモデルは技術的に拡張され、例えば、ビジネス機能の代わりにコンポーネントが記述されますが、依然として粗粒度の概念レベルにとどまります。第2レベルのモデルは実行可能コードの自動生成の基盤となるため、実装レベルの制約に合わせてさらに調整する必要がある場合があります。
3. 実行レベル：ここでは、モデルは機械が解釈可能であり、プロセスの実行時に実行時に使用できます。