覚書 – 基幹システム連携の難しさ

前書き

SF構築において基幹システム連携が要件として挙がると、難易度が跳ね上がることが多い。

前提

基幹システム（いわゆるコーポレートIT）はビジネスITと異なり、機能拡張よりも安定稼働が圧倒的に重視される。

そのため、外部システム（ビジネスIT側）の要件に合わせて基幹システム（コーポレートIT）に改修を加えることは一般に困難である。

難しいポイント

• データの持ち方
  • 基幹のマスタデータが崩壊している場合、①SFの構築とは別にマスタデータを整備する②マスタデータ側の不備をSF側の計算ロジックなどで巻き取る、などの対応が必要となる
• 業務
  • 基幹システムが絡むと少なくとも「基幹システムが必要とするデータを適切な形式・タイミングで連携する」ことが必要となるため、基幹システムに合わせる形で（SF上で業務が遂行できるよう）SFをカスタム開発する要件がしばしば発生する
• データ連携
  • 広義でのTransformが必要
    • 事前計算された値の入力が前提されている場合、計算ロジックの開発が必要
    • Entityの構成が異なる場合、レコードの分割や統合が必要
    • 基幹→SFの連携の場合、SFではレコードIDしか外部キーになれないので、親→子の投入順序が必ず何かしらの仕方で担保されている必要がある

困難をどう乗り越えるか

端的に言って、「システムアーキテクチャ」の最適化が必要である。とりわけ以下。

• データモデリングの最適化
• Transformの最適化
• データおよびテーブルのメンテナンス

最適化の要点

• 同種のTransformは、システムアーキテクチャを通して一度だけなされるべきである（DRY原則）
  • システムA→ERP←システムBという構成で同種のデータ連携がなされている場合、TransformがシステムAとシステムBの二箇所で（＝複数箇所で）行われることはアンチパターンである。
  • Transformの統一化は具体的な構成としては色々あるがパターンはほぼ同じで、①データ形式の統一化②ビジネス処理という流れを取る
    • ①ERPのインターフェースに合わせてデータ形式を変換して流す②EPR内部で処理
    • ①DWHにデータを変換した上で流す②DWH内部でdbtなどを用いて処理
    • ①Mulesoftの最初のレイヤでデータ形式を共有化②ビジネスレイヤで処理