DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

前回のテーマ“疎結合アーキテクチャへの転換”に続いて、今回は基幹系ビジネスシステムにおける“疎結合アーキテクチャの具体例”とはどのようなものかについて述べてみたい。説明は物理データモデルを用いる。

最初にＳＣＭ（サプライチェーン管理）と棚卸資産（製商品、半製品、原材料等）管理の組み合わせシステムに焦点を考えてみたい。どちらも受発注や生産といった企業内の“取引イベント”が出発点となるが、前者は物流、後者は会計とそれぞれ目的が異なる管理システムである。図１のデータモデルをクリック拡大して見ていただきたい。

モデルＡが密結合モデル、モデルＢが疎結合モデルである。モデルＡは、“受払明細イベント”と“在庫残高“の２つのエンティティからなる１つの密結合モデルである。ちなみに在庫エンティティの主ＫＥＹは拠点コード＋品目コード＋ロットNoであり、物流と会計の両機能を兼ねている。このモデルの特徴は、受払明細イベントの発生と同時に在庫残高エンティティにある数量、金額など全関連項目がリアルタイムで更新され、データの一貫性が保証されるところにある。ただし、１つに汎化された在庫残高エンティティは、ロット別在庫、品目別在庫、在庫金額など、実態はそれぞれ異なる粒度（実際のＫＥＹ）のエンティティの集まりであることから、その更新ロジックは簡単ではない。”在庫（評価）金額“に至っては、棚卸資産の評価法に基づく複雑なロジックが組み込まれる。

モデルＢは、受払管理と棚卸資産管理の２つのサブシステムから構成される疎結合モデルである。受払管理サブシステムでは、“受払明細エンティティ“の更新と同時にリアルタイムで”物流在庫エンティティ“が更新される。そして、もう１つの棚卸資産管理サブシステムでは、同様の”受払明細エンティティ“を非同期で再利用して、”会計在庫エンティティ”を必要なタイミングで更新する。このモデルの特徴は、同一の“受払明細エンティティ”を更新トランザクションとして用い、粒度も更新タイミングも異なるそれぞれの残高エンティティを別々に更新するところにある。物流在庫と会計在庫の両エンティティが“緩やかにシンクロナイズする”疎結合モデルということになる。

　もう１つの例として受発注管理に債権債務（売掛金、買掛金）管理を加えた組み合わせシステム（図２）を見ていただきたい。モデルＣが密結合モデル、モデルＤが疎結合モデルである。

モデルＣは“受発注明細”、“入出金明細”の２つのイベント系エンティティと、”債権債務残高”エンティティからなる密結合モデルである。一方のモデルＤは受発注管理と債権債務管理の２つのサブシステムからなる疎結合モデルであり、受発注明細エンティティの登録更新と、受発注明細の一部を非同期で再利用した債権債務増減明細、及び入出金明細、の両エンティティによる債権債務残高の更新は完全に非同期である。

さて、２つの例を見てみたが、果たして密結合／疎結合どちらのモデルを選択すべきであろうか？まず上記の２つのケースで共通して疑問視されるのが会計廻りのリアルタイム性である。そもそも会計はある一定期間内でビジネスを評価するもの。概念的にリアルタイムに遷移していても、現実のデータ把握は年、四半期、月単位が通常で、最小でも日単位で十分である。しかし“システムモデル”としてはどちらもアリである。

ビジネスの規模が小さくかつ要件が複雑でない場合は、密結合モデルのＥＲＰを標準仕様で使うことで早期導入、保守外注が可能となりビジネスのＲＯＩが得られるかもしれない。しかし、大規模かつ複雑になってくると、レスポンス確保やトラブル連鎖防止に備えたテスト工程の増大、複数個所の同時改修の難しさ等から、ビジネス・アジリティへ追従できなくなってくる。一方の疎結合モデルは、トラブルのサブシステム内封じ込み、個別機能の同時並行改修が可能になるとともに、不必要なデータ更新によるオーバーヘッドが少ないので、レスポンス問題も少ない。ある規模を越えると疎結合モデルが圧倒的にアジリティとコストの両面で勝るといえる。ただし、疎結合モデルでは他システム（他人）が生成したトランザクションデータを再利用することになるので、厳密なデータの定義が必須となる。

ＩＴアーキテクチャはビジネスと表裏一体である。ビジネスの進展をＩＴで下支えするために、アーキテクチャ・モデルは最も重要な設計要素の１つである。