エージェント指向のアーキテクチャ
PSLXフォーラムが提案するAPSを実装していくためには、分散的で、頑強（ロバスト）で、ダイナミックで、かつ、進化可能な新しいタイプの情報システムが必要となります。そのためには、以下のようなエージェント指向の情報システムアーキテクチャが有効です。このアーキテクチャでは、製造業全体の意思決定を実施するシステムは、複数の部分システムをその内部に持っています。それらのサブシステムが自律的かつ主体的に振舞うことで、総体としての全体システムがその機能を実現するというモデルがエージェント指向のアーキテクチャです。
上の図において、各サブシステムを、ここでは、業務エージェント（業務請負組織）と呼ぶことにします。各業務エージェントは、経営企画、利益管理、需給調整、生産計画、工程管理、設計開発、技術管理、品質管理、保守管理、受注管理、発注管理、出荷管理、入荷管理、在庫管理といった、４章で定義した業務機能パッケージの単位、あるいはより詳細な単位である業務機能ブロックの単位で定義することができます。また、同一の機能パッケージや機能ブロックであっても、物理的空間が離れている場合や、経営組織的に一体とならない部分は、別エージェントとすることができます。このように、APSを構成するエージェントの単位は、個々の製造業の状況に応じて、調整されることになります。
ここで定義される業務エージェント（業務請負組織）は、いわゆるソフトウェアエージェントとは異なり、担当者である人間もその構成要素としている点が特徴です。つまり、経営的にみた場合のまとまった意思決定の単位が業務エージェントであり、その内部は人間であってもコンピュータであってもかまいません。業務エージェント間は、それぞれメッセージ交換によって、必要な情報のやりとりを行います。これは、計算機ネットワーク上での情報の送受信である場合、共通ＤＢを介したデータの受け渡しである場合、そして、もちろん、計算機を用いない会話や紙ベースの帳票による場合もあります。
業務エージェント（業務請負組織）として必要な要件としては、各エージェントは担当する業務に対する知識をもっていて、しかるべき情報処理あるいは情報加工サービスを行うことができるという点です。ただし、依頼人は、業務エージェントの業務実行のための詳細な手段については知る必要はありません。また、業務エージェントは他の業務エージェントが提供可能なサービスについての知識をもっており、必要に応じて他の業務エージェントに自分の作業の一部を依頼することもできるものとします。
図で示したモデルで重要な点は、各業務エージェントは、それぞれ外部との情報交換用に、あらかじめ相手に対して公開したインタフェースを持つという点です。そして、交換する情報もまた、あらかじめ相手との間で合意された構造によって、合意された“意味”を表現したものでなければなりません。これにより、個々のサブシステムの数、あるいは業務エージェント数に応じて、N×Nの数の仕様を決定するのではなく、あらかじめ策定した仕様に、各サブシステムあるいは業務エージェントが合わせることで、インタフェースの調整のための負担が軽減できます。本仕様書で規定する業務アクティビティモデルや業務オブジェクトモデルでは、これらの意味情報を規定しています。また、具体的な実装レベルでのインタフェースは、本仕様書第5部のXMLスキーマや第6部のRDBスキーマによって規定されています。
従来型のシステムアーキテクチャと比較した場合のエージェント指向のアーキテクチャの特徴は、そこでは業務エージェント内部の構造や業務手順がすべて隠蔽されていることです。これによって、エンタープライズモデルとしては、企業全体の複雑な業務手順を飛躍的に単純化して捉えることができます。企業全体のレベルで見た場合、それぞれのエージェントがどのような業務を行えるのかを知り、そしてそれらの業務を依頼するためにはどうしたらよいのかを知っていれば十分です。そして、それらを定義するための情報として第2部で、業務アクティビティモデルが規定されています。企業の担当者が行うべきことは、これらのエージェントの機能を、さまざまビジネス環境に応じてどのように組み合わせるかというオーケストレーション（楽団の編成）とその指揮となります。