» 【156号】 3階層通信場アーキテクチャの考察

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【156号】 3階層通信場アーキテクチャの考察

■3階層通信場
先の155号でDOA的SOAの前提として、3階層通信場を提案しました。スパ
ゲッティ化を避けるとき、プロセス間の直接的通信はなくなり、n個のプロセスが
やり取りするメッセージを集め、データの標準化を行い、その結果できる通信場を
共用するDOAの通信形式になります。これを
 L1:個別アプリ内
 L2:個別アプリ間(全社、注1)
 L3:企業間
のように分類したわけです。L1では生産、販売、経理など個性的なデータを扱う。
L2では品物やお金の残高など、経営リソースの有効活用の鍵を握るデータを扱う。
L3には企業の利害に係るネゴマターが含まれる。このため4階層、5階層などい
ろいろな考え方があるとしても、3階層がやはり最も本質的なものである、と考え
たのです。

注1:大手エンジニアリング会社の場合は、ここは全社でなく1プロジェクト全体
となる。

またメッセージの中で用語の役割を果たすリソースデータ(取引先や製商品など)
は、「システム広辞苑」とも言うべき通信の要であり、原則としてL2ないしL3
とすべきものと考えました。ここでL3のリソースとは、業界標準の商品や組織な
どの情報であり、将来的にはサプライヤーが公開し、ユーザは仮想的にこれにアク
セスできるため、自社DBに取り込む必要がなくなると予想されるものです。一方、
いわゆるアプリケーションパッケージにはL1のリソースデータが含まれますが、
これは他との通信において変換を必要とする、今MDMとして課題になっている
データです。

■通信場の5分類
したがって、3階層の通信場(DH:Data Hub)をリソース系とイベント系に分け、
これらをR、Eとして示すと(R1DHは除かれるので)、
 R2DH、R3DH、E1DH、E2DH、E3DH
ように5つに分類でき、E1DHについてはさらに生産、販売、経理などと、個別
アプリごとに分類されると考えられます。全社標準化を進めることによって、企業
内は将来R2DHとE2DHに統一できるとしても、当面はレガシーの継続活用、
パッケージの導入などにより、各種標準間の変換を行いながら運用せざるを得ない
ものと考えます。

通信場通信においては、プロセスのオペレーションは参照も更新も、DHに対して
行われます。参照の場合はメッセージ種別を指定する定型、また個別に属性を指定
する不定型、いずれの場合も、正しく該当する標準を選択することのほか、特別の
配慮は不要なので、以下更新の場合について考察するものとします。

■事例研究
更新の事例として、購買システムにおける「発注」を考えましょう。そのメッセー
ジは次のような形をしているものとします(スペース節約のため省略記号を使いま
す)。

発注:[発#]-(仕入先#、品#、 @、数量、¥、  納期、  届先#、・・・)
     123    S15   P01  5  10  50  9日15時  F4

このデータが購買DB(E1DH)にストアされるわけですが、同時に整合性保障
のため、次のようなデータを生成し、先日付在庫および仕入先に対する買掛残を更
新すべきとします。

先日付在庫:[品#. 倉庫#. 締時]-(初残、末残、安全残、残チェック)
          P01. F4. 9日18時   30  40   20  0(正常)

買掛残  :[仕入先#. 締時]-(初残、末残、残チェック)
         S15. 9日24時  100  150  0(正常)

そしてこれらは、他の生産や経理システムからも更新されるデータですから、E2
DHにストアされるべきと考えます。これらはE2DHの言わば全社標準のデータ
ですから、購買システムが独自の標準を採用している場合は、形式についてはメタ
データの、また値についてはリソースの、変換テーブルに基づく変換を行ってから
更新をかけることになります。

また、発注データは仕入先に届けるべく、E3DHにストアされます。E3DHは
種々のイベントデータの行き交う企業間通信場ですから、次のようにメッセージの
KEYに宛先、イベント種別(E種)、発番箇所を補う必要があります。

発注MSG:[宛先.E種.発番箇所.発#]-(仕入先#、品#、・・・)
        S15 発注 TB02  123    S15   P01

この発注MSGは、宛先が適時E3DHをスキャンして入手するか、ワークフロー
機能に委託して入手し処理することになります。いずれにしても、E3DHの標準
によるデータですから、形式や値に関して、自らの標準に変換する必要があります。
この発注MSGは仕入先によって処理され、回答の形でE3DHに戻ってきます。
これを入手した購買アプリは先日付在庫や買掛残を予定から確定に変えてE2DH
にストアすることになります(以下省略)。

■統一的なミドルウエアで裁く
このように3階層通信場アーキテクチャでは、アプリ間のメッセージは所定の通信
場に属するものとすることによって、整合性管理、標準変換、配信などの処理を統
一的なミドルウエアで裁き、簡素化と高信頼性を実現するものと考えます。これに
よって従来、「製品在庫を販売システムと生産システムの両方で抱え、厄介なオペ
レーションを行っていた」などの問題は未然に防げるのではないでしょうか。また、
大手企業の力によるEDI通信場が、このようなE3DHに容易にシフトするとは
考えられませんが、通信場先行のDOA的アーキテクチャの特徴を理解しておくこ
との重要性が、今後増大してくると考えます。

3階層通信場アーキテクチャのイメージ理解のために、製造業の基幹システムが経
営・経理・購買・生産・販売からなるものとし、これらの間、およびサプライ
チェーン先A、B、C、・・・との間にどのような通信場が形成されるかを描いて
みます。

      経営  経理
       |  |
       E2DH(社内アプリ間通信場)
      /  | \
     購買 生産 販売
       \   /
        E3DH(企業間通信場)
         /||\
       A B C ・・・

理解しやすくするために、単純化していますが、3階層通信場アーキテクチャの本
質は表現できているように思われます。通信場アーキテクチャがいかにあるべきか
は、まだ今後の検討を要する課題ですが、これに言及しないで済ませる問題ではな
いと考えます。EAやSOAの成果を実りあるものにするための前提として提案し
たいと考えました。

追伸:
発注を事例としたため、E2DHでは在庫引当型通信、E3DHでは要求回答型通
信が登場しました。しかし、E2DHでも販売が特殊仕様の製品を生産に依頼する
場合は、要求回答型通信が、またE3DHでも座席予約のような場合は在庫引当型
通信が登場すると考えられます。このほかE2DHには、月次販売・生産・購買計
画数量のような多部門にまたがる経営計画を追跡するデータが所属します。個別ア
プリのインターフェースとなるE2DHのデータおよびこの加工元データは、多く
の企業においてまだ可視化されていないように見えますが、経営の役割と部門の役
割の関係を明快に示すための、今後の課題かと思われます。